SSO....(KDC has no support for encryption type)

Openfire Openfire Support
1

Still having issues getting SSO to work. I’ve had one of our network engineers sniff the traffic and they came back with the attached PDF.

The main thing I see is:

Kerberos: Error-Code = 14 (KDC has no support for encryption type)

I found the error on Sun’s site via google:

javax.security.auth.login.LoginException: KrbException: KDC has no support for encryption type (14) - KDC has no support for encryption type

Cause 1: Your KDC does not support the encryption type requested.
Solution 1: Sun’s implementation of Kerberos supports the following encryption types:<code>des-cbc-md5</code>, <code>des-cbc-crc</code> and <code>des3-cbc-sha1</code>.
Applications can select the desired encryption type by specifying following tags in the Kerberos Configuration file<code>krb5.conf</code>:bq. [libdefaults] \ default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 \ default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 \ permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 \

If not specified, the default value is:

des-cbc-md5 des-cbc-crc des3-cbc-sha1 \

Cause 2: This exception is thrown when using native ticket cache on some Windows platforms. Microsoft has added a new feature in which they no longer export the session keys for Ticket-Granting Tickets (TGTs). As a result, the native TGT obtained on Windows has an “empty” session key and null EType. The effected platforms include: Windows Server 2003, Windows 2000 Server Service Pack 4 (SP4) and Windows XP SP2.

Solution 2: You need to update the Windows registry to disable this new feature. The registry key <code>allowtgtsessionkey</code> should be addedand set correctlyto allow session keys to be sent in the Kerberos Ticket-Granting Ticket.

On the Windows Server 2003 and Windows 2000 SP4, here is the required registry setting:

HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaKerberosParameters \ Value Name: allowtgtsessionkey \ Value Type: REG_DWORD \ Value: 0x01 ( default is 0 ) \

By default, the value is 0; setting it to “0x01” allows a session key to be included in the TGT.

Here is the location of the registry setting on Windows XP SP2:

HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaKerberos \ Value Name: allowtgtsessionkey \ Value Type: REG_DWORD \ Value: 0x01 \

Now obviously I’ve already made the appropriate registry changes, any other thoughts?

Thanks,

-Stuart

2

This is a mislesading error. Generally the error “KDC has no support for encryption type (14)” has nothing to do with the encryption type itself, but with access to the credentials (a very misleading error message). You need to make sure the client has access to the credential cache. Microsoft changed things a while back, so Java cannot by default access the full credentials to use with GSSAPI without a registry change. This means the registry settings you describe below need to happen on the client- not the server. Well, if you are testing on the server, the server is also a client so you will need to make the changes there as well then. You didn’t say in your message if you made the change on the server or the client, but I’d be willing to guess you made the change on the server. If so, go make the change on the client and test again. If you still get the error, then continue on:

How did you generate the Keytab? Make sure you follow the SSO directions carefully, its easy to make a mistake that will generate these types of errors. However, one thing the SSO directions have you do is explicitly list which encryption types are allowed. One thing I notice is the request from the server is saying the encryption types supported are des-cbc-md5, des-cbc-crc, rc4-hmac, and des3-cbc-sha1. None of these are very secure encryption mechanisms anymore, so its possible your KDC does not support them in favor of something like aes256. This is not default behavior in windows, but I think it can be changed, so that might be your issue.

What version of Java are you using? Have you installed the “JCE Unlimited Strength Jurisdiction Policy Files” for your version of Java? I dont remember for sure, but I think the RC4 encryption type with Kerberos required Java 5 to have the unlimited strength policy installed. I know that Java 6 does not, however. The unlimited strength policy files allow java to use more encryption types and stronger keys (higher bit counts).

3

Thanks for the input. I have created keytab files multiple times, both through windows and java to no avail. We’re actually going to be throwing out the idea of SSO. After sniffing the traffic we realized the client need to talk directly to the KDC for authentication, credentials arent verified through the Openfire server as they would for LDAP. Since we intend on putting this server in our DMZ for allowing secured access without VPN to our users we feel it’s not the best idea to put a KDC in the DMZ for security reasons.

Thanks,

-Stuart