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!

[ahollifield]

If I understand correctly, just assign different Endpoint ID Groups to each portal. In authz policies map those EIDs to SSIDs.

[KevinMuller]

Yes, this is something that^I've done already but it does not prevent you to have GuestType "A" authenticating on Guest Portal "B", and if the users does so, its MAC will be added to the Endpoint ID Group mapped to GuestType "A",

[ahollifield]

Just curious but why treat these two guest differently in the first place?

[MHM Cisco World]

In wlc make sure you set calling ID to inlcude SSID 

Then match SSID in authz 

MHM

[KevinMuller]

Yes, that's already what I do for "classic" CWA, but in the Identity Source Sequence mapped to the Guest Portal, there is no way to set a specific "user groups", you can only define identity store.

[MHM Cisco World]

I think you can do two policy (not two authz policy) and match SSID in policy.

So each policy have it authz policy abd it portal 

MHM

[Arne Bier]

@KevinMuller what is Type A/B exactly, and how would ISE discern (in a RADIUS Access-Request) which is which?  You can't rely on MAC addresses - so there is no unique client identifier that I know of, at the pre-auth stage (i.e. the stage where you want this MAC address to be steered to a particular Guest Portal).

[KevinMuller]

Type A/B are GuestType (so basically the User ID Group to which Guest account belong).
Indeed, there is no actual way of filtering on the pre-auth as ISE only get the client's MAC, but I was thinking of restricting access to "A" portal to only guest that below to User ID Group mapped with GuestType "A" during the portal authentication. Hope it makes it clearer

[MHM Cisco World]

[MHM Cisco World]

You have One SSID or two ?  

If you have two use  one for each policy.

MHM

[Arne Bier]

I don’t understand why you’d want to do that. Notwithstanding the fact that it’s possible to direct a client to a specific portal based on MAC address identity - unless you had some bizarre 6th sense to know which MAC address needs which portal. The screenshot that MHM posted doesn’t solve the issue either. The portal selection can be done on ISE hostname, but that means the WLC is now the one with the 6th sense to know which PSN to target. What exact problem are you looking to solve? Is it that you want the self registering user to end up in a specific group, rather than the default (and one and only) Group for self registering guest flow? 

[KevinMuller]

Challenge is quite simple : Sponsor can create account for group "A" or group "B". Depending on the SSID you are connected to, and the associated portal (Portal are different between SSID "A" and "B"), you only allow guest account from group "A" or group "B".
Let's say you have a Guest/Visitor SSID with its associated portal where Guest account are created and associated to User ID Group "Guest". We don't want them to use their account to associated to another CWA SSID named "Contractor" which is also authenticated via ISE. Even if the Guest Portal is different the Identity Store remains the same (Guest Users) and there is no way natively to limit to specific User ID Groups (Guest Type)

[Arne Bier]

You should create two Guest Types - Contractor and GuestOnly - each Guest Type has its own Endpoint Identity Group and rules etc. The question you're asking is how to ensure that Contractor can't authenticated on 'GuestOnly' Portal and vice-versa.

I think that would be possible in an Authorization Policy (each Guest Type that you create, also creates an internal user Identity Group that can be leveraged here)

The Rules shown above do not include handling HA (multiple PSN's) - you should add the ISE hostname check to redirect to your secondary PSN (if you have one) - that just doubles the rules to 4 in total.

The Rules that come after the redirection part will then simply check the Endpoint Identity Group and then return the Authorization Policies accordingly (Access-Accept with Session-Timeout etc.)

[MHM Cisco World]

So what difference between my suggestion and your?

Really don't get. 

MHM