summaries krb5 keytab requirements

Gerald (Jerry) Carter jerry at samba.org
Fri May 19 17:34:55 GMT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave,

> 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 ?

> Salt is case sensitive. In the Windows world SPNs and 
> UPNs are not. You can't assume that if someone types
> in aDmInIsTrator at foo.com 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:
http://marc.theaimsgroup.com/?l=samba-technical&m=110005392723944&w=2

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.

>> SPN values
>> =========
>> The CIFS/machine principal name is unnecessary in AD (even though
>> clients ask for it): http://support.microsoft.com/kb/326985/en-us
> 
> 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/webserver1.microsoft.com to perform an HTTP
	connection to the Web server on the webserver1.microsoft.com
	server, but this SPN is not registered on the server,
	the Windows 2000 domain controller will automatically
	map it to HOST/webserver1.microsoft.com. 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.

http://marc.theaimsgroup.com/?l=samba-technical&m=110005392723944&w=2




- -- cheers, jerry

$ cat ~/.signature
=====================================================================
Samba                                    ------- http://www.samba.org
Centeris                         -----------  http://www.centeris.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFEbgG+IR7qMdg1EfYRAn7wAKDLWxrxJknzmpDWCXmwPULTeGWC3gCgk1Ev
XdD9sMH4aksm1HEoKAe/sxY=
=iTIk
-----END PGP SIGNATURE-----


More information about the samba-technical mailing list