samba keytab support for AD and kinit -k

[Sam Hartman]

>>>>> "Rakesh" == Rakesh Patel <rapatel at optonline.net> writes:

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

    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> In the case of UNIX host
    Rakesh> keytabs, it is not unusual to attempt to use the host key
    Rakesh> as a primary authentication mechanism, though not an
    Rakesh> optimal or appropriate mechanism, it is occasionally
    Rakesh> utilized using kinit -k.  

When acting as the computer itself, it is both optimal and appropriate.

    Rakesh> For example, years back, I used
    Rakesh> it to create a dedicated credentials cache for nss_ldap
    Rakesh> (and nscd) on Solaris without having to create a separate
    Rakesh> keytab to be maintained.  

This is actually a very appropriate use of the host principal.

    Rakesh> The problem is that the version
    Rakesh> I just tested with on Fedora Core 3 + all updates
    Rakesh> (samba-3.0.8-0.pre1.3), registers a UPN using the short
    Rakesh> host name and generates the keys in /etc/krb5.keytab using
    Rakesh> FQDNs. This means the kinit -k option is unusable, as
    Rakesh> specifying "kinit -k host/SHN at REALM" (SHN = Short Host
    Rakesh> Name) will return an error indicating the key is not in
    Rakesh> the keytab, while "kinit -k host/FQDN at REALM" will return
    Rakesh> from the KDC as client not found.  I was able to correct
    Rakesh> this by setting the UPN to be the same as the entry in
    Rakesh> /etc/krb5.keytab and it addressed the issue.  Given that
    Rakesh> Windows does not utilize a UPN at all for hosts joined to
    Rakesh> a domain and the only reason we may have added the UPN is
    Rakesh> to permit the host key to be used for authentication, is
    Rakesh> there any reason we can't use the FQDN for the UPN?  I
    Rakesh> recall seeing some discussions on that a long time ago,
    Rakesh> but was distracted at the time.

Samba's handling of short names and Kerberos principals seems
different than the Microsoft tools and tends to work much less of the
time.  IT would be great to see it more consistent with the Windows
domain join procedure.
--Sam