[OpenAFS] Windows auth against Kerb5

[David Botsch]

We decided to get the des-cbc-md5:normal a run to see if that worked 
with Windows.

It almost works. There seems to be some weirdness in the 
support_enctypes in kdc.conf...

   kdc_supported_enctypes = des3-cbc-sha1:normal des3-hmac-sha1:normal 
des-cbc-crc:afs3 des-cbc-crc:normal des-cbc-md5:normal
   supported_enctypes = des3-cbc-sha1:normal des3-hmac-sha1:normal 
des-cbc-crc:afs3 des-cbc-crc:normal des-cbc-md5:normal

However, if after restart krb5kdc and kadmind, I change the password of 
a user, I get the following:

Number of keys: 3
Key: vno 19, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 19, DES cbc mode with CRC-32, AFS version 3
Key: vno 19, DES cbc mode with CRC-32, no salt


Now, if I rearrange the order of those some (in kdc.conf), I do get the 
des-cbc-md5 key but am then missing one or more of the other key:salt 
combos.

On 2004.06.18 12:07 Jeffrey Altman wrote:
> I recommend you add support either for RC4-HMAC keys to your 
> principals.
> RC4-HMAC keys will be the first enctype in the list from Windows 
> clients.
> The second enctype in the list will be DES-CBC-MD5; followed by 
> DES-CBC-CRC.
> 
> Jeffrey Altman
> 
> 
> David Botsch wrote:
> 
>> So, we've migrated our kaserver to kerb5 (yay!).
>> 
>> Now, what we'd like to do is to get Windows systems to be able to 
>> authenticate
>> against kerberos 5. To maintain compatibility with clients out 
>> there, we still
>> have users with AFS salted keys. So, a user's entry might look like:
>> 
>> kadmin:  getprinc bozo
>> Principal: bozo@MSC.CORNELL.EDU
>> Expiration date: [never]
>> Last password change: Thu Jun 17 18:20:45 EDT 2004
>> Password expiration date: [none]
>> Maximum ticket life: 30 days 00:00:00
>> Maximum renewable life: 30 days 00:00:00
>> Last modified: Thu Jun 17 18:20:45 EDT 2004 Last successful 
>> authentication: [never]
>> Last failed authentication: [never]
>> Failed password attempts: 0
>> Number of keys: 3
>> Key: vno 12, Triple DES cbc mode with HMAC/sha1, no salt
>> Key: vno 12, DES cbc mode with CRC-32, AFS version 3
>> Key: vno 12, DES cbc mode with CRC-32, no salt
>> Attributes:
>> Policy: [none]
>> 
>> 
>> Now, I've been told that this is just an unordered collection of 
>> keys. Yet,
>> somehow, it seems that in the case of windows, whatever happens to 
>> be the first
>> one is the only one that's tried (Windows doesn't specify which one 
>> it wants
>> and so the server just returns the first one in its list and auth 
>> fails?).
>> 
>> So, other than my hacking up create user and change password scripts 
>> to do
>> something like "-e des-cbc-crc:normal des-cbc-crc:v4 
>> des3-cbc-sha1:normal" so
>> that this unordered collection is in an order that Windows works, is 
>> the only
>> solution to sacrifice all other keys so that the one Windows likes 
>> is the only
>> one there?
>> 
>> Thanks!
>> 
>> 

-- 
********************************
David William Botsch
Consultant/Advisor II
CCMR Computing Facility
dwb7@ccmr.cornell.edu
********************************