On Windows clients, this behavior typically indicates either:
- The NPS/MFA flow is working, but Windows is rejecting the server certificate or 802.1X configuration and silently restarting authentication, or
- NPS/MFA is fine, but there is a Windows‑specific 802.1X or certificate trust issue.
Use these steps to isolate and fix it.
- Verify NPS + MFA without the extension
Use the NPS troubleshooting checklist to confirm that basic RADIUS auth works from Windows without the MFA extension:
- On the NPS server, back up the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Authsrv\Parameters.
- Under this key, delete the
AuthorizationDLLs and ExtensionDLLs entries (this temporarily disables the Microsoft Entra MFA NPS extension only).
- Try connecting from the Windows client again.
- If Windows now connects successfully, the issue is specific to the MFA extension or its interaction with Windows 802.1X.
- If it still fails, the issue is with 802.1X/certificates on Windows, not MFA.
- Check Event Viewer on the NPS server for the failure reason codes.
- If the issue is MFA‑specific, check Event Viewer on the NPS server under Applications and Services Logs > Microsoft > AzureMfa > AuthN / AuthZ for related errors.
Network Policy Server troubleshooting guidance
- Check Windows 802.1X client logs
On the Windows machine that cannot connect:
- Open Event Viewer.
- For Wi‑Fi: go to Applications and Services Logs > Microsoft > Windows > WLAN-AutoConfig > Operational.
- For wired 802.1X, use Wired-AutoConfig > Operational.
- Reproduce the connection attempt and review the events for:
- EAP type in use (PEAP, EAP-TLS, etc.).
- Explicit error reasons (certificate validation failure, chain trust failure, revocation check failure, etc.).
Most 802.1X failures on Windows are certificate‑related (invalid cert, wrong EKU, chain not trusted, revocation check failure).
Advanced troubleshooting 802.1X authentication
- Confirm the server certificate used by NPS
On the NPS server:
- Open the NPS snap‑in.
- Go to Policies > Network Policies.
- Open the policy used for Wi‑Fi, go to Constraints tab → Authentication Methods.
- Open the EAP method properties and confirm which server certificate is selected.
Ensure that:
- The certificate is valid (not expired) and has the correct EKU for server authentication.
- The issuing CA is trusted by the Windows client.
If certificate issues are suspected, enable the CAPI2 log on the Windows client for more detail:
- In Event Viewer, go to Applications and Services Logs > Microsoft > Windows > CAPI2.
- Right‑click Operational → Enable Log.
- Reproduce the connection and review CAPI2 events for chain or revocation failures.
Advanced troubleshooting 802.1X authentication
- Fix Windows trust for the NPS server certificate
On workgroup or non‑domain‑joined Windows machines, a common issue is that the CA that issued the NPS server certificate is not trusted for Windows logon/EAP:
- Windows checks whether the issuing CA is in the NTAuth store (
CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE).
- If the CA is not in NTAuth, Windows shows warnings or silently fails 802.1X authentication.
To work around this on a workgroup Windows client:
- Export the issuing CA certificate from the NPS server.
- Copy it to the Windows client.
- Run an elevated Command Prompt on the client:
certutil -enterprise -addstore NTAuth CA_CertFilename.cer
- Retry the Wi‑Fi connection.
This explicitly adds the CA to the NTAuth store so Windows can trust the NPS server certificate for authentication.
Windows Security Alert appears when connecting to a wireless network on a workgroup machine
- Understand duplicate/timeout behavior with NPS extension
The behavior where the Windows client prompts again after a few seconds can also be influenced by RADIUS timeouts and the NPS extension:
- If the VPN/AP or controller RADIUS timeout is too low, it may resend Access‑Request packets while MFA is still in progress.
- NPS with the MFA extension treats these as duplicate requests and discards them by design.
- This can appear as repeated prompts or failed connections on the client, even though MFA was approved.
To minimize this:
- Configure the Wi‑Fi controller/AP RADIUS timeout to at least 60 seconds (90–120 seconds if needed) so the MFA flow can complete without duplicate requests.
Integrate your existing Network Policy Server (NPS) infrastructure with Microsoft Entra multifactor authentication
- Check for July 2024 NPS/RADIUS changes (if recently updated)
If the NPS server has the July 2024 (or later) Windows security updates installed, and the Wi‑Fi controller/AP or firewall does not fully support the RADIUS Message-Authenticator attribute, RADIUS authentication to NPS can fail:
- This affects environments where the RADIUS client (AP/controller/firewall) does not include or process the Message-Authenticator attribute in Access‑Request packets.
- Linux/macOS/iOS/Android may behave differently depending on how the AP/controller handles their requests, so Windows‑only symptoms are possible.
If this matches the timing of when failures started, follow the guidance from the firewall/RADIUS solution provider to ensure Message-Authenticator is supported in both requests and responses.
KB5043417: RADIUS authentication to NPS might fail with the July 2024 security update and later updates
- Summary of concrete next steps
- Temporarily disable the MFA extension via registry (as above) and confirm Windows can connect with plain RADIUS.
- On the Windows client, collect WLAN-AutoConfig and CAPI2 logs during a failed attempt and look for certificate or EAP errors.
- Confirm the NPS server certificate and CA chain, and add the issuing CA to the NTAuth store on the Windows client using
certutil -enterprise -addstore NTAuth.
- Increase RADIUS timeout on the Wi‑Fi controller/AP to at least 60 seconds.
- If NPS was recently patched (July 2024+), verify that the Wi‑Fi controller/firewall supports the RADIUS Message-Authenticator attribute per KB5043417.
These steps will identify whether the issue is certificate trust on Windows, RADIUS/MFA timing, or a post‑update RADIUS compatibility problem, and provide a path to resolution.
References: