samba keytab support for AD and kinit -k

[Rakesh Patel]

Rakesh Patel wrote:

> 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.

Unfortunately it looks like 3.0.9, while providing the host services 
that use the keytab with all combinations of
keytab entries to match the Windows 2003/AD SPN and UPN combinations, 
does not address this issue.  The UPN
is still registered as HOST/{short-host-name}@REALM, and a normal kinit 
-k  will not succeed because the KDC
does not accept the use of the SPN for an initial authentication.   I 
understand there is a way under Windows to
map SPNs to user accounts (UPNs), but I'm not sure how to accomplish 
that. Maybe we can accomplish this when
we create the LDAP entry in AD?   That might be a better alternative 
than changing the UPN to HOST/{fqdn}@REALM
if it may cause any problems.

Rocky.