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"

[Tarik Admani]

Bastien,

I have configured ISE many times and was curious as to how you were able to validate the following statement:

"The WLC Redirects back to the original URL."

My experiences when using CWA that you always get redirected to the page that shows the exit button and to retry the orignal url request.

Thanks,

Tarik Admani

[Bastien Migette]

Hello Tarik, You are right, with CWA, the ISE shows a message indicating the user he can retry his original URL. This is a current limitation, as the ISE doesn't know the original URL.

What you can do is to create a custom portal with HTML Files and modify the success page to redirect to an arbitrary web page.

[Peter Nugent]

Just getting started with ISE.

This looks ok but could use a little more detail if I could ask around creating the Authorization policy Guest redirect.

However its only valid for code 7.2. It seems a lot more complicated in 7.0.

Any chance you could do this for 802.1x PEAP? Also with code 7.0. as I am really struggling getting my gead around the interface and policy creations.

[Bastien Migette]

Hello Peter,

Welcome to the ISE world... It can be hard to do what we want at first glance due to numerous features, but after some time you'll get used to it.

Concerning the guest redirect, here's basically how it works:

-The Guest user associate to the WLC

-The WLC send a MAB Request to ISE

-the ISE match the first authorization rules, and send the redirect parameters (acl and URL)

-The WLC will redirect the GUEST to the ISE

-Once the guest is authenticated, the ISE will make a second authorization (that we call Radius Change of Authorization - CoA, which require 7.2 Code). In this second authorization, we need to return a profile so the guest is permitted access to the network. We can use usecase: guestflow to easily match this second authorization.

For PEAP, you may have a look at this doc, there's an example of 802.1x:

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bba10d.shtml

I hope this is clear.

[Peter Nugent]

It is becoming clear! Just the ability to run 7.2 is an issue for me at the present time. Also there are alot of features as you say.

[Bastien Migette]

Good,

You can still use Local Web Auth (LWA) with WLC 7.0. There's an example in the BYOD Guide (link above) as well.

[edondurguti]

I have a default deny rule in the authorization and if users come in first time they are always denied, they have to re-connect manually and once that's done they are okay forever.

CoA is globally enabled for ReAuth.

I've tried many things but never got it working and kinda found a workaround with isolated vlan with ip helpers :s

[Bastien Migette]

Hello Edondurguti,

It's hard to give you an answer without knowing the details of your setup. Maybe you should try to open a separate post on this forum, or open a TAC Case if you have a support contract.

Regards,
Bastien

[Dominic Stalder (old profile)]

Hi Bastien

thanks a lot for this great post!

I have a question about CWA design in association with an anchor / foreigner installation. We would like to use CWA in this scenario:

- The ISE is located in the internal server subnet

- The foreign WLC is located in the same server subnet

- The anchor WLC ist located in the DMZ subnet

Between the server subnet and the DMZ, the traffic is blocked (except for guest mobility and so on --> no ISE traffic allowed).

No our problem:

1. The client connects to the guest SSID and does need to do a MAB (Layer 2), this works fine because the foreign WLC has connection to the ISE

2. The client gets an IP address via DHCP from the anchor WLC (Layer 3), so the client is now located in a quarantine VLAN behind the firewall and does not have any connection to the ISE, BUT the client should be redirected to the guest portal of the ISE

Now my question, is CWA the right way or should we better use LWA for anchor / foreign scenarios. And if CWA is good, what is a good design to implement it in these scenarios?

Thanks a lot in advance and best regards

Dominic

[Bastien Migette]

Hello Dominic,

When you have anchor/foreign, the web auth traffic always go to the anchor, so with CWA, the traffic from the anchor to the ISE will need to be permitted.

Now, both LWA and CWA works fine, but CWA is the new way to do things, and I personnally think it's a bit more cleaner, regarding the process flow than LWA...

If this is not an option to open connectivity to the ISE from behind the firewall, then I guess you will have to go for LWA.

Regards,

Bastien

[Dominic Stalder (old profile)]

Hi Bastien

thanks a lot for your feedback, I think it would be nice to have CWA, but if the communication should not be possible, then LWA is the way to go.

Thanks and best regards

Dominic

[Dominic Stalder (old profile)]

Hi Bastien

one more question about the design above. You use the "Mac Filtering" to have a redirect to the guest portal of the ISE, this makes it necessary, that Layer 2 authentication traffic flows from the foreign controller to the ISE. In the "Cisco Bring Your Own Device (BYOD) Smart Solution Design Guide" I can see, that this is solved via the "External Web Auth URL" under Security > Web Auth > Web Login Page:

So we don't have any traffic from the foreign controller to the ISE. Is that correct?

Best regards

Dominic

[Bastien Migette]

Hello Dominic,

When you have Anchor/Foreign, basically all L2 Authentication is made on the foreign, but all L3 Traffic (including webauth) is going through the anchor, so whether you use CWA or External Server, the traffic will need to be allowed from anchor to ISE. If you don't want this, then you can use Local Web Auth, and use the ISE as radius server, but still the foreign will need to be allowed to contact the ISE via Radius.

Hope this is clear.

[Dominic Stalder (old profile)]

Hi Bastien

thanks, that's clear and that is what I want: ONLY allow traffic from the anchor to the ISE, but NOT from the foreign as it would go with L2 MAC authentication bypass.

Short summary:

- CWA with MAB as you mentioned above --> L2 from foreign AND L3 from anchor

- CWA with external server -> ONLY L3 from anchor

Best regards and have a nice weekend

Dominic

[guillerm]

Hello,

I have set up a Guest Portal with WLC 5508 7.4 and ISE 1.1.1 ;

everything is OK, except one thing :

the Guest VLAN, associated to the Guest SSID is, actually, a DMZ behind my customer firewall and the DHCP parameters provided to the wireless Guest equipement connected on this VLAN include the public ISP DNS servers addresses, not the customer internal DNS serveurs addresses;

this seems OK since the idea of this Guest SSID is to give a pure Internet access to the Guests, and no connection at all towards the customer internal servers;

the problem is that, when the wireless guest receives the redictect URL from ISE (URL to access the ISE Guest Portal), this URL is based on the ISE DNS name, not on its IP address; so, the PC can't resolve this internal DNS name by using the ISP DNS servers addresses provided by the DHCP server, and, so, it can't access the Guest Portal at all ;

Apart from changing those DNS values in the DHCP server (the customer does not accept this solution), how could we solve this problem ?

I have tried to code, in the CWA Authorization profile, the equivalent URL redirect via the CISCO av-pair as follows :

cisco-av-pair=url-redirect=https://192.168.1.10:8443/guestportal/gateway?sessionId=sessionIdValue&action=cwa,

but, it does not work, since the sessionIdValue is not replaced by its real value when sent to the wireless client

any comment welcomed