If you would like to read the other parts in this article series please go to:
In the previous article in this series, I explained some of the inner workings of Credential Guard. In this article, I want to go ahead and conclude the series by showing you how to enable Credential Guard for your Windows Server 2016 servers and Windows 10 client devices.
Given the length of the technical explanation of Credential Guard in the first two articles in this series, it would be easy to assume that Credential Guard is difficult to configure. However, enabling Credential Guard is surprisingly easy.
For the purposes of this article, I am assuming that Windows Server 2016 has been installed on a physical server. I am also assuming that you have enabled hardware level virtualization, and that you have installed the Hyper-V role.
So with that said, the first step in setting up credential guard is to enable Virtual Secure Mode. The easiest way to accomplish this is through the Group Policy Editor. To do so, open the Group Policy Editor and load the group policy object within which you want to enable Virtual Secure Mode. Now, navigate through the console tree to Computer Configuration \ Administrative Templates \ System \ Device Guard. As you can see in Figure A, the Device Guard container includes a group policy setting called Turn On Virtualization Based Security.
You can use group policy to turn on virtualization based security.
If you double click on this group policy setting, you will see that once enabled, the policy setting contains a number of different options. The reason for this is that Virtual Secure Mode has a variety of different capabilities, which can be enabled or disabled as needed. You can see the available options in Figure B.
The group policy setting provides a number of different configuration options.
The first option shown in the figure above allows you to select the platform security level. You can choose to enable either secure boot or secure boot with DMA protection.
The second option is Virtualization Based Protection of Code Integrity. When this option is enabled, Windows does two things. First, it protects the code integrity validation path. Second, it enables protection for kernel mode memory.
The Virtualization Based Protection of Code Integrity feature also includes a UEFI Lock option. If the feature is enabled with the UEFI lock, then Windows is protected against virtualization based protection of code integrity being disabled by remote. If code integrity protection is enabled without the UEFI lock, then the code will still be protected, but the protection can be remotely disabled.
The last configuration option shown in the figure above is the option that is the most relevant to this article series. This is the Credential Guard Configuration option. As you can see in Figure C, this feature is like the Virtualization Based Protection of Code Integrity feature in that it can be enabled with or without the UEFI lock. Once again, the UEFI lock prevents protection from being remotely disabled.
So as you can see, it’s really easy to enable Credential Guard. So how can we confirm that it is working? Well, if you think back to the previous article in this series, you will recall that Credential Guard works by taking the secrets that would have otherwise been stored in the Local Security Authority (LSA), and placing those secrets into an isolated LSA process instead. Surprisingly, Task Manager’s list of processes does not seem to provide any sort of confirmation that Credential Guard is running. Even so, there are other ways of verifying that Credential Guard is in use.
The easiest method of checking Credential Guard’s status is to enter the MSINFO32 command at the server’s Run prompt. This causes Windows to launch the System Information tool. If you go to this tool’s System Summary tab, and then scroll down toward the bottom, you will see several mentions of Device Guard. You can use this information to confirm that the Device Guard services are running, and to see which Device Guard security services have been configured. If you look at Figure D for instance, you can see that Device Guard virtualization based security is running on this server, and that the only Device Guard security service that has been configured is Credential Guard. You can also see that the Device Guard security services are indeed running.
Microsoft’s System Information tool can confirm that Device Guard and Credential Guard are functional.
Another way that you can verify that Credential Guard is working is by using a utility called Mimikatz. Mimikatz is a hacking utility that can be used to expose a wide variety of Windows account information. I saw a live demo last year while I was in Redmond, in which Mimikatz specifically reported that the LSA data on a server that was running Credential Guard had been isolated. After doing a bit of searching, I managed to find a Web site in which someone had posted the results of the Mimikatz demo 9 http://deploymentresearch.com/Research/Post/490/Enabling-Virtual-Secure-Mode-VSM-in-Windows-10-Enterprise-Build-10130).
It is possible to download Mimikatz, and try this experiment for yourself. However, at the time that I was writing this article, my antivirus software kept reporting that the copies of Mimikatz that I was attempting to download were infected with malware. You should therefore exercise extreme caution if you attempt to download Mimikatz.
As you can see, it is surprisingly easy to enable Credential Guard on a Windows Server. All you have to do is to enable the appropriate group policy settings. After enabling these settings, I also rebooted my server, but I have not seen anything in the documentation indicating that a reboot is required.
One of the nice things about Credential Guard is that its use is not confined to Windows Server. Windows 10 also supports Credential Guard. Enabling Credential Guard or other Virtualization Based Security features on your Windows 10 endpoints is a great way to improve your organization’s overall security.