ClearPass Tiny Bite 7 – Clearpass Guest Social Login With Azure AD (Part 1)

To be frank, this will not be a tiny bite but a more detailed walk-through of what happens under the hood when a guest authenticates using ClearPass Guest with a Social Login provider. In this particular case, I will cover what happens under the hood with Microsoft Azure AD using OAUTH 2.0. The same logic applies to other cloud providers. In a future post, I will cover how to configure this workflow. For now, let’s focus on how it works in details.

The Catalyst Behind this Post

Islam Zidan, one of the Aruba Experts in our partner community here in UAE, called me to discuss an interesting requirement from one of our customers. The customer wants his employees to access the Guest Network using their Azure Active Directory account instead of using the self-registration workflow. We were both sure it can be done using OAUTH or SAML but we didn’t want to waste time trying it at the customer site especially that access to the site is restricted these days. So, we decided to work jointly on testing the setup offline using both SAML and OAUTH. While testing this, we thought that others engineers might find it useful especially that it is not very well documented so we decided to write this post series explaining what happens under the hood!

The Authentication Workflow!

The below diagram shows the authentication workflow and the interactions between the various components. “Azure AD”, in the below diagram, is used as a “simplification” to cover multiple Azure services including Login, graph.windows.net..etc.

Step by Step View!

Steps 1/2: The user will connect to the guest network and will be redirected to the ClearPass Guest Portal page. The user will be placed in guest-logon role which will allow DHCP, DNS, https access to ClearPass, https access to Social Provider Login FQDNs, Captive portal redirection to ClearPass.

Step 3: The user will press login button and this will kick start the OAUTH workflow.

Steps 4/5: The browser will be redirected to the login page of the Cloud Provider (Microsoft in this case)

Step 6: The user will fill in the account details and the password and then sign in. In the post request, the client_id, redirection_url (callback) will be specified. The browser will be expecting a code as response_type.

Step 7: Azure will return an access code for the browser with a redirect back to the ClearPass guest page submitted in Step 6.

Step 8: The browser will be redirected back to the ClearPass Guest page. It will post back the code it obtained from Azure.

Steps 9/10: ClearPass will use the code, along with its client-id and secret to access Azure graph APIs. As per my understanding of OAUTH code workflow, ClearPass should exchange the code for an access token but I couldn’t any logs on ClearPass for this step. The logs that are available show ClearPass calling Azure APIs to collect the information about the user and his group memberships.

Step 11: ClearPass creates an endpoint entry and populates it with the fields it acquired from the Social Login Provider. The interesting field is the social_password which gets sent back to the controller to complete the radius authentication.

Step 12: ClearPass will instruct the controller to post-back back to controller so controller can do a radius authentication against Clearpass. The social_password is sent here.

Steps 13/14: Browser will post back to controller and controller will send radius request to ClearPass including the social password.

Steps 15/16: ClearPass validates the provided details against the Social Login Repository and returns a Radius Accept. The controller changes the role for the user and the user now has guest access.

This completes this workflow steps in details. Feel free to share your comments and feedback below.

If you are interested to check other ClearPass Tiny Bites, click here.

2 comments

  1. Great Post Ayman. Even though I am not based in UAE , I am sure the chocolate is KitKat 😅

    I had a question related to security of the AD passwords on the open network.

    We had some challenges with setting open network with CP Auth tied to AD credentials as some of the folks were against the idea.

    This was due to the fact that someone can use wi-fi pineapple etc to spin up a similar CP page and lure clients to pass on their credentials.

    1. Hi Nitesh,

      Thank you for the comment!

      Usually, when you use an Open Wi-Fi network traffic will not be encrypted over Wi-Fi and you need to use higher level protocols to encrypt the traffic. So it is best practice to use a trusted certificate for the captive portal pages to prevent anyone from sniffing the traffic.

      However, the concern that you raised is valid and it will not be solved even with https on the captive portal page / login pages. Having an evil-twin AP with a similar captive portal look and feel will most likely fool most clients who will submit their credentials to the fake AP/portal.

      The recommended ways to resolve this or at least reduce its risk
      1- Use WIPS/WIDS to detect/prevent rogue evil-twin APs
      2- Educate clients to check for https for the specific domain names while authenticating
      3- Use WPA3 (Traffic on the open Wi-Fi network will be encrypted)
      4- Use MFA for authentication so even if the AD password was compromised, you will not be able to access resources.

      Ayman

Leave a Reply