Cisco ISE CWA (Guest Portal) Authentication -> Broken By Design

[ChristianBur]

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 in the Autorizaiton Policy.

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 (mainly with smarphones in deep sleep). Sleeping client we cannot use, because our guests WLANs are secured with PSK. 

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". But if I add an AD-connection in the Identy Source Seuences it always includes ALL users, but I only want to add a part by groups. 

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]

yes this is the way it works. Please reach out through your sales team to our ISE product managers for feature request.

[ChristianBur]

You are confirming that there is currently no way to create a guest portal where you can restrict access to certain user groups. Either all users of an Identy Source or none. Even if I would create a feature request now, Cisco might not care much about it.

[howon]

Christian, it is possible to tie it to separate endpoint group based on AD group and also tie the endpoint with portal user. The Flow is similar to what you have described but instead of forcing the session through hotspot portal after initial CoA, use BYOD portal. Now, you don’t want to make the endpoint go through the full BYOD process, so the trick is to make any endpoint OS to be unsupported so endpoints will be exempted from full BYOD flow. This can be achieved by:
Administration > System > Settings > Client Provisioning. Change ‘Native Supplicant Provisioning Policy Unavailable:’ setting to Allow Network Access

Policy > Client Provisioning. Modify the condition or simply disable all rules

Once above is done, create matching endpoint groups, then matching BYOD portal that registers to respective endpoint groups, and finally authorization profiles for each BYOD portals.

After that, create policy to permit based on endpoint group and another to provide respective BYOD portal based on AD group.

Note that while the flow is configurable on ISE 2.1, you will need 2.4 to make the username visible in the livelog.

[ChristianBur]

Thank you for this food for thought, I haven't thought about that yet.

This solution has however also the following disadvantages:
- In the WLC you have to activate "Captive Network Assistant Bypass" in the corresponding WLAN under Layer 3 Security, because the Mini Safari Broser (for Captive Portal sites) is not supported by BYOD (will be used with Apple iOS devices). This means that guests have to manually call an http (no https) url in the browser.
- Sometimes the CoA (Dynamic Authorization failed) [reason unknown] is not working, so a guest does not complete the process (GuestPortal -> CoA -> BYODPortal).
If the terminal device has defined another WLAN (which is also within range), the terminal device connects to this WLAN after the CoA. Thus the guest does not see the BYOD portal.
- In the GuestPortal ALL identifiers are still allowed, so a not authorized but valid account doesn't get an error message, but always gets back to the GuestPortal. The whole thing therefore looks like an error and not after a non-authorized login.

Therefore there is unfortunately still no possibility to bring guests into the WLAN/LAN using certain AD groups.

[paul]

Why can't we just use the RADIUS callback trick we use on other portals?  Unless I am reading this wrong you don't want to break out AD groups into different endpoint identity groups you just want to only allow certain AD groups onto the guest Internet access.

Define your ISE PSNs as a RADIUS token server, call it RADIUS_Callback.  Then define a sequence that uses the Guest Users and RADIUS Callback.  Define your ISE PSNs as network devices and assign them to an NDG called ISE_PSNs.  Create a policy set for device types ISE_PSNs knowing the only time it will be hit is the guest portal doing a RADIUS callback.  Then in your authorization rules for the RADIUS Callback policy set only allow the AD groups you want.  

[ChristianBur]

I have already tried the RADIUS callback trick for about 1 year, but I couldn't use it either.
I mean I couldn't see which portal the request came from, because we have several portals with 5 different ADs.

In addition to the AD groups (for private end devices of the employees) we use the internal users (with different groups "GuestType_...").

[paul]

Ahh yeah sorry missed you had 5 different portals.

[ChristianBur]

I just noticed that BYOD requires a Plus license and no normal Base license.

Question:
Has anyone ever built an LDAP proxy (ISE -> LDAP Proxy -> Microsoft AD)? the LDAP proxy will filter to certain AD groups, because the ISE cannot do that.

[hslai]

AD itself can serve LDAP, by default. In our lab, we normally create a LDAP external ID store and add OU qualifiers to narrow the subject search base.

[ChristianBur]

Right now I doubt that LDAP can be used with CWA.

Because the TechNotes only mention EAP-GTC, EAP-TLS and PEAP-TLS but no PAP_ASCII.

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/119149-configure-ise-00.html

When I test it, I only get the following error message at the guest portal during login.

     [ 400 ] Bad Request
    The request is invalid due to malformed syntax or invalid data.

------

However, the solution was also described here.

https://community.cisco.com/t5/policy-and-access/sponsored-guest-portal-with-active-directory-users-and-group/td-p/2762468

We have an organizational unit in which all AD users are included (e.g. AllUsers) and an AD group (e.g. WLANUsers) in which the wlan users are included.

Subject Search Base= OU=ALLUsers,OU=TEST,OU=Customer,DC=TestIntra,DC=de
Group Search Base= CN=WLANUsers,OU=US-TEST,DC=TestIntra,DC=de

The aim is that the LDAP Connector only authorizes the AD users in the WLANUsers group, all other users from ALLUsers not. Would the filter be correct?

[hslai]

CWA is actually performing PAP-ASCII internally between the guest portal and ISE. That TechNotes is performing DOT1X in a WPA2 Enterprise network so not applicable to CWA.

I can't tell how you got HTTP 400 Bad Request, which might need a TAC case to debug. It worked ok for me as below:

The trick to restrict users with LDAP in this case is to put them in a particular organization unit (OU); e.g. "OU=Users,OU=HCC,DC=demo,DC=local", in our lab.

I first attempted a user not in the OU so it failed with user not found. Then, logged-in ok with a user in the OU.

[ChristianBur]

We have ADs with more than 10.000 users and it is not desired to move users within OUs, only AD groups work :-/

Therefore I had the idea with a LDAP proxy. In the LDAP Proxy only the desired AD groups are deposited and the ISE receives a deny from the Proxy, when the user is not in the corresponding AD group.

Unfortunately you have to run a separate service (e.g. OpenLDAP) and if it works at all I don't know.

[ChristianBur]

https://community.cisco.com/t5/other-security-subjects/is-possible-to-use-cwa-chaining-with-mab-authentication/m-p/3779687#M148685

[Jason Kunst]

have you seen this? https://community.cisco.com/t5/identity-services-engine-ise/guest-portal-how-to-restrict-employee-access-to-only-specific-ad/m-p/3460223/thread-id/3355#M3360