- Your WLC and AP registration is already in place, if using Meraki then Meraki AP is already registered on dashboard and all the allowed URL are added to walled garden.
- ISE does not support token encryption as of this writing, so ensure that you are not encrypting the token on Azure side
- The Service Provider never directly interacts with the Identity Provider. A browser acts as the agent to carry out all the redirections.
- The Service Provider needs to know which Identity Provider to redirect to before it has any idea who the user is.
- The Service Provider does not know who the user is until the SAML assertion comes back from the Identity Provider.
- Devices used:
ISE 2.6 patch3, WLC 184.108.40.206, Azure AD, iPadOS 13.3, windows10.
Flow and Key terms
- A Service Provider (SP) is the entity providing the service, typically in the form of an application, in this case ISE.
- An Identity Provider (IDP) is the entity providing the identities, including the ability to authenticate a user. The Identity Provider typically also contains the user profile: additional information about the user such as first name, last name, job code, phone number, address, etc. Depending on the application, some service providers may require a very simple profile (username, email), while others may require a richer set of user data (job code, department, address, location, manager, etc), in this case Azure.
- A SAML Request, also known as an authentication request, is generated by the Service Provider to “request” an authentication.
- A SAML Response is generated by the Identity Provider. It contains the actual assertion of the authenticated user. In addition, a SAML Response may contain additional information, such as user profile information and group/role information, depending on what the Service Provider can support, in this case we will ensure SAML response contains Azure AD group information to built group based policy on ISE
- The Flow is shown below at high level
- The user connects to the SSID configured for mac filtering (mab).
- ISE responds back with access-accept that contains Redirect-URL and Redirect-ACL attributes
- Webpage is initiated from user’s machine.
- WLC intercepts the web request and redirects the user to the ISE guest portal.
- ISE verifies if there is an active assertion associated to this client’s browser session against the IdP. If there are no active sessions, the IdP will enforce the user login. At this step the user will be prompted to enter AD credentials in the IdP portal directly.
- After successful authentication, Azure sends the SAML assertion response to the browser.
- Browser relays the assertion back to ISE.
- ISE verifies the assertion response and if the user is properly authenticated, it proceeds to AUP and then with device registration.
- ISE issues COA , this time hitting role-based condition policy.
- User is granted access based on role-based result defined in ISE policy.
Lets start with SSID configuration on Cisco WLC
Captive Network Assistance Bypass can be disable, This mechanism is used for the device to automatically open a web browser when a direct connection to the internet is not possible. This allows WLC to interrupt the web request and relay portal page hosted by AAA server or other identity provider like Azure in this case, without user opening a webpage on the device.
This ACL is used for redirection of traffic, any traffic denied will be redirected.
make sure that the below URLs are permitted in the ACL, they are used for devices to access azure portal.
while ISE pushed the ACL name the ACL itself needs to be defined on WLC, this ACL is enforced on users belonging to G-1 group.
This ACL is enforced on users belonging to G-2 group.
On azure start with an application configuration, ISE is not one of the listed applications on Azure gallery so start with Non-gallery application.
Home>Default Directoy>Enterprise Applications> New application>Non-Gallery application
Give a name to your application and click Add, new application will show up on list of enterprise application.
Go back to default directory and add groups, in my case I have added 2 groups.
Add users now and assign it to specific Group. In my case I have 4 users and 1 default Azure login user account.
Map the group/Users to the application, as per your business requirements.
Next is configure Single sign-on for your application, but before that we should configure ISE.
Start with configure Azure as SAML Id provider on ISE.
ISE portal configuration, in my case I am using self-registered portal on ISE.
Setup portal setting as needed, make sure authentication method is SAML Id.
Export Service provider info from ISE and import it on azure.
configure Single sign-on for your application and upload the Service Provider info exported from ISE.
Create a custom Group Attribute, under user and attribute Claims section.
You will see group attribute is added now, all these attributes need to be added to ISE shortly.
Download Federation metadata from Azure and import it on ISE
Add group information defined on Azure, so that we can call them when building policy.
Name of assertion is Object ID for the group that you can get from Azure.
Add user attributes from Azure
ISE policy is simple like any Guest policy with additional condition of Azure group requirement.
First test is with test1 user which is part of G-1 group and it should be assigned GUEST_INTERNET authorization result, which allows internet only access.
Connect to SSID
User gets redirected to captive.apple.com, automatically.
WLC interrupts the requests and redirects it to ISE
ISE redirects the request to Microsoft login portal, now user logs in (ignore the long user ID, courtesy to free azure account)
Sucessful authentication message
This can also be validated with SAML debug logs from ISE.
Now the user since belonging to G-1, should not be able to access Server1, 192.168.129.13.
However, when the user logs in using test3 credential belonging to G-2, it should not able to access Server1, 192.168.129.13.
I hope you enjoyed reading it, as much as I enjoyed writing it.