The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes a configuration example that is used in order to complete Central Web Authentication (CWA) on the Wireless LAN Controller (WLC).
It is superseded by the more complete Guest deployment guide available here : https://communities.cisco.com/docs/DOC-77590
There are no specific requirements for this document.
The information in this document is based on these software and hardware versions:
The first method of web authentication is local web authentication. In this case, the WLC redirects the HTTP traffic to an internal or external server where the user is prompted to authenticate. The WLC then fetches the credentials (sent back via an HTTP GET request in the case of an external server) and makes a RADIUS authentication. In the case of a guest user, an external server such as Identity Services Engine (ISE) is required because the portal provides features such as device registering and self-provisioning. The flow includes these steps:
This flow includes several redirections. The new approach is to use CWA. The flow includes these steps:
The setup used is:
The WLC configuration is fairly straightforward. A trick is used (same as on switches) in order to obtain the dynamic authentication URL from the ISE (since it uses Change of Authorization (CoA), a session must be created and the session ID is part of the URL). The SSID is configured in order to use MAC filtering. The ISE is configured in order to return an access-accept even if the MAC address is not found so that it sends the redirection URL for all users.
In addition to this, ISE Network Admission Control (NAC) and Authentication, Authorization, and Accounting (AAA) Override must be enabled. The ISE NAC allows the ISE to send a CoA request that indicates that the user is now authenticated and is able to access the network. It is also used for posture assessment, in which case the ISE changes the user profile based on the posture result.
Ensure that the RADIUS server has Support for CoA enabled, which is by default.
The final step is to create a redirect ACL. This ACL is referenced in the access-accept of the ISE and defines what traffic should be redirected (denied by the ACL) and what traffic should not be redirected (permitted by the ACL). Here you just prevent from redirection traffic towards the ISE. You might want to be more specific and only prevent traffic to/from the ISE on port 8443 (guest portal), but still redirect if a user tries to access the ISE on port 80/443.
Note: Earlier versions of WLC software such as 7.2 or 7.3 did not require you to specify Domain Name System (DNS), but later code versions require you to permit DNS traffic on that redirect ACL.
The configuration is now complete on the WLC.
On the ISE, the authorization profile must be created. Then, the authentication and authorization policies are configured. The WLC should already be configured as a network device.
In the authorization profile, enter the name of the ACL created earlier on the WLC.
Ensure that the ISE accepts all of the MAC authentications from the WLC and make sure it will pursue authentication even if the user is not found.
Under the Policy > Policy Sets > Default Polcy Set, click Authentication.
The next image shows an example of how to configure the authentication policy rule. In this example, a rule is configured that triggers when MAB is detected.
Note: MAB authentication rule is already created on the ISE by default.
Configure the authorization policy. One important point to understand is that there are two authentications/authorizations:
Complete these steps in order to create the authorization rules as shown in the previous images:
Note: It is very important that this new rule comes before the Guest Redirection rule.
Note: In a multi-controller environment the WLAN-ID should be the same across the WLCs. If one does not want to use the Airespace-Wlan-Id attribute as a condition, then it is better to match Wireless_MAB (Built-in condition) requests.
If you assign a VLAN, the final step is for the client PC to renew its IP address. This step is achieved by the guest portal for Windows clients. If you did not set a VLAN for the 2nd AUTH rule earlier, you can skip this step. This is not a recommended design as changing the client VLAN after it already got an IP address will disrupt connectivity, some clients might wrongly react to it and it requires elevated Windows privileges to work fine.
If you assigned a VLAN, complete these steps in order to enable IP renewal:
Note: VLAN DHCP Release support is available for Windows devices only. It is not available for mobile devices. If the device being registered is mobile and the VLAN DHCP Release option is enabled, the guest is requested to manually renew their IP address. For mobile device users, we recommend using Access Control Lists(ACLs) on the WLC, rather than using VLANs.
This setup can also work with the auto-anchor feature of the WLCs. The only catch is that since this web authentication method is Layer 2, you have to be aware that it will be the foreign WLC that does all of the RADIUS work. Only the foreign WLC contacts the ISE, and the redirection ACL must be present also on the foreign WLC. The foreign just needs to have the ACL name exist (Does not need ACL entries). The foreign WLC will send the ACL name to the anchor and it will be the anchor applying the redirection (and therefore needs the right ALC content).
Just like in other scenarios, the foreign WLC quickly shows the client to be in the RUN state, which is not entirely true. It simply means that traffic is sent to the anchor from there. The real client state can be seen on the anchor where it should display CENTRAL_WEBAUTH_REQD.
Here is the flow in an anchor-foreign setup:
The firewall ports which are required to allow communication between the WLC and ISE are:
Note: The anchor-foreign setup with Central Web Authentication (CWA) only works in Releases 7.3 or later.
Note: Due to Cisco bug ID CSCul83594, you cannot run accounting on both anchor and foreign because it causes the profiling to become inaccurate due to a potential lack of IP-to-MAC binding. It also creates many issues with the session ID for guest portals. If you desire to configure accounting, then configure it on the foreign controller. Note that this should not be the case anymore starting 8.6 WLC software where the session id will be shared between the anchor and foreign controllers and accounting will then be possible to enable on both.
Use this section in order to confirm that your configuration works properly.
The client details in the WLC show that the redirection URL and ACL are applied.
In the WLC client and AAA all debug, you can see access accept with the redirect URL and ACL sent from the ISE.
*radiusTransportThread: d0:37:45:89:ef:64 Access-Accept received from RADIUS server 10.106.32.25 (qid:4) with port:1812, pktId:24 for mobile d0:37:45:89:ef:64 receiveId = 0
*radiusTransportThread: AuthorizationResponse: 0x166ab570
*radiusTransportThread: structureSize................................425
*radiusTransportThread: resultCode...................................0
*radiusTransportThread: protocolUsed.................................0x00000001
*radiusTransportThread: proxyState...................................D0:37:45:89:EF:64-00:00
*radiusTransportThread: Packet contains 4 AVPs:
*radiusTransportThread: AVP[01] User-Name................................D0-37-45-89-EF-64 (17 bytes)
*radiusTransportThread: AVP[02] Class....................................CACS:0a6a207a0000000a5fe8f217:ISE3-1/397801666/90 (49 bytes)
*radiusTransportThread: AVP[03] Cisco / Url-Redirect-Acl.................CWA_Redirect (12 bytes)
*radiusTransportThread: AVP[04] Cisco / Url-Redirect.....................DATA (175 bytes)
*radiusTransportThread: d0:37:45:89:ef:64 processing avps[0]: attribute 1
*radiusTransportThread: d0:37:45:89:ef:64 username = D0-37-45-89-EF-64
!
*apfReceiveTask: d0:37:45:89:ef:64 Redirect URL received for client from RADIUS. Client will be moved to WebAuth_Reqd state to facilitate redirection. Skip web-auth Flag = 0
The same thing can also be verified in the ISE. Navigate to Operations > Radius livelogs. Click the detail for that MAC.
You can see that for the first authentication (MAC filtering) ISE returns the AuthZ profile WLC_CWA as it hits the authentication rule MAB and authz policy Guest Redirection.
When the credentials are entered, ISE authenticates the client and sends the CoA.
On the WLC this can be seen in AAA all debugs.
*radiusCoASupportTransportThread: audit session ID recieved in CoA = 0a6a207a0000000b5fe90410
*radiusCoASupportTransportThread: Received a 'CoA-Request' from 10.106.32.25 port 23974
*radiusCoASupportTransportThread: CoA - Received IP Address : 10.106.32.122, Vlan ID: (received 0)
*radiusCoASupportTransportThread: d0:37:45:89:ef:64 Calling-Station-Id ---> d0:37:45:89:ef:64
*radiusCoASupportTransportThread: Handling a valid 'CoA-Request' regarding station d0:37:45:89:ef:64
*radiusCoASupportTransportThread: Sending Radius CoA Response packet on srcPort: 1700, dpPort: 2, tx Port: 23974
*radiusCoASupportTransportThread: Sent a 'CoA-Ack' to 10.106.32.25 (port:23974)
After this the client is reauthenticated and granted access to the network.
Note: In Release 7.2 or earlier, the state CENTRAL_WEB_AUTH was called POSTURE_REQD.
Note that the type of CoA returned by ISE evolved across versions. ISE 3.0 will request the WLC to start re-authentication using the last method i.e. MAB in this case. The WLC re-authenticates the user when it sends the RADIUS Access-Request with the Authorize-Only attribute.
Example of ISE 3.0 CoA request :
The WLC will then not send a disassociation frame to the client and will run a radius authentication again and apply the new result transparently to the client. Since 8.3, the WLC supports setting a WPA pre-shared key on a CWA SSID. The user experience remains the same as in classical non-PSK scenarios, the WLC will not send a disassociate frame to the client and will simply apply the new authorization result. However an "association response" is still sent to the client although no "association request" was ever received from the client, which might seem curious when analyzing sniffer traces.
Complete these steps in order to troubleshoot or isolate a CWA problem:
Consider these Cisco bug IDs that limit the efficiency of the CWA process in a mobility scenario (especially when accounting is configured):