Implement Security and Role-Based Access Control for Wireless Clients
Role-based access control
Aruba RBAC separates authentication, authorization, and enforcement. Authentication is handled by an AAA profile: 802.1X with RADIUS, MAC authentication, PSK, or captive portal. Authorization assigns a user role. Roles can be derived from the initial role, from RADIUS attributes (including Aruba VSAs such as Aruba-User-Role and Aruba-User-Vlan), from user-derivation rules, or from server rules. Enforcement is a stateful firewall policy attached to the role, using aliases for networks and services. The policy is evaluated top-down; end with an explicit deny.
ClearPass is commonly used to return role and VLAN attributes, but the controller must have a matching role and policy. Guests typically land in an initial role that permits DHCP, DNS, and captive portal, then move to a post-authentication guest role after login. Employees may use 802.1X with EAP-TLS or PEAP and land in an employee role with VLAN 10. Remember that role assignment and VLAN assignment are separate: a server can send a VLAN, but the controller must have that VLAN and a role that permits it.
Traps: confusing the initial role with the final role; expecting a RADIUS VSA to create a role automatically; placing a deny-all before permit rules; and forgetting that firewall policies are applied at the controller or AP enforcement point.
Worked example
Employee SSID: 802.1X to ClearPass; accept returns Aruba-User-Role=employee and Aruba-User-Vlan=10. Guest SSID: initial role guest-logon permits DHCP/DNS to portal; after login, role guest permits internet only, denies RFC1918, and is denied all else.