ISE CWA portal mapping AD group to Endpoint Group

[Anthony Poli]

Hello,

Is it possible to automatically register devices to specific endpoint groups based on AD security group membership of the user authenticating via a guest portal?  Ideally the user's group membership drops their MAC into the specified endpoint group during login and without manual intervention.

My customer is using a typical MAB/guest portal for BYOD and would like to apply different device purge policies based on user role in the organization: group A never expires, group B purges every X days, etc.

Appreciate any help.

Anthony

[Jason Kunst · Accepted solution]

Moved this to ISE public for maximum exposure.

Under the guest portal settings there is a selection - Employees using this portal as guests inherit login options from

you choose this pulldown to select a guest type, under this guest type is where you choose the associated endpoint group. This means all employees are handled the same. So you can't do it with native portal

However you might be able to do what you need using the following:

Setup HotspotX portal settings for employeeEndpointgroupX and HotspotY for employeEndpointgroupY

Authz rules

If wireless_mab and employeeEndpointgroupX or Y permit access

If wireless_mab and employeeADloginX then redirect to hotspotX

If wireless_mab and employeeADLoginY then redirect to hotspotY

If wireless_mab then redirect to guest portal

Users will come into the portal login as employee and then be redirected respective portal to be put into the correct endpoint group and accept the AUP on the hotspot. Then users will be permitted access

[Anthony Poli]

Jason,

Good thinking, and I appreciate the innovative workaround.  This does appear to work however it comes at the price of logging in twice, at least as I have worked it out interpretting your suggestions.

Thanks for your help.

[paul]

You should only have to login once.  The first portal is a typical sponsor portal with AD logins allowed.  The first portal has no AUP page and basically just goes to the success condition.  The key is the CoA is kicked off that would then set the next URL redirect to the correct hotspot portal.  The hotspot portal would display AUP and do the success condition after accepting AUP.

So the flow would look like this:

1. Employee connects to SSID and get redirected to portal.
2. Enters their AD credentials.
3. The success condition says direct them to "www.cisco.com".
4. CoA is sent to the WLC.
5. Employee hits the desired hotspot rule.
6. As the browser is trying to go to www.cisco.com the second hotspot redirect would kick in and send the user to the AUP page.  
7. Employee accepts the AUP.
8. MAC address moved into the endpoint identity group specified by the hotspot portal
9. Success condition says direct them to "www.cisco.com".
10. CoA is sent to the WLC.
11. Session hits the rule that allows the endpoint identity group.
12. Employee sees Cisco's homepage.

[Anthony Poli]

Paul,

Thanks for the additional clarification.  I just reconfigured this in the lab and it works perfectly, and is what Jason meant all along but I simply overlooked. 

Thanks again to you both!

Anthony

[Jason Kunst]

Great! Please if you have an authorization policy screenshot to share that will finish this masterpiece!

[Anthony Poli]

Image below.

I had no idea that the CoA process could work in this way, where an if/then condition could leverage something that occurred in the past, as in the user presenting credentials and that being captured/leveraged as they go through the CoA a second time.   I would have (incorrectly) thought that once that lookup had transpired and the CoA re-initiated, that it wouldnt be possible to "hang on" to that info for use in the second attempt. 

Now I am wondering what the limits are and what else is possible.

Thanks again, guys.  Really enjoyed sorting though this one with y'all.

Anthony

[shamax_1983]

You explained exactly what I was thinking before as well.
Nice to know this is possible, so you can play with this and hopefully do new things.

[ChristianBur]

my post was unfortunately deleted by Cisco, so I'll post it here again.

https://community.cisco.com/t5/identity-services-engine-ise/cisco-ise-cwa-guest-portal-broken-by-design/m-p/3709455#M18080

In the last days I have been working with the guest portals of the Cisco ISE (v2.1.0). My result: "Broken By Design".

We are currently using Local Web Authentication (Layer 3 Auth) on the Cisco WLC. The WLC forwards the username/password by radius to the ISE. In the "Policy Set" I can then process this request as "WLC_Web_Authentication". Currently we use several Windows AD groups and different GuestType groups per tenant.

The disadvantage of Local Web Authentication is that guests are thrown out of the WLAN at undefined intervals (broadcast key refresh), so guests have to enter their username and password again.

With Central Web Authentication, this is bypassed by storing the MAC address of the guest device in an Identity Group, so with broadcast key refresh only Layer 2 authentication (PSK + MAC address) is required and no Layer 3 (PSK + WebAuth) authentication.

We would also like to have Web Authentication in a larger Internet switch environment (about 80 switches) so that guests have to authenticate themselves before they can use the Internet. In this scenario, however, Local Web Authentication is hardly feasible since SSL/TLS certificates and the Captive Portal would have to be installed on every switch.

That's why I tested the CWA of the ISE. The main problem is that the guest portals are designed in a way that you can't define rules for the allowed guests (Windows AD groups, GuestTypes), but only "Identy Source Seuences". Using separate LDAP "Ex ID Sources", you could define individual Windows AD groups, but not individual GuestTypes for Guest Portal and each tenant.

After some searching I found the following workaround.

https://community.cisco.com/t5/identity-services-engine-ise/ise-cwa-only-allow-certain-ad-group-to-register-their-devices/td-p/3461321

https://community.cisco.com/t5/identity-services-engine-ise/ise-cwa-portal-mapping-ad-group-to-endpoint-group/m-p/3554392

By linking "SponsoredGuestPortal - CoA -> Rules with AD-Groups/GuestTypes -> HotspotGuestPortal - CoA" it is possible to assign single AD-Groups/GuestTypes, but with the following disadvantages: - the initial WLAN connection is disconnected twice (because of CoA) - Since the MAC address of the guest is moved by the HotspotGuestPortal into the final Identiy Group, no reference to the registered guest ( AD-ID or guest ID) is stored in the properties of the MAC address (under Identies).

which means that in the Identity Group many MAC addresses of the guests are available by the successful registration, but you cannot see however which MAC address belongs to which AD identification.???

[Jason Kunst · Accepted solution]

Yes that’s correct behavior. Perhaps with a system like splunk you might be able to stitch together some information. Please reach out through your sales team to the use product managers for an enhancement request.