I85PREP
⌘ K
Aruba Network Security Associate study materials
Aruba Network Security Associate study resources

Role Derivation Conflict for Contractor Access

Aruba Network Security Associate · Put your knowledge to work in context.

All case studies

Role Derivation Conflict for Contractor Access

An Aruba deployment enforces role-based access at the controller. Employees authenticate via 802.1X and receive an employee role with full internal access. Contractors authenticate via the same SSID but are identified in ClearPass by group membership and should receive a contractor role limited to a print server and internet. The policy currently derives roles from both a server-derived role returned in the RADIUS reply and a user-role rule on the controller that matches on the SSID name. Two problems appear: (1) some contractors get the employee role, and (2) a handful of employees who occasionally connect from a contractor-managed laptop get the contractor role. The controller's role-mapping order is: server-derived role first, then user-role rules, then default role. The SSID is the same for both populations.

1. Explain why both misassignments occur, given the stated role-mapping order.

Read the worked answer

The two symptoms point to two different precedence sources fighting.

  1. Contractors getting employee: The controller applies the server-derived role first. If ClearPass returns an employee role for some contractors - e.g., because their group lookup falls through to a default or a nested group that maps to employee - the controller honors that before the user-role rule ever runs. The SSID-based user-role rule cannot override a server-derived role that is applied first.

  2. Employees on contractor laptops getting contractor: If those sessions do not produce a server-derived role (e.g., machine auth vs. user auth, or a RADIUS reply missing the role attribute), the controller falls through to the user-role rule matching on SSID. Since the SSID is shared, that rule cannot distinguish population, so it assigns contractor based on SSID alone.

The root cause is that SSID is not an identity signal here, and the precedence order lets a server-derived role silently win while the fallback rule is population-blind.

2. Recommend a role-derivation design that is deterministic for both populations.

Read the worked answer

Make ClearPass the single source of role truth and stop deriving role from SSID.

  1. Remove the SSID-based user-role rule as a role source. SSID is identical for both populations, so any rule keyed on it is inherently ambiguous.
  2. Enforce a server-derived role for every authenticated session in ClearPass: employees → employee, contractors → contractor, with an explicit deny/default-deny outcome for unmatched identities rather than a permissive fallback.
  3. Fix the ClearPass group logic so contractors cannot inherit employee via nested groups - audit group membership and role mapping rules, and add a test case per contractor group.
  4. Handle the employee-on-contractor-laptop case by identity, not device: the role should follow the authenticated user (employee → employee), with device posture/health checked separately (e.g., ClearPass OnGuard) so an unmanaged laptop can be restricted by posture rather than by a mis-derived role.
  5. Set the controller's default role to a deny/quarantine role so any session that fails to receive a server-derived role is contained, not elevated.
  6. Log role assignments with the deriving source (server vs. rule vs. default) and alert when the default role is hit, which surfaces mapping gaps early.

Result: role is a function of authenticated identity and posture, not of which SSID or which laptop was used.