802.1X Rollout Breaks Legacy Lab Devices

Options and trade-offs.

1. MAB (MAC Authentication Bypass) with ClearPass as the authenticator. The switch sends the device MAC as username/password. Pros: no supplicant needed, still RADIUS-controlled, ports stay closed until authorized. Cons: MAC spoofing is trivial, so treat MAB as low-trust; assign a restricted VLAN/role with ACLs limited to what the instruments need, and log every MAB auth. Maintain the MAC list in ClearPass (endpoint repository) with ownership and review.
2. Static/exception port with port-security - weaker; avoid unless the device cannot do MAB and is physically secured.
3. Profiling + device fingerprint in ClearPass to auto-classify the instruments and apply a role, reducing manual MAC lists.

Recommendation. MAB to a restricted role/VLAN with least-privilege ACLs, endpoint profiling, and alerting on unknown MACs. Add port-security (max MACs = 1) on those ports so a rogue device cannot piggyback. This keeps ports closed until authorized while accepting the residual spoofing risk, which is mitigated by network segmentation and monitoring.

Most likely causes (floor-scoped):

• That floor's access switch has a different RADIUS server order or a dead RADIUS entry (one ClearPass node unreachable from that segment), so PEAP fails there only.
• Certificate/CA trust: the floor's clients may be hitting a different SSID/profile or a different RADIUS policy that uses a certificate the client doesn't trust.
• VLAN/role mismatch or a stale CoA: the floor switch may not process RADIUS Change-of-Authorization, so the client stays in the wrong state.
• Switch-level config drift: different 802.1X timers, different aaa authentication method list, or missing dot1x on some ports.

Isolation steps.

1. Compare show running-config for AAA/RADIUS/802.1X between a working and failing switch.
2. Check RADIUS reachability from the failing floor (show radius statistics, test auth).
3. Pull ClearPass Access Tracker for a failing client: which service matched, which result, which role/VLAN returned.
4. Compare client-side: same SSID/profile, same CA.
5. Test one client on a known-good switch port to confirm it's the switch, not the client.

Fix the drift (standardize AAA/RADIUS config via template) and verify CoA is enabled where roles are enforced.

Where the fault lives. Authentication succeeding but the wrong VLAN means the authorization result is wrong, not the authentication. Candidates:

• ClearPass role/VLAN mapping returns the wrong VLAN ID or role for that service/group.
• Switch enforcement: the switch may be applying a role instead of a VLAN, or the VLAN returned by RADIUS isn't defined on that switch, so it falls back to a default.
• CoA not applied: the client authenticated before the policy decision and never received the change, so it stays in the initial VLAN.
• Interface config: a default/guest VLAN is applied on the port and the authorized VLAN isn't overriding it.

Fix.

1. In ClearPass Access Tracker, confirm the returned attributes (Tunnel-Private-Group-ID / role) for a sample user.
2. On the switch, confirm the VLAN exists and that the port is enforcing the RADIUS-returned VLAN/role; check show port-access ... state.
3. Enable/verify CoA (RFC 5176) so mid-session changes apply.
4. Standardize the port template so initial and authorized states are consistent.

Add a test matrix (per user group, per floor) to catch mapping errors before rollout.