Central Web Authentication (CWA) for guests with ISE

[Bastien Migette]

• Introduction
• Setup Used
• WLC Configuration
• ISE Configuration
• Test

Introduction

There are multiple ways of doing Web Authentication on the WLC. The first one is Local Web Authentication. In this case, the WLC will redirect the HTTP Traffic to an internal or external server where the user will be prompted to authenticate. The WLC will then fetch this credentials (sent back via HTTP GET Request in case of external server), and make a radius authentication. In case of guest user, we need an external server (like ISE or NGS), as the portal can provide some feature like Device Registering, Self Provisionning, ...

The flow would be the following:

-User associate to the Web Auth SSID

-User starts its browser

-The WLC Redirect to the guest portal (ISE/NGS)

-The user authenticate on the portal

-The Guest Portal redirect back to the WLC with the credentials entered

-The WLC Authenticate the guest user via Radius

-The WLC Redirects back to the original URL.

That makes a lot of redirection. The new approach is to use Central Web Authentication. This works with ISE  > 1.1 and WLC > 7.2.

The flow in this case would be:

-User associate to the Web Auth SSID

-User starts its browser

-The WLC Redirect to the guest portal (ISE)

-The user authenticate on the portal

-The ISE send a Radius Change Of Authorization (CoA - UDP Port 3799) to indicate to the controller that the user is valid, and eventually push radius attributes (ACL for example).

-The User is prompted to retry his original URL

Setup Used

The version used are:

ISE: 1.1.1.268

WLC: 7.2.110.0

WLC Configuration

The WLC Configuration is pretty straight-forward. We uses a "trick" (same as on Switches) to get the dynamic authentication URL from the ISE (as it is using CoA, a session needs to be created, and the session ID is part of the URL). We need to configure the SSID to use MAC Filtering. We will configure the ISE to return an access-accept even if the mac address is not found, so that it will sends the redirection URL for all users.

In addition to this, we need to enable Radius NAC and AAA Override. The Radius NAC allows the ISE to send a CoA Request to indicate that the user is now authenticated and can access the network. It is also used for Posture Assessment, in which case the ISE would change the user profile based on posture result.

We need also to be sure that the radius server have RFC 3576 (CoA) enabled, which is by default.

The final step is to create a Redirect-ACL. This ACL will be referenced in the access-accept of the ISE and will define what traffic should be redirected (denied by ACL), and what traffic shouldn't (permitted by the ACL). Basically, we need to permit DNS and traffic to/from ISE.

Everthing is now complete on the WLC. Let's configure the ISE

ISE Configuration

On the ISE, we need to make authorization profile, and then we can configure authentication and authorization. The WLC should already configured as a network device.

In the authorization profile, we need to put the name of the ACL has been created earlier on the WLC:

Now, we need to make sure the ISE is accepting all the MAC Authentication from the WLC and return the profile:

We can use the Built-In Wireless MAB condition, which match :

-Radius:Service-Type : Call Check (Mac Authorization use Call Check on WLC and Switches).

-Radius:NAS-Port-Type: Wireless - IEEE 802.11

Now, we need to configure the authorization. One important thing to understand is that there will be 2 authentication / authorization:

-One when the user associate to the SSID, and when we need to return the cwa profile

-Another when the user authenticate on the web portal. This one will match the default rule (internal users), in my situation (you can configure it as you want). What is important is that the authorization part doesn't match the CWA Profile again, otherwise we would have a redirection loop. We can use the attribute "Network Access:UseCase Equals Guest Flow" to match this second authentication.

The result looks like this:

Test

Once we associate to the SSID, we can see the auth in the ISE page:

And if we check the client details in the WLC, we can see the Redirection URL and ACL are applied:

Now, when we open any address on the client, we are redirected to our ISE (be careful to have DNS setup correctly).

Then the user needs to accept the policies, and then it will be granted access to the network.

If we look back at my ISE, we can now see the authentication, the change of authorization, and that the profile applied is permitAccess:

On the controller, the Policy Manager State and Radius NAC State should change from "POSTURE_REQD" to "RUN"

[Bastien Migette]

Hello Moises,

Starting ISE 1.2, you have the ability to select "Static ip/hostname" in the authorization profile, under the WebAuth part. That way you can put ISE's Policy Node IP address if you don't have correct DNS Entry.

[ajc]

Hi Bastien, 

We are moving from LWA to CWA so I was wondering what you mean by USECASE:GUESTFLOW. I am assuming that GUESTFLOW has something to do with having the Authorization Profile --- > CWA redirect pointing to DEFAULT. So what happens if I the redirect points to a MANUAL Login Page that I loaded into the ISE instead of Default? Is the USECASE:VALUE still the same as before?

BTW, from the basic CWA configuration example from Cisco link next, that additional AUTHZ Policy with the USECASE:GUESTFLOW is required in order to avoid loops in the AUTHZ part (double authorization is performed).

Thanks for any orientation regarding this question.

[Bastien Migette]

Hello Abraham,

In CWA, there is 2 authentication sharing the same session. The first one redirects to the portal via MAB, the second one is the actual authentication on the guest portal.

When authenticating on guest portal, ISE sets the flag GuestFlow so we can identify it and apply the correct authorization policy.

I hope this is clear.

[ajc]

Hi Bastien,

Thanks a lot for your note. Now I understand what means GUESTFLOW and how this Flag is used in the cisco example of the following link in order to avoid the Authorization LOOP mentioned as well on this link.

http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/115732-central-web-auth-00.html

I will give a try in the lab and let you know but I was wondering if the FLAG is set with the same value = GuestFlow when I use a customized login page (Manual option selected in the redirect part of the CWA configuration for the AuthZ profile - see attached image)

On the other hand, I have been doing research for a while and I could not find a link or document that explain in details the meaning for all the NETWORKACCESS: USECASE equals to:

-Eap chaining
-Guest Flow
-Host Lookup
-Proxy

Please let me know if you have any link so I can take a look on  it.

[Bastien Migette]

Hello Abraham,

Yes, all CWA auth will have the guest flow flag, whether you use a custom portal or not.
For host-lookup, this identifies MAB request (it basically checks service-type=6)
For EAP Chaining, this is when you have eap-chaining: http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-security/howto_80_eapchaining_deployment.pdf

Proxy I am not sure, I never had to use it. 
I am not aware of any document that summarize all use-case, this is rather integrated on specific configuration example such as the one you pointed.

[ajc]

Hi Bastien,

CWA works straightforward based on the Cisco configuration example. The only thing that I found weird is that when I am using Chrome on my Win7 laptop or a Chromebook device and connect to the SSID configured for CWA, 2 browsers are opened simultaneously. Do you have any idea about this?. Maybe this is something to do with the settings on the Chrome Browser but I was wondering if you have seen this before.

Thanks

Abraham

[Bastien Migette]

Hello Abraham,

Glad you made this work. Concerning the issue with 2 browser being opened, I don't recall having seen anything similar, sorry.

[CB90021204]

Hi Bastien,

I'm implementing the same scenario as Dominic above using a foreign/anchor controller.

Do you know what firewall ports are required to allow communication between the wireless controller and ISE?

Do the ports below look correct?

 UDP:1645, 1812 (RADIUS Authentication)

UDP:1646, 1813 (RADIUS Accounting)

UDP: 1700 (RADIUS change of authorization Send)

UDP: 1700, 3799 (RADIUS change of authorization Listen/Relay)

http://www.cisco.com/c/en/us/td/docs/security/ise/1-2/installation_guide/ise_ig/ise_app_c-ports.html

[Bastien Migette]

Hello,

That should be enough, but keep in mind Radius packets (MAB Requests) and CoA will be handled at Foreign WLC.

Accounting will go out from where it is configured, but it is recommended to enable it only at foreign as it can cause issue otherwise.

Lastly, Client traffic to ISE will use port 8443 or 8905/6/9 if you have Posture, and will go out of anchor.

I hope this helps.

[CB90021204]

Thank you Bastien, yes thats very helpful.

[acontes]

Any hints how to configure this with a second ISE as backup? How does the redirect acl look like?

[1s.bancha]

Do you know if WLC CWA with ISE supports to intercept https traffic and redirect to guest portal?

If not, any roadmap?

Thank you,

Bancha

[gohussai]

That link is really useful

http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/115732-central-web-auth-00.html

[ajc]

Hi Bastien,

I am currently testing 1.4 patch3 - latest version on ISE because I am planning to use PEAP + AUP on HotSpot Option. However, my question on this case is the following:

Based on the link, we have a note that says the next:

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

Note: The CoA Admin-Reset is specific for Hotspot functionality and described in Cisco bug ID CSCus46754. The behavior for ISE Version 1.2 with a guest portal was different; a CoA Re-authenticate or Terminate was sent.

So my question is:

On CWA, are we using CoA Re-authenticate, right?. On what cases are we using Terminate?

thanks

[Bastien Migette]

Hello Abraham, In most of the case you will have reauth action, because the purpose  is to refresh the profile after some events, being profiling, auth, ...

The hotspot feature in 1.3 is a bit different and do not require authentication. In this scenario, the flow will be different, and the bug you mentioned is a documentation bug, meaning the product works as expected but this is not properly documented.

For regular Guest CWA portals, there should not be a difference.