Guest portal: How to restrict employee access to only specific AD group?

[jdal]

Hi,  I've got an interesting request from a customer today.  They are using their guest portal for both regular guest users and employees. They would like the employees to connect only once to the portal and then be connected automatically... easy, you'd think, just use device registration!  Indeed! The problem is that they want to restrict access to only some employees identified by a specific AD group.    So they had created to endpoints group : guest and ADusers. The employees were mapped to the "ADusers" endpoints group.  Their authorization rule then looked like this:  1. if ADusers and AD group = authorizedToUseGuestPortal  and usecase = guestflow then permit access  2. if ADusers then permit access  This was working fine...but any user with an account in AD could also connect to the portal !!    So just to confirm one thing, when exactly do we 'automatically register the MAC address of an endpoints"? Based on that, I'd say when a guest is successfully authenticated on the portal, before even sending the CoA.  Ideally the first rule should be:  1. if any endpoints group and AD group = authorizedToUseGuestPortal  and usecase = guestflow then permit access  and then only the MAC address of the device would be added to the ADusers group.  Otherwise, that means me can't really apply any authorization or differentiate "employees" connected from AD or with any other internal account...    What I don't understand is that if we didn't configure ISE to "automatically" register the endpoints but instead provide the capability to user to manually register their endpoints, this seemed to be working fine. Employees that didn't belong to the proper group were looped through the registration process.  That doesn't really make sense to me. Could someone provide an explanation?    This was based on ISE v1.4. Is this addressed in some later release?  Is there any way to make this work without relying on the manual registration?    Thanks,  JF

[Craig Hyps · Accepted solution]

You could use a workaround as covered in document here whereby you send auth to a RADIUS Token server (essentially loopback to ISE itself as a RADIUS server) to provide auth response based on group membership.  If member of group to be disallowed, then return Access Reject.

Another workaround would be to NOT register in same flow but send authenticated AD users in special group to a Hotspot flow (or BYOD flow where it performs registration only).  In this way, you could permit some members based on group membership, register others, while denying the rest.

Restricted users could be redirected to a HTML page (2.2 custom portal files) or pre 2.2 (hotspot as a message portal) Re: Support Information button in place of link?

[Jason Kunst]

Sorry as I understand it, its for separate AD groups. In that case you could could call out the different AD groups as part of the flow.

if denyemployeeendpoint group, deny

if permitemployeeendpoint group, permit

If guest_flow and certain AD groups then send to hotspot portal to registered to deny endpoint group

If guest_flow and different AD groups then send to hotspot portal to register to permit endpoint group

If guest endpoints then permit guest

Otherwise redirect to portal

Will this work?

[Craig Hyps]

Jason,

I think you may be saying the same thing as covered under 2nd workaround.  That option would have following flow:

Permitted AD User:

1. Send user initially through CWA
2. User authenticates to AD. 
3. CoA reauth sent and user now in Guest_Flow and AD lookup can be performed.  Based on AD group membership to "AllowedGroup", they can be returned policy to a Hotspot portal X.
4. Hotspot Portal X assigns endpoint to a permitted endpoint group. 
5. CoA again sent and access based on ID group applied.

Non-Permitted AD User: Same flow, but due to matching "DisAllowedGroup" in step 3, they are sent to Hotspot Portal Y which assigns them to no access policy.

Guest User: Standard access after step 1.

The caution here is multiple redirects in succession.  This should occur without issue, but some earlier, non-patched ISE versions may not always behave as desired.

/Craig

[dkorell]

I am desperately trying to get this to work but no luck. The document was written for a sponsor portal login but should it work for a guest portal login? Basically in my setup employees connect to an SSID that directs them to a guest portal which requires a username and password. There are AD accounts I do not want being used for this so I'm trying to lock this down to an AD group. When I follow the directions they are still authenticating even though the sequence only has the PSN configured. They are also not matching the policy specifying the device IP and AD group.

[Jason Kunst · Accepted solution]

The easier route is this mentioned before:

Another workaround would be to NOT register in same flow but send authenticated AD users in special group to a Hotspot flow (or BYOD flow where it performs registration only).  In this way, you could permit some members based on group membership, register others, while denying the rest.

Restricted users could be redirected to a HTML page (2.2 custom portal files) or pre 2.2 (hotspot as a message portal) Re: Support Information button in place of link?

authorization rules

if denyemployeeendpoint group, deny

if permitemployeeendpoint group, permit

If guest_flow and certain AD groups then send to hotspot portal to registered to deny endpoint group

If guest_flow and different AD groups then send to hotspot portal to register to permit endpoint group

If guest endpoints then permit guest

Otherwise redirect to portal (wireless_mab only)

[dkorell]

I am still learning ISE and the logic makes perfect sense but I'm not sure how do I redirect a guest, once they have already opened the first portal and logged in, to a second portal which can register their endpoint? Would they have to close their browser and reopen? I'm currently  running ISE 2.1.

[Jason Kunst]

When they try to access any http site they are redirected.

You can get ISE 2.2 up and running quickly here using the secure access wizard.

There is a guide that goes through most of the flow as well

https://communities.cisco.com/docs/DOC-71189

https://communities.cisco.com/docs/DOC-66329

Please bring up other questions outside of this specific post directly to a community post.

[dkorell]

I got the second redirect figured out and it's working as needed. Thanks for your help.