Share via

RADIUS Wi-Fi with NPS extension for MFA Windows machine can't connect to the Wi-Fi network

aydinyusifli 0 Reputation points
2026-05-15T07:19:15.21+00:00

Screenshot 2026-05-15 112924

Screenshot 2026-05-15 112410

We have set RADIUS server and NPS extension for MFA. Linux, Macbook, iPhone, Android devices can connect to the network. But when trying to connect from Windows, after entering username and password, and then validating the connection trial from Microsoft authentication app, it tries to connect for 4-5 seconds, and then it stops, and username password prompt appears again. After redoing the same process, this time it says "can't connect". I have tried to import both RADIUS and MFA certificate (istalled by NPS extensin) from Windows server into Windows machine, made them trusted (by copying from personal to root trusted certificates). But the same problem appears again. I don't know what else could I do? I didn't find any solutions on the internet either.

P.S. Windows could connect to the network before MFA was configured, with only RADIUS authentication.

Windows for business | Windows Server | Networking | Network connectivity and file sharing
0 comments No comments

2 answers

Sort by: Most helpful
  1. Jason Nguyen Tran 17,755 Reputation points Independent Advisor
    2026-05-15T08:38:51.0033333+00:00

    Hi aydinyusifli,

    From your explanation, the fact that Windows could connect before MFA was enabled suggests the problem lies in how the NPS extension and certificates are being validated on Windows. Unlike Linux, macOS, or mobile devices, Windows enforces stricter checks on the certificate chain and the EAP handshake. Even if you import the RADIUS and MFA certificates, if the root CA or intermediate certificates are not properly trusted, Windows will reject the connection after the MFA challenge.

    I recommend verifying that the full certificate chain (root and intermediates) is present in the Trusted Root Certification Authorities store on the Windows client. Also, ensure that the certificate used by the NPS extension includes the proper Enhanced Key Usage (EKU) for server authentication. Another common issue is that Windows requires the subject name or SAN on the certificate to match the RADIUS server name being contacted.

    It’s also worth checking the NPS logs for Reason Code 21 errors, which indicate that the extension DLL rejected the request. This can happen if the MFA response is not passed back correctly to the Windows supplicant. Updating the NPS extension to the latest version and confirming that the Microsoft Authenticator app is fully up to date can help.

    As a troubleshooting step, you can temporarily disable MFA on the NPS policy and confirm that Windows connects successfully with just RADIUS. If that works, the issue is definitely in the MFA handshake path rather than the base Wi-Fi configuration.

    I hope this explanation provided some helpful insight. If this answer is helpful, please don’t forget to hit “Accept Answer”.

    Jason.

    Was this answer helpful?


  2. Q&A Assist
    2026-05-15T07:19:42.1133333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    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.

    1. Verify NPS + MFA without the extension

    Use the NPS troubleshooting checklist to confirm that basic RADIUS auth works from Windows without the MFA extension:

    1. On the NPS server, back up the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Authsrv\Parameters.
    2. Under this key, delete the AuthorizationDLLs and ExtensionDLLs entries (this temporarily disables the Microsoft Entra MFA NPS extension only).
    3. 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.
    4. Check Event Viewer on the NPS server for the failure reason codes.
    5. 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

    1. Check Windows 802.1X client logs

    On the Windows machine that cannot connect:

    1. Open Event Viewer.
    2. For Wi‑Fi: go to Applications and Services Logs > Microsoft > Windows > WLAN-AutoConfig > Operational.
      • For wired 802.1X, use Wired-AutoConfig > Operational.
    3. 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

    1. Confirm the server certificate used by NPS

    On the NPS server:

    1. Open the NPS snap‑in.
    2. Go to Policies > Network Policies.
    3. Open the policy used for Wi‑Fi, go to Constraints tab → Authentication Methods.
    4. 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:

    1. In Event Viewer, go to Applications and Services Logs > Microsoft > Windows > CAPI2.
    2. Right‑click OperationalEnable Log.
    3. Reproduce the connection and review CAPI2 events for chain or revocation failures.

    Advanced troubleshooting 802.1X authentication

    1. 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:

    1. Export the issuing CA certificate from the NPS server.
    2. Copy it to the Windows client.
    3. Run an elevated Command Prompt on the client:
         certutil -enterprise -addstore NTAuth CA_CertFilename.cer
      
    4. 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

    1. 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

    1. 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

    1. Summary of concrete next steps
    2. Temporarily disable the MFA extension via registry (as above) and confirm Windows can connect with plain RADIUS.
    3. On the Windows client, collect WLAN-AutoConfig and CAPI2 logs during a failed attempt and look for certificate or EAP errors.
    4. 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.
    5. Increase RADIUS timeout on the Wi‑Fi controller/AP to at least 60 seconds.
    6. 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:

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.