samba keytab support for AD and kinit -k

[Rakesh Patel]

Sam Hartman wrote:

>>>>>>"Bob" ==   <Bob.Smart at csiro.au> writes:
>>>>>>            
>>>>>>
>
>    Bob> Unfortunately when I test it with "kinit -k" it says "can't
>    Bob> find KDC".  An ordinary kinit works.
>
>You actually need kinit -k principalname
>
>So run klist -k, find the principal name and kinit -k with that
>principal.
>
>--Sam
>  
>

The issue is that in the Windows KDC, an SPN can not be used as a "user" 
for authentication
and computers normally do not contain a UPN entry.  In the case of UNIX 
host keytabs, it is
not unusual to attempt to use the host key as a primary authentication 
mechanism, though
not an optimal or appropriate mechanism, it is occasionally utilized 
using kinit -k.  For example,
years back, I used it to create a dedicated credentials cache for 
nss_ldap (and nscd) on Solaris
without having to create a separate keytab to be maintained.   The 
problem is that the version
I just tested with on Fedora Core 3 + all updates 
(samba-3.0.8-0.pre1.3), registers a UPN
using the short host name and generates the keys in /etc/krb5.keytab 
using FQDNs. This
means the kinit -k option is unusable, as specifying "kinit -k 
host/SHN at REALM" (SHN = Short Host Name) will
return an error indicating the key is not in the keytab, while "kinit -k 
host/FQDN at REALM" will
return from the KDC as client not found.  I was able to correct this by 
setting the UPN
to be the same as the entry in /etc/krb5.keytab and it addressed the 
issue.  Given that Windows
does not utilize a UPN at all for hosts joined to a domain and the only 
reason we may have
added the UPN is to permit the host key to be used for authentication, 
is there any reason
we can't use the FQDN for the UPN?   I recall seeing some discussions on 
that a long time
ago, but was distracted at the time.

An additional item I forget to mention - we had coded the "net ads 
keytab create" function to leave
old verions in place in case someone had an active credentials cache 
with that version, however no
functionality was added to clean the old version up.  There were early 
stabs at addressing that,
but we dropped the code at the time.  I believe it is not unreasonable 
to provide options to "net ads keytab"
to flush old entries. 

There were also concerns about managing other service specific keys in 
the host keytab,
but that adds complexity not to mention that they probably should be in 
their own keytab files with separate
permissions (preferably non-root).   The advantages of using Samba 
utilities to manage that when
participating in a Windows KDC are numerous.  Maybe I will have to make 
some time for more code
contributions to help address that, though the issue of UPN vs. SPN 
comes into play again if one
needs to seed a credentials cache with the service key used as the 
primary (user) authenticator.

Rakesh Patel.