How to Configure Credential Guard Through Group Policy on Windows Server 2016


Credential Guard in Windows Server 2016 allows you to protect in-memory credentials. This article explains how Credential Guard works and how you can configure it via Group Policy.


Credential Guard requirements

At first blush, the Credential Guard hardware and software requirements seem pretty steep, at least if your shop doesn’t have fairly current hardware. Here’s the list:
  • Operating systems: 64-bit Windows 10 Enterprise or Windows Server 2016
  • Firmware: UEFI firmware v2.3.1 or higher. The key point here is that the system’s UEFI must support Secure Boot. Recall that Secure Boot is a UEFI feature embraced by Microsoft that prevents unsigned (unauthorized) OS loaders or device drivers from loading during startup.
  • CPU virtualization extensions: Intel VT-x or AMD-V with SLAT support
  • TPM v 1.2 or 2.0: Trusted Platform Module (TPM) is a motherboard chip that stores Credential Guard encryption keys
As of this writing, you can’t enable Credential Guard on a Windows 10-based VM.


Enabling Credential Guard via Group Policy

The easiest way to deploy Credential Guard is to do so in local or domain Group Policy. Pop open your Group Policy editor and navigate to the following location:

Computer Configuration\Administrative Templates\System\Device Guard

We’re looking for the policy named “Turn on Virtualization Based Security,” as shown in the following screen capture from my Windows Server 2016 Technical Preview (TP) 5 VM:


Disabling Credential Guard

After enabling this policy, you have two choices about how you want Credential Guard to behave:
  • Enabled with UEFI lock: Credential Guard can’t be remotely disabled. An administrator needs to locally logon to the machine in question to disable the feature (along with modifying Group Policy if necessary).
  • Enabled without lock: Credential Guard can be disabled remotely via Group Policy.
However, you’ll want to perform due diligence before enabling Credential Guard across your enterprise. The reason for this is that Credential Guard prevents the use of older NTLM credentials and unconstrained Kerberos delegation for security reasons. That second point may tweak a few of you in our readership because Kerberos delegation is a standard method to allow our line-of-business (LOB) applications to forward account credentials.

We can use good ol’ System Information (msinfo32.exe) to determine whether Credential Guard is enabled or disabled. My virtual machine wouldn’t work with UEFI, so you can see in the following screenshot that Credential Guard is enabled but not running:


Remaining vulnerabilities

We must always keep in mind that no single security feature or measure alone provides complete protection. Here’s a laundry list of scenarios that Credential Guard can’t mitigate:
  • Software that doesn’t store secrets within Windows feature protection (Microsoft recently announced that Credential Guard now protects credentials stored in Windows Credential Manager.)
  • Local user accounts
  • Microsoft Accounts
  • Key loggers or other physical attacks

No comments:

Powered by Blogger.