Share via

Windows NPS with CA 802.1x wired

Paweł Wójcik 0 Reputation points
2026-06-03T13:25:00.5166667+00:00

I am experiencing an issue with 802.1X authentication. This is the first user/computer attempting to authenticate in this setup.

The environment consists of Windows 11 clients and Windows Server 2025. On the server side, NPS is configured with network policies, and Certificate Services (CA) is deployed.

I created a profile for computer certificate-based authentication, issued an auto-enrolled certificate, and authentication using the computer certificate works correctly.

However, when I switch the profile to user authentication, I receive the following error:

Reason: 0x50005

Reason Text: Network authentication failed due to a problem with the user account

Error Code: 0x40420110

It appears that Windows 11 may be validating the certificate locally. When I click "Login" the error appears immediately, without waiting for a response from the server, which suggests the failure occurs on the client side before reaching NPS.

The Windows 11 client has the Root CA installed, so the trust requirement should be satisfied. The certificate is valid. The only potential issue I can think of is CRL validation, since the client does not yet have network access. However, I verified that the CRL is present in the local cache, so in theory this requirement should also be met.

Do you have any suggestions on what else could be causing this issue, what additional checks I should perform, or where I might have made a mistake?

Thank you for your assistance.

Windows for business | Windows Server | Directory services | Certificates and public key infrastructure (PKI)
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Tan Vu 2,735 Reputation points Independent Advisor
    2026-06-03T14:09:16.3866667+00:00

    Hello, the 0x50005 error appearing immediately means that the Windows 11 machine is blocking local authentication and hasn't sent any packets to the NPS server. Since the Computer certificate is already running, this error is 90% likely due to the User certificate configuration.

    Please quickly resolve this using the concise steps below:

    1. Modify the Certificate Template on the CA Server (Main Cause)

    Windows 11 requires the User certificate to contain account identification information.

    • On the CA Server, open the Certificate Templates Console -> Right-click on the User template -> Properties -> Subject Name tab.
    • Check the box "Include User Principal Name (UPN) in subject alternative name".
    • Delete the old certificate on the client machine and auto-enroll a new certificate.
    1. Verify the Certificate on the Client

    Open certmgr.msc (Current User) on the Windows 11 machine and check the following three factors:

    • The certificate must be in the Current User's Personal storage (not the machine's).
    • Double-click the certificate; ensure there is a small key icon (indicating "You have a private key that corresponds to this certificate").
    • In the Details tab -> Enhanced Key Usage, the line Client Authentication (1.3.6.1.5.5.7.3.2) must be present.
    1. Verify the 802.1X Profile Configuration on the Client
    • Go to Network Properties (Wired/Wireless Properties) -> Security tab -> Select Smart Card or other certificate -> Click Settings -> Click Advanced.
    • Temporarily uncheck advanced filters such as Certificate Issuers or EKU to prevent Windows from automatically filtering out the user's certificate.
    1. Eliminating Windows Hello (PIN/Fingerprint) Conflicts

    If a user is logging into their computer using a PIN or fingerprint, Windows 11 will sometimes try to use the Windows Hello certificate for 802.1X authentication, causing errors.

    -> Sign out and log back in using your traditional Domain Password, then click Login again.

    TV

    Was this answer helpful?

  2. AI answer

    2026-06-03T13:25:35.9333333+00:00

    Based on the described behavior and the provided data, focus troubleshooting on certificate-based user authentication and 802.1X client-side validation.

    Key areas to verify:

    1. EAP method and certificate usage
      • Confirm which EAP method is configured in the NPS network policy (for example, EAP‑TLS vs. PEAP‑MS‑CHAP v2).
      • For EAP‑TLS (user certificate):
        • Ensure the user certificate is present in the user’s personal certificate store on the Windows 11 client and is issued by a CA that the NPS trusts.
        • Ensure the organization’s CA certificate is in the Trusted Root Certification Authorities store for both Local Computer and Current User on all clients and NPS servers, as required for EAP‑TLS.
      • For PEAP‑MS‑CHAP v2 (password-based user auth):
        • Ensure the NPS server certificate meets the minimum server certificate requirements and is issued by a CA trusted by the client.
    2. Client-side certificate validation and CRL
      • Most 802.1X issues are caused by certificate problems such as invalid certificate, expiration, chain verification failure, or revocation check failure.
      • Because the error appears immediately on the client, check the client-side logs:
        • For wired 802.1X: Event Viewer → Applications and Services Logs → Microsoft → Windows → Wired-AutoConfig → Operational.
        • For wireless (if applicable): … → WLAN-AutoConfig → Operational.
      • Enable and review the CAPI2 Operational log on the client to see detailed certificate chain and CRL validation events:
        • In Event Viewer, go to Applications and Services Logs → Microsoft → Windows → CAPI2 → Operational, right-click Operational, and select Enable Log.
        • Alternatively, use: 
                 wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true
       wevtutil sl Microsoft-Windows-CAPI2/Operational /ms:104857600
      • Look for events indicating chain or revocation failures for the user certificate or intermediate CA.
    3. NPS and CRL availability design
      • For certificate-based methods (EAP‑TLS, PEAP‑TLS), NPS checks the revocation status for all certificates in the chain. If revocation check fails for any certificate, the connection is denied.
      • Ensure CRLs for all CAs in the chain are:
        • Published and not expired.
        • Accessible from all NPS servers and, where applicable, from clients.
      • Design CRL distribution for high availability (multiple CRL distribution points, appropriate publication schedules). If CRLs are unavailable to NPS, all certificate-based connections fail.
    4. Data collection for deeper analysis
      • Collect detailed client and NPS traces for 802.1X:
        • On the Windows 11 client, create C:\MSLOG, then run (for wired): 
                 netsh ras set tracing * enabled
       netsh trace start scenario=lan globallevel=0xff capture=yes maxsize=1024 tracefile=C:\MSLOG\%COMPUTERNAME%_wired_cli.etl
        • Enable CAPI2 logging as shown above.
        • On the NPS server, similarly enable tracing for the relevant scenario (wireless or wired) and store logs in C:\MSLOG.
      • After reproducing the issue, analyze:
        • Client-side EAPOL traffic and NPS-side EAP traffic using Network Monitor with filters EAPOL (client) and EAP (NPS).
        • CAPI2 logs for certificate and CRL validation errors.
    5. NPS audit/logging
      • Ensure NPS is logging connection attempts so that any server-side failures are visible:
        • On NPS, run: 
                 auditpol /get /subcategory:"Network Policy Server"
        • If auditing is disabled or set to “No auditing”, enable it: 
                 auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable
      • Even if enabled, toggling off/on can help refresh the setting.
    6. Policy and certificate planning checks
      • Verify that the network policy for user authentication matches the intended method (EAP‑TLS vs PEAP‑MS‑CHAP v2) and that the corresponding certificates and PKI deployment are correctly planned:
        • For EAP‑TLS: ensure both server and user certificates meet the minimum requirements and are issued by trusted CAs.
        • For PEAP‑MS‑CHAP v2: ensure a valid server certificate is installed on NPS and that clients trust the issuing CA.

    By combining client-side 802.1X logs (Wired-AutoConfig), CAPI2 logs, and NPS audit logs, it is possible to pinpoint whether the failure is due to user certificate validity, trust chain, or CRL accessibility, and then adjust PKI, CRL distribution, or NPS policy accordingly.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    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.