On Thu, Jul 28, 2011 at 6:50 PM, Sabharanjak, Ravi <[email protected]> wrote: > Even omitting des from the default enctypes gets the same result - > KRB5KDC_ERR_ETYPE_NOSUPP. So as long as I have aes specified, I get "no > support" in the response. > > I can understand the Java issue, but this behavior is with the latest Java > off the web and also with the MIT release and the UNIX and Solaris releases. > > I can see the exchange as follows (on solaris): > - AS-REQ from client, specifying Encryption Types: aes256-cts-hmac-sha1-96 > aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc > - Error: KRB5KDC_ERR_PREAUTH_REQUIRED from the kdc. This does have aes > specified in the PA-ENCTYPE-INFO2 in the e-data field as follow: > Value: 3064301da003020112a1161b144e412e424c4b494e542e43... > aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-md5 des-cbc-crc > - Client repeats AS-REQ, includes Encryption Types: aes256-cts-hmac-sha1-96 > aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc > - Server responds with KRB5KDC_ERR_ETYPE_NOSUPP
I don't understand. The above shows DES enctypes in the list. I assume this is without using default_tkt_enctypes / default_tgs_enctypes set? What enctype did Java use to encrypt the padata in the AS-REQ? Mike > -----Original Message----- > From: Michael B Allen [mailto:[email protected]] > Sent: Thursday, July 28, 2011 3:22 PM > To: Sabharanjak, Ravi > Cc: [email protected] > Subject: Re: Is Windows server 2008+KDC not interoperable with Java, Solaris > and UNIX or MIT kerberos? > > On Thu, Jul 28, 2011 at 4:49 PM, Sabharanjak, Ravi > <[email protected]> wrote: >> The syntax is actually - >> default_tkt_enctypes = rc4-hmac >> default_tgs_enctypes = rc4-hmac >> >> That works, However that locks my clients down to rc4-hmac forever and I >> don't want to do that. I would like them to move up to aes automatically >> when the KDC supports it and negotiate (not hard-code) rc4-hmac till that >> happens. > > And if you specify multiple mechanism names separated by spaces like: > > default_tkt_enctypes = aes128-cts rc4-hmac > default_tgs_enctypes = aes128-cts rc4-hmac > > Does that still "lock" clients into a particular mechanism? > >> It can't be the des in the request that would turn the kdc off - it is >> supposed to pick an acceptable mechanism from the list proposed, and it >> should negotiate rc4-hmac according to me. > > Yes, the KDC is supposed to pick an appropriate mechanism but if your > observations are accurate, then apparently that is not the case. You said a > capture showed Java offering RC4 and AES but you still got > KRB5KDC_ERR_ETYPE_NOSUPP anyway. So maybe if you explicitly specify two mechs > it will negotiate properly. > > Otherwise it is possible that this could be traced back to an obscure > incompatibility in the builtin Java Kerberos implementation. As I said > before, it has had a troubled history. > > Actually now that I think about it, an XP SP2 client will offer to do DES. So > I don't see how a Windows KDC could proactively reject DES and maintain > backward compatibility. Maybe your security policy has been tweaked to reject > DES in this way. > > Just hypothesizing. > > Mike > > -- > Michael B Allen > Java Active Directory Integration > http://www.ioplex.com/ > > >> -----Original Message----- >> From: Michael B Allen [mailto:[email protected]] >> Sent: Thursday, July 28, 2011 1:02 PM >> To: Sabharanjak, Ravi >> Cc: [email protected] >> Subject: Re: Is Windows server 2008+KDC not interoperable with Java, Solaris >> and UNIX or MIT kerberos? >> >> On Thu, Jul 28, 2011 at 2:22 PM, Sabharanjak, Ravi >> <[email protected]> wrote: >>> Hello all, >>> >>> I am not able to get a ticket from a server 2008 or a server 2008 R2 KDC >>> from a Java, Solaris or Linux client unless I constrain the client to use >>> RC4-HMAC for the encryption types. (Have tried this using kfw-3-2-2 on >>> Windows as well). Is server2008+ not interoperable with these Kerberos >>> implementations? >>> >>> A brief background - if the domain is not in server 2008+ functionality >>> mode (ie there are 2003 or older domain controllers in the environment), >>> server 2008+ does not enable support for AES encryption (unless the client >>> is a vista+ client that has updated the msDS-SupportedEncryptionTypes >>> attribute in its user object). Server 2008+ also does not enable support >>> for DES by default. >>> >>> In the network traces, I can see clients proposing to use DES, RC4-HMAC and >>> AES for the AS-REQ if they are not configured to be limited to using >>> RC4-HMAC. I am expecting the client and the KDC to settle on the use of >>> RC4-HMAC, however the KDC replies with KRB5KDC_ERR_ETYPE_NOSUPP. >>> >>> I don't want to constrain the clients to use just RC4-HMAC, as I want them >>> to switch to AES automatically when the domain functional level is upgraded >>> and AES support becomes available on the DC. >>> >>> The Java version is the latest off Java.com. The linux and Solaris versions >>> are fairly current. >>> >>> Wireshark traces attached. Any help you can provide or insights into why >>> this is not working out would be greatly appreciated. >> >> Hi Ravi, >> >> I think you probably need to do something like: >> >> permitted_enctypes = aes128-cts rc4-hmac >> >> [But I just typed this in from memory, double check at your end what the >> right parameter values are.] >> >> It sounds like Windows does not like clients even offering to do DES maybe. >> I agree that the Windows KDC should probably just ignore DES but maybe >> that's Windows' way of disabling DES at the front door as a precaution in >> the case were old accounts still have DES keys laying around. Java shouldn't >> even be trying DES anymore. Make sure you're not using an old Java. But I >> would not be surprised if Java is still trying to do DES. The Java Kerberos >> implementation is not particularly good and it has had a sorry history. >> >> Mike > > THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE > PRIVILEGED. If this message was misdirected, BlackRock, Inc. and its > subsidiaries, ("BlackRock") does not waive any confidentiality or privilege. > If you are not the intended recipient, please notify us immediately and > destroy the message without disclosing its contents to anyone. Any > distribution, use or copying of this e-mail or the information it contains by > other than an intended recipient is unauthorized. The views and opinions > expressed in this e-mail message are the author's own and may not reflect the > views and opinions of BlackRock, unless the author is authorized by BlackRock > to express such views or opinions on its behalf. All email sent to or from > this address is subject to electronic storage and review by BlackRock. > Although BlackRock operates anti-virus programs, it does not accept > responsibility for any damage whatsoever caused by viruses being passed. > > > -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
