Aruba ClearPass APC common mistakes
Aruba ClearPass APC · Understand the traps and how to avoid them.
Treating the Policy Manager as the component that makes the actual forwarding/authentication decision on the wire, rather than mapping each service (Policy Manager, ClearPass OnGuard, Guest, Onboard, Profiler, Insight) to its role in the node architecture.
The product is a suite of services that can be deployed on one appliance or split across nodes; candidates memorize feature names but not which service owns which function, so architecture questions about distributed deployments and service placement trip them up.
What to do instead
Build a one-page map of each ClearPass service to its function and to the deployment models (standalone, publisher/subscriber, cluster). For each service, state what it does and does not do before answering architecture questions.
Confusing the access license (counts concurrent endpoints/nodes) with the device/feature licenses (Onboard, OnGuard, Guest, Profiler, Enterprise), and assuming a base license enables those features.
Licensing terminology overlaps and candidates assume 'more licenses = more features' rather than understanding that access licenses govern scale while feature licenses govern which modules run.
What to do instead
Memorize the two-tier model: access licenses set concurrent endpoint capacity; feature licenses unlock specific services. Practice scenarios where you must state which license is missing to enable a given capability.
Mixing up the enforcement profile (the action/attributes sent to the NAD) with the enforcement policy (the rule that evaluates conditions and selects a profile), and writing conditions in the wrong object.
The two share the word 'enforcement' and are configured on adjacent screens; candidates conflate the decision logic with the result action, so they misdescribe where a role or VLAN is actually assigned.
What to do instead
State the flow explicitly: service → enforcement policy (conditions) → enforcement profile (action/attributes). For each question, identify whether it asks about the decision or the outcome before choosing.
Assuming a service will match without confirming the service's match criteria (NAD/IP range, authentication method, port type) and rule ordering, then blaming the enforcement policy when nothing matches.
Services are evaluated top-down and require match criteria to fire; candidates jump to enforcement debugging without verifying that the correct service was even selected.
What to do instead
Always trace the request path: which service matched first? Check service ordering and match criteria before touching enforcement. Practice reading a request through the service-match step first.
Treating RADIUS and TACACS+ as interchangeable for NAC, or misassigning which protocol carries which attributes (e.g., expecting a RADIUS reply to carry shell/command authorization).
Both are AAA protocols and share terminology, but they differ in transport, encryption scope, and purpose; candidates blur them and pick the wrong protocol for a use case.
What to do instead
Anchor each protocol to its use: RADIUS for network access (802.1X/MAC auth, CoA), TACACS+ for device administration. Note transport (UDP vs TCP) and encryption differences and test yourself with use-case prompts.
Confusing authentication (proving identity) with authorization (what the identity may do) when describing 802.1X/EAP flows and where each happens.
The terms are used loosely in study material and both occur inside a single 802.1X exchange, so candidates misattribute which step produced a given result.
What to do instead
For every scenario, split it into 'who are you?' (auth source, EAP method) and 'what do you get?' (role/VLAN/ACL via enforcement). Practice labeling each step of an 802.1X exchange as authN or authZ.
Designing guest flows that skip the authorization/role-assignment step, or assuming a guest is fully provisioned the moment the captive portal authenticates them.
Guest access is a multi-stage flow (captive portal → authentication → role → enforcement → optional sponsor approval/account creation); candidates collapse it and miss the enforcement and provisioning stages.
What to do instead
Map the guest flow end to end: portal detection, login/registration, sponsor or self-approval, role assignment, and enforcement to the NAD. Identify which stage a question targets before answering.
Treating OnGuard as a simple authentication check rather than a posture evaluation that produces a health state and can trigger remediation, and confusing posture policies with enforcement policies.
OnGuard sits alongside authentication but evaluates endpoint health; candidates fold it into auth and miss the health-class → remediation → enforcement chain.
What to do instead
Separate the OnGuard chain: posture policy (what is checked) → health class (result) → remediation action → enforcement. Practice tracing a non-compliant endpoint through each stage.
Debugging enforcement or authentication failures without first checking the Access Tracker and the relevant service logs, or reading only the summary without drilling into the request details.
The Access Tracker records the full decision path (service matched, auth source, enforcement result); candidates guess at causes instead of using the built-in trace, so they chase the wrong component.
What to do instead
Make Access Tracker the first stop: confirm which service matched, which auth source responded, and which enforcement profile was applied. Practice reading a request's detail view to locate the failing stage.
Assuming an Aruba or third-party NAD will accept a role/VLAN assignment without the matching CoA/RADIUS attributes and correct shared secret/NAD configuration, or ignoring vendor-specific attribute differences.
Integration depends on both sides agreeing on attributes and on the NAD being correctly registered; candidates focus on ClearPass config and forget the NAD side and vendor attribute mapping.
What to do instead
For each integration, verify both ends: NAD registered with correct shared secret and IP, vendor-specific attributes matching the NAD's expectations, and CoA supported. Practice mapping a role assignment to the exact attributes sent.