RC4HMAC Issue To AD

[Wilper, Ross A]

Is the external trust from Windows configured to use RC4-HMAC? If I
remember correctly, the default is DES-CBC-CRC (At least in Windows 2000
- 2003 R2). 

HMAC-RC4 for external trust requires Windows 2003 SP1 or later domain
controllers.

For Pre-Windows 2008, there was a later version of "ktpass" to set the
encryption type for the trust (DES or RC4). In Windows 2008+, multiple
enctypes can be active on the trust and they can be set using "ksetup".

-Ross

-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
Behalf Of miguel.sanders at arcelormittal.com
Sent: Tuesday, April 28, 2009 6:29 AM
To: kerberos at mit.edu
Subject: RC4HMAC Issue To AD

Hi folks

I'm observing a rather odd situation when using the RC4HMAC encryption
type to AD.
What I can see from the key exchanges is the following:
1) MIT Client performs AS-REQ and mentions aes256-cts-hmac-sha1-96,
rc4-hmac and des3-cbc-sha1 as supported enctypes.
2) AD responds with an AS-REP which holds the TGT and states it has been
encrypted with rc4-hmac.
3) Now the MIT client want to verify the TGT and performs a TGS REQ to
obtain the cross realm ticket, and mentions aes256-cts-hmac-sha1-96,
rc4-hmac and des3-cbc-sha1 as supported enctypes.
4) AD responds now with KRB5KDC_ERR_ETYPE_NOSUPP, even though in step 1)
and 2) we are use it understands rc4-hmac.

I was pretty convinced that AD supported both DES (no option for us) and
RC4-HMAC for cross realm situations...
Any idea what I am doing wrong?	

Thanks!

Miguel

**** 
This message and any attachment are confidential, intended solely for
the use of the individual or entity to whom it is addressed and may be
protected by professional secrecy or intellectual property rights. 
If you have received it by mistake, or are not the named recipient(s),
please immediately notify the sender and delete the message. You are
hereby notified that any unauthorized use, copying or dissemination of
any or all information contained in this message is prohibited. 
Arcelormittal shall not be liable for the message if altered, falsified,
or in case of error in the recipient. 
This message does not constitute any right or commitment for
ArcelorMittal except when expressly agreed otherwise in writing in a
separate agreement.  
****  

________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos