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
-----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.
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
