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