DES vs DES3 problem

[Monica Lau]

Hi all,

I have a KDC client (luke) that is trying to authenticate with the KDC server.  The client is expecting a DES session key encryption type.  However, the server is issuing a DES3 session key.  So, the client doesn't like the key and constantly ask the KDC server for a new key.  (This problem occurs on both the KDCs that have been ported to Linux and the Lynx OS.)  I have these lines in the krb.conf and kdc.conf files:

krb.conf:

default_tgs_enctypes = des-cbc-crc 
default_tkt_enctypes = des-cbc-crc 

kdc.conf:

supported_enctypes = des-cbc-crc:normal 
kdc_supported_enctypes = des-cbc-crc:normal 

Does anyone know why the KDC would constantly send DES3 session key when we specified that we want DES?  Here's the log message from the krb5kdc.log file:

Jul 19 12:09:49 mlau krb5kdc[65](info): AS_REQ (1 etypes {1}) Client's_IP(39
848): ISSUE: authtime 1027105789, etypes {rep=1 tkt=1 ses=1}, luke at REALMNAME
 for krbtgt at REALMNAME
Jul 19 12:09:49 mlau krb5kdc[65](info): DISPATCH: repeated (retransmitted?) re
quest from 0.0.0.0 port 39848, resending previous response
Jul 19 12:09:49 mlau krb5kdc[65](info): DISPATCH: repeated (retransmitted?) re
quest from 0.0.0.0 port 39848, resending previous response
Jul 19 12:09:49 mlau krb5kdc[65](info): DISPATCH: repeated (retransmitted?) re
quest from 0.0.0.0 port 39848, resending previous response
Jul 19 12:09:49 mlau krb5kdc[65](info): DISPATCH: repeated (retransmitted?) re
quest from 0.0.0.0 port 39848, resending previous response
Jul 19 12:09:49 mlau krb5kdc[65](info): DISPATCH: repeated (retransmitted?) re
quest from 0.0.0.0 port 39848, resending previous response
Jul 19 12:09:49 mlau krb5kdc[65](info): DISPATCH: repeated (retransmitted?) re
quest from 0.0.0.0 port 39848, resending previous response 

Any pointers or suggestions would really be a great help and very much appreciated!  Thanks for your time and help.

Sincerely,

Monica



---------------------------------
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/kerberos/attachments/20020719/7e572204/attachment.htm