summaries krb5 keytab requirements

Dave Daugherty dave.daugherty at
Fri May 19 18:57:39 GMT 2006

From: Gerald (Jerry) Carter [mailto:jerry at] 
Sent: Friday, May 19, 2006 10:35 AM


>> The bit is for "use DES only", but DES keys are 
>> still honored. Some applications such as Oracle
>> and MIT's Kerberized telnet only use DES,
>> and will fail if the salted DES keys are not in 
>> the keytab.

>Let me restart this and see if you agree.

>* MIT krb5 telnet client tries to connect to a Unix server
>  joined to an AD domain.
>* The telnet client requests a service tkt for host/fqdn.
>* The service tkt is encrypted with the strongest key
>  stored for the principal in the realm (RC4-HMAC unless
>  the UF_USE_DES_KEY_ONLY is set).
>* The client sends an AP_REQ containing the service tkt.
>* When decrypting the service ticket, we use RC4-HMAC
>  unless we have specifically configured the machine account
>  for DES only.
>* The AP_REP uses the strongest enctype supported by the
>  client and server (in this case, the telnet client only
>  supports DES) to encrypt the client's new session key.

>And this is why we still need the DES keys in /etc/krb5.keytab,
>correct ?

That is my understanding.

>> Salt is case sensitive. In the Windows world SPNs and 
>> UPNs are not. You can't assume that if someone types
>> in aDmInIsTrator at then that is what the salt
>> should be.
>> Computer account salt is not the same as User salt, 
>> and the computer account salting rules are different
>> for Win2k and Win2k3 (Win2K will use the UPN host/name at REALM
>> if it is present), hence the net ads join code to guess
>> what salt should be used.

>Simple question.  Are you saying Luke's analysis is wrong:

Talking just about the computer account...

No. I read that he did his testing on Win2k3, and that on Win2k3 we
agree that the UPN has no effect on the salt.

BTW yesterday one of my associates tried to repro Luke's results on
Win2k and was not able to.  I did not follow up on this yet.

>But that still doesn't make sense as to why we guess.  We should be
>able to deduce without a large set of loopy code.

I think more knowledge is now available since the original salting code
implementations were done.  So more educated guesses could be made.  Or
if you do not want to guess, I think you can use our Kerberos
modifications to recover the salt off the wire.

>> SPN values
>> =========
>> The CIFS/machine principal name is unnecessary in AD (even though
>> clients ask for it):
>> On the other hand other apps want things like HTTP/... and FTP/...

> True.  While these would be necessary in the keytab for other
> services (Samba internally might be able to do some canonicalization),
> they apparently do not have to be present in the SPN list for the
> machine in AD.  Hence why I listed the KB article:

>	"Note that you do not have to register all services.
>	Many service types, such as HTTP, W3SVC, WWW, RPC, CIFS
>	(file access), WINS, and uninterruptible power supply
>	(UPS), will map to a default service type named HOST.
>	For example, if your client software uses an SPN of
>	HTTP/ to perform an HTTP
>	connection to the Web server on the
>	server, but this SPN is not registered on the server,
>	the Windows 2000 domain controller will automatically
>	map it to HOST/ This mapping
>	applies only if the Web service is running under the
>	local System account."

>>  I think Samba could live without UPN on a computer account, 
>>  but it should live with it if it is there (i.e. Win2k Computer
>>  Account - UPN determines the salt).

> This is the second time at least that you've mentioned this.
> What you are saying about the UPN being used for the salt
> contradicts Luke's mail.  I can run my own tests of course,
> but are you sure that Luke's analysis is incorrect ?  His
> research says that the UPN is only used in the salt for user
> objects.  Not computer accounts.


Nope I think Luke and I agree WRT Win2k3 and computer account salt. It's
only Win2k that tries to use UPN.

More information about the samba-technical mailing list