Troubleshooting access to networks protected by Portnox Cloud

In this topic, you will learn how to address the most common issues when connecting to networks protected by Portnox™ Cloud.

Why do Windows devices fail 802.1x authentication after upgrading to Windows 11 version 22H2 or later?

After upgrading to Windows 11 version 22H2 or later, some Windows devices fail to authenticate using 802.1x. These devices can still connect to the network when 802.1x is not required. In the AAA logs, the only error shown is EAP FAILED (EXPIRED) during the PEAP Phase 2 initialization.

This issue affects devices that use 802.1x for wireless or wired network access, RDP, or VPN connections that rely on insecure, password-based authentication protocols. When Credential Guard is enabled, users cannot use Single Sign-On (SSO) and must manually enter credentials for each new Windows session.

Any device with Credential Guard enabled can encounter this issue. Starting with Windows 11 version 22H2 and Windows Server 2025 (preview), Credential Guard is enabled by default on eligible devices unless it was explicitly disabled. This applies to Enterprise (E3 and E5) and Education licenses, and to some Pro licenses, as long as the device meets the minimum hardware requirements.

The root cause is that Credential Guard blocks insecure authentication protocols that use password-based authentication, because these protocols can expose passwords on the client or server. Affected protocols include Kerberos unconstrained delegation, Kerberos with PKINIT using RSA instead of Diffie-Hellman, MS-CHAP, WDigest, and NTLM v1. For MS-CHAP, WDigest, and NTLM v1, only SSO is blocked, and users can still authenticate by manually entering credentials.

Microsoft recommends moving away from MS-CHAPv2-based methods such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, and using certificate-based authentication instead, such as PEAP-TLS or EAP-TLS. Credential Guard does not block certificate-based authentication.

As a temporary but less secure workaround, you can disable Credential Guard. Credential Guard does not support per-protocol or per-application settings, so it must be fully enabled or disabled. Disabling it increases the risk of stored domain credentials being stolen.

This information is based on Microsoft documentation titled Considerations and known issues when using Credential Guard. Third-party information is provided for reference only and should be independently verified. Use of such information is at your own risk.

Why are devices not assigned to the fallback VLAN when using MSCHAPv2 authentication?

When using MSCHAPv2 authentication, devices that fail authentication are rejected instead of being assigned to the fallback VLAN. This occurs even if the fallback VLAN is properly configured and works correctly with other authentication methods. This behavior has been observed on Ubiquiti access points but can also happen on other network devices.

The reason is that MSCHAPv2 handles authentication strictly. It verifies a user’s password by generating a special code called the NTKey. If the password is incorrect or the account does not exist, the authentication process fails, and the device stops communicating with the network entirely. Since the device loses connectivity during this failure, the network cannot assign it to a fallback or quarantine VLAN.

Because MSCHAPv2 enforces this strict behavior for security reasons, there is no workaround to enable fallback VLAN assignment for devices using this authentication method. The only solution is to use an alternative authentication method that supports fallback VLANs.