step by step guide for Windows 2003 Server and MIT Kerberos trust?

[Jeffrey Altman]

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 
non-Windows services.

-- 
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu