samba keytab support for AD and kinit -k
Rakesh Patel
rapatel at optonline.net
Mon Nov 29 20:37:29 EST 2004
Sam Hartman wrote:
>>>>>>"Rakesh" == Rakesh Patel <rapatel at 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.
More information about the Kerberos
mailing list