802.1x is an Institute of Electrical and Electronics Engineers (IEEE) standard that provides an authentication framework for WLANs. 802.1x uses the Extensible Authentication Protocol (EAP) to exchange messages during the authentication process. The authentication protocols that operate inside the 802.1x framework that are suitable for wireless networks include EAP-Transport Layer Security (EAP-TLS), Protected EAP (PEAP), and EAP-Tunneled TLS (EAP-TTLS). These protocols allow the network to authenticate the client while also allowing the client to authenticate the network.
This chapter describes the following topics:
Other types of authentication not discussed in this chapter can be found in the following sections of this guide:
-
Captive portal authentication: “Captive Portal Authentication”
-
VPN authentication: “VPN Configuration”
-
MAC authentication: “Configuring MAC-Based Authentication”
-
Stateful 802.1x, stateful NTLM, and WISPr authentication: “Stateful and WISPr Authentication”
Overview of 802.1x Authentication
802.1x authentication consists of three components:
-
The supplicant, or client, is the device attempting to gain access to the network. You can configure the Arubauser-centric network to support 802.1x authentication for wired users as well as wireless users.
-
The authenticator is the gatekeeper to the network and permits or denies access to the supplicants.
-
The Arubacontroller acts as the authenticator, relaying information between the authentication server and supplicant. The EAP type must be consistent between the authentication server and supplicant and is transparent to the controller.
The following is the list of supported EAP types.
-
PEAP—Protected EAP (PEAP) is an 802.1x authentication method that uses server-side public key certificates to authenticate clients with server. The PEAP authentication creates an encrypted SSL / TLS tunnel between the client and the authentication server. The exchange of information is encrypted and stored in the tunnel ensuring the user credentials are kept secure.
-
EAP-GTC—The EAP-GTC (Generic Token Card) type uses clear text method to exchange authentication controls between client and server. Since the authentication mechanism uses the one-time tokens (generated by the card), this method of credential exchange is considered safe. In addition, EAP-GTC is used in PEAP or TTLS tunnels in wireless environments. The EAP-GTC is described in RFC 2284.
-
EAP-AKA—The EAP-AKA (Authentication and Key Agreement) authentication mechanism is typically used in mobile networks that include Universal Mobile Telecommunication Systems (UMTS) and CDMA 2000. This method uses the information stored in the Subscriber Identity Module (SIM) for authentication. The EAP-AKA is described in RFC 4187.
-
EAP-FAST—The EAP-FAST (Flexible Authentication via Secure Tunneling) is an alternative authentication method to PEAP. This method uses the Protected Access Credential (PAC) for verifying clients on the network. The EAP-FAST is described in RFC 4851.
-
EAP-MD5—The EAP-MD5 method verifies MD5 hash of a user password for authentication. This method is commonly used in a trusted network. The EAP-MD5 is described in RFC 2284.
-
EAP-SIM—The EAP-SIM (Subscriber Identity Module) uses Global System for Mobile Communication (GSM) Subscriber Identity Module (SIM) for authentication and session key distribution. This authentication mechanism includes network authentication, user anonymity support, result indication, and fast re-authentication procedure. Complete details about this authentication mechanism is described in RFC 4186.
-
EAP-TLS—The EAP-TLS (Transport Layer Security) uses Public key Infrastructure (PKI) to set up authentication with a RADIUS server or any authentication server. This method requires the use of a client-side certificate for communicating with the authentication server. The EAP-TLS is described in RFC 5216.
-
EAP-TLV- The EAP-TLV (type-length-value) method allows you to add additional information in an EAP message. Often this method is used to provide more information about a EAP message. For example, status information or authorization data. This method is always used after a typical EAP authentication process.
-
EAP-TTLS—The EAP-TTLS (Tunneled Transport Layer Security) method uses server-side certificates to set up authentication between clients and servers. The actually authentication is, however, performed using passwords. Complete details about EAP-TTLS is described in RFC 5281.
-
LEAP—Lightweight Extensible Authentication Protocol (LEAP) uses dynamic WEP keys and mutual authentication between client and RADIUS server.
-
ZLXEAP—This is Zonelabs EAP. For more information, visit http://tools.ietf.org/html/draft-bersani-eap-synthesis-sharedkeymethods-00#page-30.
Authentication with a RADIUS Server
See Table 53for an overview of the parameters that you need to configure on authentication components when the authentication server is an 802.1x EAP-compliant RADIUS server.
Figure 45 802.1x Authentication with RADIUS Server
The supplicant and authentication server must be configured to use the same EAP type. The controllerdoes not need to know the EAP type used between the supplicant and authentication server.
For the controllerto communicate with the authentication server, you must configure the IP address, authentication port, and accounting port of the server on the controller. The authentication server must be configured with the IP address of the RADIUS client, which is the controllerin this case. Both the controllerand the authentication server must be configured to use the same shared secret.
|
|
Additional information on EAP types supported in a Windows environment, Microsoft supplicants, and authentication server, is available at http://technet.microsoft.com/en-us/library/cc782851(WS.10).aspx. |
The client communicates with the controllerthrough a GRE tunnel in order to form an association with an AP and to authenticate to the network. Therefore, the network authentication and encryption configured for an ESSID must be the same on both the client and the controller.
Authentication Terminated on Controller
User authentication is performed either via the controller ’s internal database or a non-802.1x server. See “802.1x Authentication Profile Basic WebUI Parameters”for an overview of the parameters that you need to configure on 802.1x authentication components when 802.1x authentication is terminated on the controller(AAA FastConnect).
Figure 46 802.1x Authentication with Termination on Controller
In this scenario, the supplicant is configured for EAP-Transport Layer Security (TLS) or EAP-Protected EAP (PEAP).
-
EAP-TLS is used with smart card user authentication. A smart card holds a digital certificate which, with the user-entered personal identification number (PIN), allows the user to be authenticated on the network. EAP-TLS relies on digital certificates to verify the identities of both the client and server.
-
EAP-PEAP uses TLS to create an encrypted tunnel. Within the tunnel, one of the following “inner EAP” methods is used:
-
EAP-Generic Token Card (GTC): Described in RFC 2284, this EAP method permits the transfer of unencrypted usernames and passwords from client to server. The main uses for EAP-GTC are one-time token cards such as SecureID and the use of an LDAP or RADIUS server as the user authentication server. You can also enable caching of user credentials on the controlleras a backup to an external authentication server.
-
EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2): Described in RFC 2759, this EAP method is widely supported by Microsoft clients. A RADIUS server must be used as the backend authentication server.
If you are using the controller ’s internal database for user authentication, you need to add the names and passwords of the users to be authenticated. If you are using an LDAP server for user authentication, you need to configure the LDAP server on the controller , and configure user IDs and passwords. If you are using a RADIUS server for user authentication, you need to configure the RADIUS server on the controller.
Configuring 802.1x Authentication
On the controller , use the following steps to configure a wireless network that uses 802.1x authentication:
1. Configure the VLANs to which the authenticated users will be assigned. See Chapter 2, “Network Parameters”
2. Configure policies and roles. You can specify a default role for users who are successfully authenticated using 802.1x. You can also configure server derivation rules to assign a user role based on attributes returned by the authentication server; server-derived user roles take precedence over default roles. For more information about policies and roles, see Chapter 10, “Roles and Policies”.
|
|
The Policy Enforcement Firewall Virtual Private Network (PEFV)module provides identity-based security for wired and wireless users and must be installed on the controller . The stateful firewall allows user classification based on user identity, device type, location and time of day and provides differentiated access for different classes of users. For information about obtaining and installing licenses, see Chapter 31, “Software Licenses”. |
3. Configure the authentication server(s) and server group. The server can be an 802.1x RADIUS server or, if you are using AAA FastConnect, a non-802.1x server or the controller ’s internal database. If you are using EAP-GTC within a PEAP tunnel, you can configure an LDAP or RADIUS server as the authentication server (see Chapter 8, “Authentication Servers”) If you are using EAP-TLS, you need to import server and CA certificates on the controller(see “Configuring and Using Certificates with AAA FastConnect” ).
4. Configure the AAA profile.
-
Select the 802.1x default user role.
-
Select the server group you previously configured for the 802.1x authentication server group.
5. Configure the 802.1x authentication profile. See “Using the WebUI”
6. Configure the virtual AP profile for an AP group or for a specific AP:
-
Select the AAA profile you previously configured.
-
In the SSID profile, configure the WLAN for 802.1x authentication.
For details on how to complete the above steps, see “Example Configurations”
This section describes how to create and configure a new instance of an 802.1x authentication profile in the WebUI or the CLI.
1. Navigate to the Configuration >Security >Authentication > L2 Authentication page.
2. In the Profiles list, select 802.1x Authentication Profile.
3. Enter a name for the profile, then click Add.
4. Click Apply.
5. In the Profiles list, select the 802.1x authentication profile you just created.
6. The profile details window includes Basicand Advancedtabs for basic and advanced configuration settings. Click on one or both of these tab to configure the 802.1x Authentication settings. Table 53describes the parameters you can configure in the high-throughput radio profile.
|
Parameter |
Description |
|---|---|
|
Basic 802.1x Authentication Profile settings |
|
|
Max authentication failures |
Number of times a user can try to login with wrong credentials after which the user will be blacklisted as a security threat. Set to 0 to disable blacklisting, otherwise enter a non-zero integer to blacklist the user after the specified number of failures. Default: 0 |
|
Enforce Machine Authentication |
(For Windows environments only) Select this option to enforce machine authentication before user authentication. If selected, either the Machine Authentication Default Role or the User Authentication Default Role is assigned to the user, depending on which authentication is successful. This option is disabled by default. Note: This option may require a PEFNG or PEFV license (seelicense descriptions at “License Types”). The Enforce Machine Authenticationcheckbox is also available on the Advanced settings tab. |
|
Machine Authentication: Default Machine Role |
Select the default role to be assigned to the user after completing only machine authentication. Default: guest |
|
Machine Authentication: Default User Role |
Select the default role to be assigned to the user after completing 802.1x authentication. Default: guest |
|
Reauthentication |
Select this option to force the client to do a 802.1x re-authentication after the expiration of the default timer for re-authentication. The default value of the timer (Reauthentication Interval) is 24 hours. If the user fails to re-authenticate with valid credentials, the state of the user is cleared. If derivation rules are used to classify 802.1x-authenticated users, then the Re-authentication timer per role overrides this setting. Default: disabled |
|
Termination |
Select this option to terminate 802.1x authentication on the controller. Default: disabled |
|
Termination EAP-Type |
The EAP method, either EAP-PEAP or EAP-TLS. Default: eap-peap |
|
Termination Inner EAP-Type |
Select one of the following: l EAP-Generic Token Card (GTC): Described in RFC 2284, this EAP method permits the transfer of unencrypted usernames and passwords from client to server. The main uses for EAP-GTC are one-time token cards such as SecureID and the use of LDAP or RADIUS as the user authentication server. You can also enable caching of user credentials on the controller as a backup to an external authentication server. l EAP-Microsoft Challenge Authentication Protocol version 2 (MS-CHAPv2): Described in RFC 2759, this EAP method is widely supported by Microsoft clients. Default: eap-mschapv2 |
|
Advanced 802.1x Authentication Profile settings |
|
|
Max authentication failures |
Number of times a user can try to login with wrong credentials after which the user is blacklisted as a security threat. Set to 0 to disable blacklisting, otherwise enter a non-zero integer to blacklist the user after the specified number of failures. The range of allowed values is 0-5 failures, and the default value is 0 failures. Note: This option may require a license(see license descriptions at “License Types” ). |
|
Enforce Machine Authentication |
Select the Enforce Machine Authentication option to require machine authentication. This option is also available on the Basic settings tab. Note: This option may require a license (see license descriptions at “License Types” ). |
|
Machine Authentication: Default Machine Role |
Default role assigned to the user after completing only machine authentication. The default role for this setting is the “guest” role. |
|
Machine Authentication Cache Timeout |
The timeout, in hours, for machine authentication. The allowed range of values is 1-1000 hours, and the default value is 24 hours. |
|
Blacklist on Machine Authentication Failure |
Select the Blacklist on Machine Authentication Failurecheckbox to blacklist a client if machine authentication fails. This setting is disabled by default |
|
Machine Authentication: Default User Role |
Default role assigned to the user after 802.1x authentication. The default role for this setting is the “guest” role. |
|
Interval between Identity Requests |
Interval, in seconds, between identity request retries. The allowed range of values is 1-65535 seconds, and the default value is 30 seconds. |
|
Quiet Period after Failed Authentication |
The enforced quiet period interval, in seconds, following failed authentication. The allowed range of values is 1-65535 seconds, and the default value is 30 seconds. |
|
Reauthentication Interval |
Interval, in seconds, between reauthentication attempts. The allowed range of values for this parameter is 60-864000 seconds, and the default value is 86400 seconds (1day). |
|
Use Server provided Reauthentication Interval |
Select this option to override any user-defined reauthentication interval and use the reauthentication period defined by the authentication server. |
|
Multicast Key Rotation Time Interval |
Interval, in seconds, between multicast key rotation. The allowed range of values for this parameter is 60-864000 seconds, and the default value is 1800 seconds. |
|
Unicast Key Rotation Time Interval |
Interval, in seconds, between unicast key rotation. The allowed range of values for this parameter is 60-864000 seconds, and the default value is 900 seconds. |
|
Authentication Server Retry Interval |
Server group retry interval, in seconds. The allowed range of values for this parameter is 5-65535 seconds, and the default value is 30 seconds. |
|
Authentication Server Retry Count |
Maximum number of authentication requests that are sent to server group. The allowed range of values for this parameter is 0-3 requests, and the default value is 2 requests. |
|
Framed MTU |
Sets the framed Maximum Transmission Unit (MTU) attribute sent to the authentication server. The allowed range of values for this parameter is 500-1500 bytes, and the default value is 1100 bytes. |
|
Number of times ID-Requests are retried |
Maximum number of times ID requests are sent to the client. The allowed range of values for this parameter is 1-10 retries, and the default value is 3 retries. |
|
Maximum Number of Reauthentication Attempts |
Number of times a user can try to login with wrong credentials after which the user is blacklisted as a security threat. Set to 0 to disable blacklisting, otherwise enter a value from 0-5 to blacklist the user after the specified number of failures. Note: If changed from its default value, this may require a license This option may require a license (see license descriptions at “License Types” ). |
|
Maximum number of times Held State can be bypassed |
Number of consecutive authentication failures which, when reached, causes the controllerto not respond to authentication requests from a client while the controlleris in a held state after the authentication failure. Before this number is reached, the controllerresponds to authentication requests from the client even while the controlleris in its held state. (This parameter is applicable when 802.1x authentication is terminated on the controller , also known as AAA FastConnect.) The allowed range of values for this parameter is 0-3 failures, and the default value is 0. |
|
Dynamic WEP Key Message Retry Count |
Set the Number of times WPA/WPA2 Key Messages are retried. The allowed range of values is 1-5 retries, and the default value is 3 retries. |
|
Dynamic WEP Key Size |
The default dynamic WEP key size is 128 bits, If desired, you can change this parameter to either 40 bits. |
|
Interval between WPA/WPA2 Key Messages |
Interval, in milliseconds, between each WPA key exchange.s The allowed range of values is 1000-5000ms, and the default value is 3000 ms. |
|
Delay between EAP-Success and WPA2 Unicast Key Exchange |
Interval, in milliseconds, between unicast and multicast key exchanges. The allowed range of values is 0-2000ms, and the default value is 0 ms (no delay). |
|
Delay between WPA/WPA2 Unicast Key and Group Key Exchange |
Interval, in milliseconds, between unicast and multicast key exchanges. The allowed range of values is 0-2000ms, and the default value is 0 ms (no delay). |
|
WPA/WPA2 Key Message Retry Count |
Number of times WPA/WPA2 key messages are retried. The allowed range of values for this parameter is 1-5 retries, and the default value is 3 retries. |
|
Multicast Key Rotation |
Select this checkbox to enable multicast key rotation. This feature is disabled by default. |
|
Unicast Key Rotation |
Select this checkbox to enable unicast key rotation. This feature is disabled by default. |
|
Reauthentication |
Select the Reauthentication checkbox to force the client to do a 802.1x reauthentication after the expiration of the default timer for reauthentication. (The default value of the timer is 24 hours.) If the user fails to reauthenticate with valid credentials, the state of the user is cleared. If derivation rules are used to classify 802.1x-authenticated users, then the reauthentication timer per role overrides this setting. This option is disabled by default. |
|
Opportunistic Key Caching |
By default, the 802.1x authentication profile enables a cached pairwise master key (PMK) derived via a client and an associated AP and used when the client roams to a new AP. This allows clients faster roaming without a full 802.1x authentication. Uncheck this option to disable this feature. Note: Make sure that the wireless client (the 802.1x supplicant) supports this feature. If the client does not support this feature, the client will attempt to renegotiate the key whenever it roams to a new AP. As a result, the key cached on the controllercan be out of sync with the key used by the client. |
|
Validate PMKID |
This parameter instructs the controller to check the pairwise master key (PMK) ID sent by the client. When this option is enabled, the client must send a PMKID in the associate or reassociate frame to indicate that it supports OKC or PMK caching; otherwise, full 802.1x authentication takes place. Note: This feature is optional, since most clients that support OKC and PMK caching do not send the PMKID in their association request. |
|
Use Session Key |
Select the Use Session Keyoption to use the RADIUS session key as the unicast WEP key. This option is disabled by default. |
|
Use Static Key |
Select the Use Static Keyoption to use a static key as the unicast/multicast WEP key. This option is disabled by default. |
|
xSec MTU |
Set the maximum transmission unit (MTU) for frames using the xSec protocol. The range of allowed values is 1024-1500 bytes, and 1300 bytes |
|
Termination |
Select the Termination checkbox to allow 802.1x authentication to terminate on the controller. This option is disabled by default. |
|
Termination EAP-Type |
If termination is enabled, click either EAP-PEAP or EAP-TLS to select a Extensible Authentication Protocol (EAP) method. |
|
Termination Inner EAP-Type |
If you are using EAP-PEAP as the EAP method, specify one of the following inner EAP types: l eap-gtc: Described in RFC 2284, this EAP method permits the transfer of unencrypted l usernames and passwords from client to server. The main uses for EAP-GTC are one-time token cards such as SecureID and the use of LDAP or RADIUS as the user authentication server. You can also enable caching of user credentials on the controller as a backup to an external authentication server. l eap-mschapv2: Described in RFC 2759, this EAP method is widely supported by Microsoft clients. |
|
Token Caching |
If you select EAP-GTC as the inner EAP method, you can select the Token Caching checkbox to enable the controllerto cache the username and password of each authenticated user. The controllercontinues to reauthenticate users with the remote authentication server, however, if the authentication server is not available, the controller will inspect its cached credentials to reauthenticate users. This option is disabled by default. |
|
Token Caching Period |
If you select EAP-GTC as the inner EAP method, you can specify the timeout period, in hours, for the cached information. The default value is 24 hours. |
|
CA-Certificate |
Click the CA-Certificatedrop-down list and select a certificate for client authentication. The CA certificate needs to be loaded in the controllerbefore it will appear on this list. |
|
Server-Certificate |
Click the Server-Certificatedrop-down list and select a server certificate the controller will use to authenticate itself to the client. |
|
TLS Guest Access |
Select TLS Guest Access to enable guest access for EAP-TLS users with valid certificates. This option is disabled by default. |
|
TLS Guest Role |
Click the TLS Guest Roledrop-down list and select the default user role for EAP-TLS guest users. Note: This option may require a license This option may require a license (see license descriptions at “License Types”). |
|
Ignore EAPOL-START after authentication |
Select Ignore EAPOL-STARTafter authentication to ignore EAPOL-START messages after authentication. This option is disabled by default. |
|
Handle EAPOL-Logoff |
Select Handle EAPOL-Logoffto enable handling of EAPOL-LOGOFF messages. This option is disabled by default. |
|
Ignore EAP ID during negotiation |
Select Ignore EAP ID during negotiationto ignore EAP IDs during negotiation. This option is disabled by default. |
|
WPA-Fast-Handover |
Select this option to enable WPA-fast-handover on phones that support this feature. WAP fast-handover is disabled by default. |
|
Disable rekey and reauthentication for clients on call |
This feature disables rekey and reauthentication for VoWLAN clients. It is disabled by default, meaning that rekey and reauthentication is enabled. Note: This option may require a license This option may require a license (see license descriptions at “License Types” ). |
7. Click Apply.
The following command configures settings for an 802.1x authentication profiles. Individual parameters are described in Table 53, above.
aaa authentication dot1x {<profile>|countermeasures}
ca-cert <certificate>
clear
clone <profile>
eapol-logoff
framed-mtu <mtu>
heldstate-bypass-counter <number>
ignore-eap-id-match
ignore-eapolstart-afterauthentication
machine-authentication blacklist-on-failure|{cache-timeout <hours>}|enable|
{machine-default-role <role>}|{user-default-role <role>}
max-authentication-failures <number>
max-requests <number>
multicast-keyrotation
no ...
opp-key-caching
reauth-max <number>
reauthentication
server {server-retry <number>|server-retry-period <seconds>}
server-cert <certificate>
termination {eap-type <type>}|enable|enable-token-caching|{inner-eap-type (eapgtc|
eap-mschapv2)}|{token-caching-period <hours>}
timer {idrequest_period <seconds>}|{mkey-rotation-period <seconds>}|{quiet-period
<seconds>}|{reauth-period <seconds>}|{ukey-rotation-period <seconds>}|{wpagroupkey-
delay <seconds>}|{wpa-key-period <milliseconds>}
tls-guest-access
tls-guest-role <role>
unicast-keyrotation
use-session-key
use-static-key
validate-pmkid
voice-aware
wep-key-retries <number>
wep-key-size {40|128}
wpa-fast-handover
wpa-key-retries <number>
xSec-mtu <mtu>
Configuring and Using Certificates with AAA FastConnect
The controllersupports 802.1x authentication using digital certificates for AAA FastConnect.
-
Server Certificate—A server certificate installed in the controllerverifies the authenticity of thecontrollerfor 802.1x authentication. Arubacontrollersship with a demonstration digital certificate. Until you install a customer-specific server certificate in the controller, this demonstration certificate is used by default for all secure HTTP connections (such as the WebUI and captive portal) and AAA FastConnect. This certificate is included primarily for the purposes of feature demonstration and convenience and is not intended for long-term use in production networks. Users in a production environment are urged to obtain and install a certificate issued for their site or domain by a well-known certificate authority (CA). You can generate a Certificate Signing Request (CSR) on the controllerto submit to a CA. For information on how to generate a CSR and how to import the CA-signed certificate into the controller, see “Managing Certificates”
-
Client Certificates—Client certificates are verified on the controller(the client certificate must be signed by a known CA) before the user name is checked on the authentication server. To use client certificate authentication for AAA FastConnect, you need to import the following certificates into the controller(see “Importing Certificates” :
-
Controller’s server certificate
-
CA certificate for the CA that signed the client certificates
1. Navigate to the Configuration >Security >Authentication > L2 Authentication page.
2. In the Profiles list, select 802.1x Authentication Profile.
3. Select the “default” 802.1x authentication profile from the drop-down menu to display configuration parameters.
4. In the Basictab, select Termination.
5. Select the Advanced Tab.
6. In the Server-Certificate field, select the server certificate imported into the controller.
7. In the CA-Certificate field, select the CA certificate imported into the controller.
8. Click Save As. Enter a name for the 802.1x authentication profile.
9. Click Apply.
aaa authentication dot1x <profile>
termination enable
server-cert <certificate>
ca-cert <certificate>
Configuring User and Machine Authentication
When a Windows device boots, it logs onto the network domain using a machine account. Within the domain, the device is authenticated before computer group policies and software settings can be executed; this process is known as machine authentication. Machine authentication ensures that only authorized devices are allowed on the network.
You can configure 802.1x for both user and machine authentication (select the Enforce Machine Authenticationoption described in Table 53 ). This tightens the authentication process further since both the device and user need to be authenticated.
Role Assignment with Machine Authentication Enabled
When you enable machine authentication, there are two additional roles you can define in the 802.1x authentication profile:
-
Machine authentication default machine role
-
Machine authentication default user role
While you can select the same role for both options, you should define the roles as per the polices that need to be enforced. Also, these roles can be different from the 802.1x authentication default role configured in the AAA profile.
With machine authentication enabled, the assigned role depends upon the success or failure of the machine and user authentications. In certain cases, the role that is ultimately assigned to a client can also depend upon attributes returned by the authentication server or server derivation rules configured on the controller.
Table 54 describes role assignment based on the results of the machine and user authentications.
For example, if the following roles are configured:
-
802.1x authentication default role (in AAA profile): dot1x_user
-
Machine authentication default machine role (in 802.1x authentication profile): dot1x_mc
-
Machine authentication default user role (in 802.1x authentication profile): guest
Role assignments would be as follows:
-
If both machine and user authentication succeed, the role is dot1x_user. If there is a server-derived role, the server-derived role takes precedence.
-
If only machine authentication succeeds, the role is dot1x_mc.
-
If only user authentication succeeds, the role is guest.
-
On failure of both machine and user authentication, the user does not have access to the network.
VLAN Assignment with Machine Authentication Enabled
With machine authentication enabled, the VLAN to which a client is assigned (and from which the client obtains its IP address) depends upon the success or failure of the machine and user authentications. The VLAN that is ultimately assigned to a client can also depend upon attributes returned by the authentication server or server derivation rules configured on the controller(see “About VLAN Assignments” ). If machine authentication is successful, the client is assigned the VLAN configured in the virtual AP profile. However, the client can be assigned a derived VLAN upon successful user authentication.
|
|
You can optionally assign a VLAN as part of a user role configuration. You should not use VLAN derivation if you configure user roles with VLAN assignments |
Table 55describes VLAN assignment based on the results of the machine and user authentications when VLAN derivation is used.
The following examples show basic configurations on the controller for:
-
“Authentication with an 802.1x RADIUS Server”
-
“Authentication with the Controller’s Internal Database”
In the following examples:
-
Wireless clients associate to the ESSID WLAN-01.
-
The following roles allow different networks access capabilities:
-
student
-
faculty
-
guest
-
system administrators
The examples show how to configure using the WebUI and CLI commands.
Authentication with an 802.1x RADIUS Server
-
An EAP-compliant RADIUS server provides the 802.1x authentication. The RADIUS server administrator must configure the server to support this authentication. The administrator must also configure the server to all communications with the Arubacontroller.
-
The authentication type is WPA. From the 802.1x authentication exchange, the client and the controllerderive dynamic keys to encrypt data transmitted on the wireless network.
-
802.1x authentication based on PEAP with MS-CHAPv2 provides both computer and user authentication. If a user attempts to log in without the computer being authenticated first, the user is placed into a more limited “guest” user role.
|
|
Appendix D, “802.1x Configuration for IAS and Windows Clients”describes how to configure the Microsoft Internet Authentication Server and Windows XP wireless client to operate with the controllerconfiguration shown in this section. |
Configuring Roles and Policies
You can create the following policies and user roles for:
-
Student
-
Faculty
-
Guest
-
Sysadming
-
Computer
Creating the student role and policy
The studentpolicy prevents students from using telnet, POP3, FTP, SMTP, SNMP, or SSH to the wired portion of the network. The studentpolicy is mapped to the student user role.
Using the WebUI
1. Navigate to the Configuration >Security >Access Control > Policies page. Select Addto add the student policy.
2. For Policy Name, enter student.
3. For Policy Type, select IPv4Session.
4. Under Rules, select Add to add rules for the policy.
a. Under Source, select user.
b. Under Destination, select alias.
|
|
The following step defines an alias representing all internal network addresses. Once defined, you can use the alias for other rules and policies. |
c. Under the alias selection, click New. For Destination Name, enter “Internal Network”. Click Addto add a rule. For Rule Type, select network. For IP Address, enter 10.0.0.0. For Network Mask/Range, enter 255.0.0.0. Click Addto add the network range. Repeat these steps to add the network range 172.16.0.0 255.255.0.0. Click Done. The alias “Internal Network” appears in the Destination menu. This step defines an alias representing all internal network addresses. Once defined, you can use the alias for other rules and policies.
d. Under Destination, select Internal Network.
e. Under Service, select service. In the Service scrolling list, select svc-telnet.
f. Under Action, select drop.
g. Click Add.
5. Under Rules, click Add.
a. Under Source, select user.
b. Under Destination, select alias. Then select Internal Network.
c. Under Service, select service. In the Service scrolling list, select svc-pop3.
d. Under Action, select drop.
e. Click Add.
6. Repeat steps 4A-E to create rules for the following services: svc-ftp, svc-smtp, svc-snmp, and svc-ssh.
7. Click Apply.
8. Click the User Roles tab. Click Add to create the student role.
9. For Role Name, enter student.
10. Under Firewall Policies, click Add. In Choose from Configured Policies, select the student policy you previously created. Click Done.
11. Click Apply.
Using the CLI
ip access-list session student
user alias “Internal Network” svc-telnet deny
user alias “Internal Network” svc-pop3 deny
user alias “Internal Network” svc-ftp deny
user alias “Internal Network” svc-smtp deny
user alias “Internal Network” svc-snmp deny
user alias “Internal Network” svc-ssh deny
user-role student
session-acl student
session-acl allowall
Creating the faculty role and policy
The facultypolicy is similar to the studentpolicy, however faculty members are allowed to use POP3 and SMTP for VPN remote access from home. (Students are not permitted to use VPN remote access.) The facultypolicy is mapped to the faculty user role.
Using the WebUI
1. Navigate to the Configuration >Security >Access Control > Policies page. Click Addto add the faculty policy.
2. For Policy Name, enter faculty.
3. For Policy Type, select IPv4Session.
4. Under Rules, click Add to add rules for the policy.
a. Under Source, select user.
b. Under Destination, select alias, then select Internal Network.
c. Under Service, select service. In the Service scrolling list, select svc-telnet.
d. Under Action, select drop.
e. Click Add.
f. Repeat steps A-E to create rules for the following services: svc-ftp, svc-snmp, and svc-ssh.
5. Click Apply.
6. Select the User Roles tab. Click Add to create the faculty role.
7. For Role Name, enter faculty.
8. Under Firewall Policies, click Add. In Choose from Configured Policies, select the faculty policy you previously created. Click Done.
Using the CLI
ip access-list session faculty
user alias “Internal Network” svc-telnet deny
user alias “Internal Network” svc-ftp deny
user alias “Internal Network” svc-snmp deny
user alias “Internal Network” svc-ssh deny
user-role faculty
session-acl faculty
session-acl allowall
Creating the guest role and policy
The guestpolicy permits only access to the Internet (via HTTP or HTTPS) and only during daytime working hours. The guestpolicy is mapped to the guest user role.
Using the WebUI
1. Navigate to the Configuration >Security >Access Control > Time Rangespage to define the time range “working-hours”. Click Add.
a. For Name, enter working-hours.
b. For Type, select Periodic.
c. Click Add.
d. For Start Day, click Weekday.
e. For Start Time, enter 07:30.
f. For End Time, enter 17:00.
g. Click Done.
h. Click Apply.
2. Click the Policies tab. Click Add to add the guest policy.
3. For Policy Name, enter guest.
4. For Policy Type, select IPv4Session.
5. Under Rules, click Add to add rules for the policy.
a. Under Source, select user.
b. Under Destination, select host. In Host IP, enter 10.1.1.25.
c. Under Service, select service. In the Service scrolling list, select svc-dhcp.
d. Under Action, select permit.
e. Under Time Range, select working-hours.
f. Click Add.
g. Repeat steps A-F to create a rule for svc-dns.
a. Under Source, select user.
b. Under Destination, select alias. Select Internal Network.
c. Under Service, select any.
d. Under Action, select drop.
e. Click Add.
a. Under Source, select user.
b. Under Destination, select any.
c. Under Service, select service. In the Services scrolling list, select svc-http.
d. Under Action, select permit.
e. Under Time Range, select working-hours.
f. Click Add.
g. Repeat steps A-F for the svc-https service.
a. Under Source, select user.
b. Under Destination, select any.
c. Under Service, select any.
d. Under Action, select drop.
e. Click Add.
6. Click Apply.
7. Click the User Roles tab. Click Add to create the guest role.
8. For Role Name, enter guest.
9. Under Firewall Policies, click Add. In Choose from Configured Policies, select the guest policy you previously created. Click Done.
Using the CLI
time-range working-hours periodic
weekday 07:30 to 17:00
ip access-list session guest
user host 10.1.1.25 svc-dhcp permit time-range working-hours
user host 10.1.1.25 svc-dns permit time-range working-hours
user alias “Internal Network” any deny
user any svc-http permit time-range working-hours
user any svc-https permit time-range working-hours
user any any deny
user-role guest
session-acl guest
Creating roles and policies for sysadmin and computer
-
The allowallpolicy, a predefined policy, allows unrestricted access to the network. The allowallpolicy is mapped to both the sysadminuser role and the computer user role.
Using the WebUI to create the sysadmin role
1. Navigate to Configuration >Security >Access Control > User Roles page. Click Addto create the sysadmin role.
2. For Role Name, enter sysadmin.
3. Under Firewall Policies, click Add. In Choose from Configured Policies, select the predefined allowallpolicy. Click Done.
4. Click Apply.
Using the CLI to create the sysadmin role
user-role sysadmin
session-acl allowall
Using the WebUI to create the computer role
1. Navigate to Configuration >Security >Access Control > User Roles page. Click Addto create the computer role.
2. For Role Name, enter computer.
3. Under Firewall Policies, click Add. In Choose from Configured Policies, select the predefined allowallpolicy. Click Done.
4. Click Apply.
Using the CLI to create the computer role
user-role computer
session-acl allowall
Creating an alias for the internal network using CLI
netdestination “Internal Network”
network 10.0.0.0 255.0.0.0
network 172.16.0.0 255.255.0.0
Configuring the RADIUS Authentication Server
Configure the RADIUS server IAS1, with IP address 10.1.1.21 and shared key. The RADIUS server is configured to sent an attribute called Class to the controller; the value of this attribute is set to either “student,” “faculty,” or “sysadmin” to identify the user’s group. The controlleruses the literal value of this attribute to determine the role name.
On the controller, you add the configured server (IAS1) into a server group. For the server group, you configure the server rule that allows the Class attribute returned by the server to set the user role.
1. Navigate to the Configuration >Security >Authentication > Servers page.
2. In the Servers list, select Radius Server. In the RADIUS Server Instance list, enter IAS1and click Add.
a. Select IAS1 to display configuration parameters for the RADIUS server.
b. For IP Address, enter 10.1.1.21.
c. For Key, enter |*a^t%183923!. (You must enter the key string twice.)
d. Click Apply.
3. In the Servers list, select Server Group. In the Server Group Instance list, enter IASand click Add.
a. Select the server group IAS to display configuration parameters for the server group.
b. Under Servers, click New.
c. From the Server Name drop-down menu, select IAS1. Click Add Server.
4. Under Server Rules, click New.
a. For Condition, enter Class.
b. For Attribute, select value-of from the drop-down menu.
c. For Operand, select set role.
d. Click Add.
5. Click Apply.
aaa authentication-server radius IAS1
host 10.1.1.21
key |*a^t%183923!
aaa server-group IAS
auth-server IAS1
set role condition Class value-of
Configure 802.1x Authentication
An AAA profile specifies the 802.1x authentication profile and 802.1x server group to be used for authenticating clients for a WLAN. The AAA profile also specifies the default user roles for 802.1x and MAC authentication.
In the 802.1x authentication profile, configure enforcement of machine authentication before user authentication. If a user attempts to log in without machine authentication taking place first, the user is placed in the limited guest role.
1. Navigate to the Configuration >Security >Authentication > L2 Authentication page.
2. Select 802.1x Authentication Profile.
a. In the list of instances, enter dot1x, then click Add.
b. Select the profile name you just added.
c. Select Enforce Machine Authentication.
d. For the Machine Authentication: Default Machine Role, select computer.
e. For the Machine Authentication: Default User Role, select guest.
f. Click Apply.
3. Select the AAA Profiles tab.
a. In the AAA Profiles Summary, click Add to add a new profile.
b. Enter aaa_dot1x, then click Add.
a. Select the profile name you just added.
b. For MAC Auth Default Role, select computer.
c. For 802.1x Authentication Default Role, select faculty.
d. Click Apply.
4. In the Profiles list (under the aaa_dot1x profile), select 802.1x Authentication Profile.
a. From the drop-down menu, select the dot1x 802.1x authentication profile you configured previously.
b. Click Apply.
5. In the Profiles list (under the aaa_dot1x profile), select 802.1x Authentication Server Group.
a. From the drop-down menu, select the IAS server group you created previously.
b. Click Apply.
aaa authentication dot1x dot1x
machine-authentication enable
machine-authentication machine-default-role computer
machine-authentication user-default-role guest
aaa profile aaa_dot1x
dot1x-default-role faculty
mac-default-role computer
authentication-dot1x dot1x
dot1x-server-group IAS
In this example, wireless clients are assigned to either VLAN 60 or 61 while guest users are assigned to VLAN 63. VLANs 60 and 61 split users into smaller IP subnetworks, improving performance by decreasing broadcast traffic. The VLANs are internal to the Arubacontrolleronly and do not extend into other parts of the wired network. The clients’ default gateway is the Arubacontroller, which routes traffic out to the 10.1.1.0 subnetwork.
You configure the VLANs, assign IP addresses to each VLAN, and establish the “helper address” to which client DHCP requests are forwarded.
1. Navigate to the Configuration >Network > VLANspage. Click Add to add VLAN 60.
a. For VLAN ID, enter 60.
b. Click Apply.
c. Repeat steps A and B to add VLANs 61 and 63.
2. To configure IP parameters for the VLANs, navigate to the Configuration >Network >IP > IP Interfaces page.
a. Click Edit for VLAN 60.
b. For IP Address, enter 10.1.60.1.
c. For Net Mask, enter 255.255.255.0.
d. Under DHCP Helper Address, click Add. Enter 10.1.1.25and click Add.
e. Click Apply.
3. In the IP Interfaces page, click Edit for VLAN 61.
a. For IP Address, enter 10.1.61.1.
b. For Net Mask, enter 255.255.255.0.
c. Under DHCP Helper Address, click Add. Enter 10.1.1.25and click Add.
d. Click Apply.
4. In the IP Interfaces page, click Edit for VLAN 63.
a. For IP Address, enter 10.1.63.1.
b. For Net Mask, enter 255.255.255.0.
c. Under DHCP Helper Address, click Add. Enter 10.1.1.25and click Add.
d. Click Apply.
5. Select the IP Routes tab.
a. For Default Gateway, enter 10.1.1.254.
b. Click Apply.
vlan 60
interface vlan 60
ip address 10.1.60.1 255.255.255.0
ip helper-address 10.1.1.25
vlan 61
interface vlan 61
ip address 10.1.61.1 255.255.255.0
ip helper-address 10.1.1.25
vlan 63
interface vlan 63
ip address 10.1.63.1 255.255.255.0
ip helper-address 10.1.1.25
ip default-gateway 10.1.1.254
In this example, default AP parameters for the entire network are as follows: the default ESSID is WLAN-01 and the encryption mode is TKIP. A second ESSID called “guest” has the encryption mode set to static WEP with a configured WEP key.
In this example, the non-guest clients that associate to an AP are mapped into one of two different user VLANs. The initial AP to which the client associates determines the VLAN: clients that associate to APs in the first floor of the building are mapped to VLAN 60 and clients that associate to APs in the second floor of the building are mapped to VLAN 61. Therefore, the APs in the network are segregated into two AP groups, named “first-floor” and “second-floor”. (See “AP Groups for information about creating AP groups.) The guest clients are mapped into VLAN 63.
You create and configure the virtual AP profile “guest” and apply the profile to each AP group. The “guest” virtual AP profile contains the SSID profile “guest” which configures static WEP with a WEP key.
1. Navigate to the Configuration >Wireless > AP Configuration page.
2. In the AP Group list, click Edit for first-floor.
3. Under Profiles, select Wireless LAN, then select Virtual AP.
4. To create the guest virtual AP:
a. Select NEW from the Add a profile drop-down menu. Enter guest, and click Add.
b. In the Profile Details entry for the guest virtual AP profile, select NEW from the SSID profile drop-down menu. A pop-up window allows you to configure the SSID profile.
c. For the name for the SSID profile enter guest.
d. For the Network Name for the SSID, enter guest.
e. For Network Authentication, select None.
f. For Encryption, select WEP.
g. Enter the WEP Key.
h. Click Apply to apply the SSID profile to the Virtual AP.
i. Under Profile Details, click Apply.
5. Click on the guestvirtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select 63.
c. Click Apply.
6. Navigate to the Configuration >Wireless > AP Configuration page.
7. In the AP Group list, click Edit for the second-floor.
8. In the Profiles list, select Wireless LAN, then select Virtual AP.
9. Select guestfrom the Add a profile drop-down menu. Click Add.
10. Click Apply.
wlan ssid-profile guest
essid guest
wepkey1 aaaaaaaaaa
opmode static-wep
wlan virtual-ap guest
vlan 63
ssid-profile guest
ap-group first-floor
virtual-ap guest
ap-group second-floor
virtual-ap guest
Configuring the Non-Guest WLANs
You create and configure the SSID profile “WLAN-01” with the ESSID “WLAN-01” and WPA TKIP encryption. You need to create and configure two virtual AP profiles: one with VLAN 60 for the first-floor AP group and the other with VLAN 61 for the second-floor AP group. Each virtual AP profile references the SSID profile “WLAN-01” and the previously-configured AAA profile “aaa_dot1x”.
1. Navigate to the Configuration >Wireless > AP Configuration page.
2. In the AP Group list, click Edit for the first-floor.
3. In the Profiles list, select Wireless LAN, then select Virtual AP.
4. To configure the WLAN-01_first-floor virtual AP:
a. Select NEW from the Add a profile drop-down menu. Enter WLAN-01_first-floor, and click Add.
b. In the Profile Details entry for the WLAN-01_first-floor virtual AP profile, select the aaa_dot1xAAA profile you previously configured. A pop-up window displays the configured AAA profile parameters. Click Apply in the pop-up window.
c. From the SSID profile drop-down menu, select NEW. A pop-up window allows you to configure the SSID profile.
d. Enter WLAN-01 for the name of the SSID profile.
e. For Network Name, enter WLAN-01.
f. For Network Authentication, select WPA.
g. Click Apply in the pop-up window.
h. At the bottom of the Profile Details page, click Apply.
5. Click on the WLAN-01_first-floor virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select 60.
c. Click Apply.
6. Navigate to the Configuration >Wireless > AP Configuration page.
7. In the AP Group list, click Edit for the second-floor.
8. In the Profiles list, select Wireless LAN, then select Virtual AP.
9. To configure the WLAN-01_second-floor virtual AP:
a. Select NEW from the Add a profile drop-down menu. Enter WLAN-second-floor, and click Add.
b. In the Profile Details entry for the virtual AP profile, select aaa_dot1x from the AAA profile drop-down menu. A pop-up window displays the configured AAA profile parameters. Click Applyin the pop-up window.
c. From the SSID profile drop-down menu, select WLAN-01. A pop-up window displays the configured SSID profile parameters. Click Apply in the pop-up window.
d. At the bottom of the Profile Details page, click Apply.
10. Click on the new virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select 61.
c. Click Apply.
wlan ssid-profile WLAN-01
essid WLAN-01
opmode wpa-tkip
wlan virtual-ap WLAN-01_first-floor
vlan 60
aaa-profile aaa_dot1x
ssid-profile WLAN-01
wlan virtual-ap WLAN-01_second-floor
vlan 61
aaa-profile aaa_dot1x
ssid-profile WLAN-01
ap-group first-floor
virtual-ap WLAN-01_first-floor
ap-group second-floor
virtual-ap WLAN-01_second-floor
Authentication with the Controller’s Internal Database
In the following example:
-
The controller’s internal database provides user authentication.
-
The authentication type is WPA. From the 802.1x authentication exchange, the client and the controllerderive dynamic keys to encrypt data transmitted on the wireless network.
Configuring the Internal Database
Configure the internal database with the username, password, and role (student, faculty, or sysadmin) for each user. There is a default internalserver group that includes the internal database. For the internal server group, configure a server derivation rule that assigns the role to the authenticated client.
1. Navigate to the Configuration >Security >Authentication > Servers page.
2. In the Servers list, select Internal DB.
3. Under Users, click Add User to add users.
4. For each user, enter a username and password.
5. Select the Role for each user (if a role is not specified, the default role is guest).
6. Select the expiration time for the user account in the internal database.
7. Click Apply.
|
|
Use the privileged mode in the CLI to configure users in the controller’s internal database. |
local-userdb add username <user> password <password>
Configuring a server rule using the WebUI
1. Navigate to the Configuration >Security >Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Select the internal server group.
4. Under Server Rules, click New to add a server derivation rule.
a. For Condition, enter Role.
b. Select value-of from the drop-down menu.
c. Select Set Role from the drop-down menu.
d. Click Add.
5. Click Apply.
Configuring a server rule using the CLI
aaa server-group internal
set role condition Role value-of
Configure 802.1x Authentication
An AAA profile specifies the 802.1x authentication profile and 802.1x server group to be used for authenticating clients for a WLAN. The AAA profile also specifies the default user role for 802.1x authentication.
For this example, you enable both 802.1x authentication and termination on the controller.
1. Navigate to the Configuration >Security >Authentication > L2 Authentication page. In the profiles list, select 802.1x Authentication Profile.
a. In the Instance list, enter dot1x, then click Add.
b. Select the dot1x profile you just created.
c. Select Termination.
|
|
The defaults for EAP Method and Inner EAP Method are EAP-PEAP and EAP-MSCHAPv2, respectively. |
d. Click Apply.
2. Select the AAA Profiles tab.
a. In the AAA Profiles Summary, click Add to add a new profile.
b. Enter aaa_dot1x, then click Add.
c. Select the aaa_dot1x profile you just created.
d. For 802.1x Authentication Default Role, select faculty.
e. Click Apply.
3. In the Profiles list (under the aaa_dot1x profile you just created), select 802.1x Authentication Profile.
a. Select the dot1x profile from the 802.1x Authentication Profile drop-down menu.
b. Click Apply.
4. In the Profiles list (under the aaa_dot1x profile you just created), select 802.1x Authentication Server Group.
a. Select the internal server group.
b. Click Apply.
aaa authentication dot1x dot1x
termination enable
aaa profile aaa_dot1x
dot1x-default-role student
authentication-dot1x dot1x
dot1x-server-group internal
In this example, wireless clients are assigned to either VLAN 60 or 61 while guest users are assigned to VLAN 63. VLANs 60 and 61 split users into smaller IP subnetworks, improving performance by decreasing broadcast traffic. The VLANs are internal to the Arubacontrolleronly and do not extend into other parts of the wired network. The clients’ default gateway is the Arubacontroller, which routes traffic out to the 10.1.1.0 subnetwork.
You configure the VLANs, assign IP addresses to each VLAN, and establish the “helper address” to which client DHCP requests are forwarded.
1. Navigate to the Configuration >Network > VLANpage. Click Add to add VLAN 60.
a. For VLAN ID, enter 60.
b. Click Apply.
c. Repeat steps A and B to add VLANs 61 and 63.
2. To configure IP parameters for the VLANs, navigate to the Configuration >Network >IP > IP Interfaces page.
a. Click Edit for VLAN 60.
b. For IP Address, enter 10.1.60.1.
c. For Net Mask, enter 255.255.255.0.
d. Under DHCP Helper Address, click Add. Enter 10.1.1.25and click Add.
e. Click Apply.
3. In the IP Interfaces page, click Edit for VLAN 61.
a. For IP Address, enter 10.1.61.1.
b. For Net Mask, enter 255.255.255.0.
c. Under DHCP Helper Address, click Add. Enter 10.1.1.25and click Add.
d. Click Apply.
4. In the IP Interfaces page, click Edit for VLAN 63.
a. For IP Address, enter 10.1.63.1.
b. For Net Mask, enter 255.255.255.0.
c. Under DHCP Helper Address, click Add. Enter 10.1.1.25and click Add.
d. Click Apply.
5. Select the IP Routes tab.
a. For Default Gateway, enter 10.1.1.254.
b. Click Apply.
vlan 60
interface vlan 60
ip address 10.1.60.1 255.255.255.0
ip helper-address 10.1.1.25
vlan 61
interface vlan 61
ip address 10.1.61.1 255.255.255.0
ip helper-address 10.1.1.25
vlan 63
interface vlan 63
ip address 10.1.63.1 255.255.255.0
ip helper-address 10.1.1.25
ip default-gateway 10.1.1.254
In this example, default AP parameters for the entire network are as follows: the default ESSID is WLAN-01 and the encryption mode is TKIP. A second ESSID called “guest” has the encryption mode set to static WEP with a configured WEP key.
In this example, the non-guest clients that associate to an AP are mapped into one of two different user VLANs. The initial AP to which the client associates determines the VLAN: clients that associate to APs in the first floor of the building are mapped to VLAN 60 and clients that associate to APs in the second floor of the building are mapped to VLAN 61. Therefore, the APs in the network are segregated into two AP groups, named “first-floor” and “second-floor”. (See “AP Groups” for information about creating AP groups.) The guest clients are mapped into VLAN 63.
You create and configure the virtual AP profile “guest” and apply the profile to each AP group. The “guest” virtual AP profile contains the SSID profile “guest” which configures static WEP with a WEP key.
1. Navigate to the Configuration >Wireless > AP Configuration page.
2. In the AP Group list, select first-floor.
3. In the Profiles list, select Wireless LAN then select Virtual AP.
4. To configure the guest virtual AP:
a. Select NEW from the Add a profile drop-down menu. Enter guestfor the name of the virtual AP profile, and click Add.
b. In the Profile Details entry for the guest virtual AP profile, select NEW from the SSID profile drop-down menu. A pop-up window allows you to configure the SSID profile.
c. Enter guest for the name of the SSID profile.
d. Enter guest for the Network Name.
e. For Network Authentication, select None.
f. For Encryption, select WEP.
g. Enter the WEP key.
h. Click Apply.
i. Under Profile Details, click Apply.
5. Click on the guest virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select 63.
c. Click Apply.
6. Navigate to the Configuration >Wireless > AP Configuration page.
7. In the AP Group list, select second-floor.
8. In the Profiles list, select Wireless LAN, then select Virtual AP.
9. Select guestfrom the Add a profile drop-down menu. Click Add.
10. Click Apply.
wlan ssid-profile guest
essid guest
wepkey1 aaaaaaaaaa
opmode static-wep
wlan virtual-ap guest
vlan 63
ssid-profile guest
ap-group first-floor
virtual-ap guest
ap-group second-floor
virtual-ap guest
Configuring the Non-Guest WLANs
You create and configure the SSID profile “WLAN-01” with the ESSID “WLAN-01” and WPA TKIP encryption. You need to create and configure two virtual AP profiles: one with VLAN 60 for the first-floor AP group and the other with VLAN 61 for the second-floor AP group. Each virtual AP profile references the SSID profile “WLAN-01” and the previously-configured AAA profile “aaa_dot1x”.
1. Navigate to the Configuration >Wireless > AP Configuration page.
2. In the AP Group list, select first-floor.
3. In the Profiles list, select Wireless LAN, then select Virtual AP.
4. To configure the WLAN-01_first-floor virtual AP:
a. Select NEW from the Add a profile drop-down menu. Enter WLAN-01_first-floor, and click Add.
b. In the Profile Details entry for the WLAN-01_first-floor virtual AP profile, select aaa_dot1xfrom the AAA Profile drop-down menu. A pop-up window displays the configured AAA parameters. Click Apply in the pop-up window.
c. From the SSID profile drop-down menu, select NEW. A pop-up window allows you to configure the SSID profile.
d. Enter WLAN-01 for the name of the SSID profile.
e. Enter WLAN-01 for the Network Name.
f. Select WPA for Network Authentication.
g. Click Apply in the pop-up window.
h. At the bottom of the Profile Details page, click Apply.
5. Click on the WLAN-01_first-floor virtual AP profile name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select 60.
c. Click Apply.
6. Navigate to the Configuration >Wireless > AP Configuration page.
7. In the AP Group list, select second-floor.
8. In the Profiles list, select Wireless LAN then select Virtual AP.
9. To create the WLAN-01_second-floor virtual AP:
a. Select NEW from the Add a profile drop-down menu. Enter WLAN-01_second-floor, and click Add.
b. In the Profile Details entry for the virtual AP profile, select aaa_dot1x from the AAA Profile drop-down menu. A pop-up window displays the configured AAA profile parameters. Click Applyin the pop-up window.
c. From the SSID profile drop-down menu, select WLAN-01. a pop-up window displays the configured SSID profile parameters. Click Apply in the pop-up window.
d. At the bottom of the Profile Details page, click Apply.
10. Click on the WLAN-01_second-floor virtual AP profile name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select 61.
c. Click Apply.
wlan ssid-profile WLAN-01
essid WLAN-01
opmode wpa-tkip
wlan virtual-ap WLAN-01_first-floor
vlan 60
aaa-profile aaa_dot1x
ssid-profile WLAN-01
wlan virtual-ap WLAN-01_second-floor
vlan 61
aaa-profile aaa_dot1x
ssid-profile WLAN-01
ap-group first-floor
virtual-ap WLAN-01_first-floor
ap-group second-floor
virtual-ap WLAN-01_second-floor
Advanced Configuration Options for 802.1x
This section describes advanced configuration options for 802.1x authentication.
Configuring reauthentication with Unicast Key Rotation
When enabled, unicast and multicast keys are updated after each reauthorization. It is a best practice to configure the time intervals for reauthentication, multicast key rotation, and unicast key rotation to be at least 15 minutes. Make sure these intervals are mutually prime, and the factor of the unicast key rotation interval and the multicast key rotation interval is less than the reauthentication interval.
|
|
Unicast key rotation depends upon both the AP/controllerand wireless client behavior. It is known that some wireless NICs have issues with unicast key rotation. |
The following is an example of the parameters you can configure for reauthentication with unicast and multicast key rotation:
-
Reauthentication: Enabled
-
Reauthentication Time Interval: 6011 Seconds
-
Multicast Key Rotation: Enabled
-
Multicast Key Rotation Time Interval: 1867 Seconds
-
Unicast Key Rotation: Enabled
-
Unicast Key Rotation Time Interval: 1021 Seconds
1. Navigate to the Configuration >Security >Authentication > L2 Authentication page.
2. Select 802.1x Authentication Profile, then select the name of the profile you want to configure.
3. Select the Advanced tab. Enter the following values:
-
Reauthentication Interval: 6011
-
Multicast Key Rotation Time Interval: 1867
-
Unicast Key Rotation Time Interval: 1021
-
Multicast Key Rotation: (select)
-
Unicast Key Rotation: (select)
-
Reauthentication: (select)
4. Click Apply.
aaa authentication dot1x profile
reauthentication
timer reauth-period 6011
unicast-keyrotation
timer ukey-rotation-period 1021
multicast-keyrotation
timer mkey-rotation-period 1867