Restrict GuestType to specific portal/SSID

[KevinMuller]

Hello!
For a customer, i'd like to configure two captive portals respectively tied to two SSID (different usage).

However, i'd like Guest Type to be tied to one of the captive portal/SSID, basically : 
- GuestType "A" can only authenticate to GuestPortal/SSID "A"
- GuestType "B" can only authenticate to Guest Portal/SSID "B"
- GuesType "B" cannot login to Guest Portal/SSID "A" and vice-versa

I there a way to perform this with ISE in 3.3 ?
Thanks a lot!

[Arne Bier]

@MHM Cisco World - your screenshot shows the proven solution for doing ISE Portal HA, by checking which PSN is processing the request (hostname check) and then returning the appropriate URL to the endpoint. Noticed that the SSID is the same in both rules.

What @KevinMuller was asking for was to prevent Guests and Contractors from using the wrong portal - and that enforcement requires validation of the SSID AND the Internal User Group of the authenticating user.

My comment at the end of my last post mentioned the HA aspect - which your slide covered. So it's a merging of both of our suggestions.

[MHM Cisco World]

@Arne Bier 

Please check my all comments' I already mentioned many times he need two ssid.

MHM

[Arne Bier]

You're right about suggesting two SSID's - it was when @KevinMuller  explained his intention of restricting each guest type to a particular portal, that I added the AND rule logic to enforce that.

Something worth trying and testing.

[KevinMuller]

You cannot checks on these conditions are for CWA you perform Host Lookup type of authentication. ISE performs the authentication process on the guest portal "internally", it doesn't go through the RADIUS Policy Sets for this. Only Endpoint ID Groups are correct conditions in the AuthZ Rules (unfortunatly ...).
I'll try enable external authentication in the ISS pointing to RADIUS Token Identity Store where the RADIUS Server is actually the same ISE to "loopback" the authentication.I've never tested that before. Anyhow, even if it works, I can only restrict one Portal not both.

[MHM Cisco World]

You cannot checks on these conditions are for CWA you perform Host Lookup type of authentication.  <<- I dont get what you meaning here

But

Guest when it authc in ISE it CWA 

MHM

[KevinMuller]

To clarify my statement : I'm not 100% sure we can match on the User Identity Groups instead of Endpoint Identity Group in authz conditions. As the RADIUS authentication is MAC based, the lookup should be performed on the Internal Endpoints identity store.
Tbh, I don't know if ISE re-eveluate the Policy Sets when the client hit the "submit" button when guest portal is filled with username/password, I know for sure that CoA is triggered to have a new MAC Authentication.

[MHM Cisco World]

Do me or @Arne Bier mention any match of endpoint group?

Sure for guest after the guest success authc via portal it mac will add internal store and you can not use it as condition.

We match conditions before even guest authc' 

WLC always send SSID guest associate with to ISE

Now ISE receive this radius request with specfic SSID' it will redirect traffic to any of your portals.

At this point you dont need to match mac in internal store since it not even found'

MHM

[KevinMuller]

Yes, review the thread/printscreen. And this is something that is usual to do that for "Permanent Guest" that's why i'm mentionning it (i.e : https://documentation.meraki.com/MR/Encryption_and_Authentication/CWA_-_Central_Web_Authentication_with_Cisco_ISE)
"Now ISE receive this radius request with specfic SSID' it will redirect traffic to any of your portals."
Indeed, but the redirection is fine, I match the SSID and send different AuthZ profile to send users to thei respective portal. However, the Identity Store (Guest Users), remains the same for both portal, you can have hundred portals and/or SSIDs they will allrely on the same Guest Users database of ISE (if authenticated locally), no matter what SSID or portal you are hitting.

[MHM Cisco World]

Even if all SSID guest mac in one internal identity store' still when guest re-auth ISE can match it SSID and hence know this mac+ssid is authc via policy 1 or 2 and apply correct download ACL.

MHM

[MHM Cisco World]

after this informal discussion I finally get why @Arne Bier many times ask why need this separate.

Download ACL in end for both guest is same allow ALL traffic from guest to network' so why this headache config.

The only reason we need this if ypu want to do some load balance between two PSN or two portal(interface) of PSN 

Other than this there is no meaning of this config.

Thanks alot 

I hope I get your reply to my above statement.

MHM

[KevinMuller]

dACL is not a thing as SSID are mapped to different subnets. Once the Guest is authenticated, I just send an Access-Accept without any other attributes.
"Even if all SSID guest mac in one internal identity store' still when guest re-auth ISE can match it SSID and hence know this mac+ssid is authc via policy 1 or 2 and apply correct download ACL."
--> What if a Guest which is suppoed to authenticated to SSID "A", authenticate successfully to SSID "B" ? There is no way to prevent that, because the MAC is not yet added to the EID Group.

[MHM Cisco World]

It is more sense now

AP beacon both SSID' and you want guest only content to specific SSID.

Since we dont have mac (yet) abd guest use portal to authc so

Sorry we can not force guest to use specific SSID 

All my reply before assume that you have two AP and each one in different site and beacon one ssid.

Sorry for this bad news.

MHM

[KevinMuller]

Thanks for trying to help on this topic

[MHM Cisco World]

You are so welcome 

MHM