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!

0

There are 0 answers