[22916] in Kerberos
Re: samba keytab support for AD and kinit -k
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sun Nov 28 19:47:28 2004
To: Rakesh Patel <rapatel@optonline.net>
From: Sam Hartman <hartmans@MIT.EDU>
Date: Sun, 28 Nov 2004 19:44:58 -0500
In-Reply-To: <41AA650D.1080901@optonline.net> (Rakesh Patel's message of
"Sun, 28 Nov 2004 18:53:49 -0500")
Message-ID: <87vfbp5vqt.fsf@luminous.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
cc: samba-technical@lists.samba.org
cc: bob.smart@csiro.au
cc: kerberos@MIT.EDU
Errors-To: kerberos-bounces@MIT.EDU
>>>>> "Rakesh" == Rakesh Patel <rapatel@optonline.net> writes:
Rakesh> Sam Hartman wrote:
>>>>>>> "Bob" == <Bob.Smart@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@REALM" (SHN = Short Host
Rakesh> Name) will return an error indicating the key is not in
Rakesh> the keytab, while "kinit -k host/FQDN@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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
