One wrong assumption that breaks every ClearPass deployment
Most new NAC engineers think ClearPass is "just a RADIUS server" — type a username, get a yes/no, done. That single assumption causes 90% of the day-one tickets. ClearPass is a policy pipeline, not a password checker. The yes/no is the easy part. The hard part is everything AROUND it: which service caught the request, what role the device earned, whether it passed posture, and which enforcement profile it returned.
🧒 Think of ClearPass as a club bouncer with a checklist. He doesn't just check your ID — he checks which door you came to (service), whether you're a member or guest (role), whether your jacket meets the dress code (posture), and only THEN points you to the VIP room or the general floor (enforcement).
🛠 In Access Tracker every request shows these stages as a vertical timeline. When something is wrong, you read down that timeline and find the exact stage that produced the wrong result — usually a mis-ordered service or a missing enforcement rule.
🏛 Architecturally ClearPass separates identity (who/what), context (role mapping, profiling), state (posture/health), and action (enforcement). Treating these as one monolith is exactly why "single mega-service" designs rot. Keep them decoupled and the policy stays readable at 200 services.
One sentence to memorise: "ClearPass evaluates services top-down and stops at the first match." Get the service ORDER wrong and a corporate laptop can land in the Guest VLAN — even though authentication "succeeded". Drill this in; it is the most-tested idea on the ACCP exam.
WLAN-Corp-Dot1X SSID. They authenticate fine but get the Guest VLAN 172.16.40.0/24 with no internal access. Tickets flood in. The bug is not authentication — it is a broad MAC-Auth service sitting ABOVE the 802.1X service, catching the request first. She reorders, problem gone in two minutes.
Before we start: when ClearPass receives a request, how many services can match it?
What actually carries the VLAN number back to the switch?
Tunnel-Private-Group-ID for the VLAN.Which OnGuard agent can auto-fix a non-compliant device?
① The pipeline — the one diagram that explains everything
Every ClearPass decision flows through the same six stages, in order. Memorise the order and you can debug anything.
The request is matched against services top-down. First match wins. The chosen service owns every step below it.
Validate the credential against ordered auth sources (AD, local DB, SQL). Stops at the first source that authenticates.
Tag the user/device with roles using attributes (AD group, device type, time). Roles are pure context — no action yet.
OnGuard reports a health token: Healthy / Checkup / Quarantine / Unknown. Optional — only if posture is enabled on the service.
Enforcement policy maps (role + health + time) → an enforcement profile, which carries the real RADIUS attributes back to the NAD.
Change of Authorization (RFC 5176) re-authorizes a LIVE session — bounce/VLAN-change/re-auth — with no reconnect. Default UDP 3799.
Pause & predict: if authentication succeeds but the role is empty, which stage failed?
② RADIUS & Roles — watch a real 802.1X request
Office mein 500 corporate laptops authenticate to the WLAN-Corp-Dot1X SSID using EAP-TLS. The controller is the NAD at 10.10.0.5; ClearPass listens on 10.10.0.20. Let's watch one request flow end to end.
▶ Watch an 802.1X request walk the pipeline
Click Play. Each stage lights up as ClearPass processes Sneha's corporate laptop.
aa:bb:cc:11:22:33, hits ClearPass on 10.10.0.20.memberOf = Corp-Employees → role Employee
If Role = Employee → profile "Employee-VLAN-20" → returns Tunnel-Private-Group-ID = 20
Authentication source vs authorization source — the trap
ClearPass distinguishes authentication sources (where it checks the credential) from authorization sources (where it fetches extra attributes for role mapping). Crucially: ClearPass fetches role-mapping attributes from the authorization sources regardless of which source authenticated the user — but only if you LIST AD as an authorization source on the service.
Symptom you see: Access Tracker shows "User Authenticated = true" but the Role column is the default role, and the VLAN is wrong.
Cause: the [Local User Repository] is listed ABOVE Active Directory in the service's authentication sources. The local DB authenticates the user first, so ClearPass never queries AD for the memberOf group — the AD-group role-mapping rule never fires. Fix: move AD above local, or add AD explicitly as an authorization source.
Sneha at Infosys finds her 802.1X laptops landing in a Guest role instead of Employee. Access Tracker shows the WLAN-Corp-Dot1X service is being SKIPPED entirely. What is the most likely cause?
WLAN-Corp-Dot1X grabs the request first. Reorder the 802.1X service above it (or tighten the broad service's match rules). Service order is the #1 ClearPass gotcha.[Local User Repository] above AD, so AD group attributes were never read. Reordering the auth sources restores group-based roles instantly.
Rahul at TCS placed [Local User Repository] above Active Directory in the authentication-source list. Users authenticate fine, but the AD-group-based Employee role never applies. Why?
memberOf attributes are never queried, so the AD-group role-mapping rule silently misses. Move AD above the local repository, or add AD as an explicit authorization source on the service.In the ClearPass pipeline, which component decides WHAT the switch actually does to the port — the VLAN, ACL or downloadable role?
③ Posture & OnGuard — is the device actually healthy?
Authentication proves who you are. Posture proves your device is safe. OnGuard performs advanced endpoint health checks over wired, wireless and VPN, then hands ClearPass a posture token used in enforcement.
🧒 Posture is the "wash your hands before dinner" check. Even if mum knows it's you (authentication), you still don't get to the table until your hands are clean (healthy device).
🛠 You bind OnGuard to a service via the Posture tab. If the device is Quarantine, your enforcement policy routes it to a remediation VLAN with access only to the patch/AV servers — not the corporate LAN.
🏛 Posture is a continuous control, not a one-shot. With a persistent agent + CoA, a device that goes unhealthy mid-session (AV disabled at 3pm) is bounced into quarantine automatically — that's the difference between authentication and true zero-trust posture.
Persistent vs dissolvable — pick the right agent
Installed on IT-managed devices. Nonstop monitoring + auto-remediation. Re-checks continuously and can fix issues (start AV, force update).
Web-based, for BYOD / guests via captive portal. One-time check at login, then self-uninstalls. Same checks, but NO auto-remediation.
The persistent agent can fix a failed check itself — restart antivirus, trigger Windows Update. The user often never sees the quarantine.
Unhealthy devices land in a remediation VLAN with reach only to patch/AV servers. The user sees a message + fix instructions.
Pause & predict: a guest phone fails the AV check on the captive portal. Will ClearPass auto-fix it?
▶ Posture failure → CoA quarantine
Priya's laptop is online and Healthy. At 3pm her antivirus is disabled. Watch ClearPass re-quarantine her WITHOUT a reconnect.
If health = Quarantine → profile "Quarantine-VLAN-99"
UDP 3799 → bounce session / change VLAN
Priya at HCL deploys OnGuard. IT laptops auto-remediate when antivirus is stale, but BYOD phones on the captive portal only get a one-time health check and never auto-fix. Is this expected?
④ Troubleshoot — Access Tracker playbook + CVE fix
A request misbehaves. ClearPass gives you a single best tool: Access Tracker. Open the request, read the stages top-down, and the wrong stage will be obvious. Here's the 4-step ladder.
Access Tracker → request → "Service" field. Wrong service = reorder. No service = no rule matched; widen the rules or add a service.
Check "Authentication" and "Roles" in the request details. Empty role usually = AD not queried as an authorization source.
Check "Enforcement Profiles" + the RADIUS reply attributes. Default profile = no enforcement rule matched the role.
Auth works but the bounce/VLAN-change never lands → check the NAD's dynamic-author port (default UDP 3799) and CoA shared secret.
aaa server radius dynamic-author client 10.10.0.20 server-key MyCoASecret port 3799 auth-type all
switch# show aaa servers | include CoA|3799 RADIUS: id 1, priority 1, host 10.10.0.20, auth-port 1812, acct-port 1813 CoA dynamic-author: client 10.10.0.20, port 3799, state UP Disconnects: total 14, sent 14, failed 0 CoA requests: total 38, sent 38, failed 0
Pause & predict: auth works but a CoA bounce never lands on the switch. Which port and secret would you check first?
aaa server radius dynamic-author and the port on both ends.Symptom you see: the user logs in fine and Access Tracker shows Accept, but when ClearPass tries to bounce or move them, nothing happens — the session stays put and CoA shows as failed/timed-out.
Cause: CoA uses a SEPARATE UDP port (default 3799) and its own shared secret in the NAD's dynamic-author config. If the port or secret doesn't match what ClearPass sends, normal auth (port 1812) still works but CoA is dropped. This is the most-reported CoA issue on the Aruba Airheads community.
After a posture failure, ClearPass needs to move an ALREADY-CONNECTED device from the Healthy VLAN to the Quarantine VLAN without making the user reconnect. Which mechanism does this?
Patch the CVEs — ClearPass is your control plane, treat it like one
ClearPass decides who gets on your network. If it's compromised, the attacker controls access for everyone. Two recent advisories matter: CVE-2025-23060 (cleartext information disclosure — enables interception / MITM) and CVE-2024-51771 (authenticated command-injection RCE in the web UI). A third, CVE-2025-23058, is an authenticated broken-access-control privilege escalation.
1. Patch. Upgrade to a fixed train — ClearPass 6.12.4 / 6.11.10 or later per the HPE advisory — which resolves these CVEs. 2. Segment. Put the management interface on a dedicated admin VLAN with strict firewall rules so only the NOC subnet can reach the web UI. 3. Least-privilege admins. Use scoped admin roles so a low-privilege account can't escalate (the CVE-2025-23058 class). Patching closes the bug; segmentation shrinks who can even attempt it.
🤖 Ask the AI Tutor
Tap any question — instant context-aware answer. No login, no waiting.
Pre-curated answers from HPE Aruba ClearPass docs + Airheads community Q&A. For complex prod issues, paste your Access Tracker request detail into chat.techclick.in.
📝 Wrap-up — five more
You've already answered 5 inline. Five left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 Lock it in — explain it back
In your own words, write the six pipeline stages and what each one does. Self-explanation is the single biggest retention multiplier — your future on-call self will thank you.
Teach a friend: message one teammate the one-liner "ClearPass evaluates services top-down and stops at the first match — get the order wrong and a corporate laptop lands in Guest." If you can teach it, you own it.
We'll send ONE recall question in a week. No spam, unsubscribe anytime.
📖 Glossary
- Service
- A policy container for one access type (802.1X Wireless, MAC-Auth, VPN). First-match-wins, top-down.
- Role
- A context label ClearPass assigns from attributes (AD group, device type). Drives enforcement — not a switch port role.
- Enforcement profile
- The actual RADIUS attributes returned to the NAD: VLAN, ACL, Aruba-User-Role.
- OnGuard
- The ClearPass posture agent. Checks AV, firewall, patches, encryption. Persistent or dissolvable.
- Posture token
- The health result: Healthy / Checkup / Quarantine / Unknown. Fed into the enforcement policy.
- CoA
- Change of Authorization (RFC 5176). Re-authorizes a live session. Default UDP 3799.
- NAD
- Network Access Device — the switch or WLAN controller that speaks RADIUS and enforces the result.
- Access Tracker
- The ClearPass log/troubleshooting view. Shows every request's stages top-down.
📚 Sources
- HPE Aruba Networking TechDocs — ClearPass Policy Manager 6.12 User Guide: About ClearPass, Services, Enforcement Policies. arubanetworking.hpe.com/techdocs
- HPE Aruba Networking TechDocs — ClearPass OnGuard: Persistent vs Dissolvable Agents, Agentless OnGuard Troubleshooting (6.11).
- Juniper Networks Docs — Example: Configuring 802.1X-PEAP and MAC RADIUS Authentication with EX Series Switches and Aruba ClearPass Policy Manager. juniper.net/documentation
- HPE Aruba Airheads Community — "ClearPass and Cisco CoA Failing" / "ClearPass CoA Problem" threads (CoA port + shared-secret mismatch).
- NACSOC — ClearPass Access Tracker Explained (With Real Troubleshooting Flow); top-down service + role-mapping order gotchas + Monitor Mode.
- HPE Security Advisories / CVE — CVE-2025-23060 (info disclosure), CVE-2024-51771 (authenticated RCE), CVE-2025-23058 (broken access control); fixed in 6.12.4 / 6.11.10.
- HPE Certification & Learning — Aruba Certified ClearPass Professional (ACCP, HPE6-A68) exam blueprint (AAA, Posture, Operations weightings).
What's next?
You can now identify a device, role it, posture-check it and enforce a VLAN. Next we push the policy decision all the way to the edge — how Aruba turns a ClearPass role into a port-level firewall with Dynamic Segmentation and the Policy Enforcement Firewall (PEF), so traffic is filtered the moment it hits the switch.