[PATCH] keytab management for ADS mode.
rapatel at optonline.net
Tue Jan 27 11:09:44 GMT 2004
The issue with Microsoft using aliases I encountered in testing the full
and the smb clients will utilize whatever principal the server provides.
When smbclient connects to
smbd, it is told to use a host/machine-fqdn at REALM principal, but when an
XP desktop connects, it
uses cifs/machine-fqdn at REALM, so we generate both cifs/machine at REALM and
host/machine at REALM
principals. When XP communicates with a win2K file server, the NetBIOS
naming is used (machine$@REALM)
and the MS KDC of course maps it to host/machine at REALM, but issues it as
machine$@REALM - I believe it
does not pre-generate all aliased keys, but merely stores the unicode
password and generates the key on the fly
since the principal name is a component of the kerberos key generation
process if I recall correctly.
At some point, I will fix the patch so that smbclient uses
cifs/machine at REALM just like the XP client
does when communicating with smbd (both clients utilize the NetBIOS
naming to a MS file server), but
host/machine at REALM is not a serious concern since it is a valid
principal, but cifs would be the proper
principal to use just as ldap/machine at REALM is utilized for AD.
Thanks for the info on Heimdal!
>Rakesh Patel <rapatel at optonline.net> writes:
>>While it may seem drastic to expect the host principal to be
>>re-created and managed through Samba, it
>>may be the best approach given it would be for a Win2K/AD environment
>>with just the KDC externalized.
>>I am assuming that MIT/Heimdal now support the same password changing
>>protocol supported by Microsoft.
>Heimdal will support ms change password protocol whenever 0.7 is released.
>There is another problem with using keytab's to store longterm
>credentials. Since microsoft have aliasing on the principal names
>(host/computer at realm, HOST/computer at realm, computer$@REALM all the same),
>that needs to be taken into account.
More information about the samba-technical