Role-Based Access Control and Policy Enforcement
Core concepts
Role-based access control assigns permissions to roles, and roles to users or devices, rather than to individual ports. In Aruba terms this appears as user roles applied at the controller or via ClearPass role mapping, with enforcement through firewall policies (ACLs) that permit or deny traffic based on role, destination, and service.
Understand the policy chain: authentication identifies the user, authorization assigns a role, and enforcement applies the role's policy. Know that a role can carry a VLAN assignment, a firewall policy, and a captive portal redirect. Understand default roles (e.g., a deny-all or guest role) and the principle of least privilege.
Traps to watch
- Role vs. VLAN. A role is a policy container; a VLAN is a Layer 2 segment. Assigning a role does not automatically move a client to a VLAN unless the role specifies it.
- Policy ordering. Firewall rules are evaluated top-down; a broad permit above a deny makes the deny unreachable. Questions love to test rule order.
- Deny-by-default. The implicit final rule drops unmatched traffic; do not assume a permissive default.
- Role derivation precedence when multiple attributes match (e.g., user vs. device attributes) - the most specific or highest-priority rule wins.
Rule of thumb
Trace every policy question through the three steps: identify → authorize (role) → enforce (policy). If a distractor skips the role assignment step, it is usually wrong.
Worked example
A contractor authenticates successfully but should only reach the internet. The correct design assigns a contractor role whose policy permits outbound internet and denies internal subnets - not a VLAN change alone, which would not restrict traffic.