Credential guard can break WiFi when updating to Windows 11 22H2. I noticed that some Windows 11 devices wouldn’t connect to our corporate WiFi. This is secured with 802.1x EAP as per this previous post.
This is caused by a feature in Windows 11 called credential guard being enabled by default:
‘Starting in Windows 11, version 22H2, VBS and Credential Guard are enabled by default on all devices that meet the system requirements.’ – Microsoft Docs
When this feature is enabled, it stops the use of some authentication mechanisms:
‘If you’re using WiFi and VPN endpoints that are based on MS-CHAPv2, they’re subject to similar attacks as for NTLMv1.
For WiFi and VPN connections, it’s recommended to move from MSCHAPv2-based connections (such as PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (such as PEAP-TLS or EAP-TLS).’ – Microsoft Docs
With this in mind, you can follow the advice of moving to certificate-based authentication (not something you want to do on a whim). Especially when you just need to get a device back on the WiFi for an end user.
The other option (though more of a workaround for now) is to disabled Credential Guard. I say workaround because this isn’t going to go away, but it does give you some time to work out a more long term solution, maybe certificate-based authentication. Though having investigated this myself I’m not completely sold on this solution either!
Anyway, if you try to connect to a 802.1 EAP secured WiFi network you will be presented with this:
If I then check the event log under ‘Application and Services Logs > Microsoft > Windows > WLAN-AutoConfig > Operational’ you will see event ID 12013
You can see from the description that ‘There was an internal authentication error.’
To check if credential guard is running in the background you can run a handy script which will tell you which services are enabled and running. This script can be found here.
Download the zip, extract the contents and run as below. First you need to set the PowerShell execution policy to ‘Unrestricted’ on the client you want to check:
Set-ExecutionPolicy -ExecutionPolicy UnrestrictedThen run the readiness tool:
DG_Readiness.ps1 -Ready
You can see from the output on my example that all 3 services are enabled and running, including credential guard.
As we have confirmed credential guard is running, we can now go ahead and disable it to see if this is the root cause.
You can use the readiness tool to disable DG and CG (this is covered in the readme.txt file contained in the download) or you can use Group policy. You can use this tool for testing, but on a larger scale Group Policy is a lot easier.
I would start with the local group policy on that device to check you get the desired effects.
Open ‘Local Group Policy Editor’ and navigate to ‘Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security’
Firstly, disable the policy and reboot the system. This turns off all DG/CG services. This isn’t essential but I have found that explicitly disabling the services and then enabling them works every time. Otherwise, they can persist.
After the reboot you can confirm this by running the readiness tool again.
Open the policy again in GP editor and then enable the services you would like, setting the ‘Credential Guard Configuration’ to ‘Disabled’. Reboot the client again.
Once it’s restarted run the readiness tool again, you should then see Credential guard is not running:
Providing that was the problem you should then be able to connect to your 802.1 EAP secured WiFi.
Lastly make sure that you revert your execution policy on the client back to what it was.
Set-ExecutionPolicy -ExecutionPolicy Restricted
Providing you are happy with the results you can push this out using a central Group Policy. You could just target Windows 11 devices with a WMI filter if needed. However, the device will need network access to get the policy, obviously!
