Table Of Contents
Configuring Security Solutions
Cisco UWN Solution Security
Security Overview
Layer 1 Solutions
Layer 2 Solutions
Layer 3 Solutions
Rogue Access Point Solutions
Rogue Access Point Challenges
Tagging and Containing Rogue Access Points
Integrated Security Solutions
Configuring TACACS+
Configuring TACACS+ on the ACS
Using the GUI to Configure TACACS+
Using the CLI to Configure TACACS+
Viewing the TACACS+ Administration Server Logs
Configuring Local Network Users
Using the GUI to Configure Local Network Users
Using the CLI to Configure Local Network Users
Configuring LDAP
Using the GUI to Configure LDAP
Using the CLI to Configure LDAP
Configuring Local EAP
Using the GUI to Configure Local EAP
Using the CLI to Configure Local EAP
Configuring the System for SpectraLink NetLink Telephones
Using the GUI to Enable Long Preambles
Using the CLI to Enable Long Preambles
Using the CLI to Configure Enhanced Distributed Channel Access
Using Management over Wireless
Using the GUI to Enable Management over Wireless
Using the CLI to Enable Management over Wireless
Configuring DHCP Option 82
Validating SSIDs
Configuring and Applying Access Control Lists
Using the GUI to Configure Access Control Lists
Using the GUI to Apply Access Control Lists
Applying an Access Control List to an Interface
Applying an Access Control List to the Controller CPU
Applying an Access Control List to a WLAN
Applying a Preauthentication Access Control List to a WLAN
Using the CLI to Configure Access Control Lists
Using the CLI to Apply Access Control Lists
Configuring Management Frame Protection
Guidelines for Using MFP
Using the GUI to Configure MFP
Using the GUI to View MFP Settings
Using the CLI to Configure MFP
Using the CLI to View MFP Settings
Using the CLI to Debug MFP Issues
Configuring Client Exclusion Policies
Configuring Identity Networking
Identity Networking Overview
RADIUS Attributes Used in Identity Networking
QoS-Level
ACL-Name
Interface-Name
VLAN-Tag
Tunnel Attributes
Configuring AAA Override
Updating the RADIUS Server Dictionary File for Proper QoS Values
Using the GUI to Configure AAA Override
Using the CLI to Configure AAA Override
Configuring IDS
Configuring IDS Sensors
Using the GUI to Configure IDS Sensors
Using the CLI to Configure IDS Sensors
Viewing Shunned Clients
Configuring IDS Signatures
Using the GUI to Configure IDS Signatures
Using the CLI to Configure IDS Signatures
Using the CLI to View IDS Signature Events
Configuring AES Key Wrap
Using the GUI to Configure AES Key Wrap
Using the CLI to Configure AES Key Wrap
Configuring Maximum Local Database Entries
Using the GUI to Configure Maximum Local Database Entries
Using the CLI to Specify the Maximum Number of Local Database Entries
Configuring Security Solutions
This chapter describes security solutions for wireless LANs. It contains these sections:
•
Cisco UWN Solution Security
•Configuring TACACS+
•Configuring Local Network Users
•Configuring LDAP
•Configuring Local EAP
•Configuring the System for SpectraLink NetLink Telephones
•Using Management over Wireless
•Configuring DHCP Option 82
•Validating SSIDs
•Configuring and Applying Access Control Lists
•Configuring Management Frame Protection
•Configuring Client Exclusion Policies
•Configuring Identity Networking
•Configuring IDS
•Configuring AES Key Wrap
•Configuring Maximum Local Database Entries
Cisco UWN Solution Security
Cisco UWN Solution security includes the following sections:
•Security Overview
•Layer 1 Solutions
•Layer 2 Solutions
•Layer 3 Solutions
•Rogue Access Point Solutions
•Integrated Security Solutions
Security Overview
The Cisco UWN security solution bundles potentially complicated Layer 1, Layer 2, and Layer 3 802.11 Access Point security components into a simple policy manager that customizes system-wide security policies on a per-WLAN basis. The Cisco UWN security solution provides simple, unified, and systematic security management tools.
One of the biggest hurdles to WLAN deployment in the enterprise is WEP encryption, which is a weak standalone encryption method. A newer problem is the availability of low-cost access points, which can be connected to the enterprise network and used to mount man-in-the-middle and denial-of-service attacks. Also, the complexity of add-on security solutions has prevented many IT managers from embracing the benefits of the latest advances in WLAN security.
Layer 1 Solutions
The Cisco UWN security solution ensures that all clients gain access within an operator-set number of attempts. Should a client fail to gain access within that limit, it is automatically excluded (blocked from access) until the operator-set timer expires. The operating system can also disable SSID broadcasts on a per-WLAN basis.
Layer 2 Solutions
If a higher level of security and encryption is required, the network administrator can also implement industry-standard security solutions such as Extensible Authentication Protocol (EAP), Wi-Fi protected access (WPA), and WPA2. The Cisco UWN Solution WPA implementation includes AES (advanced encryption standard), TKIP + Michael (temporal key integrity protocol + message integrity code checksum) dynamic keys, or WEP (Wired Equivalent Privacy) static keys. Disabling is also used to automatically block Layer 2 access after an operator-set number of failed authentication attempts.
Regardless of the wireless security solution selected, all Layer 2 wired communications between controllers and lightweight access points are secured by passing data through LWAPP tunnels.
Layer 3 Solutions
The WEP problem can be further solved using industry-standard Layer 3 security solutions such as passthrough VPNs (virtual private networks).
The Cisco UWN Solution supports local and RADIUS MAC (media access control) filtering. This filtering is best suited to smaller client groups with a known list of 802.11 access card MAC addresses.
Finally, the Cisco UWN Solution supports local and RADIUS user/password authentication. This authentication is best suited to small to medium client groups.
Rogue Access Point Solutions
This section describes security solutions for rogue access points.
Rogue Access Point Challenges
Rogue access points can disrupt WLAN operations by hijacking legitimate clients and using plaintext or other denial-of-service or man-in-the-middle attacks. That is, a hacker can use a rogue access point to capture sensitive information, such as passwords and username. The hacker can then transmit a series of clear-to-send (CTS) frames, which mimics an access point informing a particular NIC to transmit and instructing all others to wait, which results in legitimate clients being unable to access the WLAN resources. WLAN service providers thus have a strong interest in banning rogue access points from the air space.
The operating system security solution uses the radio resource management (RRM) function to continuously monitor all nearby access points, automatically discover rogue access points, and locate them as described in the "Tagging and Containing Rogue Access Points" section.
Tagging and Containing Rogue Access Points
When the Cisco UWN Solution is monitored using WCS. WCS generates the flags as rogue access point traps, and displays the known rogue access points by MAC address. The operator can then display a map showing the location of the lightweight access points closest to each rogue access point, allowing Known or Acknowledged rogue access points (no further action), marking them as Alert rogue access points (watch for and notify when active), or marking them as contained rogue access points. Between one and four lightweight access points discourage rogue access point clients by sending the clients deauthenticate and disassociate messages whenever they associate with the rogue access point.
When the Cisco UWN Solution is monitored using a GUI or a CLI, the interface displays the known rogue access points by MAC address. The operator then has the option of marking them as Known or Acknowledged rogue access points (no further action), marking them as Alert rogue access points (watch for and notify when active), or marking them as Contained rogue access points (have between one and four lightweight access points discourage rogue access point clients by sending the clients deauthenticate and disassociate messages whenever they associate with the rogue access point).
Integrated Security Solutions
•Cisco UWN Solution operating system security is built around a robust 802.1X AAA (authorization, authentication and accounting) engine, which allows operators to rapidly configure and enforce a variety of security policies across the Cisco UWN Solution.
•The controllers and lightweight access points are equipped with system-wide authentication and authorization protocols across all ports and interfaces, maximizing system security.
•Operating system security policies are assigned to individual WLANs, and lightweight access points simultaneously broadcast all (up to 16) configured WLANs. This can eliminate the need for additional access points, which can increase interference and degrade system throughput.
•Operating system security uses the RRM function to continually monitor the air space for interference and security breaches, and notify the operator when they are detected.
•Operating system security works with industry-standard authorization, authentication, and accounting (AAA) servers, making system integration simple and easy.
Configuring TACACS+
Terminal Access Controller Access Control System Plus (TACACS+) is a client/server protocol that provides centralized security for users attempting to gain management access to a controller. It serves as a backend database similar to local and RADIUS. However, local and RADIUS provide only authentication support and limited authorization support while TACACS+ provides three services:
•Authentication—The process of verifying users when they attempt to log into the controller.
Users must enter a valid username and password in order for the controller to authenticate users to the TACACS+ server. The authentication and authorization services are tied to one another. For example, if authentication is performed using the local or RADIUS database, then authorization would use the permissions associated with the user in the local or RADIUS database (which are read-only, read-write, and lobby-admin) and not use TACACS+. Similarly, when authentication is performed using TACACS+, authorization is tied to TACACS+.
Note When multiple databases are configured, you can use the controller GUI or CLI to specify the sequence in which the backend databases should be tried.
•Authorization—The process of determining the actions that users are allowed to take on the controller based on their level of access.
For TACACS+, authorization is based on privilege (or role) rather than specific actions. The available roles correspond to the seven menu options on the controller GUI: MONITOR, WLAN, CONTROLLER, WIRELESS, SECURITY, MANAGEMENT, and COMMANDS. An additional role, LOBBY, is available for users who require only lobby ambassador privileges. The roles to which users are assigned are configured on the TACACS+ server. Users can be authorized for one or more roles. The minimum authorization is MONITOR only, and the maximum is ALL, which authorizes the user to execute the functionality associated with all seven menu options. For example, a user who is assigned the role of SECURITY can make changes to any items appearing on the Security menu (or designated as security commands in the case of the CLI). If users are not authorized for a particular role (such as WLAN), they can still access that menu option in read-only mode (or the associated CLI show commands). If the TACACS+ authorization server becomes unreachable or unable to authorize, users are unable to log into the controller.
Note If users attempt to make changes on a controller GUI page that are not permitted for their assigned role, a message appears indicating that they do not have sufficient privilege. If users enter a controller CLI command that is not permitted for their assigned role, a message may appear indicating that the command was successfully executed although it was not. In this case, the following additional message appears to inform users that they lack sufficient privileges to successfully execute the command: "Insufficient Privilege! Cannot execute command!"
•Accounting—The process of recording user actions and changes.
Whenever a user successfully executes an action, the TACACS+ accounting server logs the changed attributes, the user ID of the person who made the change, the remote host where the user is logged in, the date and time when the command was executed, the authorization level of the user, and a description of the action performed and the values provided. If the TACACS+ accounting server becomes unreachable, users are able to continue their sessions uninterrupted.
TACACS+ uses Transmission Control Protocol (TCP) for its transport, unlike RADIUS which uses User Datagram Protocol (UDP). It maintains a database and listens on TCP port 49 for incoming requests. The controller, which requires access control, acts as the client and requests AAA services from the server. The traffic between the controller and the server is encrypted by an algorithm defined in the protocol and a shared secret key configured on both devices.
You can configure up to three TACACS+ authentication, authorization, and accounting servers each. For example, you may want to have one central TACACS+ authentication server but several TACACS+ authorization servers in different regions. If you configure multiple servers of the same type and the first one fails or becomes unreachable, the controller automatically tries the second one and then the third one if necessary.
Note If multiple TACACS+ servers are configured for redundancy, the user database must be identical in all the servers for the backup to work properly.
You must configure TACACS+ on both your CiscoSecure Access Control Server (ACS) and your controller. You can configure the controller through either the GUI or the CLI.
Configuring TACACS+ on the ACS
Follow these steps to configure TACACS+ on the ACS.
Note TACACS+ is supported on CiscoSecure ACS version 3.2 and greater. The instructions and illustrations in this section pertain to ACS version 4.1 and may vary for other versions. Refer to the CiscoSecure ACS documentation for the version you are running.
Step 1 Click Network Configuration on the ACS main page.
Step 2 Click Add Entry under AAA Clients to add your controller to the server. The Add AAA Client page appears (see Figure 5-1).
Figure 5-1 Add AAA Client Page on CiscoSecure ACS
Step 3 In the AAA Client Hostname field, enter the name of your controller.
Step 4 In the AAA Client IP Address field, enter the IP address of your controller.
Step 5 In the Shared Secret field, enter the shared secret key to be used for authentication between the server and the controller.
Note The shared secret key must be the same on both the server and the controller.
Step 6 Choose TACACS+ (Cisco IOS) from the Authenticate Using drop-down box.
Step 7 Click Submit + Apply to save your changes.
Step 8 Click Interface Configuration on the ACS main page.
Step 9 Click TACACS+ (Cisco IOS). The TACACS+ (Cisco) page appears (see Figure 5-2).
Figure 5-2 TACACS+ (Cisco) Page on CiscoSecure ACS
Step 10 Under TACACS+ Services, check the Shell (exec) check box.
Step 11 Under New Services, check the first check box and enter ciscowlc in the Service field and common in the Protocol field.
Step 12 Under Advanced Configuration Options, check the Advanced TACACS+ Features check box.
Step 13 Click Submit to save your changes.
Step 14 Click System Configuration on the ACS main page.
Step 15 Click Logging.
Step 16 When the Logging Configuration page appears, enable all of the events that you want to be logged and save your changes.
Step 17 Click Group Setup on the ACS main page.
Step 18 Choose a previously created group from the Group drop-down box.
Note This step assumes that you have already assigned users to groups on the ACS according to the roles to which they will be assigned.
Step 19 Click Edit Settings. The Group Setup page appears (see Figure 5-3).
Figure 5-3 Group Setup Page on CiscoSecure ACS
Step 20 Under TACACS+ Settings, check the ciscowlc common check box.
Step 21 Check the Custom Attributes check box.
Step 22 In the text box below Custom Attributes, specify the roles that you want to assign to this group. The available roles are MONITOR, WLAN, CONTROLLER, WIRELESS, SECURITY, MANAGEMENT, COMMANDS, ALL, and LOBBY. As mentioned previously, the first seven correspond to the menu options on the controller GUI and allow access to those particular controller features. You can enter one or multiple roles, depending on the group's needs. Use ALL to specify all seven roles or LOBBY to specify the lobby ambassador role. Enter the roles using this format:
rolex=ROLE
For example, to specify the WLAN, CONTROLLER, and SECURITY roles for a particular user group, you would enter the following text:
To give a user group access to all seven roles, you would enter the following text:
Note Make sure to enter the roles using the format shown above. The roles must be in all uppercase letters, and there can be no spaces within the text.
Note You should not combine the MONITOR role or the LOBBY role with any other roles. If you specify one of these two roles in the Custom Attributes text box, users will have MONITOR or LOBBY privileges only, even if additional roles are specified.
Step 23 Click Submit to save your changes.
Using the GUI to Configure TACACS+
Follow these steps to configure TACACS+ through the controller GUI.
Step 1 Click Security > AAA > TACACS+.
Step 2 Perform one of the following:
•If you want to configure a TACACS+ server for authentication, click Authentication.
•If you want to configure a TACACS+ server for authorization, click Authorization.
•If you want to configure a TACACS+ server for accounting, click Accounting.
Note The GUI pages used to configure authentication, authorization, and accounting all contain the same fields. Therefore, these instructions walk through the configuration only once, using the Authentication pages as examples. You would follow the same steps to configure multiple services and/or multiple servers.
The TACACS+ (Authentication, Authorization, or Accounting) Servers page appears (see Figure 5-4).
Figure 5-4 TACACS+ Authentication Servers Page
This page lists any TACACS+ servers that have already been configured.
•If you want to delete an existing server, hover your cursor over the blue drop-down arrow for that server and choose Remove.
•If you want to make sure that the controller can reach a particular server, hover your cursor over the blue drop-down arrow for that server and choose Ping.
Step 3 Perform one of the following:
•To edit an existing TACACS+ server, click the server index number for that server. The TACACS+ (Authentication, Authorization, or Accounting) Servers > Edit page appears.
•To add a TACACS+ server, click New. The TACACS+ (Authentication, Authorization, or Accounting) Servers > New page appears (see Figure 5-5).
Figure 5-5 TACACS+ Authentication Servers > New Page
Step 4 If you are adding a new server, choose a number from the Server Index (Priority) drop-down box to specify the priority order of this server in relation to any other configured TACACS+ servers providing the same service. You can configure up to three servers. If the controller cannot reach the first server, it tries the second one in the list and then the third if necessary.
Step 5 If you are adding a new server, enter the IP address of the TACACS+ server in the Server IP Address field.
Step 6 From the Shared Secret Format drop-down box, choose ASCII or Hex to specify the format of the shared secret key to be used between the controller and the TACACS+ server. The default value is ASCII.
Step 7 In the Shared Secret and Confirm Shared Secret fields, enter the shared secret key to be used for authentication between the controller and the server.
Note The shared secret key must be the same on both the server and the controller.
Step 8 If you are adding a new server, enter the TACACS+ server's TCP port number for the interface protocols in the Port Number field. The valid range is 1 to 65535, and the default value is 49.
Step 9 From the Server Status field, choose Enabled to enable this TACACS+ server or choose Disabled to disable it. The default value is Enabled.
Step 10 In the Retransmit Timeout field, enter the number of seconds between retransmissions. The valid range is 2 to 30 seconds, and the default value is 2 seconds.
Note Cisco recommends that you increase the retransmit timeout value if you experience repeated reauthentication attempts or the controller falls back to the backup server when the primary server is active and reachable.
Step 11 Click Apply to commit your changes.
Step 12 Click Save Configuration to save your changes.
Step 13 Repeat the previous steps if you want to configure any additional services on the same server or any additional TACACS+ servers.
Step 14 To specify the order of authentication when multiple databases are configured, click Security > Priority Order > Management User. The Priority Order > Management User page appears (see Figure 5-6).
Figure 5-6 Priority Order > Management User Page
Step 15 For Authentication Priority, choose either Radius or TACACS+ to specify which server has priority over the other when the controller attempts to authenticate management users. By default, the local database is always queried first. If the username is not found, the controller switches to the TACACS+ server if configured for TACACS+ or to the RADIUS server if configured for Radius. The default setting is local and then Radius.
Step 16 Click Apply to commit your changes.
Step 17 Click Save Configuration to save your changes.
Using the CLI to Configure TACACS+
Use the commands in this section to configure TACACS+ through the controller CLI.
Note Refer to the "Using the GUI to Configure TACACS+" section for the valid ranges and default values of the parameters used in the CLI commands.
1. Use these commands to configure a TACACS+ authentication server:
•config tacacs auth add index server_ip_address port# {ascii | hex} shared_secret—Adds a TACACS+ authentication server.
•config tacacs auth delete index—Deletes a previously added TACACS+ authentication server.
•config tacacs auth (enable | disable} index—Enables or disables a TACACS+ authentication server.
•config tacacs auth retransmit-timeout index timeout—Configures the retransmission timeout value for a TACACS+ authentication server.
2. Use these commands to configure a TACACS+ authorization server:
•config tacacs athr add index server_ip_address port# {ascii | hex} shared_secret—Adds a TACACS+ authorization server.
•config tacacs athr delete index—Deletes a previously added TACACS+ authorization server.
•config tacacs athr (enable | disable} index—Enables or disables a TACACS+ authorization server.
•config tacacs athr retransmit-timeout index timeout—Configures the retransmission timeout value for a TACACS+ authorization server.
3. Use these commands to configure a TACACS+ accounting server:
•config tacacs acct add index server_ip_address port# {ascii | hex} shared_secret—Adds a TACACS+ accounting server.
•config tacacs acct delete index—Deletes a previously added TACACS+ accounting server.
•config tacacs acct (enable | disable} index—Enables or disables a TACACS+ accounting server.
•config tacacs acct retransmit-timeout index timeout—Configures the retransmission timeout value for a TACACS+ accounting server.
4. Use these commands to see TACACS+ statistics:
•show tacacs summary—Shows a summary of TACACS+ servers and statistics.
•show tacacs auth stats—Shows the TACACS+ authentication server statistics.
•show tacacs athr stats—Shows the TACACS+ authorization server statistics.
•show tacacs acct stats—Shows the TACACS+ accounting server statistics.
For example, information similar to the following appears for the show tacacs summary command:
Idx Server Address Port State Tout
--- ---------------- ------ -------- ----
1 11.11.12.2 49 Enabled 2
2 11.11.13.2 49 Enabled 2
3 11.11.14.2 49 Enabled 2
Idx Server Address Port State Tout
--- ---------------- ------ -------- ----
1 11.11.12.2 49 Enabled 2
2 11.11.13.2 49 Enabled 2
3 11.11.14.2 49 Enabled 2
Idx Server Address Port State Tout
--- ---------------- ------ -------- ----
1 11.11.12.2 49 Enabled 2
2 11.11.13.2 49 Enabled 2
3 11.11.14.2 49 Enabled 2
Information similar to the following appears for the show tacacs auth stats command:
Server Index..................................... 1
Server Address................................... 10.10.10.10
Msg Round Trip Time.............................. 0 (1/100 second)
First Requests................................... 0
Retry Requests................................... 0
Accept Responses................................. 0
Reject Responses................................. 0
Error Responses.................................. 0
Restart Responses................................ 0
Follow Responses................................. 0
GetData Responses................................ 0
Encrypt no secret Responses...................... 0
Challenge Responses.............................. 0
Malformed Msgs................................... 0
Bad Authenticator Msgs........................... 0
Pending Requests................................. 0
Timeout Requests................................. 0
Unknowntype Msgs................................. 0
Other Drops....................................0
5. To clear the statistics for one or more TACACS+ servers, enter this command:
clear stats tacacs [auth | athr | acct] {index | all}
6. To configure the order of authentication when multiple databases are configured, enter this command. The default setting is local and then radius.
config aaa auth mgmt [radius | tacacs]
To see the current management authentication server order, enter this command:
show aaa auth
Information similar to the following appears:
Management authentication server order:
1............................................ local
2......................................... tacacs
7. To make sure the controller can reach the TACACS+ server, enter this command:
ping server_ip_address
8. To enable or disable TACACS+ debugging, enter this command:
debug aaa tacacs {enable | disable}
9. To save your changes, enter this command:
save config
Viewing the TACACS+ Administration Server Logs
Follow these steps to view the TACACS+ administration server logs, if you have a TACACS+ accounting server configured on the controller.
Step 1 Click Reports and Activity on the ACS main page.
Step 2 Click TACACS+ Administration.
Step 3 Click the .csv file corresponding to the date of the logs you wish to view. The TACACS+ Administration .csv page appears (see Figure 5-7).
Figure 5-7 TACACS+ Administration .csv Page on CiscoSecure ACS
This page provides the following information:
•The date and time the action was taken
•The name and assigned role of the user who took the action
•The group to which the user belongs
•The specific action that the user took
•The privilege level of the user who executed the action
•The IP address of the controller
•The IP address of the laptop or workstation from which the action was executed
Sometimes a single action (or command) is logged multiple times, once for each parameter in the command. For example, if the user enters the snmp community ipaddr ip_address subnet_mask community_name command, the IP address may be logged on one line while the subnet mask and community name are logged as "E." On another line, the subnet mask maybe logged while the IP address and community name are logged as "E." See the first and third lines in the example in Figure 5-8.
Figure 5-8 TACACS+ Administration .csv Page on CiscoSecure ACS
Note You can click Refresh at any time to refresh this page.
Configuring Local Network Users
This section explains how to add local network users to the local user database on the controller. The local user database stores the credentials (username and password) of all the local network users. These credentials are then used to authenticate the users. For example, local EAP may use the local user database as its backend database to retrieve user credentials. Refer to the "Configuring Local EAP" section for more information.
Note The controller passes client information to the RADIUS authentication server first. If the client information does not match a RADIUS database entry, the local user database is polled. Clients located in this database are granted access to network services if the RADIUS authentication fails or does not exist.
You can configure local network users through either the GUI or the CLI.
Using the GUI to Configure Local Network Users
Follow these steps to configure local network users using the controller GUI.
Step 1 Follow these steps to specify the maximum number of local network users that can exist on the local user database:
a. Click Security > AAA > General to access the General page (see Figure 5-9).
Figure 5-9 General Page
b. In the Maximum Local Database Entries field, enter a value for the maximum number of local network users that can be added to the local user database the next time the controller reboots. The currently configured value appears in parentheses to the right of the field. The valid range is 512 to 2048, and the default setting is 512.
c. Click Apply to commit your changes.
Step 2 Click Security > AAA > Local Net Users to access the Local Net Users page (see Figure 5-10).
Figure 5-10 Local Net Users Page
This page lists any local network users that have already been configured.
Note If you want to delete an existing user, hover your cursor over the blue drop-down arrow for that user and choose Remove.
Step 3 Perform one of the following:
•To edit an existing local network user, click the username for that user. The Local Net Users > Edit page appears.
•To add a local network user, click New. The Local Net Users > New page appears (see Figure 5-11).
Figure 5-11 Local Net Users > New Page
Step 4 If you are adding a new user, enter a username for the local user in the User Name field. You can enter up to 24 alphanumeric characters.
Note Local network usernames must be unique because they are all stored in the same database.
Step 5 In the Password and Confirm Password fields, enter a password for the local user. You can enter up to 24 alphanumeric characters.
Step 6 If you are adding a new user, check the Guest User check box if you want to limit the amount of time that the user has access to the local network. The default setting is unchecked.
Step 7 If you are adding a new user and you checked the Guest User check box, enter the amount of time (in seconds) that the guest user account is to remain active in the Lifetime field. The valid range is 60 to 259200 seconds, and the default setting is 86400 seconds.
Step 8 From the WLAN ID drop-down box, choose the number of the WLAN that is to be accessed by the local user. If you choose Any WLAN, which is the default setting, the user can access any of the configured WLANs.
Step 9 In the Description field, enter a descriptive title for the local user (such as "User 1").
Step 10 Click Apply to commit your changes.
Step 11 Click Save Configuration to save your changes.
Using the CLI to Configure Local Network Users
Use the commands in this section to configure local network users using the controller CLI.
Note Refer to the "Using the GUI to Configure Local Network Users" section for the valid ranges and default values of the parameters used in the CLI commands.
1. Use these commands to configure a local network user:
•config netuser add username password wlan_id description—Adds a permanent user to the local user database on the controller.
•config netuser add username password wlan_id description lifetime seconds—Adds a guest user to the local user database on the controller.
•config netuser delete username—Deletes a user from the local user database on the controller.
Note Local network usernames must be unique because they are all stored in the same database.
2. Use these commands to see information related to the local network users configured on the controller.
•show netuser detail username—Shows the configuration of a particular user in the local user database.
•show netuser summary—Lists all the users in the local user database.
For example, information similar to the following appears for the show netuser detail username command:
User Name............................... abc
WLAN Id................................. Any
Lifetime................................ Permanent
Description........................... test user
3. To save your changes, enter this command:
Configuring LDAP
This section explains how to configure a Lightweight Directory Access Protocol (LDAP) server as a backend database, similar to a RADIUS or local user database. An LDAP backend database allows the controller to query an LDAP server for the credentials (username and password) of a particular user. These credentials are then used to authenticate the user. For example, local EAP may use an LDAP server as its backend database to retrieve user credentials. Refer to the "Configuring Local EAP" section for more information.
Note The LDAP backend database supports only these local EAP methods: EAP-TLS and EAP-FAST with certificates. LEAP and EAP-FAST with protected access credentials (PACs) are not supported for use with the LDAP backend database.
You can configure LDAP through either the GUI or the CLI.
Using the GUI to Configure LDAP
Follow these steps to configure LDAP using the controller GUI.
Step 1 Click Security > AAA > LDAP to access the LDAP Servers page (see Figure 5-12).
Figure 5-12 LDAP Servers Page
This page lists any LDAP servers that have already been configured.
•If you want to delete an existing LDAP server, hover your cursor over the blue drop-down arrow for that server and choose Remove.
•If you want to make sure that the controller can reach a particular server, hover your cursor over the blue drop-down arrow for that server and choose Ping.
Step 2 Perform one of the following:
•To edit an existing LDAP server, click the index number for that server. The LDAP Servers > Edit page appears.
•To add an LDAP server, click New. The LDAP Servers > New page appears (see Figure 5-13).
Figure 5-13 LDAP Servers > New Page
Step 3 If you are adding a new server, choose a number from the Server Index (Priority) drop-down box to specify the priority order of this server in relation to any other configured LDAP servers. You can configure up to seventeen servers. If the controller cannot reach the first server, it tries the second one in the list and so on.
Step 4 If you are adding a new server, enter the IP address of the LDAP server in the Server IP Address field.
Step 5 If you are adding a new server, enter the LDAP server's TCP port number in the Port Number field. The valid range is 1 to 65535, and the default value is 389.
Step 6 In the User Base DN field, enter the distinguished name (DN) of the subtree in the LDAP server that contains a list of all the users. For example, ou=organizational unit, .ou=next organizational unit, and o=corporation.com. If the tree containing users is the base DN, type o=corporation.com or dc=corporation,dc=com.
Step 7 In the User Attribute field, enter the name of the attribute in the user record that contains the username. You can obtain this attribute from your directory server.
Step 8 In the User Object Type field, enter the value of the LDAP objectType attribute that identifies the record as a user. Often, user records have several values for the objectType attribute, some of which are unique to the user and some of which are shared with other object types.
Step 9 If you are adding a new server, choose Secure from the Server Mode drop-down box if you want all LDAP transactions to use a secure TLS tunnel. Otherwise, choose None, which is the default setting.
Step 10 In the Retransmit Timeout field, enter the number of seconds between retransmissions. The valid range is 2 to 30 seconds, and the default value is 2 seconds.
Step 11 Check the Enable Server Status check box to enable this LDAP server or uncheck it to disable it. The default value is disabled.
Step 12 Click Apply to commit your changes.
Step 13 Click Save Configuration to save your changes.
Step 14 Follow these steps to specify LDAP as the priority backend database server for local EAP authentication:
a. Click Security > Local EAP > Authentication Priority to access the Priority Order > Local-Auth page (see Figure 5-16).
Figure 5-14 Priority Order > Local-Auth Page
b. Highlight LOCAL and click < to move it to the left User Credentials box.
c. Highlight LDAP and click > to move it to the right User Credentials box. The database that appears at the top of the right User Credentials box is used when retrieving user credentials.
Note If both LDAP and LOCAL appear in the right User Credentials box with LDAP on the top and LOCAL on the bottom, local EAP attempts to authenticate clients using the LDAP backend database and fails over to the local user database if the LDAP servers are not reachable. If the user is not found, the authentication attempt is rejected. If LOCAL is on the top, local EAP attempts to authenticate using only the local user database. It does not fail over to the LDAP backend database.
d. Click Apply to commit your changes.
e. Click Save Configuration to save your changes.
Step 15 (Optional) Follow these steps if you wish to assign specific LDAP servers to a WLAN:
a. Click WLANs to access the WLANs page.
b. Click the profile name of the desired WLAN.
c. When the WLANs > Edit page appears, click the Security > AAA Servers tabs to access the WLANs > Edit (Security > AAA Servers) page (see Figure 5-15).
Figure 5-15 WLANs > Edit (Security > AAA Servers) Page
d. From the LDAP Servers drop-down boxes, choose the LDAP server(s) that you want to use with this WLAN. You can choose up to three LDAP servers, which are tried in priority order.
e. Click Apply to commit your changes.
f. Click Save Configuration to save your changes.
Using the CLI to Configure LDAP
Use the commands in this section to configure LDAP using the controller CLI.
Note Refer to the "Using the GUI to Configure LDAP" section for the valid ranges and default values of the parameters used in the CLI commands.
1. Use these commands to configure an LDAP server:
•config ldap add index server_ip_address port# user_dn password base_dn {secure}—Adds an LDAP server.
•config ldap delete index—Deletes a previously added LDAP server.
•config ldap {enable | disable} index—Enables or disables an LDAP server.
•config ldap retransmit-timeout index timeout—Configures the number of seconds between retransmissions for an LDAP server.
2. Use this command to specify LDAP as the priority backend database server:
config local-auth user-credentials ldap
Note If you enter config local-auth user-credentials ldap local, local EAP attempts to authenticate clients using the LDAP backend database and fails over to the local user database if the LDAP servers are not reachable. If the user is not found, the authentication attempt is rejected. If you enter config local-auth user-credentials local ldap, local EAP attempts to authenticate using only the local user database. It does not fail over to the LDAP backend database.
3. (Optional) Use these commands if you wish to assign specific LDAP servers to a WLAN:
•config wlan ldap add wlan_id index—Links a configured LDAP server to a WLAN.
•config wlan ldap delete wlan_id {all | index}—Deletes a specific or all configured LDAP server(s) from a WLAN.
4. Use these commands to view information pertaining to configured LDAP servers:
•show ldap summary—Shows a summary of the configured LDAP servers.
•show ldap detailed index—Shows detailed LDAP server information.
•show ldap statistics—Shows LDAP server statistics.
•show wlan wlan_id—Shows the LDAP servers that are applied to a WLAN.
For example, information similar to the following appears for the show ldap summary command:
Idx Host IP addr Port Enabled
--- --------------- ----- -------
Information similar to the following appears for the show ldap statistics command:
Server 1........................ 10.10.10.10 389
5. To make sure the controller can reach the LDAP server, enter this command:
ping server_ip_address
6. To save your changes, enter this command:
save config
7. To enable or disable debugging for LDAP, enter this command:
debug aaa ldap {enable | disable}
Configuring Local EAP
Local EAP is an authentication method that allows users and wireless clients to be authenticated locally. It is designed for use in remote offices that want to maintain connectivity to wireless clients when the backend system becomes disrupted or the external authentication server goes down. When you enable local EAP, the controller serves as the authentication server and the local user database, thereby removing dependence on an external authentication server. Local EAP retrieves user credentials from the local user database or the LDAP backend database to authenticate users. Local EAP supports LEAP, EAP-FAST, and EAP-TLS authentication between the controller and wireless clients.
Note The LDAP backend database supports only these local EAP methods: EAP-TLS and EAP-FAST with certificates. LEAP and EAP-FAST with PACs are not supported for use with the LDAP backend database.
Note If any RADIUS servers are configured on the controller, the controller tries to authenticate the wireless clients using the RADIUS servers first. Local EAP is attempted only if no RADIUS servers are found, either because the RADIUS servers timed out or no RADIUS servers were configured. If four RADIUS servers are configured, the controller attempts to authenticate the client with the first RADIUS server, then the second RADIUS server, and then local EAP. If the client attempts to then reauthenticate manually, the controller tries the third RADIUS server, then the fourth RADIUS server, and then local EAP.
You can configure local EAP through either the GUI or the CLI.
Using the GUI to Configure Local EAP
Follow these steps to configure local EAP using the controller GUI.
Step 1 EAP-TLS uses certificates for authentication, and EAP-FAST uses either certificates or PACs. The controller is shipped with Cisco-installed device and Certificate Authority (CA) certificates. However, if you wish to use your own vendor-specific certificates, they must be imported on the controller. If you are configuring local EAP to use one of these EAP types, make sure that the appropriate certificates and PACs (if you will use manual PAC provisioning) have been imported on the controller. Refer to Chapter 8, for instructions on importing certificates and PACs.
Step 2 If you want the controller to retrieve user credentials from the local user database, make sure that you have properly configured the local network users on the controller. See the "Configuring Local Network Users" section for instructions.
Step 3 If you want the controller to retrieve user credentials from an LDAP backend database, make sure that you have properly configured an LDAP server on the controller. See the "Configuring LDAP" section for instructions.
Step 4 Follow these steps to specify the order in which user credentials are retrieved from the backend database servers:
a. Click Security > Local EAP > Authentication Priority to access the Priority Order > Local-Auth page (see Figure 5-16).
Figure 5-16 Priority Order > Local-Auth Page
b. Determine the priority order in which user credentials are to be retrieved from the local and/or LDAP databases. For example, you may want the LDAP database to be given priority over the local user database, or you may not want the LDAP database to be considered at all.
c. When you have decided on a priority order, highlight the desired database. Then use the left and right arrows and the Up and Down buttons to move the desired database to the top of the right User Credentials box.
Note If both LDAP and LOCAL appear in the right User Credentials box with LDAP on the top and LOCAL on the bottom, local EAP attempts to authenticate clients using the LDAP backend database and fails over to the local user database if the LDAP servers are not reachable. If the user is not found, the authentication attempt is rejected. If LOCAL is on the top, local EAP attempts to authenticate using only the local user database. It does not fail over to the LDAP backend database.
d. Click Apply to commit your changes.
Step 5 Follow these steps to specify a timeout value for local EAP:
a. Click Security > Local EAP > General to access the General page.
b. In the Local Auth Active Timeout field, enter the amount of time (in seconds) that the controller attempts to authenticate wireless clients using local EAP after any pair of configured RADIUS servers fail. The valid range is 1 to 3600 seconds, and the default setting is 1000 seconds.
c. Click Apply to commit your changes.
Step 6 Follow these steps to create a local EAP profile, which specifies the EAP authentication types that are supported on the wireless clients:
a. Click Security > Local EAP > Profiles to access the Local EAP Profiles page (see Figure 5-17).
Figure 5-17 Local EAP Profiles Page
This page lists any local EAP profiles that have already been configured and specifies their EAP types. You can create up to 16 local EAP profiles.
Note If you want to delete an existing profile, hover your cursor over the blue drop-down arrow for that profile and choose Remove.
b. Click New to access the Local EAP Profiles > New page.
c. In the Profile Name field, enter a name your new profile and then click Apply.
Note You can enter up to 63 alphanumeric characters for the profile name. Make sure not to include spaces.
d. When the Local EAP Profiles page reappears, click the name of your new profile. The Local EAP Profiles > Edit page appears (see Figure 5-18).
Figure 5-18 Local EAP Profiles > Edit Page
e. Check the LEAP, EAP-FAST, and/or EAP-TLS check boxes to specify the EAP type(s) that can be used for local authentication.
Note You can specify more than one EAP type per profile. However, if you create a profile that specifies both EAP-TLS (which requires certificates) and EAP-FAST with certificates, both EAP types must use the same certificate (from either Cisco or another vendor).
f. If you chose EAP-FAST and want the device certificate on the controller to be used for authentication, check the Local Certificate Required check box. If you want to use EAP-FAST with PACs instead of certificates, leave this check box unchecked, which is the default setting.
Note This option applies only to EAP-FAST because certificates are not used with LEAP and are mandatory for EAP-TLS.
g. If you chose EAP-FAST and want the wireless clients to send their device certificates to the controller in order to authenticate, check the Client Certificate Required check box. If you want to use EAP-FAST with PACs instead of certificates, leave this check box unchecked, which is the default setting.
Note This option applies only to EAP-FAST because certificates are not used with LEAP and are mandatory for EAP-TLS.
h. If you chose EAP-FAST with certificates or EAP-TLS, choose which certificates will be sent to the client, the ones from Cisco or the ones from another Vendor, from the Certificate Issuer drop-down box. The default setting is Cisco.
i. If you chose EAP-FAST with certificates or EAP-TLS and want the incoming certificate from the client to be validated against the CA certificates on the controller, check the Check Against CA Certificates check box. The default setting is enabled.
j. If you chose EAP-FAST with certificates or EAP-TLS and want the common name (CN) in the incoming certificate to be validated against the CA certificates' CN on the controller, check the Verify Certificate CN Identity check box. The default setting is disabled.
k. If you chose EAP-FAST with certificates or EAP-TLS and want the controller to verify that the incoming device certificate is still valid and has not expired, check the Check Certificate Date Validity check box. The default setting is enabled.
l. Click Apply to commit your changes.
Step 7 If you created an EAP-FAST profile, follow these steps to configure the EAP-FAST parameters:
a. Click Security > Local EAP > EAP-FAST Parameters to access the EAP-FAST Method Parameters page (see Figure 5-19).
Figure 5-19 EAP-FAST Method Parameters Page
b. In the Server Key and Confirm Server Key fields, enter the key (in hexadecimal characters) used to encrypt and decrypt PACs.
c. In the Time to Live for the PAC field, enter the number of days for the PAC to remain viable. The valid range is 1 to 1000 days, and the default setting is 10 days.
d. In the Authority ID field, enter the authority identifier of the local EAP-FAST server in hexadecimal characters. You can enter up to 32 hexadecimal characters, but you must enter an even number of characters.
e. In the Authority ID Information field, enter the authority identifier of the local EAP-FAST server in text format.
f. If you want to enable anonymous provisioning, check the Anonymous Provision check box. This feature allows PACs to be sent automatically to clients that do not have one during PAC provisioning. If you disable this feature, PACS must be manually provisioned. The default setting is enabled.
Note If the local and/or client certificates are required and you want to force all EAP-FAST clients to use certificates, uncheck the Anonymous Provision check box.
g. Click Apply to commit your changes.
Step 8 Follow these steps to enable local EAP on a WLAN:
a. Click WLANs to access the WLANs page.
b. Click the profile name of the desired WLAN.
c. When the WLANs > Edit page appears, click the Security > AAA Servers tabs to access the WLANs > Edit (Security > AAA Servers) page (see Figure 5-20).
Figure 5-20 WLANs > Edit (Security > AAA Servers) Page
d. Check the Local EAP Authentication check box to enable local EAP for this WLAN.
e. From the EAP Profile Name drop-down box, choose the EAP profile that you want to use for this WLAN.
f. If desired, choose the LDAP server(s) that you want to use with local EAP on this WLAN from the LDAP Servers drop-down boxes.
g. Click Apply to commit your changes.
Step 9 Click Save Configuration to save your changes.
Using the CLI to Configure Local EAP
Follow these steps to configure local EAP using the controller CLI.
Note Refer to the "Using the GUI to Configure Local EAP" section for the valid ranges and default values of the parameters used in the CLI commands.
Step 1 EAP-TLS uses certificates for authentication, and EAP-FAST uses either certificates or PACs. The controller is shipped with Cisco-installed device and Certificate Authority (CA) certificates. However, if you wish to use your own vendor-specific certificates, they must be imported on the controller. If you are configuring local EAP to use one of these EAP types, make sure that the appropriate certificates and PACs (if you will use manual PAC provisioning) have been imported on the controller. Refer to Chapter 8, for instructions on importing certificates and PACs.
Step 2 If you want the controller to retrieve user credentials from the local user database, make sure that you have properly configured the local network users on the controller. See the "Configuring Local Network Users" section for instructions.
Step 3 If you want the controller to retrieve user credentials from an LDAP backend database, make sure that you have properly configured an LDAP server on the controller. See the "Configuring LDAP" section for instructions.
Step 4 To specify the order in which user credentials are retrieved from the local and/or LDAP databases, enter this command:
config local-auth user-credentials {local | ldap}
Note If you enter config local-auth user-credentials ldap local, local EAP attempts to authenticate clients using the LDAP backend database and fails over to the local user database if the LDAP servers are not reachable. If the user is not found, the authentication attempt is rejected. If you enter config local-auth user-credentials local ldap, local EAP attempts to authenticate using only the local user database. It does not fail over to the LDAP backend database.
Step 5 To specify the amount of time (in seconds) that the controller attempts to authenticate the wireless clients using local EAP after any pair of configured RADIUS servers fail.
config local-auth active-timeout timeout
Step 6 To create a local EAP profile, enter this command:
config local-auth eap-profile add profile_name
Note Do not include spaces within the profile name.
Note To delete a local EAP profile, enter this command: config local-auth eap-profile delete profile_name.
Step 7 To add an EAP method to a local EAP profile, enter this command:
config local-auth eap-profile method add method profile_name
The supported methods are leap, fast, and tls.
Note You can specify more than one EAP type per profile. However, if you create a profile that specifies both EAP-TLS (which requires certificates) and EAP-FAST with certificates, both EAP types must use the same certificate (from either Cisco or another vendor).
Note To delete an EAP method from a local EAP profile, enter this command: config local-auth eap-profile method delete method profile_name.
Step 8 To configure EAP-FAST parameters if you created an EAP-FAST profile, enter this command:
config local-auth method fast ?
where ? is one of the following:
•anon-prov {enable | disable}—Configures the controller to allow anonymous provisioning, which allows PACs to be sent automatically to clients that do not have one during PAC provisioning.
•authority-id auth_id—Specifies the authority identifier of the local EAP-FAST server.
•pac-ttl value—Specifies the number of days for the PAC to remain viable.
•server-key key—Specifies the server key used to encrypt and decrypt PACs.
Step 9 To configure certificate parameters per profile, enter these commands:
•config local-auth eap-profile method fast local-cert {enable | disable} profile_name—
Specifies whether the device certificate on the controller is required for authentication.
Note This command applies only to EAP-FAST because certificates are not used with LEAP and are mandatory for EAP-TLS.
•config local-auth eap-profile method fast client-cert {enable | disable} profile_name—
Specifies whether wireless clients are required to send their device certificates to the controller in order to authenticate.
Note This command applies only to EAP-FAST because certificates are not used with LEAP and are mandatory for EAP-TLS.
•config local-auth eap-profile method method cert-issuer {cisco | vendor}—If you specified EAP-FAST with certificates or EAP-TLS, specifies whether the certificates that will be sent to the client are from Cisco or another vendor.
•config local-auth eap-profile method method peer-verify ca-issuer {enable | disable}—If you chose EAP-FAST with certificates or EAP-TLS, specifies whether the incoming certificate from the client is to be validated against the CAs certificates on the controller.
•config local-auth eap-profile method method peer-verify cn-verify {enable | disable}—If you chose EAP-FAST with certificates or EAP-TLS, specifies whether the common name (CN) in the incoming certificate is to be validated against the CA certificates' CN on the controller.
•config local-auth eap-profile method method peer-verify date-valid {enable | disable}—If you chose EAP-FAST with certificates or EAP-TLS, specifies whether the controller is to verify that the incoming device certificate is still valid and has not expired.
Step 10 To enable local EAP and attach an EAP profile to a WLAN, enter this command:
config wlan local-auth enable profile_name wlan_id
Note To disable local EAP for a WLAN, enter this command: config wlan local-auth disable wlan_id.
Step 11 To save your changes, enter this command:
save config
Step 12 To view information pertaining to local EAP, enter these commands:
•show local-auth config—Shows the local EAP configuration on the controller.
•show local-auth status—Shows the status of local EAP.
•show certificates local-auth—Shows the certificates available for local EAP.
•show local-auth user-credentials—Shows the priority order that the controller uses when retrieving user credentials from the local and/or LDAP databases.
•show wlan wlan_id—Shows the status of local EAP on a particular WLAN.
For example, information similar to the following appears for the show local-auth config command:
User credentials database search order:
Primary ..................................... Local DB
Name ........................................ fast-cert
Certificate issuer ........................ vendor
Peer verification options:
Check against CA certificates ........... Enabled
Verify certificate CN identity .......... Disabled
Check certificate date validity ......... Enabled
Local certificate required .............. Yes
Client certificate required ............. Yes
Enabled methods ........................... fast
Configured on WLANs ....................... 1
Name ........................................ tls
Certificate issuer ........................ vendor
Peer verification options:
Check against CA certificates ........... Enabled
Verify certificate CN identity .......... Disabled
Check certificate date validity ......... Enabled
Local certificate required .............. No
Client certificate required ............. No
Enabled methods ........................... tls
Configured on WLANs ....................... 2
EAP Method configuration:
Server key ................................ <hidden>
TTL for the PAC ........................... 10
Anonymous provision allowed ............... Yes
Accept client on auth prov ................ No
Authority ID .............................. 436973636f0000000000000000000000
Authority Information ..................... Cisco A-ID
Step 13 If necessary, you can use these commands to troubleshoot local EAP sessions:
•debug aaa local-auth eap method {all | errors | events | packets | sm} {enable | disable}—
Enables or disables debugging of local EAP methods.
•debug aaa local-auth eap framework {all | errors | events | packets | sm} {enable | disable}—
Enables or disables debugging of the local EAP framework.
Note In these two debug commands, sm is the state machine.
•show local-auth statistics—Shows the local EAP statistics.
•clear stats local-auth—Clears the local EAP counters.
Configuring the System for SpectraLink NetLink Telephones
For best integration with the Cisco UWN Solution, SpectraLink NetLink Telephones require an extra operating system configuration step: enable long preambles. The radio preamble (sometimes called a header) is a section of data at the head of a packet that contains information that wireless devices need when sending and receiving packets. Short preambles improve throughput performance, so they are enabled by default. However, some wireless devices, such as SpectraLink NetLink phones, require long preambles.
Use one of these methods to enable long preambles:
•Using the GUI to Enable Long Preambles
•Using the CLI to Enable Long Preambles
Using the GUI to Enable Long Preambles
Use this procedure to use the GUI to enable long preambles to optimize the operation of SpectraLink NetLink phones on your wireless LAN.
Step 1 Log into the controller GUI.
Step 2 Follow this path to navigate to the 802.11b/g Global Parameters page:
Wireless > Global RF > 802.11b/g Network
If the Short Preamble Enabled box is checked, continue with this procedure. However, if the Short Preamble Enabled box is unchecked (which means that long preambles are enabled), the controller is already optimized for SpectraLink NetLink phones and you do not need to continue this procedure.
Step 3 Uncheck the Short Preamble Enabled check box to enable long preambles.
Step 4 Click Apply to update the controller configuration.
Note If you do not already have an active CLI session to the controller, Cisco recommends that you start a CLI session to reboot the controller and watch the reboot process. A CLI session is also useful because the GUI loses its connection when the controller reboots.
Step 5 Reboot the controller using Commands > Reboot > Reboot. Click OK in response to this prompt:
Configuration will be saved and switch will be rebooted. Click ok to confirm.
The controller reboots.
Step 6 Log back into the controller GUI and verify that the controller is properly configured. Follow this path to navigate to the 802.11b/g Global Parameters page:
Wireless > 802.11b/g > Network
If the Short Preamble Enabled box is unchecked, the controller is optimized for SpectraLink NetLink phones.
Using the CLI to Enable Long Preambles
Use this procedure to use the CLI to enable long preambles to optimize the operation of SpectraLink NetLink phones on your wireless LAN.
Step 1 Log into the controller CLI.
Step 2 Enter show 802.11b and check the Short preamble mandatory parameter. If the parameter indicates that short preambles are enabled, continue with this procedure. This example shows that short preambles are enabled:
Short Preamble mandatory....................... Enabled
However, if the parameter shows that short preambles are disabled (which means that long preambles are enabled), the controller is already optimized for SpectraLink NetLink phones and you do not need to continue this procedure. This example shows that short preambles are disabled:
Short Preamble mandatory....................... Disabled
Step 3 Enter config 802.11b disable network to disable the 802.11b/g network. (You cannot enable long preambles on the 802.11a network.)
Step 4 Enter config 802.11b preamble long to enable long preambles.
Step 5 Enter config 802.11b enable network to re-enable the 802.11b/g network.
Step 6 Enter reset system to reboot the controller. Enter y when this prompt appears:
The system has unsaved changes. Would you like to save them now? (y/n)
The controller reboots.
Step 7 To verify that the controller is properly configured, log back into the CLI and enter show 802.11b to view these parameters:
802.11b Network................................ Enabled
Short Preamble mandatory....................... Disabled
These parameters show that the 802.11b/g network is enabled and that short preambles are disabled.
Using the CLI to Configure Enhanced Distributed Channel Access
Use this CLI command to configure 802.11 enhanced distributed channel access (EDCA) parameters to support SpectraLink phones:
config advanced edca-parameters {svp-voice | wmm-default}
where
svp-voice enables SpectraLink voice priority (SVP) parameters and wmm-default enables wireless multimedia (WMM) default parameters.
Note To propagate this command to all access points connected to the controller, make sure to disable and then re-enable the 802.11b/g network after entering this command.
Using Management over Wireless
The Cisco UWN Solution Management over Wireless feature allows operators to monitor and configure local controllers using a wireless client. This feature is supported for all management tasks except uploads to and downloads from (transfers to and from) the controller.
Before you can use the Management over Wireless feature, you must properly configure the controller using one of these sections:
•Using the GUI to Enable Management over Wireless
•Using the CLI to Enable Management over Wireless
Using the GUI to Enable Management over Wireless
Step 1 Click Management > Mgmt Via Wireless to access the Management Via Wireless page.
Step 2 Check the Enable Controller Management to be accessible from Wireless Clients check box to enable management over wireless for the WLAN or uncheck it to disable this feature. The default value is unchecked.
Step 3 Click Apply to commit your changes.
Step 4 Click Save Configuration to save your changes.
Step 5 Use a wireless client web browser to connect to the controller management port or distribution system port IP address, and log into the controller GUI to verify that you can manage the WLAN using a wireless client.
Using the CLI to Enable Management over Wireless
Step 1 In the CLI, use the show network command to verify whether the Mgmt Via Wireless Interface is Enabled or Disabled. If Mgmt Via Wireless Interface is Disabled, continue with Step 2. Otherwise, continue with Step 3.
Step 2 To Enable Management over Wireless, enter config network mgmt-via-wireless enable.
Step 3 Use a wireless client to associate with an access point connected to the controller that you want to manage.
Step 4 Enter telnet controller-ip-address and log into the CLI to verify that you can manage the WLAN using a wireless client.
Configuring DHCP Option 82
DHCP option 82 provides additional security when DHCP is used to allocate network addresses. Specifically, it enables the controller to act as a DHCP relay agent to prevent DHCP client requests from untrusted sources. The controller can be configured to add option 82 information to DHCP requests from clients before forwarding the requests to the DHCP server. See Figure 5-21 for an illustration of this process.
Figure 5-21 DHCP Option 82
The access point forwards all DHCP requests from a client to the controller. The controller adds the DHCP option 82 payload and forwards the request to the DHCP server. The payload can contain the MAC address or the MAC address and SSID of the access point, depending on how you configure this option.
Note Any DHCP packets that already include a relay agent option are dropped at the controller.
Note DHCP option 82 is not supported for use with auto-anchor mobility, which is described in Chapter 11, .
Use these commands to configure DHCP option 82 on the controller.
1. To configure the format of the DHCP option 82 payload, enter one of these commands:
–config dhcp opt-82 remote-id ap_mac
This command adds the MAC address of the access point to the DHCP option 82 payload.
–config dhcp opt-82 remote-id ap_mac:ssid
This command adds the MAC address and SSID of the access point to the DHCP option 82 payload.
2. To enable or disable DHCP option 82 on the controller, enter this command:
config interface dhcp ap-manager opt-82 {enable | disable}
3. To see the status of DHCP option 82 on the controller, enter this command:
show interface detailed ap-manager
Information similar to the following appears:
Interface Name................................... ap-manager
IP Address....................................... 10.30.16.13
IP Netmask....................................... 255.255.248.0
IP Gateway....................................... 10.30.16.1
VLAN............................................. untagged
Active Physical Port............................. LAG (29)
Primary Physical Port............................ LAG (29)
Backup Physical Port............................. Unconfigured
Primary DHCP Server.............................. 10.1.0.10
Secondary DHCP Server............................ Unconfigured
DHCP Option 82................................... Enabled
ACL.............................................. Unconfigured
AP Manager....................................... Yes
Validating SSIDs
You can configure the controller to validate a rogue SSID against the SSIDs configured on the controller. If a rogue SSID matches one of the controller's SSIDs, the controller raises an alarm. Follow these steps to validate SSIDs using the controller GUI.
Note You cannot configure SSID validation from the controller CLI. However, you can use the show wps summary command to see whether SSID validation has been enabled.
Step 1 Click Security > Wireless Protection Policies > Trusted AP Policies to access the Trusted AP Policies page.
Step 2 Check the Validate SSID check box to enable SSID validation or uncheck it to disable this feature.
Step 3 Click Apply to commit your changes.
Step 4 Click Save Configuration to save your changes.
Configuring and Applying Access Control Lists
An access control list (ACL) is a set of rules used to limit access to a particular interface (for example, if you want to restrict a wireless client from pinging the management interface of the controller). After ACLs are configured on the controller, they can be applied to the management interface, the AP-manager interface, any of the dynamic interfaces, or a WLAN to control data traffic to and from wireless clients or to the controller central processing unit (CPU) to control all traffic destined for the CPU.
You may also want to create a preauthentication ACL for web authentication. Such an ACL could be used to allow certain types of traffic before authentication is complete.
Note If you are using an external web server with a 2000 or 2100 series controller or the controller network module within a Cisco 28/37/38xx Series Integrated Services Router, you must configure a preauthentication ACL on the WLAN for the external web server.
You can define up to 64 ACLs, each with up to 64 rules (or filters). Each rule has parameters that affect its action. When a packet matches all of the parameters for a rule, the action set for that rule is applied to the packet.
Note All ACLs have an implicit "deny all rule" as the last rule. If a packet does not match any of the rules, it is dropped by the controller.
You can configure and apply ACLs through either the GUI or the CLI.
Using the GUI to Configure Access Control Lists
Follow these steps to configure ACLs using the controller GUI.
Step 1 Click Security > Access Control Lists > Access Control Lists to access the Access Control Lists page (see Figure 5-22).
Figure 5-22 Access Control Lists Page
This page lists all of the ACLs that have been configured for this controller.
Note If you want to delete an existing ACL, hover your cursor over the blue drop-down arrow for that ACL and choose Remove.
Step 2 To add a new ACL, click New. The Access Control Lists > New page appears (see Figure 5-23).
Figure 5-23 Access Control Lists > New Page
Step 3 In the Access Control List Name field, enter a name for the new ACL. You can enter up to 32 alphanumeric characters.
Step 4 Click Apply. When the Access Control Lists page reappears, click the name of the new ACL.
Step 5 When the Access Control Lists > Edit page appears, click Add New Rule. The Access Control Lists > Rules > New page appears (see Figure 5-24).
Figure 5-24 Access Control Lists > Rules > New Page
Step 6 Follow these steps to configure a rule for this ACL:
a. The controller supports up to 64 rules for each ACL. These rules are listed in order from 1 to 64. In the Sequence field, enter a value (between 1 and 64) to determine the order of this rule in relation to any other rules defined for this ACL.
Note If rules 1 through 4 are already defined and you add rule 29, it is added as rule 5. If you add or change a sequence number for a rule, the sequence numbers for other rules adjust to maintain a contiguous sequence. For instance, if you change a rule's sequence number from 7 to 5, the rules with sequence numbers 5 and 6 are automatically reassigned as 6 and 7, respectively.
b. From the Source drop-down box, choose one of these options to specify the source of the packets to which this ACL applies:
•Any—Any source (This is the default value.)
•IP Address—A specific source. If you choose this option, enter the IP address and netmask of the source in the edit boxes.
c. From the Destination drop-down box, choose one of these options to specify the destination of the packets to which this ACL applies:
•Any—Any destination (This is the default value.)
•IP Address—A specific destination. If you choose this option, enter the IP address and netmask of the destination in the edit boxes.
d. From the Protocol drop-down box, choose the protocol ID of the IP packets to be used for this ACL. These are the protocol options:
•Any—Any protocol (This is the default value.)
•TCP—Transmission Control Protocol
•UDP—User Datagram Protocol
•ICMP—Internet Control Message Protocol
•ESP—IP Encapsulating Security Payload
•AH—Authentication Header
•GRE—Generic Routing Encapsulation
•IP in IP—Internet Protocol (IP) in IP. Permits or denies IP-in-IP packets.
•Eth Over IP—Ethernet-over-Internet Protocol
•OSPF—Open Shortest Path First
•Other—Any other Internet Assigned Numbers Authority (IANA) protocol
Note If you choose Other, enter the number of the desired protocol in the Protocol edit box. You can find the list of available protocols and their corresponding numbers here: http://www.iana.org/assignments/protocol-numbers
Note The controller can permit or deny only IP packets in an ACL. Other types of packets (such as ARP packets) cannot be specified.
e. If you chose TCP or UDP in the previous step, two additional parameters appear: Source Port and Destination Port. These parameters enable you to choose a specific source port and destination port or port ranges. The port options are used by applications that send and receive data to and from the networking stack. Some ports are designated for certain applications such as telnet, ssh, http, and so on.
f. From the DSCP drop-down box, choose one of these options to specify the differentiated services code point (DSCP) value of this ACL. DSCP is an IP header field that can be used to define the quality of service across the Internet.
•Any—Any DSCP (This is the default value.)
•Specific—A specific DSCP from 0 to 63, which you enter in the DSCP edit box
g. From the Direction drop-down box, choose one of these options to specify the direction of the traffic to which this ACL applies:
•Any—Any direction (This is the default value.)
•Inbound—From the client
•Outbound—To the client
Note If you are planning to apply this ACL to the controller CPU, choose Any or Inbound because a CPU ACL applies only to packets that are sent to the CPU, not packets from the CPU.
h. From the Action drop-down box, choose Deny to cause this ACL to block packets or Permit to cause this ACL to allow packets. The default value is Deny.
i. Click Apply to commit your changes. The Access Control Lists > Edit page reappears, showing the rules for this ACL. See Figure 5-25.
Figure 5-25 Access Control Lists > Edit Page
Note If you want to edit a rule, click the sequence number of the desired rule to access the Access Control Lists > Rules > Edit page. If you ever want to delete a rule, hover your cursor over the blue drop-down arrow for the desired rule and choose Remove.
j. Repeat this procedure to add any additional rules for this ACL.
Step 7 Click Save Configuration to save your changes.
Step 8 Repeat this procedure to add any additional ACLs.
Using the GUI to Apply Access Control Lists
Follow the instructions in these sections to apply ACLs using the controller GUI:
•Applying an Access Control List to an Interface
•Applying an Access Control List to the Controller CPU
•Applying an Access Control List to a WLAN
•Applying a Preauthentication Access Control List to a WLAN
Applying an Access Control List to an Interface
Follow these steps to apply an ACL to a management, AP-manager, or dynamic interface using the controller GUI.
Step 1 Click Controller > Interfaces.
Step 2 Click the name of the desired interface. The Interfaces > Edit page for that interface appears (see Figure 5-26).
Figure 5-26 Interfaces > Edit Page
Step 3 Choose the desired ACL from the ACL Name drop-down box and click Apply. None is the default value.
Note See Chapter 3 for more information on configuring controller interfaces.
Step 4 Click Save Configuration to save your changes.
Applying an Access Control List to the Controller CPU
Follow these steps to apply an ACL to the controller CPU to control traffic to the CPU using the controller GUI.
Step 1 Choose Security > Access Control Lists > CPU Access Control Lists. The CPU Access Control Lists page appears (see Figure 5-27).
Figure 5-27 CPU Access Control Lists Page
Step 2 Check the Enable CPU ACL check box to enable a designated ACL to control the traffic to the controller CPU or uncheck the check box to disable the CPU ACL feature and remove any ACL that had been applied to the CPU. The default value is unchecked.
Step 3 From the ACL Name drop-down box, choose the ACL that will control the traffic to the controller CPU. None is the default value when the CPU ACL feature is disabled. If you choose None while the CPU ACL Enable check box is checked, an error message appears indicating that you must choose an ACL.
Note This parameter is available only if you checked the CPU ACL Enable check box.
Step 4 From the CPU ACL Mode drop-down box, choose the type of traffic (wired, wireless, or both) that will be restricted from reaching the controller CPU. Wired is the default value.
Note This parameter is available only if you checked the CPU ACL Enable check box.
Step 5 Click Apply to commit your changes.
Step 6 Click Save Configuration to save your changes.
Applying an Access Control List to a WLAN
Follow these steps to apply an ACL to a WLAN using the controller GUI.
Step 1 Click WLANs to access the WLANs page.
Step 2 Click the profile name of the desired WLAN to access the WLANs > Edit page.
Step 3 Click the Advanced tab to access the WLANs > Edit (Advanced) page (see Figure 5-28).
Figure 5-28 WLANs > Edit (Advanced) Page
Step 4 From the Override Interface ACL drop-down box, choose the ACL that you want to apply to this WLAN. The ACL that you choose overrides any ACL that is configured for the interface. None is the default value.
Note See Chapter 6 for more information on configuring WLANs.
Step 5 Click Apply to commit your changes.
Step 6 Click Save Configuration to save your changes.
Applying a Preauthentication Access Control List to a WLAN
Follow these steps to apply a preauthentication ACL to a WLAN using the controller GUI.
Step 1 Click WLANs to access the WLANs page.
Step 2 Click the profile name of the desired WLAN to access the WLANs > Edit page.
Step 3 Click the Security and Layer 3 tabs to access the WLANs > Edit (Security > Layer 3) page (see Figure 5-29).
Figure 5-29 WLANs > Edit (Security > Layer 3) Page
Step 4 Check the Web Policy check box.
Step 5 From the Preauthentication ACL drop-down box, choose the desired ACL and click Apply. None is the default value.
Note See Chapter 6 for more information on configuring WLANs.
Step 6 Click Save Configuration to save your changes.
Using the CLI to Configure Access Control Lists
Follow these steps to configure ACLs using the controller CLI.
Step 1 To see all of the ACLs that are configured on the controller, enter this command:
show acl summary
Step 2 To see detailed information for a particular ACL, enter this command:
show acl detailed acl_name
Step 3 To add a new ACL, enter this command:
config acl create acl_name
You can enter up to 32 alphanumeric characters for the acl_name parameter.
Step 4 To add a rule for an ACL, enter this command:
config acl rule add acl_name rule_index
Step 5 To configure an ACL rule, enter this command:
config acl rule {
action acl_name rule_index {permit | deny} |
change index acl_name old_index new_index |
destination address acl_name rule_index ip_address netmask |
destination port range acl_name rule_index start_port end_port |
direction acl_name rule_index {in | out | any} |
dscp acl_name rule_index dscp |
protocol acl_name rule_index protocol |
source address acl_name rule_index ip_address netmask |
source port range acl_name rule_index start_port end_port |
swap index acl_name index_1 index_2}
Refer to Step 6 of the "Using the GUI to Configure Access Control Lists" section for explanations of the rule parameters.
Step 6 To save your settings, enter this command:
save config
Note To delete an ACL, enter config acl delete acl_name. To delete an ACL rule, enter config acl rule delete acl_name rule_index.
Using the CLI to Apply Access Control Lists
Follow these steps to apply ACLs using the controller CLI.
Step 1 Perform any of the following:
•To apply an ACL to a management, AP-manager, or dynamic interface, enter this command:
config interface acl {management | ap-manager | dynamic_interface_name} acl_name
Note To see the ACL that is applied to an interface, enter show interface detailed {management | ap-manager | dynamic_interface_name}. To remove an ACL that is applied to an interface, enter config interface acl {management | ap-manager | dynamic_interface_name} none.
See Chapter 3 for more information on configuring controller interfaces.
•To apply an ACL to the data path, enter this command:
config acl apply acl_name
•To apply an ACL to the controller CPU to restrict the type of traffic (wired, wireless, or both) reaching the CPU, enter this command:
config acl cpu acl_name {wired | wireless | both}
Note To see the ACL that is applied to the controller CPU, enter show acl cpu. To remove the ACL that is applied to the controller CPU, enter config acl cpu none.
•To apply an ACL to a WLAN, enter this command:
config wlan acl wlan_id acl_name
Note To see the ACL that is applied to a WLAN, enter show wlan wlan_id. To remove the ACL that is applied to a WLAN, enter config wlan acl wlan_id none.
•To apply a preauthentication ACL to a WLAN, enter this command:
config wlan security web-auth acl wlan_id acl_name
See Chapter 6 for more information on configuring WLANs.
Step 2 To save your settings, enter this command:
save config
Configuring Management Frame Protection
Management frame protection (MFP) provides security for the otherwise unprotected and unencrypted 802.11 management messages passed between access points and clients. MFP provides both infrastructure and client support. Controller software release 4.1 supports both infrastructure and client MFP while controller software release 4.0 supports only infrastructure MFP.
•Infrastructure MFP—Protects management frames by detecting adversaries that are invoking denial-of-service attacks, flooding the network with associations and probes, interjecting as rogue access points, and affecting network performance by attacking the QoS and radio measurement frames. It also provides a quick and effective means to detect and report phishing incidents.
Specifically, infrastructure MFP protects 802.11 session management functions by adding message integrity check information elements (MIC IEs) to the management frames emitted by access points (and not those emitted by clients), which are then validated by other access points in the network. Infrastructure MFP is passive. It can detect and report intrusions but has no means to stop them.
•Client MFP—Shields authenticated clients from spoofed frames, preventing many of the common attacks against wireless LANs from becoming effective. Most attacks, such as deauthentication attacks, revert to simply degrading performance by contending with valid clients.
Specifically, client MFP encrypts management frames sent between access points and CCXv5 clients so that both the access points and clients can take preventative action by dropping spoofed class 3 management frames (that is, management frames passed between an access point and a client that is authenticated and associated). Client MFP leverages the security mechanisms defined by IEEE 802.11i to protect the following types of class 3 unicast management frames: disassociation, deauthentication, and QoS (WMM) action. Client MFP protects a client-access point session from the most common type of denial-of-service attack. It protects class 3 management frames by using the same encryption method used for the session's data frames. If a frame received by the access point or client fails decryption, it is dropped, and the event is reported to the controller.
To use client MFP, clients must support CCXv5 MFP and must negotiate WPA2 using either TKIP or AES-CCMP. EAP or PSK may be used to obtain the PMK. CCKM and controller mobility management are used to distribute session keys between access points for Layer 2 and Layer 3 fast roaming.
Note To prevent attacks using broadcast frames, access points supporting CCXv5 will not emit any broadcast class 3 management frames (such as disassociation, deauthentication, or action). CCXv5 clients and access points must discard broadcast class 3 management frames.
Client MFP supplements infrastructure MFP rather than replaces it because infrastructure MFP continues to detect and report invalid unicast frames sent to clients that are not client-MFP capable as well as invalid class 1 and 2 management frames. Infrastructure MFP is applied only to management frames that are not protected by client MFP.
Infrastructure MFP consists of three main components:
•Management frame protection—The access point protects the management frames it transmits by adding a MIC IE to each frame. Any attempt to copy, alter, or replay the frame invalidates the MIC, causing any receiving access point configured to detect MFP frames to report the discrepancy.
•Management frame validation—In infrastructure MFP, the access point validates every management frame that it receives from other access points in the network. It ensures that the MIC IE is present (when the originator is configured to transmit MFP frames) and matches the content of the management frame. If it receives any frame that does not contain a valid MIC IE from a BSSID belonging to an access point that is configured to transmit MFP frames, it reports the discrepancy to the network management system. In order for the timestamps to operate properly, all controllers must be Network Transfer Protocol (NTP) synchronized.
•Event reporting—The access point notifies the controller when it detects an anomaly, and the controller aggregates the received anomaly events and can report the results through SNMP traps to the network management system.
Note Error reports generated on a hybrid-REAP access point in stand-alone mode cannot be forwarded to the controller and are dropped.
Note Client MFP uses the same event reporting mechanisms as infrastructure MFP.
Infrastructure MFP is enabled by default and can be disabled globally. When you upgrade from a previous software release, infrastructure MFP is disabled globally if access point authentication is enabled because the two features are mutually exclusive. Once infrastructure MFP is enabled globally, signature generation (adding MICs to outbound frames) can be disabled for selected WLANs, and validation can be disabled for selected access points.
Client MFP is enabled by default on WLANs that are configured for WPA2. It can be disabled, or it can be made mandatory (in which case only clients that negotiate MFP are allowed to associate) on selected WLANs.
You can configure MFP through either the GUI or the CLI.
Guidelines for Using MFP
Follow these guidelines for using MFP:
•MFP is supported for use with Cisco Aironet lightweight access points, except for the 1500 series mesh access points.
•Lightweight access points support infrastructure MFP in local and monitor modes and in hybrid-REAP mode when the access point is connected to a controller. They support Client MFP in local, hybrid-REAP, and bridge modes.
•Client MFP is supported for use only with CCXv5 clients using WPA2 with TKIP or AES-CCMP.
•Non-CCXv5 clients may associate to a WLAN if client MFP is disabled or optional.
Using the GUI to Configure MFP
Follow these steps to configure MFP using the controller GUI.
Step 1 Click Security > Wireless Protection Policies > AP Authentication/MFP. The AP Authentication Policy page appears (see Figure 5-30).
Figure 5-30 AP Authentication Policy Page
Step 2 To enable infrastructure MFP globally for the controller, choose Management Frame Protection from the Protection Type drop-down box.
Step 3 Click Apply to commit your changes.
Note If more than one controller is included in the mobility group, you must configure a Network Time Protocol (NTP) server on all controllers in the mobility group that are configured for infrastructure MFP.
Step 4 Follow these steps if you want to disable or re-enable infrastructure MFP for a particular WLAN after MFP has been enabled globally for the controller:
a. Click WLANs.
b. Click the profile name of the desired WLAN. The WLANs > Edit page appears.
c. Click Advanced. The WLANs > Edit (Advanced) page appears (see Figure 5-31).
Figure 5-31 WLANs > Edit (Advanced) Page
d. Uncheck the Infrastructure MFP Protection check box to disable MFP for this WLAN or check this check box to enable infrastructure MFP for this WLAN. The default value is enabled. If global MFP is disabled, a note appears in parentheses to the right of the check box.
e. Choose Disabled, Optional, or Required from the MFP Client Protection drop-down box. The default value is Optional. If you choose Required, clients are allowed to associate only if MFP is negotiated (that is, if WPA2 is configured on the controller and the client supports CCXv5 MFP and is also configured for WPA2).
f. Click Apply to commit your changes.
Step 5 Follow these steps if you want to disable or re-enable infrastructure MFP validation for a particular access point after infrastructure MFP has been enabled globally for the controller:
a. Click Wireless > Access Points to access the All APs page.
b. Click the name of the desired access point. The All APs > Details page appears.
c. Under General, uncheck the MFP Frame Validation check box to disable MFP for this access point or check this check box to enable MFP for this access point. The default value is enabled. If global MFP is disabled, a note appears in parentheses to the right of the check box.
d. Click Apply to commit your changes.
Step 6 Click Save Configuration to save your settings.
Using the GUI to View MFP Settings
Follow these steps to view MFP settings using the controller GUI.
Step 1 To see the controller's current global MFP settings, click Security > Wireless Protection Policies > Management Frame Protection. The Management Frame Protection Settings page appears (see Figure 5-32).
Figure 5-32 Management Frame Protection Settings Page
On this page, you can see the following MFP settings:
•The Management Frame Protection field shows if infrastructure MFP is enabled globally for the controller.
•The Controller Time Source Valid field indicates whether the controller time is set locally (by manually entering the time) or through an external source (such as NTP server). If the time is set by an external source, the value of this field is "True." If the time is set locally, the value is "False." The time source is used for validating the timestamp on management frames between access points of different controllers within a mobility group.
•The Infrastructure Protection field shows if infrastructure MFP is enabled for individual WLANs.
•The Client Protection field shows if client MFP is enabled for individual WLANs and whether it is optional or required.
•The Infrastructure Validation field shows if infrastructure MFP is enabled for individual access points.
Step 2 To see the current MFP capability for a particular access point, follow these steps:
a. Click Wireless > Access Points > Radios > 802.11a or 802.11b/g to access the 802.11a (or 802.11b/g) Radios page.
b. Hover your cursor over the blue drop-down arrow for the desired access point and choose Configure. The 802.11a (or 802.11b/g) Cisco APs > Configure page appears (see Figure 5-33).
Figure 5-33 802.11a Cisco APs > Configure Page
Under Management Frame Protection, this page shows the level of MFP protection and validation.
Note All access points that can associate using software release 4.1 have full MFP capability.
Using the CLI to Configure MFP
Use these commands to configure MFP using the controller CLI.
1. To enable or disable infrastructure MFP globally for the controller, enter this command:
config wps mfp infrastructure {enable | disable}
2. To enable or disable infrastructure MFP signature generation on a WLAN, enter this command:
config wlan mfp infrastructure protection {enable | disable} wlan_id
Note Signature generation is activated only if infrastructure MFP is globally enabled.
3. To enable or disable infrastructure MFP validation on an access point, enter this command:
config ap mfp infrastructure validation {enable | disable} Cisco_AP
Note MFP validation is activated only if infrastructure MFP is globally enabled.
4. To enable or disable client MFP on a specific WLAN, enter this command:
config wlan mfp client {enable | disable} wlan_id [required]
If you enable client MFP and use the optional required parameter, clients are allowed to associate only if MFP is negotiated.
Using the CLI to View MFP Settings
Use these commands to view MFP settings using the controller CLI.
1. To see a summary of the controller's current wireless protection policies (including infrastructure MFP), enter this command:
show wps summary
Information similar to the following appears:
Excessive 802.11-association failures.......... Enabled
Excessive 802.11-authentication failures....... Enabled
Excessive 802.1x-authentication................ Enabled
IP-theft....................................... Enabled
Excessive Web authentication failure........... Enabled
Management Frame Protection.................... Enabled
Mis-configured AP Action....................... Alarm Only
Enforced encryption policy................... none
Enforced preamble policy..................... none
Enforced radio type policy................... none
Validate SSID................................ Disabled
Alert if Trusted AP is missing................. Disabled
Trusted AP timeout............................. 120
Rogue Location Discovery Protocol.............. Disabled
RLDP Action.................................. Alarm Only
Rogues AP advertising my SSID................ Alarm
2. To see the controller's current MFP settings, enter this command:
show wps mfp summary
Information similar to the following appears:
Global Infrastructure MFP state.... Enabled
Controller Time Source Valid....... False
WLAN ID WLAN Name Status Protection Protection
------- ---------- -------- ---------- -----------
1 test1 Enabled Disabled Disabled
2 open Enabled Enabled Required
3 testpsk Enabled *Enabled Optional but inactive (WPA2 not configured)
Infra. Operational --Infra. Capability--
AP Name Validation Radio State Protection Validation
-------- ----------- ----- ----------- ----------- -----------
mapAP Disabled a Up Full Full
rootAP2 Enabled a Up Full Full
HReap *Enabled b/g Up Full Full
3. To see the current MFP configuration for a particular WLAN, enter this command:
show wlan wlan_id
Information similar to the following appears:
WLAN Identifier........................... 1
Profile Name.............................. test1
Network Name (SSID)....................... test1
Status.................................... Enabled
MAC Filtering............................. Disabled
Broadcast SSID............................ Enabled
Local EAP Authentication.................. Enabled (Profile 'test')
Diagnostics Channel....................... Disabled
802.11 Authentication:................. Open System
Static WEP Keys........................ Disabled
802.1X................................. Enabled
Encryption:.............................. 104-bit WEP
Wi-Fi Protected Access (WPA/WPA2)...... Disabled
CKIP .................................. Disabled
IP Security............................ Disabled
IP Security Passthru................... Disabled
Web Based Authentication............... Disabled
Web-Passthrough........................ Disabled
Conditional Web Redirect............... Disabled
Auto Anchor............................ Enabled
Cranite Passthru....................... Disabled
Fortress Passthru...................... Disabled
H-REAP Local Switching................. Disabled
Infrastructure MFP protection.......... Enabled
Client MFP............................. Required
4. To see the current MFP configuration for a particular access point, enter this command:
show ap config general AP_name
Information similar to the following appears:
Cisco AP Identifier.............................. 0
Cisco AP Name.................................... ap:52:c5:c0
AP Regulatory Domain............................. 80211bg: -N 80211a: -N
Switch Port Number .............................. 1
MAC Address...................................... 00:0b:85:52:c5:c0
IP Address Configuration......................... Static IP assigned
IP Address....................................... 10.67.73.33
IP NetMask....................................... 255.255.255.192
AP Mode ......................................... Local
Remote AP Debug ................................. Disabled
S/W Version .................................... 4.0.2.0
Boot Version ................................... 2.1.78.0
Mini IOS Version ................................ --
Stats Reporting Period .......................... 180
LED State........................................ Enabled
ILP Pre Standard Switch.......................... Disabled
ILP Power Injector............................... Disabled
Number Of Slots.................................. 2
AP Model......................................... AP1020
AP Serial Number................................. WCN09260057
AP Certificate Type.............................. Manufacture Installed
Management Frame Protection Validation .......... Enabled
5. To see whether client MFP is enabled for a specific client, enter this command:
show client detail client_mac
Client MAC Address............................... 00:14:1c:ed:34:72
Policy Type...................................... WPA2
Authentication Key Management.................... PSK
Encryption Cipher................................ CCMP (AES)
Management Frame Protection...................... Yes
6. To see MFP statistics for the controller, enter this command:
show wps mfp statistics
Information similar to the following appears:
Note This report contains no data unless an active attack is in progress. Examples of various error types are shown for illustration only. This table is cleared every 5 minutes when the data is forwarded to any network management stations.
BSSID Radio Validator AP Last Source Addr Found Error Type Count Frame Types
----------------- ----- ------------- ------------------ ------ ------------ ----- -------
00:0b:85:56:c1:a0 a jamesh-1000b 00:01:02:03:04:05 Infra Invalid MIC 183 Assoc Req
Probe Req
Beacon
Infra Out of seq 4 Assoc Req
Infra Unexpected MIC 85 Reassoc Req
Client Decrypt err 1974 Reassoc Req
Client Replay err 74 Assoc Req
Client Invalid ICV 174 Reassoc Req
Disassoc
Client Invalid header 174 Assoc Req
Probe Req
Beacon
Client Brdcst disass 174 Reassoc Req
Disassoc
00:0b:85:56:c1:a0 b/g jamesh-1000b 00:01:02:03:04:05 Infra Out of seq 185 Reassoc Resp
Client Not encrypted 174 Assoc Resp
Probe Resp
Using the CLI to Debug MFP Issues
Use these commands if you experience any problems with MFP:
•debug wps mfp ? {enable | disable}
where ? is one of the following:
client—Configures debugging for client MFP messages.
lwapp—Configures debugging for MFP messages between the controller and access points.
detail—Configures detailed debugging for MFP messages.
report—Configures debugging for MFP reporting.
mm—Configures debugging for MFP mobility (inter-controller) messages.
Configuring Client Exclusion Policies
Follow these steps to configure the controller to exclude clients under certain conditions using the controller GUI.
Step 1 Click Security > Wireless Protection Policies > Client Exclusion Policies to access the Client Exclusion Policies page.
Step 2 Check any of these check boxes if you want the controller to exclude clients for the condition specified. The default value for each exclusion policy is enabled.
•Excessive 802.11 Association Failures—Clients are excluded on the sixth 802.11 association attempt, after five consecutive failures.
•Excessive 802.11 Authentication Failures—Clients are excluded on the sixth 802.11 authentication attempt, after five consecutive failures.
•Excessive 802.1X Authentication Failures—Clients are excluded on the fourth 802.1X authentication attempt, after three consecutive failures.
•IP Theft or IP Reuse—Clients are excluded if the IP address is already assigned to another device.
•Excessive Web Authentication Failures—Clients are excluded on the fourth web authentication attempt, after three consecutive failures.
Step 3 Click Apply to commit your changes.
Step 4 Click Save Configuration to save your changes.
Configuring Identity Networking
These sections explain the identity networking feature, how it is configured, and the expected behavior for various security policies:
•Identity Networking Overview
•RADIUS Attributes Used in Identity Networking
•Configuring AAA Override
Identity Networking Overview
In most wireless LAN systems, each WLAN has a static policy that applies to all clients associated with an SSID. Although powerful, this method has limitations since it requires clients to associate with different SSIDs to inherit different QoS and security policies.
However, the Cisco Wireless LAN Solution supports identity networking, which allows the network to advertise a single SSID but allows specific users to inherit different QoS or security policies based on their user profiles. The specific policies that you can control using identity networking include:
•Quality of Service. When present in a RADIUS Access Accept, the QoS-Level value overrides the QoS value specified in the WLAN profile.
•ACL. When the ACL attribute is present in the RADIUS Access Accept, the system applies the ACL-Name to the client station after it authenticates. This overrides any ACLs that are assigned to the interface.
•VLAN. When a VLAN Interface-Name or VLAN-Tag is present in a RADIUS Access Accept, the system places the client on a specific interface.
Note The VLAN feature only supports MAC filtering, 802.1X, and WPA. The VLAN feature does not support web authentication or IPSec.
•Tunnel Attributes.
Note When any of the other RADIUS attributes (QoS-Level, ACL-Name, Interface-Name, or VLAN-Tag), which are described later in this section, are returned, the Tunnel Attributes must also be returned.
The operating system's local MAC filter database has been extended to include the interface name, allowing local MAC filters to specify to which interface the client should be assigned. A separate RADIUS server can also be used, but the RADIUS server must be defined using the Security menus.
RADIUS Attributes Used in Identity Networking
This section explains the RADIUS attributes used in identity networking.
QoS-Level
This attribute indicates the Quality of Service level to be applied to the mobile client's traffic within the switching fabric, as well as over the air. This example shows a summary of the QoS-Level Attribute format. The fields are transmitted from left to right.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont.) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
•Type - 26 for Vendor-Specific
•Length - 10
•Vendor-Id - 14179
•Vendor type - 2
•Vendor length - 4
•Value - Three octets:
–0 - Bronze (Background)
–1 - Silver (Best Effort)
–2 - Gold (Video)
–3 - Platinum (Voice)
ACL-Name
This attribute indicates the ACL name to be applied to the client. A summary of the ACL-Name Attribute format is shown below. The fields are transmitted from left to right.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont.) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
•Type - 26 for Vendor-Specific
•Length - >7
•Vendor-Id - 14179
•Vendor type - 6
•Vendor length - >0
•Value - A string that includes the name of the ACL to use for the client
Interface-Name
This attribute indicates the VLAN Interface a client is to be associated to. A summary of the Interface-Name Attribute format is shown below. The fields are transmitted from left to right.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont.) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
•Type - 26 for Vendor-Specific
•Length - >7
•Vendor-Id - 14179
•Vendor type - 5
•Vendor length - >0
•Value - A string that includes the name of the interface the client is to be assigned to.
Note This Attribute only works when MAC filtering is enabled or if 802.1X or WPA is used as the security policy.
VLAN-Tag
This attribute indicates the group ID for a particular tunneled session, and is also known as the Tunnel-Private-Group-ID attribute.
This attribute might be included in the Access-Request packet if the tunnel initiator can predetermine the group resulting from a particular connection and should be included in the Access-Accept packet if this tunnel session is to be treated as belonging to a particular private group. Private groups may be used to associate a tunneled session with a particular group of users. For example, it may be used to facilitate routing of unregistered IP addresses through a particular interface. It should be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session.
A summary of the Tunnel-Private-Group-ID Attribute format is shown below. The fields are transmitted from left to right.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
•Type - 81 for Tunnel-Private-Group-ID.
•Length - >= 3
•Tag - The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it should be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it should be interpreted as the first byte of the following String field.
•String - This field must be present. The group is represented by the String field. There is no restriction on the format of group IDs.
Tunnel Attributes
Note When any of the other RADIUS attributes (QoS-Level, ACL-Name, Interface-Name, or VLAN-Tag) are returned, the Tunnel Attributes must also be returned.
Reference RFC2868 defines RADIUS tunnel attributes used for authentication and authorization, and RFC2867 defines tunnel attributes used for accounting. Where the IEEE 802.1X Authenticator supports tunneling, a compulsory tunnel may be set up for the Supplicant as a result of the authentication.
In particular, it may be desirable to allow a port to be placed into a particular Virtual LAN (VLAN), defined in IEEE8021Q, based on the result of the authentication. This can be used, for example, to allow a wireless host to remain on the same VLAN as it moves within a campus network.
The RADIUS server typically indicates the desired VLAN by including tunnel attributes within the Access-Accept. However, the IEEE 802.1X Authenticator may also provide a hint as to the VLAN to be assigned to the Supplicant by including Tunnel attributes within the Access- Request.
For use in VLAN assignment, the following tunnel attributes are used:
•Tunnel-Type=VLAN (13)
•Tunnel-Medium-Type=802
•Tunnel-Private-Group-ID=VLANID
Note that the VLANID is 12-bits, taking a value between 1 and 4094, inclusive. Since the Tunnel-Private-Group-ID is of type String as defined in RFC2868, for use with IEEE 802.1X, the VLANID integer value is encoded as a string.
When Tunnel attributes are sent, it is necessary to fill in the Tag field. As noted in RFC2868, section 3.1:
•The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it must be zero (0x00).
•For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of greater than 0x1F is interpreted as the first octet of the following field.
•Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X Authenticators that may support tunneling but not VLANs), it is only necessary for tunnel attributes to specify a single tunnel. As a result, where it is only desired to specify the VLANID, the tag field should be set to zero (0x00) in all tunnel attributes. Where alternative tunnel types are to be provided, tag values between 0x01 and 0x1F should be chosen.
Configuring AAA Override
The Allow AAA Override option of a WLAN allows you to configure the WLAN for identity networking. It allows you to apply VLAN tagging, QoS, and ACLs to individual clients based on the returned RADIUS attributes from the AAA server.
Most of the configuration for allowing AAA override is done at the RADIUS server, where you should configure the Access Control Server (ACS) with the override properties you would like it to return to the controller (for example, Interface-Name, QoS-Level, and VLAN-Tag).
On the controller, simply enable the Allow AAA Override configuration parameter using the GUI or CLI. Enabling this parameter allows the controller to accept the attributes returned by the RADIUS server. The controller then applies these attributes to its clients.
Updating the RADIUS Server Dictionary File for Proper QoS Values
If you are using a Steel-Belted RADIUS (SBR), FreeRadius, or similar RADIUS server, clients may not obtain the correct QoS values after the AAA override feature is enabled. For these servers, which allow you to edit the dictionary file, you need to update the file to reflect the proper QoS values: Silver = 0, Gold = 1, Platinum = 2, and Bronze = 3. Follow the steps below to do so.
Note This issue does not apply to the Cisco Secure Access Control Server (ACS).
Step 1 Stop the SBR service (or other RADIUS service).
Step 2 Save the following text to the Radius_Install_Directory\Service folder as ciscowlan.dct:
################################################################################
# CiscoWLAN.dct- Cisco Wireless Lan Controllers
# (See README.DCT for more details on the format of this file)
################################################################################
# Dictionary - Cisco WLAN Controllers
# Start with the standard Radius specification attributes
# Standard attributes supported by Airespace
# Define additional vendor specific attributes (VSAs)
MACRO Airespace-VSA(t,s) 26 [vid=14179 type1=%t% len1=+2 data=%s%]
ATTRIBUTE WLAN-Id Airespace-VSA(1, integer) cr
ATTRIBUTE Aire-QoS-Level Airespace-VSA(2, integer) r
VALUE Aire-QoS-Level Bronze 3
VALUE Aire-QoS-Level Silver 0
VALUE Aire-QoS-Level Gold 1
VALUE Aire-QoS-Level Platinum 2
ATTRIBUTE DSCP Airespace-VSA(3, integer) r
ATTRIBUTE 802.1P-Tag Airespace-VSA(4, integer) r
ATTRIBUTE Interface-Name Airespace-VSA(5, string) r
ATTRIBUTE ACL-Name Airespace-VSA(6, string) r
################################################################################
# CiscoWLAN.dct - Cisco WLC dictionary
##############################################################################
Step 3 Open the dictiona.dcm file (in the same directory) and add the line "@ciscowlan.dct."
Step 4 Save and close the dictiona.dcm file.
Step 5 Open the vendor.ini file (in the same directory) and add the following text:
vendor-product = Cisco WLAN Controller
port-number-usage = per-port-type
Step 6 Save and close the vendor.ini file.
Step 7 Start the SBR service (or other RADIUS service).
Step 8 Launch the SBR Administrator (or other RADIUS Administrator).
Step 9 Add a RADIUS client (if not already added). Choose Cisco WLAN Controller from the Make/Model drop-down box.
Using the GUI to Configure AAA Override
Follow these steps to configure AAA override using the controller GUI.
Step 1 Click WLANs to access the WLANs page.
Step 2 Click the profile name of the WLAN that you want to configure. The WLANs > Edit page appears.
Step 3 Click the Advanced tab to access the WLANs > Edit (Advanced) page (see Figure 5-34).
Figure 5-34 WLANs > Edit (Advanced) Page
Step 4 Check the Allow AAA Override check box to enable AAA override or uncheck it to disable this feature. The default value is disabled.
Step 5 Click Apply to commit your changes.
Step 6 Click Save Configuration to save your changes.
Using the CLI to Configure AAA Override
Use this command to enable or disable AAA override using the controller CLI:
config wlan aaa-override {enable | disable} wlan_id
For wlan_id, enter an ID from 1 to 16.
Configuring IDS
The Cisco intrusion detection system/intrusion prevention system (CIDS/IPS) instructs controllers to block certain clients from accessing the wireless network when attacks involving these clients are detected at Layer 3 through Layer 7. This system offers significant network protection by helping to detect, classify, and stop threats including worms, spyware/adware, network viruses, and application abuse. Two methods are available to detect IDS attacks:
•IDS sensors, see below
•IDS signatures, see page 67
Configuring IDS Sensors
You can configure IDS sensors to detect various types of IP-level attacks in your network. When the sensors identify an attack, they can alert the controller to shun the offending client. When you add a new IDS sensor, you register the controller with that IDS sensor so that the controller can query the sensor to get the list of shunned clients. You can configure IDS sensor registration through either the GUI or the CLI.
Using the GUI to Configure IDS Sensors
Follow these steps to configure IDS sensors using the controller GUI.
Step 1 Click Security > CIDs > Sensors to access the CIDS Sensors List page appears (see Figure 5-35).
Figure 5-35 CIDS Sensors List Page
This page lists all of the IDS sensors that have been configured for this controller.
Note If you want to delete an existing sensor, hover your cursor over the blue drop-down arrow for that sensor and choose Remove.
Step 2 To add an IDS sensor to the list, click New. The CIDS Sensor Add page appears (see Figure 5-36).
Figure 5-36 CIDS Sensor Add Page
Step 3 The controller supports up to five IPS sensors. From the Index drop-down box, choose a number (between 1 and 5) to determine the sequence in which the controller consults the IPS sensors. For example, if you choose 1, the controller consults this IPS sensor first.
Step 4 In the Server Address field, enter the IP address of your IDS server.
Step 5 The Port field contains the number of the HTTPS port through which the controller is to communicate with the IDS sensor. Cisco recommends that you set this parameter to 443 because the sensor uses this value to communicate by default.
Default: 443
Range: 1 to 65535
Step 6 In the Username field, enter the name that the controller uses to authenticate to the IDS sensor.
Note This username must be configured on the IDS sensor and have at least a read-only privilege.
Step 7 In the Password and Confirm Password fields, enter the password that the controller uses to authenticate to the IDS sensor.
Step 8 In the Query Interval field, enter the time (in seconds) for how often the controller should query the IDS server for IDS events.
Default: 60 seconds
Range: 10 to 3600 seconds
Step 9 Check the State check box to register the controller with this IDS sensor or uncheck this check box to disable registration. The default value is disabled.
Step 10 Enter a 40-hexadecimal-character security key in the Fingerprint field. This key is used to verify the validity of the sensor and is used to prevent security attacks.
Note Do not include the colons that appear between every two bytes within the key. For example, enter AABBCCDD instead of AA:BB:CC:DD.
Step 11 Click Apply. Your new IDS sensor appears in the list of sensors on the CIDS Sensors List page.
Step 12 Click Save Configuration to save your changes.
Using the CLI to Configure IDS Sensors
Follow these steps to configure IDS sensors using the controller CLI.
Step 1 To add an IDS sensor, enter this command:
config wps cids-sensor add index ids_ip_address username password
The index parameter determines the sequence in which the controller consults the IPS sensors. The controller supports up to five IPS sensors. Enter a number (between 1 and 5) to determine the priority of this sensor. For example, if you enter 1, the controller consults this IPS sensor first.
Note The username must be configured on the IDS sensor and have at least a read-only privilege.
Step 2 (Optional) To specify the number of the HTTPS port through which the controller is to communicate with the IDS sensor, enter this command:
config wps cids-sensor port index port_number
For the port-number parameter, you can enter a value between 1 and 65535. The default value is 443. This step is optional because Cisco recommends that you use the default value of 443. The sensor uses this value to communicate by default.
Step 3 To specify how often the controller should query the IDS server for IDS events, enter this command:
config wps cids-sensor interval index interval
For the interval parameter, you can enter a value between 10 and 3600 seconds. The default value is 60 seconds.
Step 4 To enter a 40-hexadecimal-character security key used to verify the validity of the sensor, enter this command:
config wps cids-sensor fingerprint index sha1 fingerprint
You can get the value of the fingerprint by entering show tls fingerprint on the sensor's console.
Note Make sure to include the colons that appear between every two bytes within the key (for example, AA:BB:CC:DD).
Step 5 To enable or disable this controller's registration with an IDS sensor, enter this command:
config wps cids-sensor {enable | disable} index
Step 6 To save your settings, enter this command:
save config
Step 7 To view the IDS sensor configuration, enter one of these commands:
•show wps cids-sensor summary
•show wps cids-sensor detail index
The second command provides more information than the first.
Step 8 To obtain debug information regarding IDS sensor configuration, enter this command:
debug wps cids enable
Note If you ever want to delete or change the configuration of a sensor, you must first disable it by entering config wps cids-sensor disable index. To then delete the sensor, enter config wps cids-sensor delete index.
Viewing Shunned Clients
When an IDS sensor detects a suspicious client, it alerts the controller to shun this client. The shun entry is distributed to all controllers within the same mobility group. If the client to be shunned is currently joined to a controller in this mobility group, the anchor controller adds this client to the dynamic exclusion list, and the foreign controller removes the client. The next time the client tries to connect to a controller, the anchor controller rejects the handoff and informs the foreign controller that the client is being excluded. See Chapter 11, for more information on mobility groups.
You can view the list of clients that the IDS sensors have identified to be shunned through either the GUI or the CLI.
Using the GUI to View Shunned Clients
Follow these steps to view the list of clients that the IDS sensors have identified to be shunned using the controller GUI.
Step 1 Click Security > CIDS > Shunned Clients. The CIDS Shun List page appears (see Figure 5-37).
Figure 5-37 CIDS Shun List Page
This page shows the IP address and MAC address of each shunned client, the length of time that the client's data packets should be blocked by the controller as requested by the IDS sensor, and the IP address of the IDS sensor that discovered the client.
Step 2 Click Re-sync to purge and reset the list as desired.
Using the CLI to View Shunned Clients
Follow these steps to view the list of clients that the IDS sensors have identified to be shunned using the controller CLI.
Step 1 To view the list of clients to be shunned, enter this command:
show wps shun-list
Step 2 To force the controller to sync up with other controllers in the mobility group for the shun list, enter this command:
config wps shun-list re-sync
Configuring IDS Signatures
You can configure IDS signatures, or bit-pattern matching rules used to identify various types of attacks in incoming 802.11 packets, on the controller. When the signatures are enabled, the access points joined to the controller perform signature analysis on the received 802.11 data or management frames and report any discrepancies to the controller.
A standard signature file exists on the controller by default. You can upload this signature file from the controller, or you can create a custom signature file and download it to the controller or modify the standard signature file to create a custom signature. You can configure signatures through either the GUI or the CLI.
Using the GUI to Configure IDS Signatures
You must follow these instructions to configure signatures using the controller GUI:
•Uploading or downloading IDS signatures, page 67
•Enabling or disabling IDS signatures, page 69
•Viewing IDS signature events, page 71
Using the GUI to Upload or Download IDS Signatures
Follow these steps to upload or download IDS signatures using the controller GUI.
Step 1 If desired, create your own custom signature file.
Step 2 Make sure that you have a Trivial File Transfer Protocol (TFTP) server available. Keep these guidelines in mind when setting up a TFTP server:
•If you are downloading through the service port, the TFTP server must be on the same subnet as the service port because the service port is not routable.
•If you are downloading through the distribution system network port, the TFTP server can be on the same or a different subnet because the distribution system port is routable.
•A third-party TFTP server cannot run on the same computer as the Cisco WCS because the WCS built-in TFTP server and the third-party TFTP server require the same communication port.
Step 3 If you are downloading a custom signature file (*.sig), copy it to the default directory on your TFTP server.
Step 4 Click Commands to access the Download File to Controller page (see Figure 5-38).
Figure 5-38 Download File to Controller Page
Step 5 Perform one of the following:
•If you want to download a custom signature file to the controller, choose Signature File from the File Type drop-down box on the Download File to Controller page.
•If you want to upload a standard signature file from the controller, click Upload File and then choose Signature File from the File Type drop-down box on the Upload File from Controller page.
Step 6 In the IP Address field, enter the IP address of the TFTP server.
Step 7 If you are downloading the signature file, enter the maximum number of times the controller should attempt to download the signature file in the Maximum Retries field.
Range: 1 to 254
Default: 10
Step 8 If you are downloading the signature file, enter the amount of time in seconds before the controller times out while attempting to download the signature file in the Timeout field.
Range: 1 to 254 seconds
Default: 6 seconds
Step 9 In the File Path field, enter the path of the signature file to be downloaded or uploaded. The default value is "/."
Step 10 In the File Name field, enter the name of the signature file to be downloaded or uploaded.
Note When uploading signatures, the controller uses the filename you specify as a base name and then adds "_std.sig" and "_custom.sig" to it in order to upload both standard and custom signature files to the TFTP server. For example, if you upload a signature file called "ids1," the controller automatically generates and uploads both ids1_std.sig and ids1_custom.sig to the TFTP server. If desired, you can then modify ids1_custom.sig on the TFTP server (making sure to set "Revision = custom") and download it by itself.
Step 11 Click Download to download the signature file to the controller or Upload to upload the signature file from the controller.
Using the GUI to Enable or Disable IDS Signatures
Follow these steps to enable or disable IDS signatures using the controller GUI.
Step 1 Click Security > Wireless Protection Policies > Standard Signatures or Custom Signatures. The Standard Signatures page (see Figure 5-39) or the Custom Signatures page appears.
Figure 5-39 Standard Signatures Page
The Standard Signatures page shows the list of Cisco-supplied signatures that are currently on the controller. The Custom Signatures page shows the list of customer-supplied signatures that are currently on the controller. This page shows the following information for each signature:
•The order, or precedence, in which the controller performs the signature checks.
•The name of the signature, which specifies the type of attack that the signature is trying to detect.
•The frame type on which the signature is looking for a security attack. The possible frame types are data and management.
•The action that the controller is directed to take when the signature detects an attack. The possible action are None and Report.
•The state of the signature, which indicates whether the signature is enabled to detect security attacks.
•A description of the type of attack that the signature is trying to detect.
Step 2 Perform one of the following:
•If you want to allow all signatures (both standard and custom) whose individual states are set to Enabled to remain enabled, check the Enable Check for All Standard and Custom Signatures check box at the top of either the Standard Signatures page or the Custom Signatures page. The default value is enabled (or checked). When the signatures are enabled, the access points joined to the controller perform signature analysis on the received 802.11 data or management frames and report any discrepancies to the controller.
•If you want to disable all signatures (both standard and custom) on the controller, uncheck the Enable Check for All Standard and Custom Signatures check box. If you uncheck this check box, all signatures are disabled, even the ones whose individual states are set to Enabled.
Step 3 Click Apply to commit your changes.
Step 4 To enable or disable an individual signature, click the precedence number of the desired signature. The Signature > Detail page appears (see Figure 5-40).
Figure 5-40 Signature > Detail Page
This page shows much of the same information as the Standard Signatures and Custom Signatures pages but provides these additional details:
•The measurement interval, or the number of seconds that must elapse before the controller resets the signature threshold counters
•The tracking method used by the access points to perform signature analysis and report the results to the controller. The possible values are:
–Per Signature—Signature analysis and pattern matching are tracked and reported on a per-signature and per-channel basis.
–Per MAC—Signature analysis and pattern matching are tracked and reported separately for individual client MAC addresses on a per-channel basis.
–Per Signature and MAC—Signature analysis and pattern matching are tracked and reported on a per-signature and per-channel basis as well as on a per-MAC-address and per-channel basis.
•The signature frequency, or the number of matching packets per second that must be identified at the individual access point level before an attack is detected
•The signature MAC frequency, or the number of matching packets per second that must be identified per client per access point before an attack is detected
•The quiet time, or the length of time (in seconds) after which no attacks have been detected at the individual access point level and the alarm can stop
•The pattern that is being used to detect a security attack
Step 5 Check the State check box to enable this signature to detect security attacks or uncheck it to disable this signature. The default value is enabled (or checked).
Step 6 Click Apply to commit your changes. The Standard Signatures or Custom Signatures page reflects the signature's updated state.
Step 7 Click Save Configuration to save your changes.
Using the GUI to View IDS Signature Events
Follow these steps to view signature events using the controller GUI.
Step 1 Click Security > Wireless Protection Policies > Signature Events Summary. The Signature Events Summary page appears (see Figure 5-41).
Figure 5-41 Signature Events Summary Page
This page shows the number of attacks detected by the enabled signatures.
Step 2 To see more information on the attacks detected by a particular signature, click the signature type link for that signature. The Signature Events Detail page appears (see Figure 5-42).
Figure 5-42 Signature Events Detail Page
This page shows the following information:
•The MAC addresses of the clients identified as attackers
•The method used by the access point to track the attacks
•The number of matching packets per second that were identified before an attack was detected
•The number of access points on the channel on which the attack was detected
•The day and time when the access point detected the attack
Step 3 To see more information for a particular attack, click the Detail link for that attack. The Signature Events Track Detail page appears (see Figure 5-43).
Figure 5-43 Signature Events Track Detail Page
This page shows the following information:
•The MAC address of the access point that detected the attack
•The name of the access point that detected the attack
•The type of radio (802.11a or 802.11b/g) used by the access point to detect the attack
•The radio channel on which the attack was detected
•The day and time when the access point reported the attack
Using the CLI to Configure IDS Signatures
Follow these steps to configure IDS signatures using the controller CLI.
Step 1 If desired, create your own custom signature file.
Step 2 Make sure that you have a TFTP server available. See the guidelines for setting up a TFTP server in Step 2 of the "Using the GUI to Upload or Download IDS Signatures" section.
Step 3 Copy the custom signature file (*.sig) to the default directory on your TFTP server.
Step 4 To specify the download or upload mode, enter transfer {download | upload} mode tftp.
Step 5 To specify the type of file to be downloaded or uploaded, enter transfer {download | upload} datatype signature.
Step 6 To specify the IP address of the TFTP server, enter transfer {download | upload} serverip tftp-server-ip-address.
Note Some TFTP servers require only a forward slash (/) as the TFTP server IP address, and the TFTP server automatically determines the path to the correct directory.
Step 7 To specify the download or upload path, enter transfer {download | upload} path absolute-tftp-server-path-to-file.
Step 8 To specify the file to be downloaded or uploaded, enter transfer {download | upload} filename filename.sig.
Note When uploading signatures, the controller uses the filename you specify as a base name and then adds "_std.sig" and "_custom.sig" to it in order to upload both standard and custom signature files to the TFTP server. For example, if you upload a signature file called "ids1," the controller automatically generates and uploads both ids1_std.sig and ids1_custom.sig to the TFTP server. If desired, you can then modify ids1_custom.sig on the TFTP server (making sure to set "Revision = custom") and download it by itself.
Step 9 Enter transfer {download | upload} start and answer y to the prompt to confirm the current settings and start the download or upload.
Step 10 To enable or disable individual signatures, enter this command:
config wps signature {standard | custom} state precedence# {enable | disable}
Step 11 To save your changes, enter this command:
save config
Using the CLI to View IDS Signature Events
Use these commands to view signature events using the controller CLI.
1. To see all of the standard and custom signatures installed on the controller, enter this command:
show wps signature summary
2. To see the number of attacks detected by the enabled signatures, enter this command:
show wps signature events summary
Information similar to the following appears:
Precedence Signature Name Type No. Events
---------- ------------------ ----- -----------
1 Bcast deauth Standard 2
2 NULL probe resp 1 Standard 1
3. To see more information on the attacks detected by a particular standard or custom signature, enter this command:
show wps signature events {standard | custom} precedence# summary
Information similar to the following appears:
Precedence....................................... 1
Signature Name................................... Bcast deauth
Type............................................. Standard
Number of active events....................... 2
Source MAC Addr Track Method Frequency No. APs Last Heard
----------------- ------------ --------- -------- ------------------------
00:01:02:03:04:01 Per Signature 4 3 Tue Dec 6 00:17:44 2005
00:01:02:03:04:01 Per Mac 6 2 Tue Dec 6 00:30:04 2005
4. To see information on attacks that are tracked by access points on a per-signature and per-channel basis, enter this command:
show wps signature events {standard | custom} precedence# detailed per-signature source_mac
5. To see information on attacks that are tracked by access points on an individual-client basis (by MAC address), enter this command:
show wps signature events {standard | custom} precedence# detailed per-mac source_mac
Information similar to the following appears:
Source MAC....................................... 00:01:02:03:04:01
Precedence....................................... 1
Signature Name................................... Bcast deauth
Type............................................. Standard
Track............................................ Per Mac
Frequency........................................ 6
MAC Address.............................. 00:0b:85:01:4d:80
Name..................................... Test_AP_1
Radio Type............................... 802.11bg
Channel.................................. 4
Last reported by this AP................. Tue Dec 6 00:17:49 2005
MAC Address.............................. 00:0b:85:26:91:52
Name..................................... Test_AP_2
Radio Type............................... 802.11bg
Channel.................................. 6
Last reported by this AP................. Tue Dec 6 00:30:04 2005
Configuring AES Key Wrap
You can use the GUI or CLI to configure a controller to use AES key wrap, which makes the shared secret between the controller and the RADIUS server more secure. AES key wrap is designed for Federal Information Processing Standards (FIPS) customers and requires a key-wrap compliant RADIUS authentication server.
Using the GUI to Configure AES Key Wrap
Follow these steps to configure a controller to use AES key wrap using the GUI.
Step 1 Click Security > AAA > RADIUS > Authentication to access the RADIUS Authentication Servers page (see Figure 5-44).
Figure 5-44 RADIUS Authentication Servers Page
Step 2 To enable RADIUS-to-controller key transport using AES key wrap protection, check the Use AES Key Wrap check box. The default value is unchecked.
Step 3 Click Apply to commit your changes.
Step 4 To define an AES key wrap key for a specific RADIUS server, follow these steps:
a. Click New to configure a new RADIUS authentication server or click the server index number of an existing RADIUS server.
b. Check the Key Wrap check box (see Figure 5-45).
Figure 5-45 RADIUS Authentication Servers > New Page
c. Choose ASCII or Hex from the Key Wrap Format drop-down box to specify the format of the AES key wrap keys: Key Encryption Key (KEK) and Message Authentication Code Key (MACK).
d. Enter the 16-byte KEK in the Key Encryption Key (KEK) field.
e. Enter the 20-byte KEK in the Message Authentication Code Key (MACK) field.
f. Click Apply to commit your changes.
Step 5 Click Save Configuration to save your changes.
Using the CLI to Configure AES Key Wrap
Follow these steps to configure a controller to use AES key wrap using the CLI.
Step 1 To enable or disable the use of AES key wrap attributes, enter this command:
config radius auth keywrap {enable | disable}
Step 2 To configure AES key wrap attributes, enter this command:
config radius auth keywrap add {ascii | hex} index
The index attribute specifies the index of the RADIUS authentication server on which to configure the AES key wrap.
Configuring Maximum Local Database Entries
You can use the controller GUI or CLI to specify the maximum local database entries used for storing user authentication information. The information in the database is used in conjunction with the controller's web authentication feature.
Using the GUI to Configure Maximum Local Database Entries
Follow these steps to configure a controller to use the maximum local database entries using the GUI.
Step 1 Click Security > AAA > General to access the General page (see Figure 5-46).
Figure 5-46 General Page
Step 2 Enter the desired maximum value (on the next controller reboot) in the Maximum Local Database Entries field. The range of possible values is 512 to 2048 (which also includes any configured MAC filter entries). The default value is 2048. The current value appears in parentheses to the right of the field.
Step 3 Click Apply to commit your changes.
Step 4 Click Save Configuration to save your settings.
Using the CLI to Specify the Maximum Number of Local Database Entries
To configure the maximum number of local database entries using the CLI, enter this command:
config database size max_entries
