NPS x Access Point Aruba authentication problems

Question

Hello everyone.

I'm integrating Aruba access points managed by Aruba Central with my internal NPS server for wireless client authentication using the EAP-PEAP method. The problem doesn't appear to be on the NPS side, as I replicated the client architecture in a lab environment: I deployed a domain controller (AD) on a Windows server, an NPS on another Windows server, and connected a standalone Aruba access point.

In this scenario, clients authenticate and connect to the Wi-Fi without issue.

However, the same isn't happening in the client environment. The user is prompted to enter their Active Directory credentials, but after entering them, the authentication window reappears repeatedly, without completing the connection process. Has anyone experienced similar behavior or have any suggestions as to where the problem might lie?

Capturas desde el cliente

Answer 1

Hello David Orlando Carhuachin Fuero,

The behavior you describe is typical of an integration issue between Aruba Central and NPS, not so much an NPS configuration issue itself. Since the connection works in the lab with a standalone AP, the difference lies in how Aruba Central handles forwarding EAP requests to RADIUS. Specifically, Aruba Central must have the NPS server correctly configured as a RADIUS Authentication Server, with the shared secret identical on both sides and with the NPS server certificate valid and recognized by clients. If the certificate used by NPS is not trusted by clients, they will continue to be presented with the credentials window without completing the PEAP tunnel.

I recommend verifying that the TLS certificate used by NPS is issued by a CA that clients can validate and that the name in the certificate matches the configured FQDN. Additionally, check in Aruba Central that the SSID profile is configured with EAP-PEAP and that forwarding to RADIUS is not blocked by ACLs or internal firewalls. Another critical point is the difference between the internal domain and the one visible to clients: if clients cannot correctly resolve the realm, authentication fails. In short, the problem is almost certainly related to the TLS certificate or the RADIUS forwarding configuration in Aruba Central, not the NPS itself.

If my answer is useful to you, please click Accept the answer to support me.

Thank you,

HL.

Answer 2

For PEAP with NPS, the repeated credential prompt usually means the 802.1X exchange is not completing, and the first checks should be the client EAP method, certificate trust, and NPS/AP policy alignment.

Based on the symptoms and the packet view showing repeated EAP-Request/Identity, use this troubleshooting path:

1. Confirm the client is using the expected EAP method
   • Verify the wireless profile is configured for Protected EAP (PEAP).
   • In the client wireless profile, confirm:
     • Verify the server's identity by validating the certificate is enabled.
     • The correct Trusted Root Certification Authority is selected for the CA that issued the NPS certificate.
     • The inner method is Secured password (EAP-MS-CHAP v2).
   • If these do not match the NPS policy, the client can keep prompting without completing authentication.
2. Check the NPS certificate actually selected in the PEAP policy
   • On the NPS server, open NPS snap-in → Policies → Network Policies.
   • Open the wireless policy → Properties → Constraints → Authentication Methods.
   • Confirm the PEAP settings are using the correct server certificate.
   • In the PEAP properties, verify the selected certificate and its Issuer are correct.
3. Validate certificate health on both sides
   • Most 802.1X failures are caused by certificate problems such as:
     • invalid certificate
     • expired certificate
     • chain verification failure
     • revocation check failure
   • If the client does not trust the CA that issued the NPS certificate, PEAP authentication can loop back to another credential prompt.
4. Review the client event logs first
   • On the affected client, open Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\WLAN-AutoConfig/Operational.
   • This log records the wireless adapter, profile properties, authentication method, and failure reason.
   • If the issue is certificate-related, also enable and review:
     • Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\CAPI2\Operational
   • The CAPI2 log is specifically useful for certificate chain and revocation problems.
5. Check whether Credential Guard is enabled on affected clients
   • For PEAP-MS-CHAP v2, this is important because MSCHAP(v2) cannot work with Credential Guard enabled.
   • If the client environment differs from the lab and has Credential Guard enabled, that would explain why the lab works and production does not.
6. Compare deployment method between lab and production
   • Check how the wireless profile is deployed in production: Group Policy, MDM, NETSH/XML, or manual configuration.
   • Compare one working lab client and one failing production client for:
     • PEAP settings
     • trusted root CA list
     • user vs computer authentication requirement
     • NIC driver/version
     • OS build
   • If domain clients are used, best practice is to deploy 802.1X client settings through Group Policy.
7. Verify NPS and AP/RADIUS client configuration match
   • In NPS, confirm the Aruba AP/controller entry under RADIUS Clients has the correct:
     • friendly name
     • IP/DNS address
     • shared secret
   • Also confirm the wireless AP authentication and encryption settings match the client policy.
8. Check password content if PEAP-MS-CHAP v2 is used
   • NPS does not support Extended ASCII characters within passwords.
   • If only some users fail, this is worth checking.

A practical order is:

1. Check WLAN-AutoConfig/Operational on one failing client.
2. Check CAPI2/Operational if certificate errors appear.
3. Verify the client wireless profile is PEAP + EAP-MS-CHAP v2 and trusts the CA that issued the NPS certificate.
4. Verify the NPS network policy is bound to the correct server certificate.
5. Check whether Credential Guard is enabled in production clients.

The strongest production-vs-lab suspects from the documented causes are:

• client does not trust the NPS certificate chain
• wrong PEAP/EAP inner method on the client profile
• wrong certificate selected in NPS PEAP properties
• Credential Guard enabled on production clients

---

• Deploy Password-Based 802.1X Authenticated Wireless Access
• Network Policy Server Best Practices
• Advanced troubleshooting 802.1X authentication
• Wireless Access Deployment
• Wireless technology troubleshooting guidance