[22933] in Kerberos
Re: samba keytab support for AD and kinit -k
daemon@ATHENA.MIT.EDU (Rakesh Patel)
Mon Nov 29 21:37:57 2004
Date: Mon, 29 Nov 2004 20:37:29 -0500
From: Rakesh Patel <rapatel@optonline.net>
In-reply-to: <87653p5ixm.fsf@luminous.mit.edu>
To: Sam Hartman <hartmans@mit.edu>
Message-id: <41ABCED9.80807@optonline.net>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
cc: samba-technical@lists.samba.org
cc: bob.smart@csiro.au
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
Sam Hartman wrote:
>>>>>>"Rakesh" == Rakesh Patel <rapatel@optonline.net> writes:
>>>>>>
>>>>>>
>
> Rakesh> Just limiting below to the main issue [note that I had not
> Rakesh> encountered this before when we went through various
> Rakesh> stages of testing the keytab management changes].
>
> Rakesh> Sam Hartman wrote:
>
> Rakesh> The issue is that in the Windows KDC, an SPN can not be
> Rakesh> used as a "user" for authentication and computers normally
> Rakesh> do not contain a UPN entry.
> >> That is not my understanding of the Microsoft KDC
> >> architecture. This claim also goes against interoperability
> >> tests I have conducted with Microsoft.
> >>
> >>
> >>
>
> Rakesh> I have a machine "rockylinux" (FC3 - samba-3.0.8-0.pre1.3
> Rakesh> package) joined to an AD/2003 domain running Windows2003
> Rakesh> as the DC.
>To clarify, what I meant here is simply that my experience is that
>Windows machine accounts created by Windows tend to be set up to allow
>the principal to be used both for inbound and outbound authentication.
>Samba may well do something different.
>
>--Sam
>
>
We are both correct. There is no UPN defined for a computer joined to
an AD domain by default (at least not for an XP
workstation as I have in my test). However the SAM account name is used
as an authenticator - I was able to verify
that both the XP client and Samba client (rockylinux) were asked for a
password when ising "kinit {the SAM account entry in AD}".
If a service principal name is used, the client is not found unless that
matches a defined UPN or SAM account name.
Either way, the lack of UPN matching the host/{fdqn}@REALM entry is an
issue on the UNIX side (at least
for 3.0.8) - will have to test 3.0.9 to see if it was addressed in all
the fixes that were implemented.
Rocky.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
