Windows Defender Credential Guard uses virtualization-based security to secure secrets on Windows 10 Enterpirse and Windows Server 2019 machines. Using this method, only privileged system software can access them. Windows Defender Credential Guard will help preventing unauthorized access that can lead to credential theft attack. In this tutorial I will show you how to implement Windows Credential Guard.
How it works
Windows Defender Credential Guard prevents hackers and/or malware from retrieving NTLM password hashes, Kerberos Ticket Granting Tickets, and credentials stored by applications such as domain credentials. It accomplish this by isolating these features virtually using Hyper-V running on the local system. The Local Security Authority (LSA) that runs on modern Windows 10 devices, will talk to a new component called the isolated LSA process.
This process runs virtually and stores and protect secrets. As a result, the isolated process is not accessible by the operating system other than the local LSA.
This islolated LSA process will only host a small subset of operating system binaries that it needs to be functional. Certificates sign binaries with a certficate, whereas this is trusted by the virtualization-bases security. When the signature could not be verified, the isolated LSA process will fail to launch.
Known limitations
Note: It is important to investigate what Windows Defender Credential Guard might break in your production environment. Important authentication flows like wireless network access or application access through single sign-on might fail.
Security mostly comes at a cost. Functionality is limited. Of course, Windows Defender Credential Guard is no exception. Applications will break if they require:
- Kerberos DES encryption support
- Kerberos unconstrained delegation
- Extracting the Kerberos TGT
- NTLMv1
Applications will prompt and expose credentials to risk if they require:
- Digest authentication
- Credential delegation
- MS-CHAPv2
However, applications can prompt for credentials or use credentials stores in Windows Vault which is not potected by Windows Defender Credential Guard. Kerberos does not allow unconstrained Kerberos delegation or DES encryption, not only for signed-in credentials, but also prompted or saved credentials.
Check device capability for Windows Defender Credential Guard
Note: It is recommended to confirm that every device in your environment is capable of running Windows Defender Credential Guard.
There are some specific hardware requirements for Windows Defender Credentual Guard to work. I invested some time in creating a script myself, but there is a lot to check and verify. Luckily Microsoft provides PowerShell code that can be run from the device to check if all requirements are met.
After you have sucessfully copied the PowerShell code, save the file on the device and open a new PowerShell console with administrative access. Save the file as DG_Readiness.ps1 in C:\Defender.
Set-Location 'C:\Defender'
.\DG_Readiness.ps1 -CapableEnable for devices managed by Microsoft Intune
Access your Microsoft Intune tenant by logging in to the Microsoft Endpoint Manager admin center. Next, go to Endpoint Security and create a new policy under Account protection. Please be aware that this feature is still in preview at the time of writing.
Give the new policy a name that will suit with the rest of your environment. You might also want to add a description. When everything is filled in, click on Next.
For the purpose of this demonstration the profile has been assigned to All Devices.
Conclusion
With Windows Defender Credential Guard you will take another step to prevent credential theft on managed devices. End users do not oversee potential threats which evidently lead to a higher risk on a day to day basis. Configuring and implementing this feature in Microsoft Intune is easy and with good testing and evaluating almost nothing can go wrong.
Do you still have any questions? Please feel free to comment below or send me a message here.