WPA-Enterprise 802.1X (PEAP) clients fail to connect after Windows update

Options
Zyxel_HsinBo
Zyxel_HsinBo Posts: 530
Zyxel Certified Network Engineer Level 2 - Switch Zyxel Certified Network Engineer Level 1 - Switch Zyxel Certified Network Administrator - Security Zyxel Certified Network Administrator - WLAN
image  Zyxel Employee
edited October 21 in Other Topics

Symptom
After the October 2026 Windows security update, Windows 11 clients can no longer connect to an SSID that uses 802.1X PEAP-MSCHAPv2.

  • Nebula shows the client associating and then “Station left”, repeatedly.
  • It fails when Windows supplies the credentials automatically (Single Sign-On with “Automatically use my Windows logon name and password”).
  • It works when the user enters the username and password manually.
  • The RADIUS server shows no Access-Reject.

Affected environments

  • Windows 11 24H2 / 25H2 / 26H2 with KB5127648 installed, and Windows Server 2025 with KB5126646.
  • 802.1X with PEAP-MSCHAPv2 or EAP-MSCHAPv2 (Wi-Fi or wired) using Single Sign-On with Windows logon credentials.
  • Only devices where Windows Credential Guard is disabled.

Not affected: PSK networks, certificate-based authentication (EAP-TLS / PEAP-TLS), and manually entered credentials. The issue does not depend on the AP model or Nebula settings.

Cause
This is a planned Windows security change, not a bug. MS-CHAPv2 still relies on NTLMv1-derived credentials. Starting with the October 2026 update, if the registry value BlockNtlmv1SSO has not been configured, Windows switches its default from Audit to Enforce and blocks these credentials from being used for Single Sign-On. The client cannot generate the MSCHAPv2 response, so no credentials are sent to the RADIUS server and the client disconnects.

This is a Windows-side change. No setting on the AP, Nebula or the RADIUS server can fix it.

How to confirm

  1. Check that KB5127648 is installed: Settings > Windows Update > Update history.
  2. In Event Viewer, open Applications and Services Logs > Microsoft > Windows > NTLM > Operational and look for Event ID 4025 (“An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy”) at the time of the failure.
  3. Optional quick test: clear “Automatically use my Windows logon name and password” in the SSID’s PEAP settings and enter the credentials manually. If the client connects, it is this issue.

Solution

Workaround 1 (recommended): set BlockNtlmv1SSO to Audit mode
Run as administrator. No restart is required:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

This keeps the October security fixes installed. For multiple clients, deploy the value through Group Policy Preferences or Intune. This lowers protection, so use it only as a temporary measure.

Workaround 2: uninstall KB5127648
Use only if the registry change cannot be applied.

  1. Go to Settings > Windows Update > Update history > Uninstall updates and remove KB5127648, or run wusa /uninstall /kb:5127648 as administrator.
  2. Reboot the client and connect again.
  3. Pause Windows Update so the update is not reinstalled.

Uninstalling also removes the October security fixes, and later cumulative updates will bring back the same behavior.

Long-term solution
Microsoft recommends removing the dependency on MS-CHAPv2 and moving to certificate-based authentication such as EAP-TLS or PEAP-TLS.

References

Categories

EnglishTiếng ViệtРусскийไทย中文（台灣）