Credential Guard + WPA2-Enterprise

2018-06-21 • 4 minutes to read

At MMSMOA 2017, there was a great presentation by Nash Pherson and Michael Niehaus called “If You Simply Deploy Windows 10, You Failed.” In short, they talked about how your upgrade to Windows 10 should not just be a task sequence running setup.exe, it should also be your chance to do some course correction, finally address those things that you’ve been meaning to roll out, and pause for a moment to challenge why you’re doing things the way you are today (and continually improve on it).

I’ve modeled every Windows 10 upgrade after this, and it’s allowed for some significant progress in finally deploying things that had been put on the back burner. Most recently was Credential Guard.


What’s Credential Guard?

Credential Guard protects credentials by isolating secrets so only privileged system software can access them. This is done by moving these secrets to an isolated local security process that’s protected using virtualization-based security. This helps prevent credential theft attacks such as Pass-the-Hash or Pass-the-Ticket, and also helps prevent unauthorized/malicious processes from extracting secrets from the LSA.

By design, NTLMv1, MS-CHAPv2, Digest, and CredSSP cannot use signed-in credentials when Credential Guard is enabled, meaning single sign-on doesn’t work with these protocols.


What’s WPA2-Enterprise Got to Do, Got to Do with It?

My laptop had been connected to our WPA2-Enterprise wireless network until I rolled out my Credential Guard pilot policy. One reboot later, I quickly noticed that I was no longer able to connect to the network. Other network types (WPA2-Personal) seemed to be OK. I searched my event viewer and found some less-than-helpful errors (event IDs 12013 and 11006) in the Microsoft-Windows-WLAN-AutoConfig/Operational log:

Wireless security failed.<br /> Reason: Explicit Eap failure received
Error: 0x80070285

Wireless 802.1x authentication failed.<br /> Reason: Explicit Eap failure received
Error: 0x80070285
EAP Reason: 0x285
EAP Root cause String: There was an internal authentication error.
EAP Error: 0x285

Since Credential Guard had been the most recent change (and surely WiFi should still work with it enabled!), I started my troubleshooting there, eventually finding this post. I was later able to confirm that while I thought our WPA2-Enterprise network was using machine certificates to authenticate, it was actually using a Secured Password.

To resolve this, there were two three steps:

Step 0, make sure all your clients have a certificate. (I’m guessing you already have this in place since, if you were like me, you thought you were using them.) If you don’t have a PKI + client certificates deployed, there’s a great walkthrough here (this article is for Configuration Manager + PKI, but that particular section covers how to set up client certificates and autoenrollment).

Step 1, in the NPS/RADIUS server, confirm that Smart Card or other certificate is in your Network Policy:


Step 2, in the GPO deployed to your wireless clients, validate that your trusted root CA certificate(s) are checked and that the authentication method is set to “Smart Card or other certificate” :

Now that these are in place, your clients should be able to connect–this time actually using certificate authentication–even if they have Credential Guard enabled! As an added bonus, this is a change you can apply and existing clients will not lose their network connection (since the NPS/RADIUS server is still accepting certificates and secured passwords). As long as they have a client certificate, they will switch over successfully (and if they don’t, you can quickly identify machines that are probably having issues communicating with Configuration Manager over HTTPS…).

Fun bonus note: If you happen to rename a computer that is connected to your certificate-secured WPA2-Enterprise network, you will need to find a way to connect it to the network a different way for a short period of time after the first reboot. Since the computer name has changed, the client certificate won’t match, and the computer won’t be able to jump on the network. (Fortunately, I’ve found that the autoenrollment for a new certificate happens quickly).


Now you can push forward with your Credential Guard pilot. Onward and upward!



Credential GuardPKI

Updating Service Manager Work Items Ownership (In Bulk!)

Improving the TPM OSD Experience