Multiple guest portals one SSID

[dan.letkeman]

Hello,

I'm wondering if there is a way to create a guest network that has multiple guest portals with one SSID?  I would like to have different guest types for different types of guest users so that I can limit max connections and max devices differently.  I only see a way to select one Guest Type in each Guest Portal.

Thanks,

Dan.

[Config T]

There are ways to do this but it just depends on how you want to approach it. How will ISE know which portal to present to each guest?

[dan.letkeman]

That sounds promising.  My thought was some kind of pre-portal, but I don't see anyway of doing that.  What I would like to see is a way to apply different guest types based on the user AD group.

Do you have a suggestion on a way to accomplish this?

[Config T]

What you can do is provide a single portal where guests can enter their credentials. Make sure the portal is configured to NOT automatically register guests, you'll do this manually. Once the guest enters their credentials, you build an authorization policy to check the user against AD Groups. The result of those authorization policies would be to redirect the user to a hidden portal page. That hidden portal page assigns the guest user's endpoint to a endpoint identity group/guest type. Each guest type would have it's own unique hidden portal page.

[dan.letkeman]

Sounds like it could work, however, manually registering 4000+ guest devices would be a problem.

I would really like to do 802.1x for the SSID connection and then have the first connection redirect to the correct portal, but it doesn't look like that is an option as you cannot do MAB and 802.1x at the same time on an SSID.  eg:

Client1 - 802.1x - user1/group1 - authenticated - ise authorization would redirect to portal1 based on group1.

Client2 - 802.1x - user2/group2 - authenticated - ise authorization would redirect to portal2 based on group2

[Config T]

Sorry, I probably didn't word my example correctly. I didn't mean you would need to manually register each individual guest endpoint. What I meant was that you don't want the initial portal page to register each guest endpoint, you want the hidden guest portal pages to register the guest endpoints.

For example, if you have four different guest types, you would create four of these hidden guest portal pages. Each hidden portal page would be configured to assign the endpoint into the appropriate identity group.

[dan.letkeman]

Ok, that makes sense.  So two authorization policies, one that has Wireless_MAB, and SSID id 20, and the result is guest_web_redirection, and then the user will enter there credentials, and then another policy above that one that will apply after the portal login was successful to redirect to another portal based on the ad credentials entered on the first login.  Do you know if the users will have to login again the second time?

[Config T]

If you set it up right, users will only have to enter their credentials once. At least until their endpoint is purged from the identity group.

It's really three authorization policies, one common to all guests and two unique to each guest type:

1. The default central web authentication shown to all guest users when they first connect.
2. DRW (device registration wizard). You would configure your conditions to check AD group membership here. The result would be a hidden portal page with the only function being to assign the MAC address to a specific group. You need to create one of these for each unique guest type. The portal page is hidden because you won't display any login prompts or AUP pages.
3. MAB. If the device is already a member of an identity group then we know it was previously assigned to a guest group, so just authorize it with the desired access here.

Of course you need to order these authorization policies in reverse order.

The idea is based off this document: https://communities.cisco.com/servlet/JiveServlet/previewBody/68170-102-1-125090/How-To_97_Create_Custom_Guest_Success_Pages_by_Active_Directory_Group_with_ISE_12.pdf

[dan.letkeman]

Thanks, I will give it a try sometime this week.

Dan.

[dan.letkeman]

Well it seems as if I can get it to work, however I need to authenticate twice.

I am unable to find a place where the redirect example found in the document works to redirect the users to the correct portal.

[Config T]

When you authenticate twice, are both authentications to the same portal page? Or two different portal pages?

[dan.letkeman]

Two different portal pages.  The first authentication is the the default portal page.  The second authentication is to the portal based on the AD group.

At this point it does not redirect to the second portal page, because if I put in a redirect url such as http://www.yahoo.com I get a browser error page and the browser does nothing from that point.

I also noticed that once I successfully authenticate and the device is added to the correct endpoint group, when I re-authenticate the identity is the mac address of the device and not the originating user account.

[Config T]

Your requirements have changed since the original post. If you're doing 802.1x, why do you even need a portal page to identify the user? Since you're already doing 802.1x, you can identify the user and just grant them the access they need for that session without sending them to a portal page.

[dan.letkeman]

The requirements are still the same.  I mentioned that I would have liked to use 802.1x, but you cannot do 802.1x and MAB at the same time, and you cannot set max concurrent logins based on ad accounts when using 802.1x.  So because of this I am left with using the guest portal system.

Your example of using multiple portals almost works.  The only issue I have is with the redirect.

The other issue I have, which is not related to the portals is the loss of the identity when authenticating using MAB after the device is registered.  This is a problem because I need the identity of the user for upstream web filter user authentication.

[dan.letkeman]

What I landed up going with this 802.1x PEAP-MSCHAPv2 and CWA chaining for BYOD access.   This way I didn't have to figure out how to redirect one portal to another (which doesn't seem to work in 2.x anyway).  I authenticate users against AD groups and redirect separate groups to separate portals each which have separate guest types.