Why is JDK1.8.0u121 unable to find the kerberos default_tkt_enctypes types? (KrbException: no supported default etypes for default_tkt_enctypes)

Question

Following are my environment details:-

KDC Server : Windows Server 2012

Target machine : Windows 7

JDK Version : Oracle 1.8.0_121 (64 bit)

I'm getting the following exception on running the Java's kinit command the on Windows 7 machine :-

C:\Program Files\Java\jdk1.8.0_121\bin>kinit -k -t "C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab" HTTP/[email protected]
Exception: krb_error 0 no supported default etypes for default_tkt_enctypes No error
KrbException: no supported default etypes for default_tkt_enctypes
        at sun.security.krb5.Config.defaultEtype(Config.java:844)
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:249)
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:262)
        at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
        at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
        at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
        at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:219)
        at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)

Command output in debug mode:-

C:\Program Files\Java\jdk1.8.0_121\bin>kinit -J-Dsun.security.krb5.debug=true -k -t "C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomca
t_ad.keytab" HTTP/[email protected]
>>>KinitOptions cache name is C:\Users\devtcadmin\krb5cc_devtcadmin
Principal is HTTP/[email protected]
>>> Kinit using keytab
>>> Kinit keytab file name: C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab
Java config name: null
LSA: Found Ticket
LSA: Made NewWeakGlobalRef
LSA: Found PrincipalName
LSA: Made NewWeakGlobalRef
LSA: Found DerValue
LSA: Made NewWeakGlobalRef
LSA: Found EncryptionKey
LSA: Made NewWeakGlobalRef
LSA: Found TicketFlags
LSA: Made NewWeakGlobalRef
LSA: Found KerberosTime
LSA: Made NewWeakGlobalRef
LSA: Found String
LSA: Made NewWeakGlobalRef
LSA: Found DerValue constructor
LSA: Found Ticket constructor
LSA: Found PrincipalName constructor
LSA: Found EncryptionKey constructor
LSA: Found TicketFlags constructor
LSA: Found KerberosTime constructor
LSA: Finished OnLoad processing
Native config name: C:\Windows\krb5.ini
Loaded from native config
>>> Kinit realm name is DEVDEVELOPMENT.COM
>>> Creating KrbAsReq
>>> KrbKdcReq local addresses for dev26 are:

        dev26/192.168.1.229
IPv4 address

        dev26/fe80:0:0:0:78ae:388f:4f63:3717%11
IPv6 address
>>> KdcAccessibility: reset
>>> KeyTabInputStream, readName(): DEVDEVELOPMENT.COM
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): dev26.devdevelopment.com
>>> KeyTab: load() entry length: 99; type: 18
Looking for keys for: HTTP/[email protected]
Added key: 18version: 3
Exception: krb_error 0 no supported default etypes for default_tkt_enctypes No error
KrbException: no supported default etypes for default_tkt_enctypes
        at sun.security.krb5.Config.defaultEtype(Config.java:844)
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:249)
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:262)
        at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
        at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
        at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
        at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:219)
        at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)

Following is the output of the ktpass command on the KDC server (Windows Server 2012) to generate the tomcat_ad.keytab file :-

C:\Users\Administrator>ktpass /out C:\tomcat_ad.keytab /mapuser [email protected] /princ HTTP/[email protected] /pass ****** /crypto AES256-SHA1 ptype KRB5_NT_PRINCIPAL
    Targeting domain controller: dev.devdevelopment.com
    Using legacy password setting method
    Successfully mapped HTTP/dev26.devdevelopment.com to devtcadmin.
    Key created.
    Output keytab to C:\tomcat_ad.keytab:
    Keytab version: 0x502
    keysize 99 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (0xf20788d7c6f99c385fc91b53c7d9ef55591d314e5340ca1fb9acac1b178c8861)

Following is the content of the krb5.ini file that is at C:\Windows in Windows 7 machine :-

[libdefaults]
default_realm=DEVDEVELOPMENT.COM
default_keytab_name=“C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab"
default_tkt_enctypes=aes256-cts-hmac-shal-96
default_tgs_enctypes=aes256-cts-hmac-shal-96
permitted_enctypes=aes256-cts-hmac-shal-96
udp_preference_limit=1
forwardable=true

[realms]
DEVDEVELOPMENT.COM={
    kdc=dev.devdevelopment.com:88
}

[domain_realm]
devdevelopment.com=DEVDEVELOPMENT.COM
.devdevelopment.com=DEVDEVELOPMENT.COM

Following is the output of Java's ktab command on Windows 7 machine :-

C:\Program Files\Java\jdk1.8.0_121\bin>ktab -l -e -t -k "C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab"
Keytab name: C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab
KVNO Timestamp      Principal
---- -------------- ---------------------------------------------------------------------------------------
   3 1/1/70 5:30 AM HTTP/[email protected] (18:AES256 CTS mode with HMAC SHA1-96)

I have also updated the JCE jar files under C:\Program Files\Java\jre1.8.0_121\lib\security and C:\Program Files\Java\jdk1.8.0_121\jre\lib\security folders.

What should be done to overcome this exception?

EDIT 1 (continued from my 3rd comment) :-

Following is the output of the first knit command with the tomcat_ad.keytab file in the C:\Program Files\Java\jre1.8.0_121\bin folder:-

C:\Program Files\Java\jdk1.8.0_121\bin>kinit -k -t tomcat_ad.keytab HTTP/dev26.devdevelopment.com
New ticket is stored in cache file C:\Users\devtcadmin\krb5cc_devtcadmin

And, following is the output of the kinit command with the tomcat_ad.keytab file in the C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab folder and after appending the C:\Program Files\Java\jdk1.8.0_121\bin; in the path environment variable:-

C:\Users\devtcadmin>kinit -k -t "C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab" HTTP/[email protected]
New ticket is stored in cache file C:\Users\devtcadmin\krb5cc_devtcadmin

BUT the kinit command in the debug mode this time gives out the following exception :-

C:\Users\devtcadmin>kinit -J-Dsun.security.krb5.debug=true -k -t "C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\tomcat_ad.keytab" HTTP/[email protected]
>>>KinitOptions cache name is C:\Users\devtcadmin\krb5cc_devtcadmin
Principal is HTTP/[email protected]
>>> Kinit using keytab
>>> Kinit keytab file name: C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\tomcat_ad.keytab
Java config name: null
LSA: Found Ticket
LSA: Made NewWeakGlobalRef
LSA: Found PrincipalName
LSA: Made NewWeakGlobalRef
LSA: Found DerValue
LSA: Made NewWeakGlobalRef
LSA: Found EncryptionKey
LSA: Made NewWeakGlobalRef
LSA: Found TicketFlags
LSA: Made NewWeakGlobalRef
LSA: Found KerberosTime
LSA: Made NewWeakGlobalRef
LSA: Found String
LSA: Made NewWeakGlobalRef
LSA: Found DerValue constructor
LSA: Found Ticket constructor
LSA: Found PrincipalName constructor
LSA: Found EncryptionKey constructor
LSA: Found TicketFlags constructor
LSA: Found KerberosTime constructor
LSA: Finished OnLoad processing
Native config name: C:\Windows\krb5.ini
Loaded from native config
>>> Kinit realm name is DEVDEVELOPMENT.COM
>>> Creating KrbAsReq
>>> KrbKdcReq local addresses for dev26 are:

        dev26/192.168.1.229
IPv4 address

        dev26/fe80:0:0:0:78ae:388f:4f63:3717%11
IPv6 address
>>> KdcAccessibility: reset
Looking for keys for: HTTP/[email protected]
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23.
Exception: krb_error 0 Do not have keys of types listed in default_tkt_enctypes available; only have keys of following type:  No error
KrbException: Do not have keys of types listed in default_tkt_enctypes available; only have keys of following type:
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:280)
        at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
        at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
        at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
        at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:219)
        at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)

Why do the above commands work after commenting those lines in the C:\Windows\krb5.ini file? And why the kinit command in the debug mode output the above exception?

Solution 1

I've seen this before. Try this. Copy the keytab into the C:\Program Files\Java\jdk1.8.0_121\bin directory and try again with the simpler command shown below from within that directory. You don't need to append the Kerberos realm to the SPN since you have the realm defined already in krb5.conf, so I removed it.

kinit -k -t tomcat_ad.keytab HTTP/dev26.devdevelopment.com

If it still doesn't work, be sure you really do have the unlimited strength JCE jar files inside the \lib\security directory. Although you said you did, a Java JRE upgrade can overwrite them.

EDIT: On the Account tab of the AD user account devtcadmin, ensure the box "This account supports Kerberos AES 256 bit encryption" is checked.

If it still doesn't work, then on the Windows 7 machine, in C:\Windows\krb5.conf, comment out the four below lines as shown. They are not required, as Kerberos is going to use the highest possible encrytpion types anyway, and in Windows 7/2008 and above, TCP is used by default so you do not need to set the UDP preference limit.

#default_tkt_enctypes=aes256-cts-hmac-shal-96
#default_tgs_enctypes=aes256-cts-hmac-shal-96
#permitted_enctypes=aes256-cts-hmac-shal-96
#udp_preference_limit=1

Take a quick glance at my TechNet article for further reference on this: Kerberos Keytabs – Explained

Solution 2

I saw a similar issue when trying to use the JDK's Kerberos support from a Windows Server 2012R2 as a client with a Linux server that was still using a 'legacy' keytab. The error I was seeing was:

KrbException: no supported default etypes for default_tkt_enctypes

To fix this interoperability issue I looked at the OpenJDK source and found a setting in EType.java called allow_weak_crypto:

Adding this setting to my krb5.conf solved the issue for me:

[libdefaults]
       allow_weak_crypto = true

Comments

[Shiva]

Thanx 4 replying @T-Heron. Tried your suggestion but still getting the same exception. I also checked if the JCE jars are being used or not by running the following code :-

[Shiva]

import javax.crypto.Cipher; public class CheckForJCE { public static void main(String[] args) throws Exception { int maxrc5 = Cipher.getMaxAllowedKeyLength("RC5"); int maxaes = Cipher.getMaxAllowedKeyLength("AES"); System.out.println("max RC5 = " + maxrc5); System.out.println("max AES = " + maxaes); //System.exit((maxaes < 256) ? 1 : 0); System.out.println((maxaes < 256) ? "JCE Not Available" : "JCE Available"); } }

[T-Heron]

I liked the way you checked if the JCE jars were being used with that code snippet. That said, I just added an edit to the answer, which hopefully should resolve the problem.

[Shiva]

) From the beginning the "This account supports Kerberos AES 256 bit encryption" checkbox was checked on the Account tab of the AD user account devtcadmin i.e., as soon as I had created the tomcat_ad.keytab file on the AD machine. Heeding your 2nd suggestion I commented out the lines in the C:\Windows\krb5.ini file (in the Windows 7 machine) as pointed out by you and voila, some of the kinit commands worked without any exception. But the kinit command in the debug mode threw a new exception. I have added an EDIT 1 with further details in the above query.

[T-Heron]

That's not really an exception - your output shows it's working now and the debug output you're seeing is basically saying it doesn't have keys for the other encryption types b/c in your ktpass creation command you chose to only utilize encryption type AES256-SHA1 --> /crypto AES256-SHA1. Your output clearly shows you are pulling a Kerberos ticket successfully now. You are good to go.

[Shiva]

THeron can you throw some light on why the kinit command worked after commenting the (above mentioned) lines in the krb5.ini file? And regarding the kinit command in the debug mode, its log says Using builtin default etypes for default_tkt_enctypes default etypes for default_tkt_enctypes: 18 17 16 23. few lines just before the pseudo-exception (as you said) and AES256-SHA1 is of type 18 that is set in the ktpass command. Also, eventually the command does not output the expected New ticket is stored in cache file C:\Users\devtcadmin\krb5cc_devtcadmin at the end. Any idea why?

[T-Heron]

I am interested in reproducing this in order to give you a more definitive answer. Will take a couple of days though. I have a lot of practice in creating keytabs and troubleshooting when they are not working, but never analyzed it at a debug level before. The psuedo-exception thrown will have something to do with the fact that encryption types 17, 16, and 23 are not in the keytab, whereas only 18 (AES256-SHA1) is.

[T-Heron]

I've gone down this path before of answering new questions in the Comments section and not even getting any credit for answers. I'm going to have to decide if I am going to spend my time and research capital on answering that b/c while I have heard of that, I don't know it solidly off the top of my head.

[Shiva]

Got your concern. NP. Thanx THeron. As per your convenience.

[T-Heron]

Added the two additional questions you raised to my project list: Attach debug to kinit command and answer more defintively about psuedo-exception and the one about tgtsessionkey from the Registry.

[T-Heron]

Good detail on that. In my experience, be aware that weak crypto usually gets flagged in security audits though.

[Gerhard Poul]

@T-Heron definitely, but the name of the directive allow_weak_crypto is appropriately chosen, so it should be easy to detect and in case of a security audit I would hope it is flagged for the server side first, which means we could just remove the directive on the client side then.