Configure Central Web Authentication (CWA) on Catalyst 9800 WLC and ISE

Introduction

This document describes how to configure a CWA Wireless LAN on a Catalyst 9800 WLC and ISE.

Prerequisites

Requirements

Cisco recommends that you have knowledge of 9800 Wireless LAN Controllers (WLC) configuration.

Components Used

The information in this document is based on these software and hardware versions:

• 9800 WLC Cisco IOS® XE Gibraltar v17.6.x
• Identity Service Engine (ISE) v3.0

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

The CWA process is shown here where you can see the CWA process of an Apple device as an example:

Configure

Network Diagram

AAA Configuration on 9800 WLC

Step 1. Add the ISE server to the 9800 WLC configuration.

Navigate to  Configuration > Security > AAA > Servers/Groups > RADIUS > Servers > + Add  and enter the RADIUS server information as shown in the images.

Ensure Support for CoA is enabled if you plan to use Central Web Authentication (or any kind of security that requires CoA) in the future.

Step 2. Create an authorization method list.

Navigate to  Configuration > Security > AAA >  AAA Method List > Authorization > + Add  as shown in the image.

Step 3. (Optional) Create an accounting method list as shown in the image.

Note: CWA does not work if you decide to load-balance (from the Cisco IOS XE CLI configuration) your radius servers due to Cisco bug ID CSCvh03827. The usage of external load balancers is fine.

Step 4. (Optional) You can define the AAA policy to send the SSID name as a Called-station-id attribute, which can be useful if you want to leverage this condition on ISE later in the process.

Navigate to  Configuration > Security > Wireless AAA Policy and either edit the default AAA policy or create a new one.

You can choose  SSID as Option 1. Be mindful that even when you choose SSID only, the called station id does still append the AP MAC address to the SSID name.

WLAN Configuration

Step 1. Create the WLAN.

Navigate to  Configuration > Tags & Profiles > WLANs > + Add  and configure the network as needed.

Step 2. Enter the WLAN general information.

Step 3. Navigate to the  Security  tab and choose the needed security method. In this case, only 'MAC Filtering' and the AAA authorization list (that you created in Step 2. in the  AAA Configuration  section) are needed.

CLI:

#config t
(config)#wlan cwa-ssid 4 cwa-ssid
(config-wlan)#mac-filtering CWAauthz
(config-wlan)#no security ft adaptive
(config-wlan)#no security wpa
(config-wlan)#no security wpa wpa2
(config-wlan)#no security wpa wpa2 ciphers aes
(config-wlan)#no security wpa akm dot1x
(config-wlan)#no shutdown

Policy Profile Configuration

Inside a Policy Profile, you can decide to assign the clients to which VLAN, among other settings (like Access Controls List (ACLs), Quality of Service (QoS), Mobility Anchor, Timers, and so on).

You can either use your default policy profile or you can create a new one.

GUI:

Step 1. Create a new  Policy Profile.

Navigate to  Configuration > Tags & Profiles > Policy  and either configure your  default-policy-profile  or create a new one.

Ensure the profile is enabled.

Step 2. Choose the VLAN.

Navigate to the  Access Policies  tab and choose the VLAN name from the drop-down or manually type the VLAN-ID. Do not configure an ACL in the policy profile.

Step 3. Configure the policy profile to accept ISE overrides (allow AAA override) and Change of Authorization (CoA) (NAC State). You can optionally specify an accounting method too.

CLI:

# config
# wireless profile policy <policy-profile-name>
# aaa-override
# nac
# vlan <vlan-id_or_vlan-name>
# accounting-list <acct-list>
# no shutdown

Policy Tag Configuration

Inside the Policy Tag is where you link your SSID with your Policy Profile. You can either create a new Policy Tag or use the default-policy tag.

Note: The default-policy tag automatically maps any SSID with a WLAN ID between 1 to 16 to the default-policy profile. It can not be modified or deleted. If you have a WLAN with ID 17 or later the default-policy tag can not be used.

GUI:

Navigate to  Configuration > Tags & Profiles > Tags > Policy  and add a new one if needed as shown in the image.

Link your WLAN Profile to the desired Policy Profile.

CLI:

# config t
# wireless tag policy <policy-tag-name>
# wlan <profile-name> policy <policy-profile-name>

Policy Tag Assignment

Assign the Policy Tag to the needed APs.

GUI:

In order to assign the tag to one AP, navigate to  Configuration > Wireless > Access Points > AP Name > General Tags, make the needed assignment, and then click  Update & Apply to Device.

Note: Be aware that after you change the policy tag on an AP, it loses its association with the 9800 WLC and joins back within about 1 minute.

In order to assign the same Policy Tag to several APs, navigate to  Configuration > Wireless > Wireless Setup > Advanced > Start Now.

Choose the APs to which you want to assign the tag and click  + Tag APs  as shown in the image.

Choose the whished Tag and click  Save & Apply to Device as shown in the image.

CLI:

# config t
# ap <ethernet-mac-addr>
# policy-tag <policy-tag-name>
# end

Redirect ACL Configuration

Step 1. Navigate to  Configuration > Security > ACL > + Add  in order to create a new ACL. 

Choose a name for the ACL, and make it  IPv4 Extended  type and add every rule as a sequence as shown in the image.

You need to deny traffic to your ISE PSNs nodes as well as deny DNS and permit all the rest. This redirect ACL is not a security ACL but a punt ACL that defines what traffic goes to the CPU (on permits) for further treatment (like redirection) and what traffic stays on the data plane (on deny) and avoids redirection.

The ACL must look like this (replace 10.48.39.28 with your ISE IP address in this example):

Note: For the redirection ACL, think of the  deny action as a deny redirection (not deny traffic) and the  permit action as permit redirection. The WLC only looks into traffic that it can redirect (ports 80 and 443 by default).

CLI:

ip access-list extended REDIRECT
 deny ip any host <ISE-IP>
 deny ip host<ISE-IP> any
 deny udp any any eq domain
 deny udp any eq domain any
 permit tcp any any eq 80

Note: If you end the ACL with a  permit ip any any instead of a permit focused on port 80, the WLC also redirects HTTPS, which is often undesirable as it has to provide its own certificate and always creates a certificate violation. This is the exception to the previous statement that says you do not need a certificate on the WLC in case of CWA: you need one if you have HTTPS interception enabled but it is never considered valid anyway.

You can improve the ACL by action to deny only the guest port 8443 to the ISE server.

Enable Redirection for HTTP or HTTPS

The web admin portal configuration is tied with the web authentication portal configuration and it needs to listen on port 80 in order to redirect. Therefore, HTTP has to be enabled for the redirection to work properly. You can either choose to enable it globally (with the use of the command  ip http server) or you can enable HTTP for the web authentication module only (with the use of the command  webauth-http-enable under the parameter map).

If you want to be redirected when you try to access an HTTPS URL, then add the command  intercept-https-enable under the parameter map but note this is not an optimal configuration, that it has an impact on the WLC CPU and generates certificate errors anyway:

parameter-map type webauth global
 type webauth
 intercept-https-enable
 trustpoint xxxxx

You can also do it via the GUI with the option 'Web Auth intercept HTTPS' checked in the Parameter Map (Configuration > Security > Web Auth).
  

ISE Configuration

Add 9800 WLC to ISE

Step 1. Open the ISE console and navigate toAdministration > Network Resources > Network Devices > Add as shown in the image.

Step 2. Configure the network device.

Optionally, it can be a specified Model name, software version, and description, and assign Network Device groups based on device types, location, or WLCs.

The IP address here corresponds to the WLC interface that sends the authentication requests. By default it is the management interface as shown in the image:

For more information about Network Device Groups, review the ISE admin guide Chapter: Manage Network Devices: ISE - Network Device Groups.

Create New User on ISE

Step 1. Navigate to  Administration > Identity Management > Identities > Users > Add  as shown in the image.

Step 2. Enter the information.

In this example, this user belongs to a group called  ALL_ACCOUNTS but it can be adjusted as needed, as shown in the image.

Create Authorization Profile

The policy profile is the result assigned to a client based on its parameters (such as mac address, credentials, WLAN used, and so on). It can assign specific settings like Virtual Local Area Network (VLAN), Access Control Lists (ACLs), Uniform Resource Locator (URL) redirects, and so on.

Note that in recent versions of ISE, a Cisco_Webauth authorization result already exists. Here, you can edit it to modify the redirection ACL name in order to match what you configured on the WLC.

Step 1. Navigate to  Policy > Policy Elements > Results > Authorization > Authorization Profiles. Click  add in order to create your own or edit the  Cisco_Webauth default result.

Step 2. Enter the redirection information. Ensure that the ACL name is the same as that was configured on the 9800 WLC.

Configure Authentication Rule

Step 1. A Policy Set defines a collection of Authentication and Authorization rules. To create one, navigate toPolicy > Policy Sets, click on the gear of the first Policy Set in the list and chooseInsert new row or click the blue arrow on the right to choose the defaut Policy Set.


Step 2. Expand  Authentication policy. For the  MAB rule (match on wired or wireless MAB), expand  Options, and choose the  CONTINUE option in case you see 'If User not found'.

Step 3. Click  Save  in order to save the changes.

Configure Authorization Rules

The authorization rule is the one in charge to determine which permissions (which authorization profile) result is applied to the client.

Step 1. On the same Policy set page, close down the  Authentication Policy and expand  Authorziation Policy  as shown in the image.

Step 2. Recent ISE versions start with a pre-created rule called  Wifi_Redirect_to_Guest_Login which matches mostly our needs. Turn the grey sign on the left to  enable.

Step 3. That rule matches Wireless_MAB only and returns the CWA redirection attributes. Now, you can optionally add a little twist and make it match only the specific SSID. Choose the condition (Wireless_MAB as of now) to make the Conditions Studio appear. Add a condition on the right and choose the  Radius dictionary with the  Called-Station-ID attribute. Make it match your SSID name. Validate with the Use at the bottom of the screen as shown in the image.

Step 4. You now need a second rule, defined with a higher priority, that matches the  Guest Flow condition in order to return network access details once the user has authenticated on the portal. You can use the  Wifi Guest Access rule which is also pre-created by default on recent ISE versions. You then only have to enable the rule with a green mark on the left.  You can return the default PermitAccess or configure more precise access list restrictions.

Step 5. Save the rules.

Click  Save  at the bottom of the rules.

Flexconnect Local Switching Access Points Only

What if you have Flexconnect local switching access points and WLANs? The previous sections are still valid. However, you need an extra step in order to push the redirect ACL to the APs in advance.

Navigate to  Configuration > Tags & Profiles > Flex and choose your Flex profile. Then, navigate to the  Policy ACL tab.

Click  Add  as shown in the image.

Choose your redirect ACL name and enable Central web authentication. This checkbox automatically inverts the ACL on the AP itself (this is because a 'deny' statement means 'do not redirect to this IP' on the WLC in Cisco IOS XE. However, on the AP the 'deny' statement means the opposite. So, this checkbox automatically swaps all permits and denies them when it does the push to the AP. You can verify this with a  show ip access list from the AP CLI).

Note:  In Flexconnect local switching scenario, the ACL must specifically mention return statements (which is not necessarily required in local mode), so ensure that all your ACL rules cover both ways of traffic (to and from the ISE for example).

Do not forget to hit  Save and then  Update and apply to the device.

Certificates

In order to have the client trust the web authentication certificate, it is not required to install any certificate on the WLC as the only certificate presented is the ISE certificate (which has to be trusted by the client).

Verify

You can use these commands to verify the current configuration.

# show run wlan
# show run aaa
# show aaa servers
# show ap config general
# show ap name <ap-name> config general 
# show ap tag summary
# show ap name <AP-name> tag detail
# show wlan { summary | id | nme | all }
# show wireless tag policy detailed <policy-tag-name>
# show wireless profile policy detailed <policy-profile-name> 

Here is the relevant part of the configuration of the WLC that corresponds to this example:

aaa new-model
!
aaa authorization network CWAauthz group radius
aaa accounting identity CWAacct start-stop group radius
!
aaa server radius dynamic-author
 client <ISE-IP> server-key cisco123
!
aaa session-id common
!
!
radius server ISE-server
 address ipv4 <ISE-IP> auth-port 1812 acct-port 1813
 key cisco123
!
!
wireless aaa policy default-aaa-policy
wireless cts-sxp profile default-sxp-profile

wireless profile policy default-policy-profile
 aaa-override
 nac
 vlan 1416
 no shutdown
wireless tag policy cwa-policy-tag
 wlan cwa-ssid policy default-policy-profile
wlan cwa-ssid 4 cwa-ssid
 mac-filtering CWAauthz
 no security ft adaptive
 no security wpa
 no security wpa wpa2
 no security wpa wpa2 ciphers aes
 no security wpa akm dot1x
 no shutdown

ip http server (or "webauth-http-enable" under the parameter map)
ip http secure-server

Troubleshoot

Checklist

• Ensure the client connects and gets a valid IP address.
• If the redirection is not automatic, open a browser and try a random IP address. For example, 10.0.0.1. If redirection works, it is possible that you have a DNS resolution problem. Verify that you have a valid DNS server provided via DHCP and that it can resolve hostnames. 
• Ensure that you have the command  ip http server configured for redirection on HTTP to work. The web admin portal configuration is tied with the web authentication portal configuration and it needs to be listed on port 80 in order to redirect. You can either choose to enable it globally (with the use of the command  ip http server) or you can enable HTTP for the web authentication module only (with the use of the command  webauth-http-enable under the parameter map).
• If you are not redirected when you try to access an HTTPS URL and that is required, then verify that you have the command  intercept-https-enable under the parameter map:
  
  

parameter-map type webauth global
 type webauth
 intercept-https-enable
 trustpoint xxxxx

You can also check via the GUI that you have the option 'Web Auth intercept HTTPS' checked in the Parameter Map:
  

Service Port Support for RADIUS

The Cisco Catalyst 9800 Series Wireless Controller has a service port that is referred to as  GigabitEthernet 0port. As from version 17.6.1, RADIUS (that includes CoA) is supported through this port.

If you want to use the Service Port for RADIUS, then you need this configuration:

aaa server radius dynamic-author 
client 10.48.39.28 vrf Mgmt-intf server-key cisco123

interface GigabitEthernet0
 vrf forwarding Mgmt-intf
 ip address x.x.x.x x.x.x.x

!if using aaa group server:
aaa group server radius group-name
 server name nicoISE
 ip vrf forwarding Mgmt-intf
 ip radius source-interface GigabitEthernet0

Collect Debugs

WLC 9800 provides ALWAYS-ON tracing capabilities. This ensures all client connectivity-related errors, warnings, and notice-level messages are constantly logged and you can view logs for an incident or failure condition after it has occurred.

Note: You can go back a few hours to several days in the logs but it depends on the volume of logs generated.

In order to view the traces that 9800 WLC collected by default, you can connect via SSH/Telnet to the 9800 WLC and perform these steps (ensure you log the session to a text file).

Step 1. Check the WLC current time so you can track the logs in the time back to when the issue happened.

# show clock

Step 2. Collect syslogs from the WLC buffer or the external syslog as dictated by the system configuration. This provides a quick view into the health of the system and errors if any.

# show logging

Step 3. Verify if any debug conditions are enabled.

# show debugging
Cisco IOS XE Conditional Debug Configs:

Conditional Debug Global State: Stop

Cisco IOS XE Packet Tracing Configs:


Packet Infra debugs:

Ip Address                                               Port
------------------------------------------------------|----------

Note: If you see any condition listed, it means the traces are logged up to debug level for all the processes that encounter the enabled conditions (mac address, IP address, and so on). This increases the volume of logs. Therefore, it is recommended to clear all conditions when you do not actively debug.

Step 4. With the assumption that the mac address under test was not listed as a condition in Step 3., collect the always-on notice level traces for the specific mac address.

# show logging profile wireless filter { mac | ip } { <aaaa.bbbb.cccc> | <a.b.c.d> } to-file always-on-<FILENAME.txt> 

You can either display the content on the session or you can copy the file to an external TFTP server.

# more bootflash:always-on-<FILENAME.txt>
or
# copy bootflash:always-on-<FILENAME.txt> tftp://a.b.c.d/path/always-on-<FILENAME.txt> 

Conditional Debugging and Radio Active Tracing

If the always-on traces do not give you enough information to determine the trigger for the problem under investigation, you can enable conditional debugging and capture Radio Active (RA) trace, which provides debug-level traces for all processes that interact with the specified condition (client mac address in this case). In order to enable conditional debugging, proceed with these steps.

Step 5. Ensure there are no debug conditions enabled.

# clear platform condition all

Step 6. Enable the debug condition for the wireless client mac address that you want to monitor.

These commands start to monitor the provided mac address for 30 minutes (1800 seconds). You can optionally increase this time to up to 2085978494 seconds.

# debug wireless mac <aaaa.bbbb.cccc> {monitor-time <seconds>}

Note: In order to monitor more than one client at a time, run debug wireless mac  <aaaa.bbbb.cccc> command per mac address.

Note: You do not see the output of the client activity on the terminal session, as everything is buffered internally to be viewed later.

Step 7`. Reproduce the issue or behavior that you want to monitor.

Step 8. Stop the debugs if the issue is reproduced before the default or configured monitor time is up.

# no debug wireless mac <aaaa.bbbb.cccc>

Once the monitor time has elapsed or the debug wireless has been stopped, the 9800 WLC generates a local file with the name:

ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log

Step 9.  Collect the file of the mac address activity. You can either copy the  ra trace .log to an external server or display the output directly on the screen.

Check the name of the RA traces file.

# dir bootflash: | inc ra_trace

Copy the file to an external server:

# copy bootflash: ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log  tftp://a.b.c.d/ra-FILENAME.txt

Display the content:

# more bootflash: ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log 

Step 10. If the root cause is still not obvious, collect the internal logs which are a more verbose view of debug-level logs. You do not need to debug the client again as we take only a further detailed look at debug logs that have been already collected and internally stored.

# show logging profile wireless internal filter { mac | ip } { <aaaa.bbbb.cccc> | <a.b.c.d> } to-file ra-internal-<FILENAME>.txt

Note: This command output returns traces for all log levels for all processes and is quite voluminous. Engage Cisco TAC to help parse through these traces.

You can either copy the  ra-internal-FILENAME.txt to an external server or display the output directly on the screen.

Copy the file to an external server:

# copy bootflash:ra-internal-<FILENAME>.txt tftp://a.b.c.d/ra-internal-<FILENAME>.txt

Display the content:

# more bootflash:ra-internal-<FILENAME>.txt

Step 11. Remove the debug conditions.

# clear platform condition all

Note: Ensure that you always remove the debug conditions after a troubleshoot session.

Examples

If the authentication result is not what you expect, it is important to navigate to the ISE  Operations > Live logs page and get the details of the authentication result.

You are presented with the reason for the failure (if there is a failure) and all the Radius attributes received by ISE.

In the next example, ISE rejected authentication because no authorization rule matched. This is because you see the Called-station-ID attribute sent as the SSID name appended to the AP mac address, while the authorization is an exact match to the SSID name. It gets fixed with the change of that rule to 'contains' instead of 'equal'.

After you solve this, the wifi client still can not associate with the SSID while ISE claims the authorization is a success and returned the right CWA attributes.

You can navigate to the  Troubleshooting > Radioactive trace page of the WLC web UI.

in most cases, you can rely on the always-on logs and even get logs from past connection attempts without the reproduction of the problem once more.

Add the client mac address and click  Generate  as shown in the image.

In this case, the problem lies with the fact that you made a typo when you created the ACL name and it does not match the ACL name returned by ISEs or the WLC complains there is no such ACL as the one requested by ISE:

2019/09/04 12:00:06.507 {wncd_x_R0-0}{1}: [client-auth] [24264]: (ERR): MAC: e836.171f.a162  client authz result: FAILURE
2019/09/04 12:00:06.516 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [24264]: (ERR): SANET_AUTHZ_FAILURE - Redirect ACL Failure username E8-36-17-1F-A1-62, audit session id 7847300A0000012EFC24CD42, 
2019/09/04 12:00:06.518 {wncd_x_R0-0}{1}: [errmsg] [24264]: (note): %SESSION_MGR-5-FAIL: Authorization failed or unapplied for client (e836.171f.a162) on Interface capwap_90000005 AuditSessionID 7847300A0000012EFC24CD42. Failure Reason: Redirect ACL Failure. Failed attribute name REDIRECT.