5

Vanilla Krb5LoginModule is working, prompting for creds

In my modest usage of JAAS -> JGSS -> Kerberos -> Windows thus far, I have set up a Krb5LoginModule When I do:

Subject.doAs(
    new LoginContext(...)).login(),  // subject
    new MyPrivilegedAction()         // action
)

... I am prompted for credentials, and the action is successful.

Using TGT Session Key hack, can avoid prompt for creds

If I also add useTicketCache=true to the login module, and if I put up with the security hazards of setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\AllowTgtSessionKey=1 and don't use Windows 10 Credential Guard, then the action is successful without a prompt for credentials.

Java 12 gives us a default native GSS-API lib even on Windows

Java 11.0.10 introduced the possibility of using a native GSS-API implementation on Windows but did not provide a default implementation. Java 12 added a native implementation of GSS-API which bridged to the Windows SSPI. This avoids the need for the risky AllowTGTSessionKey.

Using native GSS-API works too, prompting for creds

On Java 15.0.2 (both Oracle and OpenJDK) on Windows, despite the docs) still (now incorrectly) claiming, "There is no well-known native GSS-API library on Windows", I can:

  • Omit java.security.krb5.realm and java.security.krb5.kd system properties (which I use in lieu of a full-blown kr5.conf, since my AD environment is simple); and
  • merely specify sun.security.jgss.native=true.

... and the action prompts for credentials, but is successful.

But native always prompts for credentials

Can I expect when using sun.security.jgss.native=true (on JDK 15.0.2 on Windows) that JAAS -> JGSS -> Kerberos -> Windows will attempt to use the Windows LSASS via the SSPI to obtain the credentials of the user executing the JVM? Or is this not something that the native GSS-API -> SSPI library facilitates? Information is thin on the ground!

David Bullock
  • 6,112
  • 3
  • 33
  • 43
  • When the JAAS `CallbackHandler` is invoked using native, it does correctly suggest my username ... it just isn't fetching my password from Windows the way it does when using pure-Java with the `AllowTGTSessionKey` hack. – David Bullock Jan 26 '21 at 04:28
  • I feel like there are probably 4 people in the world who could answer this, and they're all really busy. – David Bullock Jan 26 '21 at 04:32
  • Out of curiosity: did you tweak the default JAAS configuration in your tests? and did you check what JAAS makes of its config via `-Djava.security.debug=gssloginconfig,configfile,configparser,logincontext` or sthg similar? – Samson Scharfrichter Jan 26 '21 at 18:47
  • Thanks @SamsonScharfrichter I can confirm the intended file is being parsed. I think I will chug along with the tutorials and try to make a minimal repro with just GSS-API and leave JAAS out of it. Will update the Qn when I have more info. – David Bullock Jan 28 '21 at 00:37
  • Any news on this topic? – fjf2002 Aug 04 '21 at 13:49
  • @fjf2002 I did not chase it to the end of the line yet. For me, the bigger picture was to allow my Java app-server to transparently propagate the identity of the user-agent all the way to the DBMS. But the whole attention of the industry is on OAuth now, and not on this scenario. I will take another look at things when JDK17 ships (not too long now!) – David Bullock Aug 17 '21 at 12:43

0 Answers0