Guest SSID Works, Employee SSID Fails After Controller Swap
A university runs ClearPass 6.11 with two nodes behind an Aruba Mobility Conductor. Guest uses a captive portal with MAC caching and works fine. The employee SSID uses 802.1X against Active Directory via a RADIUS proxy service. After a controller replacement, employees on the new controller get repeated authentication failures while the same users succeed on the old controller. The service is a single 802.1X service bound to all controllers. RADIUS shared secrets were verified as identical. The authentication source test from ClearPass to AD succeeds. The service's role mapping is empty and enforcement uses a single profile that returns an Aruba-User-Role of 'employee'. Authorization shows 'Reject' with reason 'Authentication failed'.
1. What is the most likely cause, and what evidence in the scenario supports it?
Read the worked answer
The strongest signal is that the same users succeed on the old controller and fail on the new one, while the ClearPass-to-AD source test passes. That localizes the fault to the RADIUS exchange or the service's controller binding, not the identity source.
Two credible causes remain:
- Shared secret mismatch on the new controller - the NAS client entry in ClearPass for the new controller's IP may be missing or have a different secret than the controller config. 'Verified identical' likely refers to old-vs-new config, not to the ClearPass NAS entry for the new IP.
- Service/controller binding - if the service is restricted by NAS IP or controller group, the new controller's IP may not be in the match criteria, so requests fall to a different or default service.
Reasoning path: confirm which service handled the request in Access Tracker, inspect the NAS client entry for the new controller IP, and check the service's NAS match rules. A secret mismatch typically produces an Access-Reject with a RADIUS-level error, while a service mismatch produces a different service name in the tracker. The empty role mapping is a red herring for authentication failure - it affects authorization, not the reject reason shown.
2. How would you distinguish a NAS-client secret problem from a service-matching problem using ClearPass tooling?
Read the worked answer
Use Access Tracker on the failed request:
- If the request is attributed to the wrong service (e.g., a default or guest service), it is a service-matching issue. Fix by adding the new controller IP/NAS identifier to the correct service's match criteria.
- If the request is attributed to the correct service but fails at the RADIUS layer with a shared-secret or malformed-attribute error, it is a NAS client issue. Fix the client entry under Network Devices.
Cross-check with the controller's show radius / client statistics and ClearPass event logs. A secret mismatch often shows repeated rejects with no authentication attempt reaching AD in the tracker's authentication section - the request dies before the identity source is queried.