Limitations When Applying Role Policies to Users

You must be aware of some limitations when applying roles to a user.

The user role policies are supported only in proxy-mode AAA WLANs. Within AAA profiles, you have the ability to configure the mapping of user attributes to roles.

It's important to note that certain components may not function as expected in version 3.5, despite the indications provided by the GUI.

Precedence policies can only be configured at the WLAN level, which may restrict the flexibility in role allocation.

Additionally, it's crucial to differentiate between assigning User Equipments (UEs) to roles through RADIUS and utilizing RADIUS attributes to implement specific policies, such as rate limiting, VLAN assignment, or ACLs.

The RADIUS attribute always takes precedence over role assignments, potentially limiting the control over role-based access management.

The user role policies are supported only in proxy-mode AAA WLANs, where the proxy AAA method is used for authentication. If the authentication method is non-proxy AAA, where the AP authenticates the user, the User Equipment (UE) cannot be determined. Therefore, user role policies are not supported on non-proxy mode AAA WLANs.

Typically, the RADIUS and AAA servers return a user attribute to the controller, and the controller assigns it to an UE. However, you must establish a mapping between the user attribute and the user role so that the user role policy can be applied to the UE. The attribute-to-role mapping is configured within the AAA policy.

The user traffic profiles are configured with various policies (such as rate limiting), so when a profile is applied to a WLAN, the policies in the profile are applied to all the UEs in the WLAN. The policies can also be applied to a user role in a WLAN, but not all the policies defined in the profile are applied to the role.
If a role-based VLAN policy is defined in the profile, it cannot be applied to the WLAN if it is authenticated based on a Layer 7 method (WebAuth or Hotspot/WISPr). When a VLAN is applied on a per-role basis for a Layer 7 authentication method, you receive an IP address by way of DHCP before the UE is authenticated. As this happens at Layer 3 or Layer 4, you cannot authenticate the UE and assign a role to it until Layer 7 is reached. This results in a mismatch between the VLAN IDs set within the roles, and could possibly lead to service disruptions.

Precedence profiles are configured at the WLAN level, but they influence how roles are allocated. The manner in which the profile is defined indicates the order in which policies defined within the profile are assigned. The order of priorities can be customized. For example, if you have WLAN 5 configured with VLAN ID 5, an OS policy configured with an iOS VLAN ID 10, and a role policy assigned to a student with VLAN ID 40, then there are multiple orders one can set when a student user with iOS connects to WLAN 5.

You can assign a UE to a role through RADIUS, or you can use RADIUS attributes to apply policies. However, using RADIUS attributes takes precedence over assigning UEs to a role (though it is easy to configure, because the only element required to authenticate the UE is the role information).
In the RADIUS attributes method, each policy (such a rate limiting or user traffic profile) has a unique RADIUS attribute. Therefore, specifying the RADIUS attribute for a policy overrides all other forms of the controller policy. For example, if a UE is already assigned to VLAN 7 through RADIUS, setting a RADIUS attribute for VLAN IDs to 9 will override all VLAN 7 configurations in WLANs, OS policies, role policies, and so on.