Is possible to use CWA Chaining with MAB authentication?

[Nicholas DiNofrio]

I've been able to successfully configure and test CWA Chaining after authenticating to ISE via Dot1x (User Auth) then logging into a ISE Guest Portal through CWA flow to enforce the Active Directory group membership for the same or different user account.

I am now testing to see if possible to use CWA Chaining during MAB Authentication + CWA Guest Flow on ISE, so far not seeing the CWA_ExternalGroups attribute in the Radius LiveLogs > Authentication Details.

I would like to understand if possible to use CWA Chaining with MAB authentication along with the CWA (Guest) flow in ISE? 

[Nicholas DiNofrio · Accepted solution]

I ended up finding a solution that so far has worked very well to accomplish the requirements while authenticating only with MAB, no Dot1x.  Also, technically not CWA Chaining either, however, still enforcing AD group membership.

Here's the flow I am using in ISE, please keep in mind this is not the full configuration, simply the Authorization Policy design and behavior:

1) Initial Authentication via MAB

2) Matching Guest (CWA) Redirect to get to Self-Registered or Sponsored Guest Portal

3) Login to ISE Guest Portal with AD user account. 

4) ISE Guest Portal presents AUP, upon acceptance, will also register the endpoint to "Registered Devices", per the configuration, as we desired -- but can be any endpoint identity group.

5) ISE Guest Flow completes successfully and CoA sent to NAD

6) After ISE receives successful CoA response from NAD, the authorization rule to be matched has the desired AD group(s) allowed to achieve access, in this case "Internet Access Only".

7) Authorization Rule matches, result on Authorization Profile setup with DACL (wired only) and/or Airespace ACL (wireless only) to get desired access.

8) Will stay matched to this authorization rule for the duration of this radius session.

9) Endpoint disconnects from network, for any reason, upon next connection we match a third Authorization rule that includes "Registered Devices"; but not the AD group -- since it won't be known without going through a Guest Flow in ISE.

10) Matches third authorization rule based on "Registered Devices" endpoint identity group to get desired access.

Authorization Policies are ordered in this manner, as below:

Top Rule) Guest Access with AD  -- matches right after Guest Flow success

conditions: Registered Devices, <AD Security Group>, Radius:Service-Type = Call Check, "AND" Network Access: Use Case = Guest Flow

result: <desired guest access Authorization Profile>

Middle Rule) Guest Access Reconnect -- only needed to skip Guest Portal for X hours only

conditions: Registered Devices, EndPoints:LastAUPAcceptanceHours LESS <number_of_hours>, "AND" Radius:Service-Type = Call Check

result: <desired guest access Authorization Profile>

Bottom Rule) Mab-Redirect   -- triggers the CWA Redirection to Guest Portal

conditions: Radius:Service-Type = Call Check

result: <Authorization Profile for CWA Redirect>

Please use this only as example and not the exact configuration.  They key aspect to know here is that the AD group is only learned after logging into a Guest Portal with an AD user account.  This technically does not perform CWA Chaining, as I've only seen that work with Dot1x at this time.  However, this way can enforce Guest Access for Employees based on AD group membership.

Note: If prefer to get the Guest Portal on every time connect to network/authenticate then please omit the "Middle Rule" as that will match for same level of access provided endpoint has not been purged from ISE.

[ChristianBur]

I want to do exactly this, I want to authenticate external employees with AD accounts using the AD Group to bring their private devices into our Internet WLAN.  
Only the members of one AD Group should get access, all others should get an error message that their account is not allowed (or something like that, but at least an error message). We have more tenants (with separate AD environments, for each tenant there is a separate guest WLAN).

After the external AD user has authenticated himself inital ONCE, the MAC address is to be stored in the Identity Group (with the "PortalUser" in order to find out who the MAC address belongs to) and the login to the WLAN is then to take place via MAB with the corresponding Identity Group.

This identiy group can be set in the "Guest Types", and "Automatically register guest devices" to save the MAC-address automatically can set in the GuestPortal.

I am of the opinion that this is not possible with the ISE.
- AD accounts that are not in the AD group (however login correctly) do not get an error message.
- in the guest portals no AD-group can be specified under "Authentication method" only a whole ADs (this is the design error of CWA !!!!!!!!!!!!!!!).
You can check the AD group in the Policy Sets, but then you have to make a second forwarding to a Guest Portal . Thereby the guest must register himself a second time an a second Portal (1st without "Automatically register guest devices", 2nd with "Automatically register guest devices"), because otherwise "PortalUser" is no longer stored under Endponts.

The CoA disconnects the WLAN connection at the guest's private end device and to complete the process the guest has to reconnect to the same WLAN, but if the device finds another configured WLAN it connects to the other WLAN, so the registration is never terminated.

Furthermore, we have separate GuestTpyes for each tenant I would like to realize that the corresponding GuestTpye can only log on to the WLAN of the corresponding tenant, but this is not possible because you can only select "Guest Users" (i.e. all Guest Users of ALL clients) in the guest portal.

I want to implement the login only with ISE Base licenses, not with extend licenses.

-> CWA broken by design, sorry

is there any software from other vendors that could solve the problem?

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

[Nicholas DiNofrio]

During a MAB authentication is definitely more limted then compared with a 802.1x authentication in respect with matching an identity with a username or other contextual information.   In my opinion, this is mainly due to where the identity resides -- for MAB will be "Internal Endpoints" in ISE (or another identity store where mac address are stored) and for 802.1x we can use Active Directory (or another identity store where username are stored).  

For 802.1x authentication the identity is the username (assuming configured for User Authentication) and ISE can query the identity store against the username/user account directly.   For a MAB authenticaiton the identity is the mac address of the endpoint and query against the mac address to get user group membership needs a mechanism where group membership will be checked -- for example during login to a Guest Portal in ISE that uses a username/password combination.

In my research and expertise, CWA Chaining is designed to be used with 802.1x so that can evaluate the user's group membership upon initial 802.1x authenticaiton and upon logging into the guest portal in ISE.    With MAB authentication is not possible to perform CWA Chaining.

What is possible is the next best thing, during a MAB authentication and only right after logging into a guest portal in ISE (i.e. Sposnored Guest Portal or Self-Registered Guest Portal) then after the Change of Authorization (CoA) from the guest portal then is possible to evalute group membership based on the username used to login to the guest portal in ISE.

This means on the Authorization Policy to be matched for final access under this scenario, should use Authorization Condition "Network Access: UseCase EQUALS Guest Flow" as I could not find any other time when group membership in Active Directory (AD) could be retrieved from within a MAB authentication.   This condition simply requires to have been part of the Guest Flow which will be part of the session attributes when viewed from the ISE GUI: Operations > Radius Live Logs; which gets added after logging into the guest portal in ISE.

Is important to note that when logging into a guest portal, the ones mentioned above, with any user account other than from "Guest Users" identity store (from the Sponsor Portal) then ISE Guest Portal will consider the login to be from an Employee and will use the employee guest type accordingly, from this specific setting from within the guest portal: Employees using this portal as guests inherit login options from which then points to a Guest Type.  Inside that Guest Type is where would set the endpoint group the portal should place the endpoint in -- which is part of the Guest Device Registration feature in ISE.

ISE Guest Portal will assume:

-- as an Employee = when user identity exists in Internal Users, Active Directory, LDAP, etc.

-- as a Guest = only when user identity exists in the Guest Users which is managed from within the Sponsor Portal

Please note, as it was mentioned in this thread the behavior (as described) does not include group membership being evaluated for the guest portal login to determine if success.  Instead if user exists in portal's configured identity store (regardless of group membership) then login will always be succesful.

Looking into the PortalUser attribute from the endpoint cache (from ISE GUI: Work Centers > Network Access: Identities > Endpoints > {select endpoint} > tab: Attributes)  where this is not present is after the endpoint is updated by a HotSpot Portal in ISE.  Under this scenario recommend to check the endpoint attribute "User-Name" as finding its value to be the same username used to login to the guest portal after the guest portal login; even when PortalUser attribute/value exists.  You can get a quick check if the endpoint was updated by a HotSpot Portal by checking for this attribute/value being present in the endpoint cache, as menitoned above: PortalUser.CreationType  Hot Spot

I believe this behavior where PortalUser is not present after endpoint is updated by a HotSpot Portal is expected behavior since there is no user name associated with a HotSpot portal as used to present AUP to the end-user, display message to end-user, and includes a built-in CoA as well.  

For this discussion, the behavior as described handles the behavior almost exclusively within the Authorization Policies and does not require using more than a single Guest Portal in ISE (i.e. Sposnored Guest Portal or Self-Registered Guest Portal) but end-user will be required to be redirected to the guest portal login on every connection since this is the only time to evaluate the group membership for a user account during MAB authentication for a Guest flow. 

If desired, can always use multiple portals so that the behavior is the following:

• Initial Portal displayed is a Guest Portal that will verify username exists as part of the configured identity store and evaluate group memership before able to get redirected to the next portal. CoA will be sent after this step.
• Second Portal displayed is a HotSpot Portal that will display meaningful messages to end-user and register into another identity group (behavior will overwrite if existing endpoint identity group)  as per Guest Device Registeration. CoA will be sent after this step.
  
  
• Final access achieved by matching the endpoint group updated by the second/last portal in the sequence; which also can be matched on subsequent connections/authentications to the network.

Worth mentioning, would recommend ISE BYOD flow for any supported endpoint (wireless or wired) that needs to be used where evaluating group membership (i.e from Active Directory) is critical.   Using ISE BYOD flow, able to perform MAB Authentication, go through a simple Guest Flow using one of the guest portals in ISE (not HotSpot Portal), have ISE provision the endpoint's supplicant (optional can also provision a certificate for EAP-TLS) to securely connect to the network via 802.1x --all while not having to take manual actions on every endpoint or having a complex Guest Flow.  

I particular like this video "BYOD Made Easy with ISE 2.0" to help get started with ISE BYOD flow -- be advised ISE BYOD could be considred more complex and while is not difficult, challenges may still be experienced during intial config and troubnleshooting that is not suitable for discussion on this thread as it is off-topic.   When encountered such a scneario where unable to get the ISE BYOD flow working on your ISE deployment feel free to contact Cisco TAC for assistance.

Please also feel free to reach out through your sales team to our ISE product managers for feature request to request changes to expected behavior or when behavior is by design.

[Nicholas DiNofrio]

I found where the PortalUser attribute does not appear in the endpoint cache on ISE GUI: Work Centers > Network Access: Identities > Endpoints > {select endpoint} > tab: Attributes ; appears to be due when a HotSpot Portal updates the endpoint (i.e. update the endpoint group) -- believe this is expected behavior.

In my opinion this occurs because there is no username/password associated with a HotSpot portal as meant to give AUP, some meaningful text to display to end-user, and finish with a Change of Authorization (CoA) based on configured options which are: 1) Reauthentication or 2) Terminate the session.

Instead, the endpoint attribute/value of "User-Name" should show the same username of that used to last login to the guest portal (i.e. Sponsored Guest Portal or Self-Registered Guest Portal) on the existing session. Should the session terminate the "User-Name" attribute/value may show the endpoint's mac address, as expected. Even when "PortalUser" attribute/value exists after successful login to a Guest Portal (excluding a HotSpot Portal), the "User-Name" and "PortalUser" attribute/value should be the same [also may be the same as Radius Username [1] attribute].

To evaluate the group membership of a user account during MAB Authentication will only be possible after guest portal login and thus is required to redirect to the guest portal on every connection to the network for MAB authentications. Using authorization condition "Network Access: UseCase EQUALS Guest Flow" only on the Authorization Policy to be matched after logging into the guest portal in ISE is also suitable to use to help ensure is only evaluated after login to guest portal is performed. As described, this experience only requires the use of a single Guest Portal in ISE. This is made possible and enforced through the ISE Authorization Policies as currently not possible to have the guest portal determine if user is in correct group at this time.

If use a Guest Portal followed by a HotSpot portal as enforced through the Guest Flow experience then the second portal (HotSpot Portal) can update the endpoint with a different endpoint group (via Guest Device Registeration feature in ISE) and that new endpoint group can be matched on final access Authorization Policy on initial completion of the Guest Flow and on subsequent connections/authentications to the network and does not check for UseCase=Guest Flow.  This approach requires at least three Authorization Policies to 1) Redirect to Guest Portal, 2) evaluate group membership and redirect to HotSpot Portal, and 3) to achieve final access. This is used because successful login to a guest portal is based on the identity store itself and does not evaluate group membership in the guest portal -- at this time.  Instead, the second portal only matches when group membership is evaluated in order to redirect the end-user to the HotSpot Portal.

When evaluating group membership is critical in the network (and when endpoint is capable of performing 802.1x) prefer to use 802.1x authentication since is more flexible, does not require complex Guest flow, and ISE can query the identity directly on the configured identity store to create a simplier end-user experience. On supported endpoints, the ISE BYOD flow can be used to provision the network profile (i.e supplicant settings) and (optionaly) the client certificate in order to perform certificate-based authentication through EAP-TLS.

Also feel free to reach out through your sales team to our ISE product managers for feature request to request a change in expected behavior / expected design.

[Nicholas DiNofrio]

I found where the PortalUser attribute does not appear in the endpoint cache on ISE GUI: Work Centers > Network Access: Identities > Endpoints > {select endpoint} > tab: Attributes ; appears to be due when a HotSpot Portal updates the endpoint (i.e. update the endpoint group) -- believe this is expected behavior.

In my opinion this occurs because there is no username/password associated with a HotSpot portal as meant to give AUP, some meaningful text to display to end-user, and finish with a Change of Authorization (CoA) based on available options which are: Reauthentication or Terminate the session.

Instead, the endpoint attribute/value of "User-Name" should show the same username of that used to last login to the guest portal (i.e. Sponsored Guest Portal or Self-Registered Guest Portal) on the existing session. Should the session terminate the "User-Name" attribute/value may show the endpoint's mac address, as expected. Even when "PortalUser" attribute/value exists after successful login to a Guest Portal (excluding a HotSpot Portal), the "User-Name" and "PortalUser" attribute/value should be the same [also may be the same as Radius Username [1] attribute].

To evaluate the group membership of a user account during MAB Authentication will only be possible after guest portal login and thus is required to redirect to the guest portal on every connection to the network for MAB authentications. Using authorization condition "Network Access: UseCase EQUALS Guest Flow" only on the Authorization Policy to be matched after logging into the guest portal in ISE is also suitable to use to help ensure is only evaluated after login to guest portal is performed. As described, this experience only requires the use of a single Guest Portal in ISE; and is made possible and enforced through the ISE Authorization Policies as currently not possible to have the guest portal determine if user is in correct group at this time.

If use a Guest Portal followed by a HotSpot portal as enforced through the Guest Flow experience then the second portal (HotSpot Portal) will be able to update the endpoint with a different endpoint group (via Guest Device Registration feature in ISE) and that new endpoint group can be matched on final access Authorization Policy on initial completion of the Guest Flow and on subsequent connections/authentications to the network and does not check for "UseCase=Guest Flow".

This approach requires at least three Authorization Policies to:

1) Redirect to Guest Portal

2) evaluate group membership and redirect to HotSpot Portal, and then

3) Achieve final access.

This is used because successful login to a guest portal is based on the identity store itself and does not evaluate group membership in the guest portal -- at this time. Instead, the second portal only matches when group membership is evaluated in order to redirect the end-user to the HotSpot Portal.

When evaluating group membership is critical in the network (and when endpoint is capable of performing 802.1x) prefer to use 802.1x authentication since is more flexible, does not require complex Guest flow, and ISE can query the identity directly on the configured identity store to create a simpler end-user experience. On supported endpoints, the ISE BYOD flow can be used to provision the network profile (i.e supplicant settings) and (optionaly) the client certificate in order to perform certificate-based authentication through EAP-TLS.

Also feel free to reach out through your sales team to our ISE product managers for feature request to request a change in expected behavior / expected design.

[ChristianBur]

After reading the description, I still think that Cisco didn't give enough thought to implementing CWA portals, otherwise I can't explain this catastrophic implantation.

I cannot send "ordinary users" (who have no idea of technology) through a complex guest authentication process. BYOD cannot be used either, because BYOD requires apps or certificates to be installed on the end devices, which is not desired or possible. 802.1x (PEAP or so) cannot be used because the implementation is broken. With PEAP the end devices do not check the RADIUS certificates in most cases, so they pass on their AD password to every access point with the same SSID (so the AD password is not secure). But with PEAP there is also the disadvantage that the RAIDUS certificates are not distributed centrally, so all guests would get an error message when renewing the ISE RAIDUS certificate. Otherwise, 802.1x with PEAP would be a very nice solution, as the user name would be permanently visible in ISE Live Log. 

It is also unacceptable that unauthorized AD identifiers, do not receive an error message (form the guest portal) but are redirected to the guest portal over and over again, thus complicating support.

So unfortunately only guest portals remain at the moment, but here the MAC address has to be stored somehow, because otherwise the guest registration has to be done several times a day (e.g. by the deep sleep with smartphones).

Guest portals need a way to verify AD groups or guest types out of the box.

At present the authentication of the guest Protal is not usable!!!

[Jason Kunst]

Yes that's how it was designed. I would recommend using http://cs.co/ise-feedback
Also have you seen this thread? 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

[jcatanzaro9]

I have been digging for months to try and come up with something similar to what you've listed out in your solution....smashing my head against a wall repeatedly with no luck.  I'm going to give this a try and see what happens, if it works as well in my environment this could potentially remove a huge, huge burden for me.  So thank you in advance even if it doesn't end up working because it's the closest I'll have gotten to solving the problem!