Cisco Wireless LAN Controller Configuration Guide, Release 6.0

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 CAPWAP 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.

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 RADIUS on the ACS

Follow these steps to configure RADIUS on the ACS.

Note RADIUS 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 Choose Network Configuration on the ACS main page.

Step 2 Choose 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 RADIUS (Cisco Aironet) from the Authenticate Using drop-down box.

Step 7 Click Submit + Apply to save your changes.

Step 8 Choose Interface Configuration on the ACS main page.

Step 9 Choose RADIUS (Cisco Aironet) . The RADIUS (Cisco Aironet) page appears.

Step 10 Under User Group, check the Cisco-Aironet-Session-Timeout check box.

Step 11 Click Submit to save your changes.

Step 12 Choose System Configuration on the ACS main page.

Step 13 Choose Logging .

Step 14 When the Logging Configuration page appears, enable all of the events that you want to be logged and save your changes.

Step 15 Choose Group Setup on the ACS main page.

Step 16 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 17 Click Edit Settings . The Group Setup page appears.

Step 18 Under Cisco Aironet Attributes , check the Cisco-Aironet-Session-Timeout check box and enter a session timeout value in the edit box.

Step 19 To specify read-only or read-write access to controllers through RADIUS authentication, set the Service-Type attribute (006) to Callback NAS Prompt for read-only access or to Administrative for read-write privileges. If you do not set this attribute, the authentication process completes successfully (without an authorization error on the controller), but you might be prompted to authenticate again.

Note If you set the Service-Type attribute on the ACS, make sure to check the Management check box on the RADIUS Authentication Servers page of the controller GUI. See If you are configuring a RADIUS authentication server, check the Management check box to enable management authentication, or uncheck it to disable this feature. The default value is checked. If you enable this feature, this entry is considered the RADIUS authentication server for management users, and authentication requests go to the RADIUS server. in the next section for more information.

Note The “RADIUS Authentication Attributes Sent by the Access Point” section lists the RADIUS attributes that are sent by a lightweight access point to a client in access-request and access-accept packets.

Step 20 Click Submit to save your changes.

Using the GUI to Configure RADIUS

Using the controller GUI, follow these steps to configure RADIUS.

Step 1 Choose Security > AAA > RADIUS .

Step 2 Perform one of the following:

• If you want to configure a RADIUS server for authentication, choose Authentication .
• If you want to configure a RADIUS server for accounting, choose Accounting .

Note The GUI pages used to configure authentication and accounting contain mostly 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 RADIUS Authentication (or Accounting) Servers page appears (see Figure 5-2).

Figure 5-2 RADIUS Authentication Servers Page

This page lists any RADIUS 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 From the Call Station ID Type drop-down box, choose IP Address , System MAC Address , or AP MAC Address to specify whether the IP address, system MAC address, or AP MAC address of the originator will be sent to the RADIUS server in the Access-Request message.

Step 4 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. This feature is required for FIPS customers.

Step 5 Click Apply to commit your changes.

Step 6 Perform one of the following:

• To edit an existing RADIUS server, click the server index number for that server. The RADIUS Authentication (or Accounting) Servers > Edit page appears.
• To add a RADIUS server, click New . The RADIUS Authentication (or Accounting) Servers > New page appears (see Figure 5-3).

Figure 5-3 RADIUS Authentication Servers > New Page

Step 7 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 RADIUS servers providing the same service. You can configure up to 17 servers. If the controller cannot reach the first server, it tries the second one in the list, then the third one if necessary, and so on.

Step 8 If you are adding a new server, enter the IP address of the RADIUS server in the Server IP Address field.

Step 9 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 RADIUS server. The default value is ASCII.

Step 10 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 11 If you are configuring a new RADIUS authentication server and want to enable AES key wrap, which makes the shared secret between the controller and the RADIUS server more secure, follow these steps. AES key wrap is designed for Federal Information Processing Standards (FIPS) customers and requires a key-wrap compliant RADIUS authentication server.

a. Check the Key Wrap check box.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).

b. In the Key Encryption Key (KEK) field, enter the 16-byte KEK.

c. In the Message Authentication Code Key (MACK) field, enter the 20-byte KEK.

Step 12 If you are adding a new server, enter the RADIUS server’s UDP port number for the interface protocols in the Port Number field. The valid range is 1 to 65535, and the default value is 1812 for authentication and 1813 for accounting.

Step 13 From the Server Status field, choose Enabled to enable this RADIUS server or choose Disabled to disable it. The default value is Enabled.

Step 14 If you are configuring a new RADIUS authentication server, choose Enabled from the Support for RFC 3576 drop-down box to enable RFC 3576, which is an extension to the RADIUS protocol that allows dynamic changes to a user session, or choose Disabled to disable this feature. The default value is Enabled. RFC 3576 includes support for disconnecting users and changing authorizations applicable to a user session and supports disconnect and change-of-authorization (CoA) messages). Disconnect messages cause a user session to be terminated immediately whereas CoA messages modify session authorization attributes such as data filters.

Step 15 In the Server 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 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 16 Check the Network User check box to enable network user authentication (or accounting), or uncheck it to disable this feature. The default value is checked. If you enable this feature, this entry is considered the RADIUS authentication (or accounting) server for network users. If you did not configure a RADIUS server entry on the WLAN, you must enable this option for network users.

Step 17 If you are configuring a RADIUS authentication server, check the Management check box to enable management authentication, or uncheck it to disable this feature. The default value is checked. If you enable this feature, this entry is considered the RADIUS authentication server for management users, and authentication requests go to the RADIUS server.

Step 18 Check the IPSec check box to enable the IP security mechanism, or uncheck it to disable this feature. The default value is unchecked.

Note The IPSec option appears only if a crypto card is installed in the controller.

Step 19 If you enabled IPSec in Check the IPSec check box to enable the IP security mechanism, or uncheck it to disable this feature. The default value is unchecked. , follow these steps to configure additional IPSec parameters:

a. From the IPSec drop-down box, choose one of the following options as the authentication protocol to be used for IP security: HMAC MD5 or HMAC SHA1 . The default value is HMAC SHA1.

A message authentication code (MAC) is used between two parties that share a secret key to validate information transmitted between them. HMAC (Hash MAC) is a mechanism based on cryptographic hash functions. It can be used in combination with any iterated cryptographic hash function. HMAC MD5 and HMAC SHA1 are two constructs of the HMAC using the MD5 hash function and the SHA1 hash function. HMAC also uses a secret key for calculation and verification of the message authentication values.

b. From the IPSec Encryption drop-down box, choose one of the following options to specify the IP security encryption mechanism:

• DES —Data Encryption Standard is a method of data encryption using a private (secret) key. DES applies a 56-bit key to each 64-bit block of data.
• 3DES —Data Encryption Standard that applies three keys in succession. This is the default value.
• AES CBS —Advanced Encryption Standard uses keys with a length of 128, 192, or 256 bits to encrypt data blocks with a length of 128, 192, or 256 bits. AES 128 CBC uses a 128-bit data path in Cipher Clock Chaining (CBC) mode.

c. From the IKE Phase 1 drop-down box, choose one of the following options to specify the Internet Key Exchange (IKE) protocol: Aggressive or Main . The default value is Aggressive.

IKE Phase 1 is used to negotiate how IKE should be protected. Aggressive mode passes more information in fewer packets with the benefit of slightly faster connection establishment at the cost of transmitting the identities of the security gateways in the clear.

d. In the Lifetime field, enter a value (in seconds) to specify the timeout interval for the session. The valid range is 1800 to 57600 seconds, and the default value is 1800 seconds.

e. From the IKE Diffie Hellman Group drop-down box, choose one of the following options to specify the IKE Diffie Hellman group: Group 1 (768 bits) , Group 2 (1024 bits) , or Group 5 (1536 bits) . The default value is Group 1 (768 bits).

Diffie-Hellman techniques are used by two devices to generate a symmetric key through which they can publicly exchange values and generate the same symmetric key. Although all three groups provide security from conventional attacks, Group 5 is considered more secure because of its larger key size. However, computations involving Group 1 and Group 2 based keys might occur slightly faster because of their smaller prime number size.

Step 20 Click Apply to commit your changes.

Step 21 Click Save Configuration to save your changes.

Step 22 Repeat the previous steps if you want to configure any additional services on the same server or any additional RADIUS servers.

Step 23 To specify the RADIUS server fallback behavior, follow these steps:

a. Choose Security > AAA > RADIUS > Fallback to open the RADIUS > Fallback Parameters page (see Figure 5-4).

Figure 5-4 RADIUS > Fallback Parameters Page

b. From the Fallback Mode drop-down box, choose one of the following options:

• Off —Disables RADIUS server fallback. This is the default value.
• Passive —Causes the controller to revert to a server with a lower priority from the available backup servers without using extraneous probe messages. The controller simply ignores all inactive servers for a time period and retries later when a RADIUS message needs to be sent.
• Active —Causes the controller to revert to a server with a lower priority from the available backup servers by using RADIUS probe messages to proactively determine whether a server that has been marked inactive is back online. The controller simply ignores all inactive servers for all active RADIUS requests. Once the primary server receives a response from the recovered ACS server, the active fallback RADIUS server no longer sends probe messages to the server requesting the active probe authentication.

c. If you enabled Active fallback mode in From the Fallback Mode drop-down box, choose one of the following options: , enter the name to be sent in the inactive server probes in the Username field. You can enter up to 16 alphanumeric characters. The default value is “cisco-probe.”

d. If you enabled Active fallback mode in From the Fallback Mode drop-down box, choose one of the following options: , enter the probe interval value (in seconds) in the Interval in Sec field. The interval serves as inactive time in passive mode and probe interval in active mode. The valid range is 180 to 3600 seconds, and the default value is 300 seconds.

Step 24 To specify the order of authentication when multiple databases are configured, choose Security > Priority Order > Management User . The Priority Order > Management User page appears (see Figure 5-5).

Figure 5-5 Priority Order > Management User Page

Step 25 In the Order Used for Authentication field, specify which servers have priority when the controller attempts to authenticate management users. Use the > and < buttons to move servers between the Not Used and Order Used for Authentication fields. After the desired servers appear in the Order Used for Authentication field, use the Up and Down buttons to move the priority server to the top of the list.

By default, the local database is always queried first. If the username is not found, the controller switches to the RADIUS server if configured for RADIUS or to the TACACS+ server if configured for TACACS+. The default setting is local and then RADIUS.

Step 26 Click Apply to commit your changes.

Step 27 Click Save Configuration to save your changes.

Using the CLI to Configure RADIUS

Using the controller CLI, follow these steps to configure RADIUS.

Note Refer to the “Using the GUI to Configure RADIUS” section for the valid ranges and default values of the parameters used in the CLI commands.

Step 1 To specify whether the IP address, system MAC address, or AP MAC address of the originator will be sent to the RADIUS server in the Access-Request message, enter this command:

config radius callStationIdType { ip_address, mac_address, ap_mac_address, ap_macaddr_ssid }

Step 2 To specify the delimiter to be used in the MAC addresses that are sent to the RADIUS authentication or accounting server in Access-Request messages, enter this command:

config radius { auth | acct } mac-delimiter {colon | hyphen | single-hyphen | none }

where

• colon sets the delimiter to a colon (the format is xx:xx:xx:xx:xx:xx).
• hyphen sets the delimiter to a hyphen (the format is xx-xx-xx-xx-xx-xx). This is the default value.
• single-hyphen sets the delimiter to a single hyphen (the format is xxxxxx-xxxxxx).
• none disables delimiters (the format is xxxxxxxxxxxx).

Step 3 Use these commands to configure a RADIUS authentication server:

• config radius auth add index server_ip_address port# { ascii | hex } shared_secret —Adds a RADIUS authentication server.
• config radius auth keywrap {enable | disable } — Enables 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.
• config radius auth keywrap add {ascii | hex } kek mack index— Configures the AES key wrap attributes where

– kek specifies the 16-byte Key Encryption Key (KEK).

– mack specifies the 20-byte Message Authentication Code Key (MACK).

– index specifies the index of the RADIUS authentication server on which to configure the AES key wrap.

• config radius auth rfc3576 {enable | disable } index —Enables or disables RFC 3576, which is an extension to the RADIUS protocol that allows dynamic changes to a user session. RFC 3576 includes support for disconnecting users and changing authorizations applicable to a user session and supports disconnect and change-of-authorization (CoA) messages). Disconnect messages cause a user session to be terminated immediately whereas CoA messages modify session authorization attributes such as data filters.
• config radius auth retransmit-timeout index timeout —Configures the retransmission timeout value for a RADIUS authentication server.
• config radius auth network index {enable | disable }—Enables or disables network user authentication. If you enable this feature, this entry is considered the RADIUS authentication server for network users. If you did not configure a RADIUS server entry on the WLAN, you must enable this option for network users.
• config radius auth management index {enable | disable }—Enables or disables management authentication. If you enable this feature, this entry is considered the RADIUS authentication server for management users, and authentication requests go to the RADIUS server.
• config radius auth ipsec { enable | disable } index —Enables or disables the IP security mechanism.
• config radius auth ipsec authentication { hmac-md5 | hmac-sha1 } index —Configures the authentication protocol to be used for IP security.
• config radius auth ipsec encryption { 3des | aes | des | none } index —Configures the IP security encryption mechanism.
• config radius auth ipsec ike dh-group { group-1 | group-2 | group-5 } index —Configures the IKE Diffie Hellman group.
• config radius auth ipsec ike lifetime interval index —Configures the timeout interval for the session.
• config radius auth ipsec ike phase1 { aggressive | main } index —Configures the Internet Key Exchange (IKE) protocol.
• config radius auth { enable | disable } index —Enables or disables a RADIUS authentication server.
• config radius auth delete index —Deletes a previously added RADIUS authentication server.

Step 4 Use these commands to configure a RADIUS accounting server:

• config radius acct add index server_ip_address port# { ascii | hex } shared_secret —Adds a RADIUS accounting server.
• config radius acct server-timeout index timeout —Configures the retransmission timeout value for a RADIUS accounting server.
• config radius acct network index {enable | disable }—Enables or disables network user accounting. If you enable this feature, this entry is considered the RADIUS accounting server for network users. If you did not configure a RADIUS server entry on the WLAN, you must enable this option for network users.
• config radius acct ipsec { enable | disable } index —Enables or disables the IP security mechanism.
• config radius acct ipsec authentication { hmac-md5 | hmac-sha1 } index —Configures the authentication protocol to be used for IP security.
• config radius acct ipsec encryption { 3des | aes | des | none } index —Configures the IP security encryption mechanism.
• config radius acct ipsec ike dh-group { group-1 | group-2 | group-5 } index —Configures the IKE Diffie Hellman group.
• config radius acct ipsec ike lifetime interval index —Configures the timeout interval for the session.
• config radius acct ipsec ike phase1 { aggressive | main } index —Configures the Internet Key Exchange (IKE) protocol.
• config radius acct { enable | disable } index —Enables or disables a RADIUS accounting server.
• config radius acct delete index —Deletes a previously added RADIUS accounting server.

Step 5 To configure the RADIUS server fallback behavior, enter this command:

config radius fallback-test mode {off | passive | active}

where

• Off disables RADIUS server fallback.
• Passive causes the controller to revert to a server with a lower priority from the available backup servers without using extraneous probe messages. The controller simply ignores all inactive servers for a time period and retries later when a RADIUS message needs to be sent.
• Active causes the controller to revert to a server with a lower priority from the available backup servers by using RADIUS probe messages to proactively determine whether a server that has been marked inactive is back online. The controller simply ignores all inactive servers for all active RADIUS requests. Once the primary server receives a response from the recovered ACS server, the active fallback RADIUS server no longer sends probe messages to the server requesting the active probe authentication.

Step 6 If you enabled Active mode in To configure the RADIUS server fallback behavior, enter this command: , enter these commands to configure additional fallback parameters:

• config radius fallback-test username username — Specifies the name to be sent in the inactive server probes. You can enter up to 16 alphanumeric characters for the username parameter .
• config radius fallback-test interval interval — Specifies the probe interval value (in seconds).

Step 7 To save your changes, enter this command:

save config

Step 8 To configure the order of authentication when multiple databases are configured, enter this command:

config aaa auth mgmt AAA_server_type AAA_server_type

where AAA_server_type is local, radius, or tacacs.

To see the current management authentication server order, enter this command:

show aaa auth

Information similar to the following appears:

Step 9 Use these commands to see RADIUS statistics:

• show radius summary —Shows a summary of RADIUS servers and statistics.
• show radius auth statistics —Shows the RADIUS authentication server statistics.
• show radius acct statistics —Shows the RADIUS accounting server statistics.
• show radius rfc3576 statistics —Shows a summary of the RADIUS RFC-3576 server.

Information similar to the following appears for the show radius auth statistics command:

Information similar to the following appears for the show radius acct statistics command:

Information similar to the following appears for the show radius rfc3576 statistics command:

Step 10 Use these commands to see active security associations:

• show ike {brief | detailed} ip_or_mac_addr —Shows a brief or detailed summary of active Internet Key Exchange (IKE) security associations.
• show ipsec {brief | detailed} ip_or_mac_addr —Shows a brief or detailed summary of active Internet Protocol Security (IPSec) security associations.

Step 11 To clear the statistics for one or more RADIUS servers, enter this command:

clear stats radius { auth | acct} { index | all }

Step 12 To make sure the controller can reach the RADIUS server, enter this command:

ping server_ip_address

RADIUS Authentication Attributes Sent by the Access Point

The tables in this section identify the RADIUS authentication attributes sent by a lightweight access point to a client in access-request and access-accept packets.

Note These Cisco-specific attributes are not supported: Auth-Algo-Type and SSID.

Note Message authenticator is not supported.

RADIUS Accounting Attributes

Table 5-6 identifies the RADIUS accounting attributes for accounting requests sent from a controller to the RADIUS server. Table 5-7 lists the different values for the Accounting-Status-Type attribute (40).

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 Choose Network Configuration on the ACS main page.

Step 2 Choose Add Entry under AAA Clients to add your controller to the server. The Add AAA Client page appears (see Figure 5-6).

Figure 5-6 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 Choose Interface Configuration on the ACS main page.

Step 9 Choose TACACS+ (Cisco IOS) . The TACACS+ (Cisco) page appears (see Figure 5-7).

Figure 5-7 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 Choose System Configuration on the ACS main page.

Step 15 Choose 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 Choose 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-8).

Figure 5-8 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:

role x = 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 Choose Security > AAA > TACACS+ .

Step 2 Perform one of the following:

• If you want to configure a TACACS+ server for authentication, choose Authentication .
• If you want to configure a TACACS+ server for authorization, choose Authorization .
• If you want to configure a TACACS+ server for accounting, choose 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.

Note For basic management authentication via TACACS+ to succeed, it is required to configure authentication and authorization servers on the WLC. Accounting configuration is optional.

The TACACS+ (Authentication, Authorization, or Accounting) Servers page appears (see Figure 5-9).

Figure 5-9 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-10).

Figure 5-10 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 Server Timeout field, enter the number of seconds between retransmissions. The valid range is 5 to 30 seconds, and the default value is 5 seconds.

Note Cisco recommends that you increase the 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, choose Security > Priority Order > Management User . The Priority Order > Management User page appears (see Figure 5-11).

Figure 5-11 Priority Order > Management User Page

Step 15 In the Order Used for Authentication field, specify which servers have priority when the controller attempts to authenticate management users. Use the > and < buttons to move servers between the Not Used and Order Used for Authentication fields. After the desired servers appear in the Order Used for Authentication field, use the Up and Down buttons to move the priority server to the top of the list.

By default, the local database is always queried first. If the username is not found, the controller switches to the RADIUS server if configured for RADIUS or to the TACACS+ server if configured for TACACS+. 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 server-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 server-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 server-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:

Information similar to the following appears for the show tacacs auth stats command:

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:

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 Choose Reports and Activity on the ACS main page.

Step 2 Choose 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-12).

Figure 5-12 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-13.

Figure 5-13 TACACS+ Administration .csv Page on CiscoSecure ACS

Note You can click Refresh at any time to refresh this page.

Using the GUI to Configure Maximum Local Database Entries

Using the controller GUI, follow these steps to configure the maximum number of local database entries.

Step 1 Choose Security > AAA > General to open the General page (see Figure 5-14).

Figure 5-14 General Page

Step 2 In the Maximum Local Database Entries field, enter a value for the maximum number of entries that can be added to the local 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 2048.

The Number of Entries, Already Used field shows the number of entries currently in the database.

Step 3 Click Apply to commit your changes.

Step 4 Click Save Configuration to save your settings.

Using the CLI to Configure Maximum Local Database Entries

Using the controller CLI, follow these steps to configure the maximum number of local database entries.

Step 1 To specify the maximum number of entries that can be added to the local database the next time the controller reboots, enter this command:

config database size max_entries

Step 2 To save your changes, enter this command:

save config

Step 3 To view the maximum number of database entries and the current database contents, enter this command:

show database summary

Information similar to the following appears:

Using the GUI to Configure Local Network Users

Follow these steps to configure local network users using the controller GUI.

Step 1 Choose Security > AAA > Local Net Users to open the Local Net Users page (see Figure 5-15).

Figure 5-15 Local Net Users Page

This page lists any local network users that have already been configured. It also specifies any guest users and the QoS role to which they are assigned (if applicable). See the “Configuring Quality of Service Roles” section for information on configuring QoS roles.

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 2 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-16).

Figure 5-16 Local Net Users > New Page

Step 3 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 4 In the Password and Confirm Password fields, enter a password for the local user. You can enter up to 24 alphanumeric characters.

Step 5 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 6 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 2,592,000 seconds (30 days) inclusive, and the default setting is 86,400 seconds.

Step 7 If you are adding a new user, you checked the Guest User check box, and you want to assign a QoS role to this guest user, check the Guest User Role check box. The default setting is unchecked.

Note If you do not assign a QoS role to a guest user, the bandwidth contracts for this user are defined in the QoS profile for the WLAN.

Step 8 If you are adding a new user and you checked the Guest User Role check box, choose the QoS role that you want to assign to this guest user from the Role drop-down box.

Note If you want to create a new QoS role, see the “Configuring Quality of Service Roles” section for instructions.

Step 9 From the WLAN Profile drop-down box, choose the name 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 10 In the Description field, enter a descriptive title for the local user (such as “User 1”).

Step 11 Click Apply to commit your changes.

Step 12 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 wlan_id userType permanent description description —Adds a permanent user to the local user database on the controller.
• config netuser add username password { wlan | guestlan} { wlan_id | guest_lan_id} userType guest lifetime seconds description description —Adds a guest user on a WLAN or wired guest LAN to the local user database on the controller.

Note Instead of adding a permanent user or a guest user to the local user database from the controller, you can choose to create an entry on the RADIUS server for the user and enable RADIUS authentication for the WLAN on which web authentication is performed.

• 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:

3. To save your changes, enter this command:

Using the GUI to Configure LDAP

Follow these steps to configure LDAP using the controller GUI.

Step 1 Choose Security > AAA > LDAP to open the LDAP Servers page (see Figure 5-17).

Figure 5-17 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-18).

Figure 5-18 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 Check the Enable Server Status check box to enable this LDAP server or uncheck it to disable it. The default value is disabled.

Step 7 From the Simple Bind drop-down box, choose Anonymous or Authenticated to specify the local authentication bind method for the LDAP server. The Anonymous method allows anonymous access to the LDAP server whereas the Authenticated method requires that a username and password be entered to secure access. The default value is Anonymous.

Step 8 If you chose Authenticated in From the Simple Bind drop-down box, choose Anonymous or Authenticated to specify the local authentication bind method for the LDAP server. The Anonymous method allows anonymous access to the LDAP server whereas the Authenticated method requires that a username and password be entered to secure access. The default value is Anonymous. , follow these steps:

a. In the Bind Username field, enter a username to be used for local authentication to the LDAP server. The username can contain up to 80 characters.

Note If the username starts with “cn=” (in lowercase letters), the controller assumes that the username includes the entire LDAP database path and therefore does not append the user base DN. This designation allows the authenticated bind user to be outside the user base DN.

b. In the Bind Password and Confirm Bind Password fields, enter a password to be used for local authentication to the LDAP server. The password can contain up to 32 characters.

Step 9 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 10 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 11 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 12 In the Server 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 13 Click Apply to commit your changes.

Step 14 Click Save Configuration to save your changes.

Step 15 Follow these steps to specify LDAP as the priority backend database server for local EAP authentication:

a. Choose Security > Local EAP > Authentication Priority to open the Priority Order > Local-Auth page (see Figure 5-19).

Figure 5-19 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 16 (Optional) Follow these steps if you wish to assign specific LDAP servers to a WLAN.

a. Choose WLANs to open the WLANs page.

b. Click the ID number of the desired WLAN.

c. When the WLANs > Edit page appears, choose the Security > AAA Servers tabs to open the WLANs > Edit (Security > AAA Servers) page (see Figure 5-20).

Figure 5-20 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.

Note These LDAP servers apply only to WLANs with web authentication enabled. They are not used by local EAP.

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_base user_attr user_type —
  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 simple-bind { anonymous index | authenticated index username username password password }—Specifies the local authentication bind method for the LDAP server. The anonymous method allows anonymous access to the LDAP server whereas the authenticated method requires that a username and password be entered to secure access. The default value is anonymous.

Note The username can contain up to 80 characters.

Note If the username starts with “cn=” (in lowercase letters), the controller assumes that the username includes the entire LDAP database path and therefore does not append the user base DN. This designation allows the authenticated bind user to be outside the user base DN.

• 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 server_index —Links a configured LDAP server to a WLAN.

Note The LDAP servers specified in this command apply only to WLANs with web authentication enabled. They are not used by local EAP.

• 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 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 index command:

Information similar to the following appears for the show ldap summary command:

Information similar to the following appears for the show ldap statistics command:

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}

Using the GUI to Configure Local EAP

Follow these steps to configure local EAP using the controller GUI.

Step 1 EAP-TLS, P EAPv0/MSCHAPv2, and PEAPv1/GTC use 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 the Managing Controller Software and Configurations chapter 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. Choose Security > Local EAP > Authentication Priority to open the Priority Order > Local-Auth page (see Figure 5-22).

Figure 5-22 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 values for the local EAP timers:

a. Choose Security > Local EAP > General to open the General page (see Figure 5-23).

Figure 5-23 General Page

b. In the Local Auth Active Timeout field, enter the amount of time (in seconds) in which the controller attempts to authenticate wireless clients using local EAP after any pair of configured RADIUS servers fails. The valid range is 1 to 3600 seconds, and the default setting is 100 seconds.

c. In the Identity Request Timeout field, enter the amount of time (in seconds) in which the controller attempts to send an EAP identity request to wireless clients using local EAP. The valid range is 1 to 120 seconds, and the default setting is 30 seconds.

d. In the Identity Request Max Retries field, enter the maximum number of times that the controller attempts to retransmit the EAP identity request to wireless clients using local EAP. The valid range is 1 to 20 retries, and the default setting is 20 retries.

e. In the Dynamic WEP Key Index field, enter the key index used for dynamic wired equivalent privacy (WEP). The default setting is 0.

f. In the Request Timeout field, enter the amount of time (in seconds) in which the controller attempts to send an EAP request to wireless clients using local EAP. The valid range is 1 to 120 seconds, and the default setting is 30 seconds.

g. In the Request Max Retries field, enter the maximum number of times that the controller attempts to retransmit the EAP request to wireless clients using local EAP. The valid range is 1 to 120 retries, and the default setting is 20 retries.

h. From the Max-Login Ignore Identity Response drop-down box, choose Enable to limit the number of devices that can be connected to the controller with the same username. You can log in up to eight times from different devices (PDA, laptop, IP phone, and so on) on the same controller. The default value is enabled.

i. In the EAPOL-Key Timeout field, enter the amount of time (in seconds) in which the controller attempts to send an EAP key over the LAN to wireless clients using local EAP. The valid range is 1 to 5 seconds, and the default setting is 1 second.

j. In the EAPOL-Key Max Retries field, enter the maximum number of times that the controller attempts to send an EAP key over the LAN to wireless clients using local EAP. The valid range is 0 to 4 retries, and the default setting is 2 retries.

k. 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. Choose Security > Local EAP > Profiles to open the Local EAP Profiles page (see Figure 5-24).

Figure 5-24 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 open 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-25).

Figure 5-25 Local EAP Profiles > Edit Page

e. Check the LEAP , EAP-FAST , EAP-TLS, and/or PEAP 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 choose multiple EAP types that use certificates (such as EAP-FAST with certificates, EAP-TLS, PEAPv0/MSCHAPv2, and PEAPv1/GTC), all of the EAP types must use the same certificate (from either Cisco or another vendor).

Note If you check the PEAP check box, both PEAPv0/MSCHAPv2 or PEAPv1/GTC are enabled on the controller.

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 device certificates are not used with LEAP and are mandatory for EAP-TLS and PEAP.

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 client certificates are not used with LEAP or PEAP and are mandatory for EAP-TLS.

h. If you chose EAP-FAST with certificates, EAP-TLS, or PEAP, 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.Certificate date validity is checked against the current UTC (GMT) time that is configured on the controller. Timezone offset will be ignored.

Note Certificate date validity is checked against the current UTC (GMT) time that is configured on the controller. Time zone offset will be ignored.

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. Choose Security > Local EAP > EAP-FAST Parameters to open the EAP-FAST Method Parameters page (see Figure 5-26).

Figure 5-26 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. Choose WLANs to open the WLANs page.

b. Click the ID number of the desired WLAN.

c. When the WLANs > Edit page appears, choose the Security > AAA Servers tabs to open the WLANs > Edit (Security > AAA Servers) page (see Figure 5-27).

Figure 5-27 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, P EAPv0/MSCHAPv2, and PEAPv1/GTC use 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 the Managing Controller Software and Configurations chapter 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 values for the local EAP timers, enter these commands:

• config local-auth active-timeout timeout— Specifies the amount of time (in seconds) in which the controller attempts to authenticate wireless clients using local EAP after any pair of configured RADIUS servers fails. The valid range is 1 to 3600 seconds, and the default setting is 100 seconds.
• config advanced eap identity-request-timeout timeout —Specifies the amount of time (in seconds) in which the controller attempts to send an EAP identity request to wireless clients using local EAP. The valid range is 1 to 120 seconds, and the default setting is 30 seconds.
• config advanced eap identity-request-retries retries —Specifies the maximum number of times that the controller attempts to retransmit the EAP identity request to wireless clients using local EAP. The valid range is 1 to 20 retries, and the default setting is 20 retries.
• config advanced eap key-index index —Specifies the key index used for dynamic wired equivalent privacy (WEP). The default setting is 0.
• config advanced eap request-timeout timeout —Specifies the amount of time (in seconds) in which the controller attempts to send an EAP request to wireless clients using local EAP. The valid range is 1 to 120 seconds, and the default setting is 30 seconds.
• config advanced eap request-retries retries —Specifies the maximum number of times that the controller attempts to retransmit the EAP request to wireless clients using local EAP. The valid range is 1 to 120 retries, and the default setting is 20 retries.
• config advanced eap eapol-key-timeout timeout —Specifies the amount of time (in seconds) in which the controller attempts to send an EAP key over the LAN to wireless clients using local EAP. The valid range is 1 to 5 seconds, and the default setting is 1 second.
• config advanced eap eapol-key-retries retries —Specifies the maximum number of times that the controller attempts to send an EAP key over the LAN to wireless clients using local EAP. The valid range is 0 to 4 retries, and the default setting is 2 retries.
• config advanced eap max-login-ignore-identity-response { enable | disable } —When enabled, this command limits the number of devices that can be connected to the controller with the same username. You can log in up to eight times from different devices (PDA, laptop, IP phone, and so on) on the same controller. The default value is enabled.

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, tls, and peap.

Note If you choose peap, both P EAPv0/MSCHAPv2 or PEAPv1/GTC are enabled on the controller.

Note You can specify more than one EAP type per profile. However, if you create a profile with multiple EAP types that use certificates (such as EAP-FAST with certificates, EAP-TLS, PEAPv0/MSCHAPv2, and PEAPv1/GTC), all of the 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 days —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 device certificates are not used with LEAP and are mandatory for EAP-TLS and PEAP.

• 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 client certificates are not used with LEAP or PEAP and are mandatory for EAP-TLS.

• config local-auth eap-profile cert-issuer {cisco | vendor} profile_name —If you specified EAP-FAST with certificates, EAP-TLS, or PEAP, specifies whether the certificates that will be sent to the client are from Cisco or another vendor.
• config local-auth eap-profile cert-verify ca-issuer { enable | disable } profile_name —If you chose EAP-FAST with certificates or EAP-TLS, specifies whether the incoming certificate from the client is to be validated against the CA certificates on the controller.
• config local-auth eap-profile cert-verify cn-verify { enable | disable } profile_name —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 cert-verify date-valid { enable | disable } profile_name —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.

Information similar to the following appears for the show local-auth config command:

• show local-auth statistics —Shows the local EAP statistics.
• show local-auth certificates —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 advanced eap —Shows the timer values for local EAP. Information similar to the following appears:

• show ap stats wlan Cisco_AP —Shows the EAP timeout and failure counters for a specific access point for each WLAN. Information similar to the following appears:

• show client detail client_mac —Shows the EAP timeout and failure counters for a specific associated client. These statistics are useful in troubleshooting client association issues. Information similar to the following appears:

• show wlan wlan_id —Shows the status of local EAP on a particular WLAN.

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.

• clear stats local-auth —Clears the local EAP counters.
• clear stats ap wlan Cisco_AP —Clears the EAP timeout and failure counters for a specific access point for each WLAN.

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 Choose Wireless > 802.11b/g/n > Network to open the 802.11b/g Global Parameters page.

Step 2 If the Short Preamble check box is checked, continue with this procedure. However, if the Short Preamble check 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 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 Choose Commands > Reboot > Reboot > Save and Reboot to reboot the controller . Click OK in response to this prompt:

The controller reboots.

Step 6 Log back into the controller GUI to verify that the controller is properly configured.

Step 7 Choose Wireless > 802.11b/g/n > Network to open the 802.11b/g Global Parameters page. If the Short Preamble check 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:

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:

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 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:

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 the GUI to Enable Management over Wireless

Step 1 Choose Management > Mgmt Via Wireless to open 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 management over wireless interface is e nabled or d isabled . If it is d isabled , continue with To enable management over wireless, enter config network mgmt-via-wireless enable.. Otherwise, continue with Use a wireless client to associate with an access point connected to the controller that you want to manage..

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.

Using the GUI to Configure DHCP Option 82

Using the GUI, follow these steps to configure DHCP option 82 on the controller.

Step 1 Choose Controller > Advanced > DHCP to open the DHCP Parameters page (see Figure 5-29).

Figure 5-29 DHCP Parameters Page

Step 2 Choose one of the following options from the DHCP Option 82 Remote ID Field Format drop-down box to specify the format of the DHCP option 82 payload:

• AP-MAC —Adds the MAC address of the access point to the DHCP option 82 payload. This is the default value.
• AP-MAC-SSID —Adds the MAC address and SSID of the access point to the DHCP option 82 payload.

Step 3 Click Apply to commit your changes.

Step 4 Click Save Configuration to save your changes.

Using the CLI to Configure DHCP Option 82

Use these CLI 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 overrride the global DHCP option 82 setting and disable (or enable) this feature for the AP-manager or management interface on the controller, enter this command:

config interface dhcp {ap-manager | management} option-82 {disable | en able}

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:

Using the GUI to Configure Access Control Lists

Follow these steps to configure ACLs using the controller GUI.

Step 1 Choose Security > Access Control Lists > Access Control Lists to open the Access Control Lists page (see Figure 5-30).

Figure 5-30 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 If you want to see if packets are hitting any of the ACLs configured on your controller, check the Enable Counters check box and click Apply . Otherwise, leave the check box unchecked, which is the default value. This feature is useful when troubleshooting your system.

Note If you want to clear the counters for an ACL, hover your cursor over the blue drop-down arrow for that ACL and choose Clear Counters.

Note ACL counters are available only on the following controllers: 5500 series, 4400 series, Cisco WiSM, and Catalyst 3750G Integrated Wireless LAN Controller Switch.

Step 3 To add a new ACL, click New. The Access Control Lists > New page appears (see Figure 5-31).

Figure 5-31 Access Control Lists > New Page

Step 4 In the Access Control List Name field, enter a name for the new ACL. You can enter up to 32 alphanumeric characters.

Step 5 Click Apply. When the Access Control Lists page reappears, click the name of the new ACL.

Step 6 When the Access Control Lists > Edit page appears, click Add New Rule. The Access Control Lists > Rules > New page appears (see Figure 5-32).

Figure 5-32 Access Control Lists > Rules > New Page

Step 7 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/protocol-numbers.xml

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-33.

Figure 5-33 Access Control Lists > Edit Page

The Deny Counters field shows the number of times that packets have matched the explicit deny ACL rule. The Number of Hits field shows the number of times that packets have matched an ACL rule. You must enable ACL counters on the Access Control Lists page to enable these fields.

Note If you want to edit a rule, click the sequence number of the desired rule to open 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 8 Click Save Configuration to save your changes.

Step 9 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

Note If you apply an ACL to an interface or a WLAN, wireless throughput is degraded when downloading from a 1-Gbps file server. To improve throughput, remove the ACL from the interface or WLAN, move the ACL to a neighboring wired device with a policy rate-limiting restriction, or connect the file server using 100 Mbps rather than 1 Gbps.

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 Choose Controller > Interfaces .

Step 2 Click the name of the desired interface. The Interfaces > Edit page for that interface appears (see Figure 5-34).

Figure 5-34 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 the Configuring Ports and Interfaces chapter 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-35).

Figure 5-35 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 Choose WLANs to open the WLANs page.

Step 2 Click the ID number of the desired WLAN to open the WLANs > Edit page.

Step 3 Choose the Advanced tab to open the WLANs > Edit (Advanced) page (see Figure 5-36).

Figure 5-36 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 the Configuring WLANs chapter 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 Choose WLANs to open the WLANs page.

Step 2 Click the ID number of the desired WLAN to open the WLANs > Edit page.

Step 3 Choose the Security and Layer 3 tabs to open the WLANs > Edit (Security > Layer 3) page (see Figure 5-37).

Figure 5-37 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 the Configuring WLANs chapter 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

Information similar to the following appears:

Step 2 To see detailed information for a particular ACL, enter this command:

show acl detailed acl_name

Information similar to the following appears:

The Counter field increments each time a packet matches an ACL rule, and the DenyCounter field increments each time a packet does not match any of the rules.

Step 3 To enable or disable ACL counters for your controller, enter this command:

config acl counter { start | stop }

Note If you want to clear the current counters for an ACL, enter this command:
clear acl counters acl_name

Note ACL counters are available only on the following controllers: 5500 series, 4400 series, Cisco WiSM, and Catalyst 3750G Integrated Wireless LAN Controller Switch.

Step 4 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 5 To add a rule for an ACL, enter this command:

config acl rule add acl_name rule_index

Step 6 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 Follow these steps to configure a rule for this ACL: of the “Using the GUI to Configure Access Control Lists” section for explanations of the rule parameters.

Step 7 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 the Configuring Ports and Interfaces chapter 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 the Configuring WLANs chapter for more information on configuring WLANs.

Step 2 To save your settings, enter this command:

save config

Guidelines for Using MFP

Follow these guidelines for using MFP:

• MFP is supported for use with Cisco Aironet lightweight 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 Choose Security > Wireless Protection Policies > AP Authentication/MFP. The AP Authentication Policy page appears (see Figure 5-38).

Figure 5-38 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. Choose WLANs.

b. Click the profile name of the desired WLAN. The WLANs > Edit page appears.

c. Choose Advanced . The WLANs > Edit (Advanced) page appears (see Figure 5-39).

Figure 5-39 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. Choose Wireless > Access Points > All APs to open the All APs page.

b. Click the name of the desired access point.

c. Choose the Advanced tab. The All APs > Details for (Advanced) page appears.

d. 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.

e. Click Apply to commit your changes.

Step 6 Click Save Configuration to save your settings.

Using the GUI to View MFP Settings

To see the controller’s current global MFP settings, choose Security > Wireless Protection Policies > Management Frame Protection. The Management Frame Protection Settings page appears (see Figure 5-40).

Figure 5-40 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.

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 the controller’s current MFP settings, enter this command:

show wps mfp summary

Information similar to the following appears:

2. To see the current MFP configuration for a particular WLAN, enter this command:

show wlan wlan_id

Information similar to the following appears:

3. 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:

4. To see whether client MFP is enabled for a specific client, enter this command:

show client detail client_mac

5. 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.

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.

capwap —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.

Using the GUI to Configure Client Exclusion Policies

Using the controller GUI, follow these steps to configure client exclusion policies.

Step 1 Choose Security > Wireless Protection Policies > Client Exclusion Policies to open the Client Exclusion Policies page (see Figure 5-41).

Figure 5-41 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.

Using the CLI to Configure Client Exclusion Policies

Using the controller CLI, follow these steps to configure client exclusion policies.

Step 1 To enable or disable the controller to exclude clients on the sixth 802.11 association attempt, after five consecutive failures, enter this command:

config wps client-exclusion 802.11-assoc { enable | disable }

Step 2 To enable or disable the controller to exclude clients on the sixth 802.11 authentication attempt, after five consecutive failures, enter this command:

config wps client-exclusion 802.11-auth { enable | disable }

Step 3 To enable or disable the controller to exclude clients on the fourth 802.1X authentication attempt, after three consecutive failures, enter this command:

config wps client-exclusion 802.1x-auth { enable | disable }

Step 4 To enable or disable the controller to exclude clients if the IP address is already assigned to another device, enter this command:

config wps client-exclusion ip-theft { enable | disable }

Step 5 To enable or disable the controller to exclude clients on the fourth web authentication attempt, after three consecutive failures, enter this command:

config wps client-exclusion web-auth { enable | disable }

Step 6 To enable or disable the controller to exclude clients for all of the above reasons, enter this command:

config wps client-exclusion all { enable | disable }

Step 7 To save your changes, enter this command:

save config

Step 8 To see the client exclusion policy configuration settings, enter this command:

show wps summary

Information similar to the following appears:

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 because 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.

• Type – 26 for Vendor-Specific
• Length – 10
• Vendor-Id – 14179
• Vendor type – 2
• Vendor length – 4
• Value – Three octets:

– 3 – Bronze (Background)

– 0 – Silver (Best Effort)

– 1 – Gold (Video)

– 2 – 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.

• 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.

• 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.

• 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.

Note If a client moves to a new interface due to the AAA override and then you apply an ACL to that interface, the ACL does not take effect until the client reauthenticates. To work around this issue, apply the ACL and then enable the WLAN so that all clients connect to the ACL already configured on the interface, or disable and then re-enable the WLAN after you apply the interface so that the clients can reauthenticate.

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:

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:

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 Choose WLANs to open the WLANs page.

Step 2 Click the ID number of the WLAN that you want to configure. The WLANs > Edit page appears.

Step 3 Choose the Advanced tab to open the WLANs > Edit (Advanced) page (see Figure 5-42).

Figure 5-42 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.

Challenges

Rogue access points can disrupt wireless LAN operations by hijacking legitimate clients and using plain-text 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 usernames and passwords. The hacker can then transmit a series of clear-to-send (CTS) frames. This action mimics an access point informing a particular client to transmit and instructing all others to wait, which results in legitimate clients being unable to access network resources. Therefore, wireless LAN service providers have a strong interest in banning rogue access points from the air space.

Because rogue access points are inexpensive and readily available, employees sometimes plug unauthorized rogue access points into existing LANs and build ad-hoc wireless networks without IT department knowledge or consent. These rogue access points can be a serious breach of network security as they can be plugged into a network port behind the corporate firewall. Because employees generally do not enable any security settings on the rogue access point, it is easy for unauthorized users to use the access point to intercept network traffic and hijack client sessions. Even more alarming, wireless users frequently publish unsecure access point locations, increasing the odds of having enterprise security breached.

Detecting Rogue Devices

The controller continuously monitors all nearby access points and automatically discovers and collects information on rogue access points and clients. When the controller discovers a rogue access point, it uses the Rogue Location Discovery Protocol (RLDP) to determine if the rogue is attached to your network.

You can configure the controller to use RLDP on all access points or only on access points configured for monitor (listen-only) mode. The latter option facilitates automated rogue access point detection in a crowded RF space, allowing monitoring without creating unnecessary interference and without affecting regular data access point functionality. If you configure the controller to use RLDP on all access points, the controller always chooses the monitor access point for RLDP operation if a monitor access point and a local (data) access point are both nearby. If RLDP determines that the rogue is on your network, you can choose to either manually or automatically contain the detected rogue.

Classifying Rogue Access Points

Controller software release 5.0 or later improves the classification and reporting of rogue access points through the use of rogue states and user-defined classification rules that enable rogues to automatically move between states. In previous releases, the controller listed all rogue access points on one page sorted by MAC address or BSSID. Now you can create rules that enable the controller to organize and display rogue access points as Friendly, Malicious, or Unclassified.

By default, none of the classification rules are enabled. Therefore, all unknown access points are categorized as Unclassified. When you create a rule, configure conditions for it, and enable the rule, the unclassified access points are reclassified. Whenever you change a rule, it is applied to all access points (friendly, malicious, and unclassified) in the Alert state only.

Note Rule-based rogue classification does not apply to ad-hoc rogues and rogue clients.

Note The 5500 series controllers support up to 2000 rogues (including acknowledged rogues); the 4400 series controllers, Cisco WiSM, and Catalyst 3750G Integrated Wireless LAN Controller Switch support up to 625 rogues; and the 2100 series controllers and Controller Network Module for Integrated Services Routers support up to 125 rogues. Each controller limits the number of rogue containments to three per radio (or six per radio for access points in monitor mode).

When the controller receives a rogue report from one of its managed access points, it responds as follows:

1. The controller verifies that the unknown access point is in the friendly MAC address list. If it is, the controller classifies the access point as Friendly.

2. If the unknown access point is not in the friendly MAC address list, the controller starts applying rogue classification rules.

3. If the rogue is already classified as Malicious, Alert or Friendly, Internal or External, the controller does not reclassify it automatically. If the rogue is classified differently, the controller reclassifies it automatically only if the rogue is in the Alert state.

4. The controller applies the first rule based on priority. If the rogue access point matches the criteria specified by the rule, the controller classifies the rogue according to the classification type configured for the rule.

5. If the rogue access point does not match any of the configured rules, the controller classifies the rogue as Unclassified.

6. The controller repeats the previous steps for all rogue access points.

7. If RLDP determines that the rogue access point is on the network, the controller marks the rogue state as Threat and classifies it as Malicious automatically, even if no rules are configured. You can then manually contain the rogue (unless you have configured RLDP to automatically contain the rogue), which would change the rogue state to Contained. If the rogue access point is not on the network, the controller marks the rogue state as Alert, and you can manually contain the rogue.

8. If desired, you can manually move the access point to a different classification type and rogue state.

Table 5-8 shows the rogue states that can be adopted by a rogue access point in a particular classification type.

If you upgrade to controller software release 5.0 or later, the classification and state of the rogue access points are reconfigured as follows:

• From Known to Friendly, Internal.
• From Acknowledged to Friendly, External.
• From Contained to Malicious, Contained.

As mentioned previously, the controller can automatically change the classification type and rogue state of an unknown access point based on user-defined rules, or you can manually move the unknown access point to a different classification type and rogue state. Table 5-9 shows the allowable classification types and rogue states from and to which an unknown access point can be configured.

If the rogue state is Contained, you have to uncontain the rogue access point before you can change the classification type. If you want to move a rogue access point from Malicious to Unclassified, you must delete the access point and allow the controller to reclassify it.

WCS Interaction

WCS software release 5.0 or later also supports rule-based classification. WCS uses the classification rules configured on the controller. The controller sends traps to WCS after the following events:

• If an unknown access point moves to Friendly for the first time, the controller sends a trap to WCS only if the rogue state is Alert. It does not send a trap if the rogue state is Internal or External.
• If a rogue entry is removed after the timeout expires, the controller sends a trap to WCS for rogue access points categorized as Malicious (Alert, Threat) or Unclassified (Alert). The controller does not remove rogue entries with the following rogue states: Contained, Contained Pending, Internal, and External.

Configuring RLDP

You can configure RLDP to automatically detect and contain rogue devices using the controller GUI or CLI.

Using the GUI to Configure RLDP

Using the controller GUI, follow these steps to configure RLDP.

Step 1 Make sure that rogue detection is enabled on the desired access points. Rogue detection is enabled by default for all access points joined to the controller (except for OfficeExtend access points). However, in controller software release 6.0, you can enable or disable it for individual access points by checking or unchecking the Rogue Detection check box on the All APs > Details for (Advanced) page.

Note Rogue detection is disabled by default for OfficeExtend access points because these access points, which are deployed in a home environment, are likely to detect a large number of rogue devices.

Step 2 Choose Security > Wireless Protection Policies > Rogue Policies > General to open the Rogue Policies page (see Figure 5-43).

Figure 5-43 Rogue Policies Page

Step 3 Choose one of the following options from the Rogue Location Discovery Protocol drop-down box:

• Disable —Disables RLDP on all access points. This is the default value.
• All APs —Enables RLDP on all access points.
• Monitor Mode APs —Enables RLDP only on access points in monitor mode.

Step 4 In the Expiration Timeout for Rogue AP and Rogue Client Entries field, enter the number of seconds after which the rogue access point and client entries expire and are removed from the list. The valid range is 240 to 3600 seconds, and the default value is 1200 seconds.

Note If a rogue access point or client entry times out, it is removed from the controller only if its rogue state is Alert or Threat for any classification type.

Step 5 If desired, check the Validate Rogue Clients Against AAA check box to use the AAA server or local database to validate if rogue clients are valid clients. The default value is unchecked.

Step 6 If desired, check the Detect and Report Ad-Hoc Networks check box to enable ad-hoc rogue detection and reporting. The default value is checked.

Step 7 If you want the controller to automatically contain certain rogue devices, check the following check boxes. Otherwise, leave the check boxes unchecked, which is the default value.

• Rogue on Wire —Automatically contains rogues that are detected on the wired network.
• Using Our SSID —Automatically contains rogues that are advertising your network’s SSID. If you leave this parameter unchecked, the controller only generates an alarm when such a rogue is detected.
• Valid Client on Rogue AP —Automatically contains a rogue access point to which trusted clients are associated. If you leave this parameter unchecked, the controller only generates an alarm when such a rogue is detected.
• AdHoc Rogue AP —Automatically contains adhoc networks detected by the controller. If you leave this parameter unchecked, the controller only generates an alarm when such a network is detected.

Step 8 Click Apply to commit your changes.

Step 9 Click Save Configuration to save your changes.

Using the CLI to Configure RLDP

Using the controller CLI, follow these steps to configure RLDP.

Step 1 Make sure that rogue detection is enabled on the desired access points. Rogue detection is enabled by default for all access points joined to the controller (except for OfficeExtend access points). However, in controller software release 6.0, you can enable or disable it for individual access points by entering this command: config rogue detection { enable | disable } Cisco_AP.

Note To see the current rogue detection configuration for a specific access point, enter this command: show ap config general Cisco_AP.

Note Rogue detection is disabled by default for OfficeExtend access points because these access points, which are deployed in a home environment, are likely to detect a large number of rogue devices.

Step 2 To enable, disable, or initiate RLDP, enter these commands:

• config rogue ap rldp enable alarm-only —Enables RLDP on all access points .
• config rogue ap rldp enable alarm-only monitor_ap_only—Enables RLDP only on access points in monitor mode.
• config rogue ap rldp initiate rogue_mac_address—Initiates RLDP on a specific rogue access point.
• config rogue ap rldp disable—Disables RLDP on all access points.

Step 3 To specify the number of seconds after which the rogue access point and client entries expire and are removed from the list, enter this command:

config rogue ap timeout seconds

The valid range for the seconds parameter is 240 to 3600 seconds (inclusive), and the default value is 1200 seconds.

Note If a rogue access point or client entry times out, it is removed from the controller only if its rogue state is Alert or Threat for any classification type.

Step 4 To enable or disable ad-hoc rogue detection and reporting, enter this command:

config rogue adhoc { enable | disable }

Step 5 To enable or disable the AAA server or local database to validate if rogue clients are valid clients, enter this command:

config rogue client aaa { enable | disable }

Step 6 If you want the controller to automatically contain certain rogue devices, enter these commands.

• config rogue ap rldp enable auto-contain —Automatically contains rogues that are detected on the wired network.
• config rogue ap ssid auto-contain —Automatically contains rogues that are advertising your network’s SSID.

Note If you want the controller to only generate an alarm when such a rogue is detected, enter this command: config rogue ap ssid alarm.

• config rogue ap valid-client auto-contain —Automatically contains a rogue access point to which trusted clients are associated.

Note If you want the controller to only generate an alarm when such a rogue is detected, enter this command: config rogue ap valid-client alarm.

• config rogue adhoc auto-contain —Automatically contains adhoc networks detected by the controller.

Note If you want the controller to only generate an alarm when such a network is detected, enter this command: config rogue adhoc alert.

Step 7 To save your changes, enter this command:

save config

Configuring Rogue Classification Rules

You can configure up to 64 rogue classification rules per controller using the controller GUI or CLI.

Using the GUI to Configure Rogue Classification Rules

Using the controller GUI, follow these steps to configure rogue classification rules.

Step 1 Choose Security > Wireless Protection Policies > Rogue Policies > Rogue Rules to open the Rogue Rules page (see Figure 5-44).

Figure 5-44 Rogue Rules Page

Any rules that have already been created are listed in priority order. The name, type, and status of each rule is provided.

Note If you ever want to delete a rule, hover your cursor over the blue drop-down arrow for that rule and click Remove.

Step 2 To create a new rule, follow these steps:

a. Click Add Rule . An Add Rule section appears at the top of the page.

b. In the Rule Name field, enter a name for the new rule. Make sure that the name does not contain any spaces.

c. From the Rule Type drop-down box, choose Friendly or Malicious to classify rogue access points matching this rule as friendly or malicious.

d. Click Add to add this rule to the list of existing rules, or click Cancel to discard this new rule.

Step 3 To edit a rule, follow these steps:

a. Click the name of the rule that you want to edit. The Rogue Rule > Edit page appears (see Figure 5-45).

Figure 5-45 Rogue Rule > Edit Page

b. From the Type drop-down box, choose Friendly or Malicious to classify rogue access points matching this rule as friendly or malicious.

c. From the Match Operation field, choose one of the following:

• Match All—If this rule is enabled, a detected rogue access point must meet all of the conditions specified by the rule in order for the rule to be matched and the rogue to adopt the classification type of the rule.
• Match Any— If this rule is enabled, a detected rogue access point must meet any of the conditions specified by the rule in order for the rule to be matched and the rogue to adopt the classification type of the rule. This is the default value.

d. To enable this rule, check the Enable Rule check box. The default value is unchecked.

e. From the Add Condition drop-down box, choose one or more of the following conditions that the rogue access point must meet and click Add Condition :

• SSID —Requires that the rogue access point have a specific user-configured SSID. If you choose this option, enter the SSID in the User Configured SSID field, and click Add SSID .

Note To delete an SSID, highlight the SSID and click Remove.

• RSSI —Requires that the rogue access point have a minimum received signal strength indication (RSSI) value. For example, if the rogue access point has an RSSI that is greater than the configured value, then the access point could be classified as malicious. If you choose this option, enter the minimum RSSI value in the Minimum RSSI field. The valid range is –95 to –50 dBm (inclusive), and the default value is 0 dBm.
• Duration —Requires that the rogue access point be detected for a minimum period of time. If you choose this option, enter a value for the minimum detection period in the Time Duration field. The valid range is 0 to 3600 seconds (inclusive), and the default value is 0 seconds.
• Client Count —Requires that a minimum number of clients be associated to the rogue access point. For example, if the number of clients associated to the rogue access point is greater than or equal to the configured value, then the access point could be classified as malicious. If you choose this option, enter the minimum number of clients to be associated to the rogue access point in the Minimum Number of Rogue Clients field. The valid range is 1 to 10 (inclusive), and the default value is 0.
• No Encryption —Requires that the rogue access point’s advertised WLAN does not have encryption enabled. If a rogue access point has encryption disabled, it is likely that more clients will try to associate to it. No further configuration is required for this option.

Note WCS refers to this option as “Open Authentication.”

• Managed SSID —Requires that the rogue access point’s managed SSID (the SSID configured for the WLAN) be known to the controller. No further configuration is required for this option.

Note The SSID and Managed SSID conditions cannot be used with the Match All operation as these two SSID lists are mutually exclusive. If you define a rule with Match All and have these two conditions configured, the rogue access points are never classified as friendly or malicious because one of the conditions can never be met.

You can add up to six conditions per rule. When you add a condition, it appears under the Conditions section (see Figure 5-46).

Figure 5-46 Rogue Rule > Edit Page

Note If you ever want to delete a condition from this rule, hover your cursor over the blue drop-down arrow for that condition and click Remove.

f. Click Apply to commit your changes.

Step 4 Click Save Configuration to save your changes.

Step 5 If you want to change the order in which rogue classification rules are applied, follow these steps:

a. Click Back to return to the Rogue Rules page.

b. Click Change Priority to access the Rogue Rules > Priority page (see Figure 5-47).

Figure 5-47 Rogue Rules > Priority Page

The rogue rules are listed in priority order in the Change Rules Priority edit box.

c. Highlight the rule for which you want to change the priority, and click Up to raise its priority in the list or Down to lower its priority in the list.

d. Continue to move the rules up or down until the rules are in the desired order.

e. Click Apply to commit your changes.

Step 6 If you want to classify any rogue access points as friendly and add them to the friendly MAC address list, follow these steps:

a. Choose Security > Wireless Protection Policies > Rogue Policies > Friendly Rogue to access the Friendly Rogue > Create page (see Figure 5-48).

Figure 5-48 Friendly Rogue > Create Page

b. In the MAC Address field, enter the MAC address of the friendly rogue access point.

c. Click Apply to commit your changes.

d. Click Save Configuration to save your changes. This access point is added to the controller’s list of friendly access points and should now appear on the Friendly Rogue APs page.

Using the CLI to Configure Rogue Classification Rules

Using the controller CLI, follow these steps to configure rogue classification rules.

Step 1 To create a rule, enter this command:

config rogue rule add ap priority priority classify { friendly | malicious } rule_name

Note If you later want to change the priority of this rule and shift others in the list accordingly, enter this command: config rogue rule priority priority rule_name. If you later want to change the classification of this rule, enter this command: config rogue rule classify {friendly | malicious} rule_name.

Note If you ever want to delete all of the rogue classification rules or a specific rule, enter this command: config rogue rule delete {all | rule_name}.

Step 2 To disable all rules or a specific rule, enter this command:

config rogue rule disable { all | rule_name }

Note A rule must be disabled before you can modify its attributes.

Step 3 To add conditions to a rule that the rogue access point must meet, enter this command:

config rogue rule condition ap set condition_type condition_value rule_name

where condition_type is one of the following:

• ssid —Requires that the rogue access point have a specific SSID. You should add SSIDs that are not managed by the controller. If you choose this option, enter the SSID for the condition_value parameter . The SSID is added to the user-configured SSID list.

Note If you ever want to delete all of the SSIDs or a specific SSID from the user-configured SSID list, enter this command: config rogue rule condition ap delete ssid {all | ssid} rule_name.

• rssi —Requires that the rogue access point have a minimum RSSI value. For example, if the rogue access point has an RSSI that is greater than the configured value, then the access point could be classified as malicious. If you choose this option, enter the minimum RSSI value for the condition_value parameter . The valid range is –95 to –50 dBm (inclusive), and the default value is 0 dBm.
• duration —Requires that the rogue access point be detected for a minimum period of time. If you choose this option, enter a value for the minimum detection period for the condition_value parameter . The valid range is 0 to 3600 seconds (inclusive), and the default value is 0 seconds.
• client-count —Requires that a minimum number of clients be associated to the rogue access point. For example, if the number of clients associated to the rogue access point is greater than or equal to the configured value, then the access point could be classified as malicious. If you choose this option, enter the minimum number of clients to be associated to the rogue access point for the condition_value parameter . The valid range is 1 to 10 (inclusive), and the default value is 0.
• no-encryption —Requires that the rogue access point’s advertised WLAN does not have encryption enabled. A condition_value parameter is not required for this option.
• managed-ssid —Requires that the rogue access point’s SSID be known to the controller. A condition_value parameter is not required for this option.

Note You can add up to six conditions per rule. If you ever want to delete all of the conditions or a specific condition from a rule, enter this command: config rogue rule condition ap delete {all | condition_type} condition_value rule_name.

Step 4 To specify whether a detected rogue access point must meet all or any of the conditions specified by the rule in order for the rule to be matched and the rogue access point to adopt the classification type of the rule, enter this command:

config rogue rule match { all | any } rule_name

Step 5 To enable all rules or a specific rule, enter this command:

config rogue rule enable { all | rule_name }

Note For your changes to become effective, you must enable the rule.

Step 6 To add a new friendly access point entry to the friendly MAC address list or delete an existing friendly access point entry from the list, enter this command:

config rogue ap friendly { add | delete } ap_mac_address

Step 7 To save your changes, enter this command:

save config

Step 8 To view the rogue classification rules that are configured on the controller, enter this command:

show rogue rule summary

Information similar to the following appears:

Step 9 To view detailed information for a specific rogue classification rule, enter this command:

show rogue rule detailed rule_name

Information similar to the following appears: