[31029] in Kerberos
RE: RC4HMAC Issue To AD
daemon@ATHENA.MIT.EDU (miguel.sanders@arcelormittal.com)
Tue Apr 28 13:41:13 2009
MIME-Version: 1.0
Date: Tue, 28 Apr 2009 18:26:40 +0200
Message-ID: <7DF29B50FFF41848BB2281EC2E71A206B6E951@GEN-MXB-V04.msad.arcelor.net>
In-Reply-To: <B9BF119F687A824C8A49C4E4ED695768017110CA@its-exchmb01.stanford.edu>
From: miguel.sanders@arcelormittal.com
To: rwilper@stanford.edu, kerberos@mit.edu
Content-class: urn:content-classes:message
Content-Type: text/plain; charset="windows-1252"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Hi Ross
Thanks a lot for your help.
Met vriendelijke groet
Best regards
Bien à vous
Miguel SANDERS
ArcelorMittal Gent
UNIX Systems & Storage
IT Supply Western Europe | John Kennedylaan 51
B-9042 Gent
T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023
E miguel.sanders@arcelormittal.com
www.arcelormittal.com/gent
-----Oorspronkelijk bericht-----
Van: Wilper, Ross A [mailto:rwilper@stanford.edu]
Verzonden: dinsdag 28 april 2009 17:42
Aan: SANDERS Miguel; kerberos@mit.edu
Onderwerp: RE: RC4HMAC Issue To AD
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@mit.edu [mailto:kerberos-bounces@mit.edu] On Behalf Of miguel.sanders@arcelormittal.com
Sent: Tuesday, April 28, 2009 6:29 AM
To: kerberos@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@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
****
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@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
