02-10-2020 11:13 AM
Hi Team,
We have this situation in our deployment.
2 Differents Portals on ISE (each one in 1 SSID)
a. Guest Portal
b. Contractor Portal
In authoritzation rules:
a. Rule for redirect matching Guest SSID Guest and redirect to Guest Portal, then a Rule for SSID Guest and User Guest and Guest Flow with result Accept Accept.
b. Rule for redirect matching Guest SSID Contractor and redirect to Contractor Portal, then a Rule for SSID Contractor and User Contractor nd Guest Flow with result Accept Accept.
The problem comes when a Guest User can login in Contractor Portal and viceversa, after that, a succes page appears, but after that (as expected) the user are redirected to the login page again.
How can prevent this "succes page"? Adding the Group on redirect policy?
Thank you!
Solved! Go to Solution.
02-19-2020 12:44 PM
If you have a single Policy Set handling both SSIDs then yes, that logic should work.
You could use a condition like 'Called-Station-ID ENDSWITH ":SSID_Guest" to match on the SSID (make sure that the RADIUS Authentication/Accounting settings on the WLC include the :SSID in the Called-Station-ID; this is not a default setting).
The AuthZ rule would look something like:
if RADIUS:Called-Station-ID ENDSWITH ":SSID_Guest" AND UserIdentityGroup EQUALS "GuestType_Contractor" then Redirect_DeadEndPortal
You could also create 2 separate DeadEndPortal pages; one specific for Guests and one for Contractors so the portal wording is less generic.
02-10-2020 02:00 PM
What is the difference between your Guests and Contractors in relation to identity? Are they both in the same Identity Store (e.g. Guest Users)?
If both Portals are using the same Identity Store (or Sequence), there's not much you can do to prevent the users from logging into either Portal. The best you could do would likely be to redirect to a custom dead-end portal page informing the user they've logged into the wrong portal.
Trying to match on a user group in the redirect will not work because ISE is only authenticating the MAC address via MAB at that point.
You should consider either using separate ID stores for Guests vs. Contractors or using a single combined portal and using the 'GuestType' User Identity Group matching condition in your AuthZ policy to provide differentiated network access.
Cheers,
Greg
02-10-2020 02:59 PM
Hi,
Yes they are actually on same indentity Store, there is a way to put each one in different Store? Let's say actual Guest for Guest and another one for Contractor?
The main difference is the self register link in contractor and ticket time expiration and VLAN.
Do you have any guide about how to implement the dead-end portal?
About use the combinated condition we tried, but the problem then comes with CoA, when user authenticates and was authorized, dynamic vlane assignment doesn't work as expected, looks like if the endpoint stuck un the old vlan and you need to reconnect to ssid to be reassigned.
Thank you for your help!
02-10-2020 03:50 PM
ISE only has a single internal Guest Users identity store, and there is no way to separate it. Some customers add long-term Contractors into AD, so that would facilitate a separate ID store from Guest Users and the Portals could be configured accordingly.
To add a custom portal page, you would need to create the page in HTML and upload it to ISE via the Work Centers > Guest Access > Custom Portal Files page. You could then reference the path in an AuthZ Profile using an Advanced Attribute of 'Cisco:cisco-av-pair = url-redirect=<url>' similar to what I documented in the Guest Hotspot with max 2 hours network access per day post.
02-11-2020 07:18 AM
Hi Greg,
Yes I understand what you're saying but i thing it will not work as expected.
Actually (When user guest try to log in user contractor portal or viceversa):
1. Log-in in incorrect portal
2. Success Login Page appears
3. Redirect to Portal again
With your solution:
1. Log-in in incorrect portal
2. Success Login Page appears (This cause confusion)
3. Redirect to Dead-End page
Thank you!
02-11-2020 12:56 PM
The dead-end portal will not solve the issue of the initial Success Page, which is working as designed in your scenario using the same identity store.
However, the portal is useful to inform your users that they have connected to the wrong portal instead of logging in and being redirected in a never-ending loop (which would be more confusing for the user). I used a similar approach for another customer in the past.
Cheers,
Greg
02-19-2020 01:59 AM - edited 02-19-2020 02:00 AM
Hi Greg,
But the condition to redirect, the Authz Rule, to this dead-end portal will be something like:
if SSID Contractor and UserGuest then Redirect to dead-end
if SSID Guest and UserContractor then Redirect to dead-end
This will work?
Thank you,
02-19-2020 12:44 PM
If you have a single Policy Set handling both SSIDs then yes, that logic should work.
You could use a condition like 'Called-Station-ID ENDSWITH ":SSID_Guest" to match on the SSID (make sure that the RADIUS Authentication/Accounting settings on the WLC include the :SSID in the Called-Station-ID; this is not a default setting).
The AuthZ rule would look something like:
if RADIUS:Called-Station-ID ENDSWITH ":SSID_Guest" AND UserIdentityGroup EQUALS "GuestType_Contractor" then Redirect_DeadEndPortal
You could also create 2 separate DeadEndPortal pages; one specific for Guests and one for Contractors so the portal wording is less generic.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide