Enable Credential Guard in Windows 10 during OSD w/ ConfigMgr

Update 9/27/2016 -This post was originally written for 1511, With Win10 1607, you no longer need to add Isolated User Mode - More info Here along with another nice way to deploy it.

I set this up a couple weeks ago and have been meeting to write something up.  Then before I could, Peter over at syscenramblings posted a nice how to HERE.

I’m going to post mine anyway, even if it’s not as fancy.  I’ve been going with the “KISS principle (keep it stupid simple)” model for OSD, and it’s been working well for me.  So while sure, you can do it in one step, I’m going to show you how to do it in several additional steps, but no packages are required. Smile

All information used to create these steps were based on this information: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard
I did find what appears to be a discrepancy in their documentation, I make more notes at the bottom.

My Example is done on a New Dell Laptop
UEFI & SecureBoot Enabled in Bios.
My Credential Guard Setup is:

  1. Require Secure Boot and DMA Protection
  2. Credential Guard Enabled

I’ve got two sections in my TS setup for this, one Group that installs the Windows Components, and another that sets the registry keys.

  1. Group “Enable HyperV & Isolated User Mode UEFI” – This is done nearly right after applying the image, my image gets loaded to drive C, you’ll want to make sure you adjust accordingly.  This is still while in PE, even before loading the Drivers.
    image
    image

    1. Enable HyperV Role - Step 1
      cmd /c Dism.exe /image:c: /Enable-Feature /FeatureName:Microsoft-Hyper-V /All
      image
    2. Enable HyperV Role - Step 2 (This is Optional, I like to add the Client tools as many of my users use Local Virtual Machines)
      cmd /c Dism.exe /image:c: /Enable-Feature /FeatureName:Microsoft-Hyper-V-Management-Clients /All
      image
    3. Enable Isolated User Mode- Step 3
      cmd /c Dism.exe /image:c: /Enable-Feature /FeatureName:IsolatedUserMode
      image
  2. Group “Turn on Credential Guard” – Much later in TS, typically after I’ve already installed Apps, etc.
    image
    image

    1. Tweak - Enable virtualization-based security Key 1
      REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard" /V EnableVirtualizationBasedSecurity /T REG_DWORD /D 1 /F
      image
    2. Tweak - Enable virtualization-based security Key 2 *Differs from TechNet documentation, see notes below.
      REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard" /V RequirePlatformSecurityFeatures /T REG_DWORD /D 3 /F
      image
    3. Tweak - Enable virtualization-based security Key 3
      REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA" /V LsaCfgFlags /T REG_DWORD /D 1 /F
      image

Just make sure you get a reboot in there, I got a few reboots in my TS between the first group and after the last group for other processes in the TS, since I already had reboots for those steps, I didn’t need to add any additional.  I would suggest doing what Peter illustrates in his post to add a reboot outside of the Task Sequence, I’ve been doing this for a couple years to resolve other issues at the advice of Johan during one of his sessions.  Peter’s Blog shows a nice illustration of how to set that up.
After First Logon, I double check msinfo32 to confirm that indeed Credential Guard is running with the settings I wanted.

One thing I’ve noticed that seems to be a discrepancy in the TechNet article.
image

When I set the RequirePlatformSecurityFeatures  to 2, it does not list Secure Boot
image

However, if I set that key to 3, it then reports:
image

While I honestly don’t know if this makes a difference, I’d really like it to show up in msinfo32 correctly.  If you set the setting via Group Policy and NOT OSD, it does show correctly, and it will set the Registry to value 3.  So that’s what I’m going with.

PS.. I also have it setup in Group Policy using the settings outlined in that article for the Machines that were Imaged before I implemented this.  After imaging, and group policy applies, it does “fix” the registry keys you set during OSD, and it will show up in msinfo32 correctly.  I’d just let to get it right out of the gate instead of having to wait for Group Policy to kick in and reboot the machine.

Group Policy will also add the registry key HypervisorEnforcedCodeIntegrity ,which I’m not setting at all during OSD.
Here are the settings from machine setup via Group Policy post OSD
image

Here are is one that is setup through OSD before Group Policy updates it:
image

I hope you find this useful.

For the Machines that I had already deployed, I used Group Policy to enable the Settings, and pushed out a “Application” to finish the setup.
image

image
image

image
I changed Return Code 0 to “Hard Reboot” so when it’s done it would request you to reboot, so it could finish the Feature Installs, the Detection Method will also fail until after the reboot, as it is looking for the Feature IsolatedUserMode to be enabled in the registry.

Batch File: You don’t need the registry info in there, but incase you want to set this up without group policy , just add the keys.  I had it set that way so I could test before using Group Policy.
---------

dism /online /Enable-Feature /FeatureName:IsolatedUserMode /LogPath:C:\CABS\InstalLLogs\IsolatedUserMode.log /NoRestart

REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard" /V EnableVirtualizationBasedSecurity /T REG_DWORD /D 1 /F
REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard" /V RequirePlatformSecurityFeatures /T REG_DWORD /D 3 /F
REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA" /V LsaCfgFlags /T REG_DWORD /D 1 /F

---------------

image

I only had to enable the feature IsolatedUserMode because I have HyperV enabled on all of my Windows 10 machines by default in OSD.  If you didn’t do this, you can modify that line to look like:

dism /online /Enable-Feature /FeatureName:IsolatedUserMode /FeatureName:Microsoft-Hyper-V /All /LogPath:C:\CABS\InstalLLogs\IsolatedUserMode.log /NoRestart

Hope this was useful.  Feel free to leave a comment.

6 thoughts on “Enable Credential Guard in Windows 10 during OSD w/ ConfigMgr

  • May 4, 2016 at 10:31 am
    Permalink

    If you wanted the application detection method to work before a restart, you could use a powershell script to check the value of (Get-WindowsOptionalFeature -Online | ? FeatureName -eq 'IsolatedUserMode').State to see if it equals Enabled.

    Reply
  • June 15, 2016 at 10:56 pm
    Permalink

    Nice article - I think this is the simplest way I've seen to do this so far. Question - have you ever tried to then enable the Credential Guard registry key prior to the joining of the domain? I'm working for a client who has spoken to a Microsoft PFE, and apparently it was suggested to enable Credential Guard prior to joining the domain so that the credentials used to join the domain were protected.

    Reply
    • June 16, 2016 at 8:47 am
      Permalink

      Thank you. I have not tried to do it before it was domain joined. Thought never actually crossed my mind. I didn't think it was necessary to enable it prior to domain join, as I thought it was more to protect you from having your credentials passed when the machine was compromised. During the OSD process, the machine is in the most secure state it will be (never have been logged on, or used). I would think the risk would be so small, if any, to the credentials being used to join the domain. I would be interested to learn more about this as well, to see if there is a risk during OSD and if it is beneficial to enable credential guard pre-domain join. I suppose you could have those registry keys added during sysprep. Perhaps build the HyperV and Isolated User Mode features into the Reference Image. Sounds like something fun to figure out. Let me know if you end up doing that.

      Reply
    • June 17, 2016 at 12:44 pm
      Permalink

      I'm adding the Roles & Registry Key's to my Build and Capture image. So Far it looks promising. I'll let you know if doing it that way enables Credential Guard before domain join. Probably be next week.

      Reply
  • July 26, 2016 at 6:17 pm
    Permalink

    Only just got clarification from the Microsoft PFE that as long as the domain join happens during the WinPE phase of the build, then the credentials aren't cached, and therefore no need to have Credential Guard enabled prior to domain join.
    Needless to say though, I'll be using the article as my Credential Guard guide in future.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *