Guest portal allowing only specific AD groups (no BYOD) and sponsored guests

The customer had a pretty straightforward request.

1. A sponsored guest portal where users could self register but had to be approved.
2. Only allow users of a single AD group to be able to log into the portal.
3. They did not want to configure BYOD and the provisioning that goes along with it because they didn’t want their users to go through an onboarding process.

It sounds easy enough. Guest portals can be configured to allow employee access. The problem is that the portal does not allow you to specify AD groups. You can only set the authentication sequence to use which encompasses all of the AD join point. So how can we make it to where an AD user must belong to a specific group in order to be authorized? The answer: Redirect logins for members of the AD group to a hotspot portal.

The configuration for a sponsored guest portal was already in place following the standard method. Here is how it was configured to perform authentication and authorization of the AD group.

1. Create two new endpoint groups to hold the employee device MAC addresses.
   • The Temp-Guest endpoint group will hold MAC address for endpoints on the initial guest portal login page when an employee (AD account) logs in.
   • The AD-User-Guest endpoint group will hold the MAC addresses for endpoints that belong to users allowed to authenticate on the guest network. This group will be assigned by the hotspot portal.
   • Note: Sponsored guest endpoints will still be assigned to the GuestEndpoints endpoint group.
     
     
2. Create a new Guest Type to assign employee devices logging into the guest portal to the Temp-Guest endpoint group.
   
3. Modify (or create) the sponsored guest portal and set the “Employees using this portal as guests inherit login options from” option to the Temp-Guest guest type that was created.
   • You will also need to make sure the identity sequence assigned to the portal supports your AD (Guest_Portal_Sequence by default supports Internal Endpoints, Guest Users, and All AD Join Points).
   • The success action should be configured to redirect to a website (ie corporate site) so that successful AD authentications go back through authorization and redirected to the hotspot portal if necessary.
   • If the user account is not in an authorized AD group, they will simply loop back to the login page.
   • Successful sponsored guest logins will go to the website that is configured for the success page.
     
4. Create the employee hotspot that will be assigned by the authorization policy when a member of the specified AD group logs into the guest portal.
   • In the below example, the <redacted>-Guest is the sponsored guest portal and the <redacted> AD User Portal is the hotspot portal that authorized AD users will be redirect to.
   • The hotspot portal is only configured to utilize a valid certificate, assign endpoints to the AD-User-Guest, and upon success redirect to the corporate website.
     
5. Create the authorization profile that is assigned to authorized AD logins.
   • The GuestRedirect ACL is already configured on the WLC for use by the Sponsored Guest portal redirect.
     
6. The policy set is now ready to be configured.
   • First, the policy set condition is a library condition set to Wireless_MAB and the RADIUS called-station ID ends with the SSID.
   • The authentication settings are standard for guest access.
     
7. The Authorization Policy is now ready to be configured.
   
   • Rule 1 is the default and redirects to the sponsored guest portal.
   • Rule 2 redirects the login to the AD guest hotspot if they are a member of the authorized AD group.
   • Rule 3 allows guest access based on the MAC address being in the GuestEndpoints endpoint group.
   • Rule 4 allows guest access based on the MAC address being in the AD-User-Guest endpoint group.

With all of this in place, it’s time to test. I connected my phone to the guest wireless network and was redirected to the sponsor portal. I logged in with an AD account that is a member of the authorized AD group. I was able to see the browser go to the success page (corporate website), redirect to the hotspot, and then immediately go to the corporate website. Checking the Live Logs:

The Live Logs show that I initially hit the default GuestRedirect, logged in with my test AD account, hit the Allowed AD Guest User rule (ADGuestRedirect authorization profile), and was then assigned GuestAccess by the AD Guest Allow authorization rule. Checking my endpoint in Context Visibility showed that it was assigned to the AD-User-Guest endpoint group.

Attempting the same process with an AD account that was not in authorized AD group resulted in a loop back through to the login page. The endpoint’s MAC address was never moved out of the Temp-Guest endpoint group because it did not match any other rules (ie Allowed AD Guest User rule).

In this example, the AD user isn’t given any more access than a standard guest. That could be modified to meet other requirements. You could assign a result that allowed Internet access along with access to an internal web server for specific AD users. You could set different endpoint groups for different AD groups so that they are purged at different times (ie group A purged after 7 days but group B purged after 14 days).

Please note that a BYOD set up would be better because you could provision a connection to a secure network whereas most guest networks are open. Also note that the AUP can be applied to either the initial guest portal or the hotspot but I would not apply it to both. Not applying it to the hotspot would allow automatic flow through that portal with no user interaction.