JDK-8164217 : Java 8 Krb5LoginModule is not retrieving cached TGT for the current windows user
  • Type: Bug
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 8u71
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2016-08-17
  • Updated: 2016-11-01
  • Resolved: 2016-11-01
Cu is using the Krb5LoginModule to login using cached TGT from the logged machine.  The JAAS config file is configured as:

Client {
	com.sun.security.auth.module.Krb5LoginModule required

and client code fails with the exception: That it did not retrieve TGT form the cache.  The failure is shown in the following output:

>>> Found no TGT's in LSA
Principal is null
null credentials from Ticket Cache
[Krb5LoginModule] authentication failed
Unable to obtain Principal Name for authentication
javax.security.auth.login.LoginException: Unable to obtain Principal Name for authentication
at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:841)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at com.wfs.platform.security.kerberos.Client.login(Client.java:102)
at com.wfs.platform.security.kerberos.Client.main(Client.java:63)
There was an error during the JAAS login  

This same code works with Java 6, but fails for Java 7 or 8. 

Further logs received from submitter. What submitter sees appears to be expected behaviour. MS no longer discloses information about the TGT session key unless the AllowTGTSessionKey registry setting is modified. (as verified by klist output also) Before the registry edit, you'll note that a key with no information is returned : Session Key : KeyType 0x12 - AES-256-CTS-HMAC-SHA1-96 : KeyLength 32 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 For JDK 7 and later, JDK now checks the TGT ticket returned from an internal MSDN call and returns NULL if no information is available from TGT session key (all zeros) - Hence the "LSA: Session key all zero. Stop." debug output. This extra check is present in JDK 7 and later. For JDK 6, the same ticket would get returned. Since it's a zero session key, it wouldn't contain any useful data for TGT purposes. Submitter should investigate if that information was used for anything useful in JDK 6 env. As a result, I believe the registry setting is the only way to obtain such credentials from the windows system at this moment. Let me know if this issue can be closed out as a result. Please read the "javax.security.auth.login.LoginException: KrbException: KDC has no support for encryption type (14) - KDC has no support for encryption type" section in this doc : https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/Troubleshooting.html The submitter should edit the windows registry regarding the allowtgtsessionkey key. See "solution 2".

Requested more configuration information from submitter. can we get some further configuration details about Cu krb5 setup. Their conf file has "doNotPrompt=true" set. this implies the following : https://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html "Set this to true if you do not want to be prompted for the password if credentials can not be obtained from the cache, the keytab, or through shared state.(Default is false) If set to true, credential must be obtained through cache, keytab, or shared state. Otherwise, authentication will fail." In their testcase, they have a properties file. That file has no password provided but has this comment : #client.password [will get it in the UI] Is the application meant to prompt ? Where are the credentials stored for this app ?