Example Case Study Of Credential Guard & Oracle Java GSS API Support On Windows 10

For the past years, users that have the new Windows 10 security feature, Credential Guard, enabled were experiencing issues when it blocked third-party software from accessing the user’s credentials. While not well documented, the biggest issue arises when common Java applications using the JDK for GSS API are not allowed to have access to the tokens anymore and therefore block the Single Sign-On (SSO).

Before we take a closer look at the issue itself, let’s go through how Credential Guard works in more detail.

How Does Credential Guard Protect User Secrets?

The purpose of Credential Guard, in Microsoft’s words, “is to provide a virtualization-based security to protect domain account Kerberos and NTLM credentials from theft by malicious software. Credential Guard protects the logon session as well as the credentials themselves.”

In traditional Security Support Provider (SSP) architecture, all security requests go through a Local Security Authority (LSA) Server Service layer, before being processed by various authentication protocols that will in turn cache credentials or derived credentials.

When using Credential Guard, you isolate Kerberos and NTLM to store a user’s credentials. When a user signs in with their certificate and pin, their private key is released. By doing this, a Diffie–Hellman (DH) key is created and stored within the isolated Kerberos for the purpose of generating a Public Key Authentication Request (PKINIT) which goes to the Domain Controller.

Once received, the Domain Controller sends back a message (again protected by the DH key) containing the key for the ticket granting session key wrapped with a NTOWF key. This key is required by the NTLM authentication protocol to generate a one-way function of the user’s password through the so-called NTOWF() function.

This again happens (and is stored) in isolation through Credential Guard. As a result, an attacker residing inside the OS can still open up sessions under the user’s session and connect to other file servers as the user, but he cannot extract the user’s credentials.

The Java GSS API Credential Guard Issue

Until recently, a pure Java GSS API implementation in the JDK was able to acquire security credentials through a login process through the Windows Active Directory server. These credentials were stored in a secure memory location called the Local Security Authority (LSA) and, as long as the [`allowtgtsessionkey` registry entry][allowtgtsessionkey] was set, the JDK was able to retrieve the LSA cache as a ticket and an accompanying session key, and use it to establish a security context.

Now if a Java application wants to authenticate in an environment where Windows Defender Credential Guard is enabled on Windows 10, the Java GSS API will not authenticate and the user will receive a login error because the session key of the credentials is isolated (as described above) and therefore not externally available anymore. Without it, Kerberos cannot use the Single Sign-On mechanism as the client must login itself by asking users for a password.

Microsoft deems this to be an “expected behavior because Windows Defender Credential Guard blocks specific application authentication capabilities and will not provide the TGT session key to applications regardless of registry key settings.”

However, this is a wider problem as it affects lots of often used applications, such as the Cisco AnyConnect Secure Mobility Client, the McAfee Application and Change Control (MACC), the AppSense Environment Manager, and Citrix applications (causing a high CPU usage).

Possible Ways Of Remediation

The only known workaround is to switch off Credential Guard and reboot the machine — a practice that is prohibited by many enterprise security policies.

As Oracle is the provider of the Java Development Kit (JDK), it is Oracle’s problem to fix. Two approaches have been considered: 1) to supplement with JNI calls into SSPI or 2) to create another native, but independent of Java library to translate GSS API calls to SSPI. The second option seems the most beneficial.

Developers have been requesting that the JDK support Microsoft’s dialect of the GSS API, the so-called Security Support Provider Interface (SSPI), on the Windows platform to provide better interoperability and system integration with Windows Active Directory (AD).

Since the SSPI performs the secure authentication and communication and can use the credentials it generates and stores in the isolated Credential Guard cache, it would make the most sense to leverage the JDK’s native GSS API bridge to consume tokens generated and accepted by SSPI. Although their function calls are different, they are mostly compatible with GSS API.

To make this work, Oracle would have to create a native GSS API library that gets loaded by the native GSS API bridge to translate calls from GSS API to SSPI. This allows the JDK to call SSPI functions in order to acquire user credentials, establish a security context, as well as communicate securely within a Windows 10 environment.

For the exact details on the bug and possible updates made to the ticket, please check out the Oracle Bug Database.

Next Steps

To find out if your applications will run into this problem, you can use Access AppScan as it detects which versions of Java is embedded in your applications. Although it won’t be able to determine if Java or GSS API is actually used, it can help identify any potential problems so you can at least use Access Capture’s User Acceptance Testing (UAT) module to bulk test the applications on a machine with Credential Guard switched on.