JDK 17 (Java 17) +Kerberos authentication fail

Question

Facing a very annyoing issue with JDK 17 upgrade and new Kerberos auth that is supported.

1. Problem: JDK 17 Kerberos does not support rc4-hmac anymore, as is marked as non secured. INFO: Kerberos Deprecate 3DES and RC4 in Kerberos 3DES and RC4 Kerberos encryption types have now been disabled by default. Both 3DES and RC4 are weak encryption algorithms that should not be used. The Kerberos 3DES and RC4 encryption types are officially deprecated in RFC 8429.

2. What needs to be done:

• generate new keytab files with the new supported encryption types:
• aes128-cts-hmac-sha1-96 or aes128-cts-hmac-sha256-128
• update the service user in AD (Active directory , 2 checkboxes to support the new encryption types.

Error that we cannot get out of:

Caused by: sun.security.krb5.KrbException: KDC has no support for encryption type (14)
at java.security.jgss/sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:69)
at java.security.jgss/sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:224)
at java.security.jgss/sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:235)
at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCredsSingle(CredentialsUtil.java:482)
at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:34
at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:31
at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:169)
at java.security.jgss/sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:493)
at java.security.jgss/sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:700)
... 39 common frames omitted
Caused by: sun.security.krb5.Asn1Exception: Identifier doesn't match expected value (906)
at java.security.jgss/sun.security.krb5.internal.KDCRep.init(KDCRep.java:140)
at java.security.jgss/sun.security.krb5.internal.TGSRep.init(TGSRep.java:65)
at java.security.jgss/sun.security.krb5.internal.TGSRep.<init>(TGSRep.java:60)
at java.security.jgss/sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:54)
... 47 common frames omitted

Are we missing something?

All on the pipe is updated to support the new encryption types+ the keytab.conf files.

Thank you!

Answer 1

Another important thing, in my opinion, is to clear Kerberos tickets on computer from where we want to login with Kerberos every time during deployment, as old, incorrect Kerberos tickets may cause the same error instead of the new settings in application or on domain computer.

On Windows

klist purge

On Linux

kdestroy

Answer 2

Try to update content of krb5.ini file:

default_tgs_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
default_tkt_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc

Answer 3

I was having the exact same issue as described here. Looking at the flow of kerberos authentication and using this microsoft article we figured the problem was in the principal service account of the SQL server (service we are contacting). This principal service account did not have the attribute 'msDS-SupportedEncryptionTypes' set and therefore defaults to the RC4 encryption type.

The fix was for us was to enable 'This account supports Kerberos AES 128 bit encryption' and 'This account supports Kerberos AES 256 bit encryption' for the principal service account. In some cases it could also be necessary to reset the password of this account.

As mentioned in the microsoft article, by default user acocunts do not have a value set for 'msDS-SupportedEncryptionTypes'.

Answer 4

The solution was to use a gMSA account for the MSSQL server connection.

JDK 17 app--> JDK17 aes128-cts-hmac-sha256-128 keytab--> call to MSSQL server with userid--> resolve via gMSA account.

So the MSSQL part did not accept firstly the new encryption type.

Answer 5

You can keep the existing rc4-hmac behavior by setting the 'allow_weak_crypto' property to 'true' in the krb5.conf file