Sam Hartman wrote:

>>>>>>"Bob" == 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@REALM" (SHN = Short Host Name) will
return an error indicating the key is not in the keytab, while "kinit -k
host/FQDN@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.