Those who had familiarized themselves with Credential Guard in Windows 10 prior to the Anniversary, i.e. version 1607, Update may have found that the ways to enable and configuring the feature seem have changed sine the release. Indeed, there are a few discrepancies in UI and hence operations between 1607 and 1511. And they are for the better actually. It is now easier and simpler to assess the readiness and configure Credential Guard.
For those who are new to Device Guard and Credential Guard, it is important to have some technical background and knowledge of specific hardware and software requirements. So when it comes to hardware or software refresh, you can plan accordingly. Here is a must read documentation, Protect derived domain credentials with Credential Guard. And do take time to survey and inventory your environment, if not already. Assess what you have and how devices are being used, and identify business needs and candidates for employing Credential Guard. Do set up a sandbox environment to test the settings and make sure you have established recoverability before approaching to your production devices.
Going forward, to assess and configure Credential Guard, just:
- Download and extract Device Guard and Credential Guard hardware readiness tool. This tool is designed to work with high accuracy on Windows 10, version 1607, in addition will also work on Windows 10, versions 1507 and 1511.
- In an admin command prompt, run the tool with an intended switch/parameter as explained in the readme file. By default, a log is created at C:\DGLogs.
The following is a sample session where I ran the tool in an admin command prompt with a “–ready” switch to assess the readiness of the local system for Device Guard/Credential Guard. I however had to first relax the PowerShell execution policy to “unrestricted” for the tool which is not digitally signed to run under my device’s current script execution policy set to “RemoteSigned.”
Note that the cmdlet, Set-ExecutionpPolicy, is scoped to LocalMachine as the default. Running Set-ExecutionPolicy without specifying the scope will also change the default execution policy of the local machine. To avoid inadvertently changing this security measure, a common practice is to ALWAYS run Set-ExecutionPolicy with the “-scope” parameter to explicitly and specifically define the impact of a to be introduced change in script execution policy. Here I set the scope to “process”, the execution policy was dynamically set to “Unrestricted” during the execution so the tool could run, and reset to “RemoteSigned” once having finished the process, as confirmed by the output of a following Get-ExecutionPolicy. In the sample session, my Windows 10 Enterprise device had been already configured and running Credential Guard, as indicated in the output, however my device was not configured with a Hardware Code Integrity policy which is a great feature of Device Guard, the other landmark security feature of Windows 10 Enterprise.
The same as before, once Credential Guard is properly configured, up and running, you should find in Task Manager the ‘Credential Guard’ process and ‘lsaiso.exe’ listed in the Details page as below.
And ultimately integrate this tool with your deployment and configuration management processes to assess the readiness, configure and manage Credential Guard for Windows 10 Enterprise devices in a managed environment. And that’s when no more long nights for configuring and troubleshooting a Credential Guard roll-out.
Witnessing a clear cloudy day every day 