step by step guide for Windows 2003 Server and MIT Kerberos trust?
jaltman2 at nyc.rr.com
Thu Jun 10 09:41:42 EDT 2004
Douglas E. Engert wrote:
> The AD should know what types are acceptable to the SERVER and select one
> of these which is in the list provided by the client, or ignore the client or fail.
This is correct.
> I have seen cases where one has had to add a extra entry to the keytab file with
> enctype for des-cbc-md5 even though there was a entry for des-cbc-crc.
> This may stem for the fact that AD stores a password and can generate a key for any
> enctype from it, where as MIT and Heimdal store the keys when added be kadmin
> and might be different keys.
> It could also stem from AD assuming DES is DES and if you have a key for
> des-cbc-crc you have the key for des-cbc-md5. I don't think the MIT or Heimdal
> code if it fails to find a keytab entry for des-cbc-md5 will try and look for a des-cbc-crc
> key. This only makes sense if you also assume the DES key would be the same. With AD
> this is the case, with MIT or Heimdal it is not.
This is exactly what is happening. Active Directory contains a password
and a set of string to key algorithms. The Microsoft version of
Kerberos will always generate keys on the fly.
I will be interested to see what Microsoft chooses to do when they add
new enctypes for AES.
> The point being that if you upgrade from 2000 to 2003 you may have to add additional
> keytab entries.
> Another issue is that 2003 stores a KVNO and will return it rather then just 0 or 1
> used be 2000. So you may need to add other keytab entries with the correct KVNO. .
This is another reason why I like the cross-realm solution for managing
non-Windows services. Let Active Directory manage the Windows based
services and an MIT KDC manage the non-Windows services. Use
cross-realm between the two to obtain the service tickets for the
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu
More information about the Kerberos