[PATCH] heimdal fixes for the new keytab code

[Rakesh Patel]

Gerald (Jerry) Carter wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Wed, 7 Jul 2004, Rakesh Patel wrote:
>
>  
>
>>I'm not sure what spns are created in AD from the latest version of the
>>patch, however the host keytab always needs host/fqdn at REALM for normal
>>kerberos clients to function. When joining the machine to the AD domain,
>>    
>>
>
>The problem is the different that than is needed for the keytab service 
>principal and the one apparently that can be used for kinit.
>
>  
>

I'm not sure what you are referring to. Are you referring to the need for
alternate entries such as ldap/fqdn at REALM in the krb5 keytab and having
to change/update it along with host/fqdn at REALM when a changetrustpw is done?
If so, there were some modifications I had done to support updating the
keys, however it was based upon detecting the appropriate service keys
by updating all */fdqn at REALM entries in the keytab. Unfortunately this
was not an ideal solution and it interfered with the support for preserving
the previous key version in the keytab for any active sessions utlizing
the "old" service key version number.

>>AD has a large number of automatic "aliases" for the machines principal
>>name and either pregenerates each version of the key or most likely
>>dynamically generates the kerberos key. SPNs such as "host$",
>>"HOST/machine", etc. are part of that list. It is an AD attribute and I
>>have seen it in the past - the list of acceptable SPNs is lengthy.
>>
>>Since Samba code automatically handles requests in a similar manner by
>>using the password from secrets.tdb, it does not need to worry about
>>which SPNs need to be added to the system keytab.
>>    
>>
>
>It seems that you can only perform SASL binds using the userPrincipalName 
>value and not the servicePrincipalName.  At least that's what my tests 
>seemed to imply.
>
>  
>
It has been a few months since I was performing the initial testing and 
looked at
both upn and spn values during the testing process. However my 
assumption would
be that user accounts utilize a upn and computers would utilize an spn.
Note that I just overheard someone saying that upns do not exist if you 
upgrade
an NT 4.0 DC to Windows200x, but do if you create a user via the AD 
Users & Computers mmc.

>The other curious thing is that a normal XP box joined to the domain does 
>not have the (optional) userPrincipalName attribure.  Only the 
>servicePrincipalName.  So I'm assuming the difference is due to the 
>userAccountFlags we set but I haven't had time to track that down yet
>to be 100% certain.
>
>  
>
All computers (workstations, member servers) have a host key generated 
when they
join the domain, hence a service key exists for each computer, so a 
servicePrincipalName would
seem to make the most sense. Of course when you access a file share 
using kerberos credentials
and smbclient, the windows file server uses hostname$@REALM where 
hostname is the non-fqdn (short)
version for the hostname (lowercased NetBIOS name). smbclient supports 
whatever the server returns,
so when I had the use of host/fqdn at REALM extensively used in early 
versions of the patch,
smbd used host/fdqn at REALM and hence the smbclient would obtain service 
keys for host/fqdn at REALM
instead of shorthostname$@REALM.  Now those extensive changes have been 
backed out of. I will
test the latest release to see what service keys are utilized.

>>As far as a later question about CIFS/machine - I am not sure where that
>>came from. I suggest checking a registered file server to see if
>>CIFS/machine is one of the SPNs for any file servers. If not, that
>>should probably be removed. I don't recall the name of the attribute
>>listing the "aliases" for the SPN, but the values for that attribute
>>should also be checked in case CIFS is listed in there.
>>    
>>
>
>I haven't found it anywhere so far.  Still looking though.
>
>
>
>
>
>
>cheers, jerry
>- ----------------------------------------------------------------------
>Hewlett-Packard            ------------------------- http://www.hp.com
>SAMBA Team                 ---------------------- http://www.samba.org
>GnuPG Key                  ---- http://www.plainjoe.org/gpg_public.asc
>"...a hundred billion castaways looking for a home." ----------- Sting 
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.0 (GNU/Linux)
>Comment: For info see http://quantumlab.net/pine_privacy_guard/
>
>iD8DBQFA7LqdIR7qMdg1EfYRAjhqAJwMc3F4CJr5kKEdB2D3o+9dQRKetwCeJra4
>CWqIQ9WgvK1tr96UDgTdkYg=
>=x4Jc
>-----END PGP SIGNATURE-----
>  
>