We are authenticating users on AD server 2k3, and the users are setup in AD to use DES (checked "Use DES encryption types for this account" in user properties). It failed somehow with ETYPE_NOSUPP. From the packet capture, I can find KRB5 AS-REQ contains des-cbc-crc/des-cbc-md5/des-cbc-md4 as encryption types. This is the request: ++++++++++ REQUEST ++++++++++++++++ Kerberos AS-REQ Pvno: 5 MSG Type: AS-REQ (10) padata: PA-ENC-TIMESTAMP Type: PA-ENC-TIMESTAMP (2) Value: 303ba003020117a2340432482d36ca7556ebf719421fc8b4... rc4-hmac Encryption type: rc4-hmac (23) enc PA_ENC_TIMESTAMP: 482d36ca7556ebf719421fc8b4530cfea187d35318fd63bd... KDC_REQ_BODY Padding: 0 KDCOptions: 00000010 (Renewable OK) .0.. .... .... .... .... .... .... .... = Forwardable: Do NOT use forwardable tickets ..0. .... .... .... .... .... .... .... = Forwarded: This is NOT a forwarded ticket ...0 .... .... .... .... .... .... .... = Proxiable: Do NOT use proxiable tickets .... 0... .... .... .... .... .... .... = Proxy: This ticket has NOT been proxied .... .0.. .... .... .... .... .... .... = Allow Postdate: We do NOT allow the ticket to be postdated .... ..0. .... .... .... .... .... .... = Postdated: This ticket is NOT postdated .... .... 0... .... .... .... .... .... = Renewable: This ticket is NOT renewable .... .... ...0 .... .... .... .... .... = Opt HW Auth: False .... .... .... ..0. .... .... .... .... = Constrained Delegation: This is a normal request (no constrained delegation) .... .... .... ...0 .... .... .... .... = Canonicalize: This is NOT a canonicalized ticket request .... .... .... .... .... .... ..0. .... = Disable Transited Check: Transited checking is NOT disabled .... .... .... .... .... .... ...1 .... = Renewable OK: We accept RENEWED tickets .... .... .... .... .... .... .... 0... = Enc-Tkt-in-Skey: Do NOT encrypt the tkt inside the skey .... .... .... .... .... .... .... ..0. = Renew: This is NOT a request to renew a ticket .... .... .... .... .... .... .... ...0 = Validate: This is NOT a request to validate a postdated ticket Client Name (Principal): test Name-type: Principal (1) Name: test Realm: SRV.MYTESTSERVER.LOC Server Name (Unknown): krbtgt/SRV.MYTESTSERVER.LOC Name-type: Unknown (0) Name: krbtgt Name: FP.DEREKTESTING.COM from: 2011-04-07 08:10:06 (UTC) till: 2011-04-08 08:10:06 (UTC) Nonce: 1302163806 Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-crc des-cbc-md5 des-cbc-md4 Encryption type: aes256-cts-hmac-sha1-96 (18) Encryption type: aes128-cts-hmac-sha1-96 (17) Encryption type: des3-cbc-sha1 (16) Encryption type: rc4-hmac (23) Encryption type: des-cbc-crc (1) Encryption type: des-cbc-md5 (3) Encryption type: des-cbc-md4 (2) ++++++++++ REQUEST ++++++++++++++++ And this is the response: ++++++++++ RESPONSE ++++++++++++++++ Kerberos KRB-ERROR Pvno: 5 MSG Type: KRB-ERROR (30) stime: 2011-04-07 08:10:06 (UTC) susec: 247525 error_code: KRB5KDC_ERR_ETYPE_NOSUPP (14) Realm: SRV.MYTESTSERVER.LOC Server Name (Unknown): krbtgt/SRV.MYTESTSERVER.LOC Name-type: Unknown (0) Name: krbtgt Name: SRV.MYTESTSERVER.LOC e-data padata: PA-ENCTYPE-INFO Type: PA-ENCTYPE-INFO (11) Value: 30443020a003020103a119041746502e444552454b544553... des-cbc-md5 des-cbc-crc Encryption type: des-cbc-md5 (3) Salt: 46502e444552454b54455354494e472e434f4d6a69616e Encryption type: des-cbc-crc (1) Salt: 46502e444552454b54455354494e472e434f4d6a69616e ++++++++++ RESPONSE ++++++++++++++++ What could have possibly gone wrong? I also tried to reset the passwords of administrator and the user and restart the kdc services. It didn't help. Thanks.

as you see, the client is asking for AES tickets if possible. The user is probably logging from a Vista+ workstation. There may be some collision between the checkbox. Why do you need the DES? If your domain functional level is at least 2008, then all transactions among Vista/2008 servers is AES enabled, which is slightly stronger :-) ondrej.

Thanks for the explanation. I thought Server should choose the first available encryption type from the etypes provided by the client.

I am not sure, the exact behaviour must be specified somewhere, but I was not able to find any precise documentation on the topic. It may be, that the DC preferes AES if allowed by the client and it may colide with the setting on the user account. Anyway, why do you use the checkbox at all? If you wanted to enforce DES, you could have enabled the "System Cryptography: Use FIPS compliant algorithms for encryption, hashing and siging" policy which would switch the whole environment to DES or AES automatically. The user account setting is meant to only those accounts that are used by non-windows services IMHO. ondrej.