In the previous twisted workflow where on receiving Radius Reject message leading to provide access to the WLAN may not look good when considering the accounting part of the authentication. To handle it in a better way, Arista APs can now support role-based capabilities which makes the understanding of the process authorization easy. Using these roles, a reject message from ClearPass is an actual rejection. But in this new updated workflow rejection is not used anymore.

Below are the differences in the previous and new approach:

• If the WLAN Guest user with a MAC address is a known MAC; then no need for the Guest user to access Captive Portal. Push a Captive Portal Post Auth role to the AP which in turn allows the WLAN client to pass internet traffic.
• If the WLAN Guest user with a MAC address is not a known MAC; ClearPass pushes a pre-authentication role to the user; updates the MAC address as known and applies an expiry timer for that particular MAC. Similar to the old workflow.
• In this workflow, disconnect CoA is not needed anymore. ClearPass can send appropriate roles and Arista APs support the same.

Workflow Flow Chart:

Workflow Diagram:

Workflow Steps:

Everything is almost similar as mentioned here; however in this workflow, AP doesn’t need to disconnect the user. It simply changes the role of the user from pre-auth to a post-auth role which allows internet access. Please refer to the above workflow diagram:

1. 802.11 Authentication Request is sent by the Guest User which is trying to request Guest Access. This is an 802.11 Auth frame that specifies the Arista AP the medium of communication is RF or WiFi. 
2. 802.11 Authentication Response to the Request is sent by the Arista AP.
3. Then an Association request is sent to get Associated to the Access Point for further communication.
4. An Association response to this request is sent by the Arista AP to the Guest User. This message completes basic WLAN communication between the Guest User and Arista AP.
5. Arista AP then sends a MAC Authentication Request to the ClearPass server as per configuration. The Authentication request will have username and password both as MAC addresses.
6. The CPPM server is configured to allow MAC Authentication for all the Clients and hence a Radius Accept to the MAC Auth request is sent back to the Access Point. However, a condition is validated to check if the MAC address is known or not. To understand the flow, we assume the MAC address is not known. Hence a pre-auth role is sent back to the AP for that user.
7. The Arista AP is set up to apply for a role with Captive Portal redirection enabled in case it receives a pre-auth role along with MAC Auth Success from CPPM Server. After assigning the role, the Guest User communicates to ClearPass Server directly through the Captive Portal redirect Link.
8. Guest User now receives the IP address. Since this particular user has a Captive Portal Role applied, when the user tries to access anything it will get a Captive Portal Redirect page. Many smart devices now can throw a pop-up window with the Captive Portal Login page which doesn’t need manual browsing in the web browser. Whenever the user tries to access a web browser, it will get redirected to the Captive Portal Link.
9. Guest User Sends HTTP/HTTPS request to the captive portal redirect link. This Captive Portal page is hosted on CPPM Server. Hence, the request reaches the CPPM Server.
10. CPPM Server then Presents the user with a Captive Portal Page in response to the HTTP/HTTPS request of the Guest User.
11. Guest User POST’s credentials to the CPPM server.
12. CPPM server checks for the credentials and if the same are found in Guest User Repository, it will authenticate the user. This is done using the web auth policy configured. An Accept message will be triggered by itself. A MAC Auth-Expiry attribute is attached with this response for the Guest MAC address with an Expiry time after which the client needs to login again using the Captive Portal Link. Along with the same, the MAC address is marked known.
13. CoA of a role change is sent by the ClearPass server to the AP. 
14. AP assigns this new role received from the ClearPass. This is a post-auth role that would have internet access. 
15. Guest user can then browse the internet.

Arista AP config:

The Configuration for this workflow is slightly different than the one we discussed earlier. Also, Arista AP now uses a new Cloud Vision Wifi portal cloud for configuration. Below is the config needed to support this new workflow:

Role Config: Access the Specific Location Folder where this SSID needs to be broadcasted. Here for this workflow, we will need to configure two roles: Pre-Auth and Post-Auth roles (any relevant names can be used but the functionality should be mapped accordingly). Navigate to Cloud Vision WiFi Portal and browse the location where these roles need to be defined. Then, select Configure > WiFi > Role Profile > Add Role profile > Give a Role name. For the Pre-auth role, update the redirect link. For a Post-Auth role, a redirect link will not be required.

Radius Profile config: In the same location as above, you would need to navigate to go to Radius Section and configured the relevant Radius Settings:

Configure SSID: In the same location again select SSID and click Add SSID. 

• Add the name of the SSID. Select SSID type Guest (not mandatory).
• Navigate to the Security sub-tab and select authentication as open (again not mandatory. If PSK is needed; then that can be selected as well for this workflow)
• Select Network Sub-tab to select the network settings for the WLAN clients
• Select Access Control Sub-tab. It can be pulled out from the three-dotted line as shown in the above screenshot besides the captive portal. Check Client Authentication > Select Radius MAC Authentication > Map the primary and secondary (optional) Radius Servers for MAC authentication > Make sure Password is sent along with MAC address OR the MAC auth will fail > Note or Edit down the NAS ID details as these would be needed later on by ClearPass to send roles > Check role-based control > Select 802.1X custom VSA > Select the roles that were created for Pre-Auth and Post Auth. This configures the AP to compare the roles received from the ClearPass with this list and accordingly assign them on different stages. For Aruba, Vendor ID is 14823, and Attribute ID is 1 for roles.
• Save and Turn ON the SSID which is at the bottom right of the window

ClearPass Config:

As this process is called Server-initiated login, most of the process in the above workflow is been handled at ClearPass. To achieve this workflow, this server needs to be configured with a MAC Authentication policy that allows MAC Auth for all Guest Users (without adding their MAC address in ClearPass database) and Web Authentication policy to perform Captive Portal Authentication.

Most of the configuration is quite similar to the previous workflow. However, there are a few changes. Like, instead of sending a de-auth CoA, ClearPass here sends a Role-based CoA. Although the policy settings remain the same, however, the roles need to be sent during the MAC auth itself. 

Devices and Device Group Configuration: Same as previous

Role Configuration: Steps are the same as the previous clearpass role config setting. However, in this workflow we would need three roles:

1. A role for the clients that are known and are within the expiry timer.
2. Default role for the clients that are not known and are not within the expiry timer.
3. A role for Web Auth policy for that user that will authenticate against Guest Userdb using captive portal login credentials.

Enforcement Profile containing Role: In previous workflow, we only needed CoA with Terminate Session. However, in this one, we would need to send user-roles to the AP. So for the same, we would need three Enforcement Profiles; One with Radius Pre-Auth role, one with Radius Post-Auth role and other one with Radius CoA for Post Auth Role. For all, the configuration is the same, however, we only need to specify if the enforcement is Radius CoA or normal Radius Enforcement. Navigate to Configuration > Enforcement > Profiles > Click Add:

1. Post-Auth Role (Radius Enforcement Profile):
2. Pre-Auth Role (Radius Enforcement Profile):
3. Post-Auth Role (Radius CoA):

Enforcement Policies: These policies hold the conditions as to when and where the Enforcement profile configured will be used. For this workflow we have two policies; so two different Enforcement policies will be needed. 

1. Enforcement Policy for MAC Auth service:
2. Enforcement Policy for Web Auth Service:

MAC Authentication Service: This policy will allow MAC Authentication for all the users that are trying to login to Guest SSID. Below are the requirements for MAC auth for this workflow:

1. MAC Auth accept should be sent for all the users. Irrespective of the WLAN guest user is in Pre-Auth or Post-Auth phase.
2. If the Guest user is “known” and the Guest User request is coming in before the MAC Auth Expiry timer for that user; ClearPass should assign a “Guest”(Role 1 in Role Configuration) role to this user.
3. If the Guest user is not known and/or the guest MAC tries to log in again after the expiry timer then assign a different role to that MAC (Role 2 in Role Configuration). 
4. If point 2 (in Mac Authentication Policy) is true, send the Post-Auth role along with Radius Accept.
5. If Point 3 (in MAC Authentication Policy) is true, send the Pre-Auth role along with Radius Accept.
6. Below are the snippets for this policy config:
   • Summary tab for MAC Auth Service:
   • Service tab for MAC Auth Service:
   • Authentication tab for MAC Auth Service:
   • Authorization tab for MAC Auth service:
   • Roles tab for MAC Auth service:
   • Enforcement tab for MAC Auth service:

Web Authentication Service: This policy will be used for the Guest user in the Pre-Auth role to validate the user credentials and accordingly provide a different role if successful:

1. The Guest user belonging to the pre-auth role trying to authenticate to the captive portal should have a role (Role 3 in Role Configuration). 
2. Once the user is authenticated successfully; the ClearPass should update this endpoint as known and apply a MAC expiry timer.
3. ClearPass should also send a Post-Auth role as Radius CoA to the AP wherein the AP would adhere to the same and allow the Guest user to access internet.
4. Below are the snippets from the Web Auth Policy config:
   • Summary tab for Web Auth Service:
   • Service tab for Web Auth Service:
   • Authentication tab for Web Auth Service:
   • Authorization tab for Web Auth Service:
   • Roles tab for Web Auth Service:
   • Enforcement tab for Web Auth Service:

Since the previous workflow is quite similar to this one as far as the usage of functionality is concerned and hence I have not explained everything here in this workflow. The configuration of the webpage as well is similar as defined in the previous workflow. The Access Tracker for a successful workflow should show everything “accept”.