Entra Hybrid Join + 802.1x using PEAP-MSCHAPv2 + Credential Guard = 'Perfect Storm'

I recently encountered an issue as part of a project involving Entra hybrid join for existing domain joined devices and Co-management where devices stopped connecting to corporate wireless access points automatically. The devices would complain about missing credentials, resulting in authentication errors and eventually give up on connecting to the corporate Wi-Fi. Here is a snapshot of one such error -

The environment is configured with Cisco ISE as the RADIUS solution with an authentication policy relying on PEAP MSCHAPv2 as the authentication protocol. The logs on the Cisco side reflected the same 'Internal authentication error' as seen in the event viewer of the endpoints. This was strange at first because there was nothing set up in Intune or otherwise as part of the Co-management configuration that would interfere with the WiFi settings in general. On further investigation, it was discovered that the issue could very well be related to Credential Guard on the devices. While both Microsoft and Cisco ISE have published a known issue where Credential Guard can cause issues with PEAP-MSCHAPv2 in general, there is no direct mention the issue affecting Hybrid joined devices explicitly.

So why does the issue arise only after devices are Hybrid joined? Let's break things down -

1. MSCHAPv2 requires access to NTLM-derived password hashes for the computer account. For machine authentication, Windows uses the machine password stored under LSA.

2. With Credential Guard enabled, it protects NTLM secrets, Kerberos tickets, and LSA credentials inside LSA. This means that LSASS no longer directly exposes NTLM machine credentials, thus resulting in slowing down or blocking of some NTLM\MSCHAP authentication flows.

3. In a usual setup, Cisco ISE policy requires machine authentication i.e. AD machine account. Which means it is expecting machine authentication using the protocol set for WiFi authentication, MSCHAPv2 in this case. It will use Active Directory as the identity source and use the AD computer account to validate the machine NTLM response, which will not be available immediately if machine's NTLM hash isn't available due to Credential Guard being enabled, resulting in ISE throwing the "EAP Failure / Authentication Error"

But why does this process work on LAN but not Wi-Fi?

1. On LAN Kerberos is expected to be immediately available as there is direct line of sight to the Domain Controller.

2. Machine password is accessible without wireless race conditions

3. There is no dependency on 802.1x driver being available.

4. There is no need for a pre-logon against the Wi-Fi access point.

5. There are no delays in Virtual Secure Mode (VSM) startup because network stack initializes differently.

7. Machine-based NTLM flows succeeds even with Credential Guard ON.

When you look at the entire process, suddenly the behavior involving the authentication issue starts making sense.

Now coming to the solution. Well the long term solution is to obviously move to EAP-TLS based authentication leveraging user or device based certificates. This will allow the validation and authentication to take place locally on the device, thus leaving no scope for authentication related errors.

However, it can be a big change for any organization and such a change needs to be well planned out. In the interim, organizations can disable Credential Guard which in my opinion should only be implemented as a temporary solution and not long term.

To disable Credential Guard, one can use GPO, Intune to configure the policy, but during my testing I noticed that it involved a little more than just creating the policy using built in settings in .admx or CSPs. The relevant setting in question '(Disabled) Turns off Credential Guard' is expected to disable Credential Guard and it set the value 0 for LsaCfgFlags registry value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. However, in the newer version of Windows 11, there is another registry LsaCFGFlagsDefault under the same location that enables the Credential Guard by default. This appears to take precedence thus leaving the setting against LsaCfgFlags ineffective. When this happens, Credential Guard will still show as enabled. This can be quickly verified in System info.

To address this, I decided to use remediation script feature in Intune. Here are the scripts that you can use -

Discovery Script - Detect_CredentialGuard_Enabled_v1.0.ps1

$lsa_flags = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -ErrorAction SilentlyContinue | Select-Object -ExpandProperty LsaCfgFlags

$lsa_flagsdefault = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlagsDefault" -ErrorAction SilentlyContinue | Select-Object -ExpandProperty LsaCfgFlagsDefault

# Check if LsaCfgFlags or LsaCfgFlagsDefault are running anything other than 0 (meaning configured to run)

if ($lsa_flagsdefault -ne 0 -or $lsa_flags -ne 0) {

    Write-Host "Credential Guard is currently running or configured to run. Remediation needed."

    exit 1

} else {

    Write-Host "Credential Guard is disabled/not running. No remediation needed."

    exit 0

}

Remediation Script - Remediate_CredentialGuard_Disable_v1.0.ps1

$registryPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"

$lsaFlagsName = "LsaCfgFlags"

$lsaFlagsDefaultName = "LsaCfgFlagsDefault"

$value = 0

# Set LsaCfgFlags & LsaCfgFlagsDefault to 0 to explicitly disable CG

New-ItemProperty -Path $registryPath -Name $lsaFlagsName -Value $value -PropertyType DWORD -Force

New-ItemProperty -Path $registryPath -Name $lsaFlagsDefaultName -Value $value -PropertyType DWORD -Force

Following are the steps to set things up in Intune -

1. Sign-in to the Microsoft Intune admin portal.

2. Browse to Devices > Scripts & remediations – Create

3. Fill the relevant fields like Name, Description, Publisher etc and hit Next.

4. In the settings section, select the relevant detection and remediation scripts as covered above in the blog.

5. Run the script in 64-bit PowerShell and leave the rest of the options to Default.

6. Assign to a group of devices with a schedule that you desire. I making it run every day at 0900.

Once the remediation script runs, it should modify the registries when required and report the status back to Intune.

When the discovery script runs and picks a device as compliant and requires no remediation, the following compliance will be returned.

When the discovery script runs but picks a device needing remediation, the remediation script will run and the discovery script will once again be evaluated finally reporting a compliant message as shown below.

That's it. Once Credential Guard got disabled, the authentication against the WiFi access point worked seamlessly for me.

Note: For changes made to the state of Credential Guard to come into effect, a device restart is needed.

Until next time..

References:

https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-how-it-works

https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues

https://learn.microsoft.com/en-us/windows/security/authentication/microsoft-ntlm