- Table of Contents
-
- 07-Security Configuration Guide
- 00-Preface
- 01-Security Overview
- 02-AAA Configuration
- 03-802.1X Configuration
- 04-MAC Authentication Configuration
- 05-Portal Configuration
- 06-Port Security Configuration
- 07-User Profile Configuration
- 08-Password Control Configuration
- 09-Public Key Configuration
- 10-PKI Configuration
- 11-SSH Configuration
- 12-SSL Configuration
- 13-SSL VPN Configuration
- 14-TCP Attack Protection Configuration
- 15-ARP Attack Protection Configuration
- 16-IPsec Configuration
- 17-ALG Configuration
- 18-Firewall Configuration
- 19-Session Management Configuration
- 20-Web Filtering Configuration
- 21-User Isolation Configuration
- 22-Source IP Address Verification Configuration
- 23-FIPS Configuration
- 24-Protocol Packet Rate Limit Configuration
- 25-Attack detection and protection configuration
- Related Documents
-
Title | Size | Download |
---|---|---|
03-802.1X Configuration | 324.45 KB |
Controlled/uncontrolled port and port authorization status
Initiating 802.1X authentication
802.1X client as the initiator
Access device as the initiator
802.1X authentication procedures
Comparing EAP relay and EAP termination
Using 802.1X authentication with other features
802.1X configuration task list
Enabling EAP relay or EAP termination
Setting the port authorization state
Specifying an access control method
Setting the maximum number of concurrent 802.1X users on a port
Setting the maximum number of authentication request attempts
Setting the 802.1X authentication timeout timers
Configuring the online user handshake feature
Configuring the authentication trigger feature
Specifying a mandatory authentication domain on a port
Enabling the periodic online user re-authentication feature
Configuring an 802.1X guest VLAN
Specifying supported domain name delimiters
Configuring the accounting delay feature
Displaying and maintaining 802.1X
802.1X with ACL assignment configuration example
802.1X overview
802.1X is a port-based network access control protocol initially proposed by the IEEE 802 LAN/WAN committee for securing WLANs. It has also been widely used on Ethernet networks for access control.
802.1X controls network access by authenticating the devices connected to 802.1X-enabled LAN ports.
802.1X architecture
802.1X operates in the client/server model. It includes three entities: the client (the supplicant), the network access device (the authenticator), and the authentication server.
Figure 1 802.1X architecture
· Client—A user terminal seeking access to the LAN. It must have 802.1X software to authenticate to the network access device.
· Network access device—Authenticates the client to control access to the LAN. In a typical 802.1X environment, the network access device uses an authentication server to perform authentication.
· Authentication server—Provides authentication services for the network access device. The authentication server authenticates 802.1X clients by using the data sent from the network access device, and returns the authentication results for the network access device to make access decisions. The authentication server is typically a RADIUS server. In a small LAN, you can also use the network access device as the authentication server.
Controlled/uncontrolled port and port authorization status
802.1X defines two logical ports for the network access port: controlled port and uncontrolled port. Any packet arriving at the network access port is visible to both logical ports.
· Uncontrolled port—Is always open to receive and transmit EAPOL frames.
· Controlled port—Filters packets depending on the port's state:
¡ Authorized state—The controlled port is in authorized state when the client has passed authentication. It allows traffic to pass through.
¡ Unauthorized state—The port is in unauthorized state when the client has failed authentication. It controls traffic in one of the following ways:
- Performs bidirectional traffic control to deny traffic to and from the client.
- Performs unidirectional traffic control to deny traffic from the client. The H3C devices support only unidirectional traffic control.
Figure 2 Authorization state of a controlled port
802.1X-related protocols
802.1X uses the Extensible Authentication Protocol (EAP) to transport authentication information for the client, the network access device, and the authentication server. EAP is an authentication framework that uses the client/server model. It supports a variety of authentication methods, including MD5-Challenge, EAP-Transport Layer Security (EAP-TLS), and Protected EAP (PEAP).
802.1X defines EAP over LAN (EAPOL) for passing EAP packets between the client and the network access device over a wired or wireless LAN. Between the network access device and the authentication server, 802.1X delivers authentication information in one of the following methods:
· Encapsulates EAP packets in RADIUS by using EAP over RADIUS (EAPOR), as described in "EAP relay."
· Extracts authentication information from the EAP packets and encapsulates the information in standard RADIUS packets, as described in "EAP termination."
Packet formats
EAP packet format
Figure 3 shows the EAP packet format.
· Code—Type of the EAP packet. Options include Request (1), Response (2), Success (3), or Failure (4).
· Identifier—Used for matching Responses with Requests.
· Length—Length (in bytes) of the EAP packet. The length is the sum of the Code, Identifier, Length, and Data fields.
· Data—Content of the EAP packet. This field appears only in a Request or Response EAP packet. The Data field comprises the request type (or the response type) and the type data. Type 1 (Identify) and type 4 (MD5-challenge) are two examples for the type field.
EAPOL packet format
Figure 4 shows the EAPOL packet format.
· PAE Ethernet type—Protocol type. It takes the value 0x888E for EAPOL.
· Protocol version—The EAPOL protocol version used by the EAPOL packet sender.
· Type—Type of the EAPOL packet. Table 1 lists the types of EAPOL packets supported by H3C implementation of 802.1X.
Table 1 Types of EAPOL packets
Value |
Type |
Description |
0x00 |
EAP-Packet |
The client and the network access device uses EAP-Packets to transport authentication information. |
0x01 |
EAPOL-Start |
The client sends an EAPOL-Start message to initiate 802.1X authentication to the network access device. |
0x02 |
EAPOL-Logoff |
The client sends an EAPOL-Logoff message to tell the network access device that it is logging off. |
· Length—Data length in bytes, or length of the Packet body. If packet type is EAPOL-Start or EAPOL-Logoff, this field is set to 0, and no Packet body field follows.
· Packet body—Content of the packet. When the EAPOL packet type is EAP-Packet, the Packet body field contains an EAP packet.
EAP over RADIUS
RADIUS adds two attributes, EAP-Message and Message-Authenticator, for supporting EAP authentication. For the RADIUS packet format, see "Configuring AAA."
EAP-Message
RADIUS encapsulates EAP packets in the EAP-Message attribute, as shown in Figure 5. The Type field takes 79, and the Value field can be up to 253 bytes. If an EAP packet is longer than 253 bytes, RADIUS encapsulates it in multiple EAP-Message attributes.
Figure 5 EAP-Message attribute format
Message-Authenticator
RADIUS includes the Message-Authenticator attribute in all packets that have an EAP-Message attribute to check their integrity. The packet receiver drops the packet if the calculated packet integrity checksum is different from the Message-Authenticator attribute value. The Message-Authenticator prevents EAP authentication packets from being tampered with during EAP authentication.
Figure 6 Message-Authenticator attribute format
Initiating 802.1X authentication
Both the 802.1X client and the access device can initiate 802.1X authentication.
802.1X client as the initiator
The client sends an EAPOL-Start packet to the access device to initiate 802.1X authentication. The destination MAC address of the packet is the IEEE 802.1X specified multicast address 01-80-C2-00-00-03 or the broadcast MAC address. If any intermediate device between the client and the authentication server does not support the multicast address, use an 802.1X client, the H3C iNode 802.1X client for example, that can send broadcast EAPOL-Start packets.
Access device as the initiator
The access device initiates authentication if a client cannot send EAPOL-Start packets. One example is the 802.1X client available with Windows XP.
The access device supports the following modes:
· Multicast trigger mode—The access device multicasts Identity EAP-Request packets periodically (every 30 seconds by default) to initiate 802.1X authentication.
· Unicast trigger mode—Upon receiving a frame with the source MAC address not in the MAC address table, the access device sends an Identity EAP-Request packet out of the receiving port to the unknown MAC address. It retransmits the packet if no response has been received within a certain time interval.
802.1X authentication procedures
802.1X authentication provides two methods: EAP relay and EAP termination. You choose either mode depending on the support of the RADIUS server for EAP packets and EAP authentication methods.
· EAP relay mode:
EAP relay is defined in IEEE 802.1X. In this mode, the network device uses EAPoR packets to send authentication information to the RADIUS server, as shown in Figure 7.
In EAP relay mode, the client must use the same authentication method as the RADIUS server. On the network access device, you only need to use the dot1x authentication-method eap command to enable EAP relay.
Some network access devices provide the EAP server feature so you can use EAP relay even if the RADIUS server does not support any EAP authentication method or no RADIUS server is available. For the local EAP authentication configuration procedure, see "Configuring AAA."
· EAP termination mode:
In EAP termination mode, the network access device terminates the EAP packets received from the client, encapsulates the client authentication information in standard RADIUS packets, and uses PAP or CHAP to authenticate to the RADIUS server, as shown in Figure 8.
Comparing EAP relay and EAP termination
Packet exchange method |
Benefits |
Limitations |
EAP relay |
· Supports various EAP authentication methods. · The configuration and processing is simple on the network access device. |
The RADIUS server must support the EAP-Message and Message-Authenticator attributes, and the EAP authentication method used by the client. |
EAP termination |
Works with any RADIUS server that supports PAP or CHAP authentication. |
· Supports only MD5-Challenge EAP authentication and the "username + password" EAP authentication initiated by an H3C iNode 802.1X client. · The processing is complex on the network access device. |
EAP relay
Figure 9 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that EAP-MD5 is used.
Figure 9 802.1X authentication procedure in EAP relay mode
1. When a user launches the 802.1X client software and enters a registered username and password, the 802.1X client software sends an EAPOL-Start packet to the network access device.
2. The network access device responds with an Identity EAP-Request packet to ask for the client username.
3. In response to the Identity EAP-Request packet, the client sends the username in an Identity EAP-Response packet to the network access device.
4. The network access device relays the Identity EAP-Response packet in a RADIUS Access-Request packet to the authentication server.
5. The authentication server uses the identity information in the RADIUS Access-Request to search its user database. If a matching entry is found, the server uses a randomly generated challenge (EAP-Request/MD5 challenge) to encrypt the password in the entry, and sends the challenge in a RADIUS Access-Challenge packet to the network access device.
6. The network access device relays the EAP-Request/MD5 Challenge packet in a RADIUS Access-Request packet to the client.
7. The client uses the received challenge to encrypt the password, and sends the encrypted password in an EAP-Response/MD5 Challenge packet to the network access device.
8. The network access device relays the EAP-Response/MD5 Challenge packet in a RADIUS Access-Request packet to the authentication server.
9. The authentication server compares the received encrypted password with the one it generated at step 5. If the two are identical, the authentication server considers the client valid and sends a RADIUS Access-Accept packet to the network access device.
10. Upon receiving the RADIUS Access-Accept packet, the network access device sends an EAP-Success packet to the client, and sets the controlled port in the authorized state so the client can access the network.
11. After the client comes online, the network access device periodically sends handshake requests to check whether the client is still online. By default, if two consecutive handshake attempts fail, the device logs off the client.
13. The client can also send an EAPOL-Logoff packet to ask the network access device for a logoff.
14. In response to the EAPOL-Logoff packet, the network access device changes the status of the controlled port from authorized to unauthorized and sends an EAP-Failure packet to the client.
EAP termination
Figure 10 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that CHAP authentication is used.
Figure 10 802.1X authentication procedure in EAP termination mode
In EAP termination mode, the network access device rather than the authentication server generates an MD5 challenge for password encryption (see Step 4). The network access device then sends the MD5 challenge together with the username and encrypted password in a standard RADIUS packet to the RADIUS server.
Configuring 802.1X
This chapter describes how to configure 802.1X on an H3C device. You can also configure the port security feature to perform 802.1X. Port security combines and extends 802.1X and MAC authentication. It applies to a network (for example, a WLAN) that requires different authentication methods for different users on a port. For more information about port security, see "Configuring port security."
H3C implementation of 802.1X
Access control methods
H3C implements port-based access control as defined in the 802.1X protocol, and extends the protocol to support MAC-based access control.
· Port-based access control—Once an 802.1X user passes authentication on a port, any subsequent user can access the network through the port without authentication. When the authenticated user logs off, all other users are logged off.
· MAC-based access control—Each user is separately authenticated on a port. When a user logs off, no other online users are affected.
802.1X stateful failover
Support for this feature depends on the device model. For more information, see About the H3C Access Controllers Configuration Guides.
802.1X stateful failover enables two stateful failover ACs to back up 802.1X sessions in real time on WLAN interfaces. When a primary/backup AC switchover occurs, the backup AC can immediately take over to provide 802.1X services without disrupting 802.1X sessions. To configure 802.1X stateful failover, enable port security stateful failover. For more information, see "Configuring port security."
Using 802.1X authentication with other features
VLAN assignment
You can configure the authentication server to assign a VLAN for an 802.1X user that has passed authentication. The way that the network access device handles VLANs on an 802.1X-enabled port differs by 802.1X access control mode.
Access control |
VLAN manipulation |
Port-based |
Assigns the VLAN to the port as the port VLAN (PVID). The authenticated 802.1X user and all subsequent 802.1X users can access the VLAN without authentication. When the user logs off, the previous PVID restores, and all other online users are logged off. |
MAC-based |
· If the port is a hybrid port with MAC-based VLAN enabled, maps the MAC address of each user to the VLAN assigned by the authentication server. The PVID of the port does not change. When a user logs off, the MAC-to-VLAN mapping for the user is removed. · If the port is an access, trunk, or MAC-based VLAN disabled hybrid port, assigns the first authenticated user's VLAN to the port as the PVID. If a different VLAN is assigned to a subsequent user, the user cannot pass the authentication. To avoid the authentication failure of subsequent users, be sure to assign the same VLAN to all 802.1X users on these ports. |
With 802.1X authentication, a hybrid port is always assigned to a VLAN as an untagged member. After the assignment, do not reconfigure the port as a tagged member in the VLAN.
On a periodic online user re-authentication enabled port, if a user has been online before you enable the MAC-based VLAN feature, the access device does not create a MAC-to-VLAN mapping for the user unless the user passes re-authentication and the VLAN for the user has changed.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2 Configuration Guide.
Guest VLAN
You can configure a guest VLAN on a port to accommodate users that have not performed 802.1X authentication, so they can access a limited set of network resources, such as a software server, to download anti-virus software and system patches. Once a user in the guest VLAN passes 802.1X authentication, it is removed from the guest VLAN and can access authorized network resources.
Guest VLAN is supported only on ports that perform MAC-based access control. The following table describes how the network access device handles VLANs on these ports.
Authentication status |
VLAN manipulation |
A user has not passed 802.1X authentication yet |
Creates a mapping between the MAC address of the user and the 802.1X guest VLAN. The user can access resources in the guest VLAN. |
A user in the 802.1X guest VLAN fails 802.1X authentication |
If an 802.1X Auth-Fail VLAN is available, re-maps the MAC address of the user to the Auth-Fail VLAN. The user can access only resources in the Auth-Fail VLAN. If no 802.1X Auth-Fail VLAN is configured, the user is still in the 802.1X guest VLAN. |
A user in the 802.1X guest VLAN passes 802.1X authentication |
Re-maps the MAC address of the user to the VLAN specified for the user. If the authentication server assigns no VLAN, re-maps the MAC address of the user to the initial PVID on the port. |
To use the 802.1X guest VLAN feature on a port that performs MAC-based access control, make sure that the port is a hybrid port, and enable MAC-based VLAN on the port.
The network device assigns a hybrid port to an 802.1X guest VLAN as an untagged member.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2 Configuration Guide.
Auth-Fail VLAN
You can configure an Auth-Fail VLAN to accommodate users that have failed 802.1X authentication because of the failure to comply with the organization security strategy, such as using a wrong password. Users in the Auth-Fail VLAN can access a limited set of network resources, such as a software server, to download anti-virus software and system patches.
The Auth-Fail VLAN does not accommodate 802.1X users that have failed authentication for authentication timeouts or network connection problems.
Auth-Fail VLAN is supported only on ports that perform MAC-based access control. The following table describes how the network access device handles VLANs on these ports.
Authentication status |
VLAN manipulation |
A user fails 802.1X authentication |
Re-maps the MAC address of the user to the Auth-Fail VLAN. The user can access only resources in the Auth-Fail VLAN. |
A user in the Auth-Fail VLAN fails 802.1X re-authentication |
The user is still in the Auth-Fail VLAN. |
A user in the Auth-Fail VLAN passes 802.1X authentication |
Re-maps the MAC address of the user to the server-assigned VLAN. If the authentication server assigns no VLAN, re-maps the MAC address of the user to the initial PVID on the port. |
To perform the 802.1X Auth-Fail VLAN feature on a port that performs MAC-based access control, you must ensure that the port is a hybrid port, and enable MAC-based VLAN on the port.
The network device assigns a hybrid port to an 802.1X Auth-Fail VLAN as an untagged member.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2 Configuration Guide.
ACL assignment
You can specify an ACL for an 802.1X user to control its access to network resources. After the user passes 802.1X authentication, the authentication server, either the local access device or a RADIUS server, assigns the ACL to the port to filter the traffic from this user. In either case, you must configure the ACL on the access device. You can change ACL rules while the user is online.
Configuration prerequisites
· Disable ARP snooping.
· Configure an ISP domain and AAA scheme (local or RADIUS authentication) for 802.1X users.
· If RADIUS authentication is used, create user accounts on the RADIUS server.
· If local authentication is used, create local user accounts on the access device and set the service type to lan-access.
· If you want to use EAP relay when the RADIUS server does not support any EAP authentication method or no RADIUS server is available, configure the EAP server feature on your network access device.
For information about RADIUS client and local EAP authentication configuration, see "Configuring AAA."
802.1X configuration task list
Task |
Remarks |
Enable port security to enable 802.1X |
Required. By default, the 802.1X feature of port security is disabled. 802.1X must work with the port security feature to function on a WLAN port. |
Optional. |
|
Optional. |
|
Optional. |
|
Setting the maximum number of concurrent 802.1X users on a port |
Optional. |
Setting the maximum number of authentication request attempts |
Optional. |
Optional. |
|
Optional. |
|
Optional. |
|
Optional. |
|
Optional. |
|
Optional. |
|
Optional. |
|
Optional. |
|
Optional. |
|
Optional. |
Enabling EAP relay or EAP termination
When configuring EAP relay or EAP termination, consider the following factors:
· The support of the RADIUS server for EAP packets
· The authentication methods supported by the 802.1X client and the RADIUS server
If the client is using only MD5-Challenge EAP authentication or the "username + password" EAP authentication initiated by an H3C iNode 802.1X client, you can use both EAP termination and EAP relay. To use EAP-TLS, PEAP, or any other EAP authentication methods, you must use EAP relay. When you make your decision, see "Comparing EAP relay and EAP termination" for help.
For more information about EAP relay and EAP termination, see "802.1X authentication procedures."
To configure EAP relay or EAP termination:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure EAP relay or EAP termination. |
dot1x authentication-method { chap | eap | pap } |
By default, the network access device performs EAP termination and uses CHAP to communicate with the RADIUS server. Specify the eap keyword to enable EAP relay. Specify the chap or pap keyword to enable CHAP-enabled or PAP-enabled EAP termination. |
|
NOTE: If EAP relay mode is used, the user-name-format command configured in RADIUS scheme view does not take effect. The access device sends the authentication data from the client to the server without any modification. |
Setting the port authorization state
The port authorization state determines whether the client is granted access to the network. You can control the authorization state of a port by using the dot1x port-control command and the following keywords:
· authorized-force—Places the port in the authorized state, enabling users on the port to access the network without authentication.
· unauthorized-force—Places the port in the unauthorized state, denying any access requests from users on the port.
· auto—Places the port initially in the unauthorized state to allow only EAPOL packets to pass, and after a user passes authentication, sets the port in the authorized state to allow access to the network. You can use this option in most scenarios.
You can set authorization state for one port in interface view, or for multiple ports in system view. If different authorization state is set for a port in system view and interface view, the one set later takes effect.
To set the authorization state of a port:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the port authorization state in system view, Layer 2 Ethernet interface view, or WLAN-ESS interface view. |
· In system view: · In Layer 2 Ethernet interface view or WLAN-ESS interface view: a. interface interface-type interface-number b. dot1x port-control { authorized-force | auto | unauthorized-force } |
By default, auto applies. |
Specifying an access control method
You can specify an access control method for one port in interface view, or for multiple ports in system view. If different access control methods are specified for a port in system view and interface view, the one specified later takes effect.
To specify the access control method:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Specify an access control method in system view, Layer 2 Ethernet interface view, or WLAN-ESS interface view. |
· In system view: · In Layer 2 Ethernet interface view or WLAN-ESS interface view: a. interface interface-type interface-number b. dot1x port-method { macbased | portbased } |
By default, MAC-based access control applies. To use both 802.1X and portal authentication on a port, you must specify MAC-based access control. For information about portal authentication, see "Configuring portal authentication." |
Setting the maximum number of concurrent 802.1X users on a port
You can set the maximum number of concurrent 802.1X users for ports individually in interface view or in bulk in system view. If different settings are configured for a port in both views, the setting configured later takes effect.
To set the maximum number of concurrent 802.1X users on a port:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the maximum number of concurrent 802.1X users on a port in system view, Layer 2 Ethernet interface view, or WLAN-ESS interface view. |
· In system view: · In Layer 2 Ethernet interface view or WLAN-ESS interface view: a. interface interface-type interface-number b. dot1x max-user user-number |
The default varies with devices. For more information, see About the H3C Access Controllers Command References. |
Setting the maximum number of authentication request attempts
The network access device retransmits an authentication request if it receives no response to the request it has sent to the client within a period of time (specified by using the dot1x timer tx-period tx-period-value command or the dot1x timer supp-timeout supp-timeout-value command). The network access device stops retransmitting the request if it has made the maximum number of request transmission attempts but still received no response.
To set the maximum number of authentication request attempts:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the maximum number of attempts for sending an authentication request. |
dot1x retry max-retry-value |
The default setting is 2. |
Setting the 802.1X authentication timeout timers
The network device uses the following 802.1X authentication timeout timers:
· Client timeout timer—Starts when the access device sends an EAP-Request/MD5 Challenge packet to a client. If no response is received when this timer expires, the access device retransmits the request to the client.
· Server timeout timer—Starts when the access device sends a RADIUS Access-Request packet to the authentication server. If no response is received when this timer expires, the access device retransmits the request to the server.
You can set the client timeout timer to a high value in a low-performance network, and adjust the server timeout timer to adapt to the performance of different authentication servers. In most cases, the default settings are sufficient.
To set the 802.1X authentication timeout timers:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the client timeout timer. |
dot1x timer supp-timeout supp-timeout-value |
The default is 30 seconds. |
3. Set the server timeout timer. |
dot1x timer server-timeout server-timeout-value |
The default is 100 seconds. |
Configuring the online user handshake feature
The online user handshake feature checks the connectivity status of online 802.1X users. The network access device sends handshake messages to online users at the interval specified by the dot1x timer handshake-period command. If no response is received from an online user after the maximum number of handshake attempts (set by the dot1x retry command), the network access device sets the user in the offline state.
If iNode clients are deployed, you can also enable the online handshake security feature to check for 802.1X users that use illegal client software to bypass security inspection such as dual network interface cards (NICs) detection. This feature checks the authentication information in client handshake messages. If a user fails the authentication, the network access device logs the user off.
Configuration guidelines
Follow these guidelines when you configure the online user handshake feature:
· To use the online handshake security feature, make sure the online user handshake feature is enabled. H3C recommends that you use the iNode client software and IMC server to ensure the normal operation of the online user handshake security feature.
· If the network has 802.1X clients that cannot exchange handshake packets with the network access device, disable the online user handshake feature to prevent their connections from being inappropriately torn down.
Configuration procedure
To configure the online user handshake feature:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the handshake timer. |
dot1x timer handshake-period handshake-period-value |
Optional. The default is 15 seconds. |
3. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. |
interface interface-type interface-number |
N/A |
4. Enable the online handshake feature. |
dot1x handshake |
Optional. By default, the feature is enabled. |
5. Enable the online handshake security feature. |
dot1x handshake secure |
Optional. By default, the feature is disabled. |
Configuring the authentication trigger feature
The authentication trigger feature enables the network access device to initiate 802.1X authentication when 802.1X clients cannot initiate authentication.
This feature provides the following types of authentication trigger:
· Multicast trigger—Periodically multicasts Identity EAP-Request packets out of a port to detect 802.1X clients and trigger authentication.
· Unicast trigger—Enables the network device to initiate 802.1X authentication when it receives a data frame from an unknown source MAC address. The device sends a unicast Identity EAP/Request packet to the unknown source MAC address, and retransmits the packet if it has received no response within a period of time. This process continues until the maximum number of request attempts set with the dot1x retry command (see "Setting the maximum number of authentication request attempts") is reached.
The identity request timeout timer sets both the identity request interval for the multicast trigger and the identity request timeout interval for the unicast trigger.
Configuration guidelines
Follow these guidelines when you configure the authentication trigger feature:
· Enable the multicast trigger on a port when the clients attached to the port cannot send EAPOL-Start packets to initiate 802.1X authentication.
· Disable the multicast trigger in a wireless LAN. Wireless clients and the wireless module of the network access device can both initiate 802.1X authentication.
· Enable the unicast trigger on a port if only a few 802.1X clients are attached to the port and these clients cannot initiate authentication.
· To avoid duplicate authentication packets, do not enable both triggers on a port.
Configuration procedure
To configure the authentication trigger feature on a port:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the username request timeout timer. |
dot1x timer tx-period tx-period-value |
Optional. The default setting is 30 seconds. |
3. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. |
interface interface-type interface-number |
N/A |
4. Enable an authentication trigger. |
dot1x { multicast-trigger | unicast-trigger } |
Required if you want to enable the unicast trigger. By default, the multicast trigger is enabled, and the unicast trigger is disabled. Unicast trigger is not available on a WLAN-ESS port. |
Specifying a mandatory authentication domain on a port
You can place all 802.1X users in a mandatory authentication domain for authentication, authorization, and accounting on a port. No user can use an account in any other domain to access the network through the port. The implementation of a mandatory authentication domain enhances the flexibility of 802.1X access control deployment.
To specify a mandatory authentication domain for a port:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. |
interface interface-type interface-number |
N/A |
3. Specify a mandatory 802.1X authentication domain on the port. |
dot1x mandatory-domain domain-name |
By default, no mandatory 802.1X authentication domain is specified. |
Configuring the quiet timer
The quiet timer enables the network access device to wait a period of time before it can process any authentication request from a client that has failed an 802.1X authentication.
You can set the quiet timer to a high value in a vulnerable network or a low value for quicker authentication response.
To configure the quiet timer:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable the quiet timer. |
dot1x quiet-period |
By default, the timer is disabled. |
3. Set the quiet timer. |
dot1x timer quiet-period quiet-period-value |
Optional. The default setting is 60 seconds. |
Enabling the periodic online user re-authentication feature
Periodic online user re-authentication tracks the connection status of online users and updates the authorization attributes assigned by the server, such as the ACL, VLAN, and user profile-based QoS. The re-authentication interval is user configurable.
To enable the periodic online user re-authentication feature:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the periodic re-authentication timer. |
dot1x timer reauth-period reauth-period-value |
Optional. The default setting is 3600 seconds. |
3. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. |
interface interface-type interface-number |
N/A |
4. Enable periodic online user re-authentication. |
dot1x re-authenticate |
By default, the feature is disabled. |
The periodic online user re-authentication timer can also be set by the authentication server in the session-timeout attribute. The server-assigned timer overrides the timer setting on the access device, and enables periodic online user re-authentication, even if the feature is not configured. Support for the server assignment of re-authentication timer and the re-authentication timer configuration on the server vary with servers.
The VLAN assignment status must be consistent before and after re-authentication. If the authentication server has assigned a VLAN before re-authentication, it must also assign a VLAN at re-authentication. If the authentication server has assigned no VLAN before re-authentication, it must not assign one at re-authentication. Violation of either rule can cause the user to be logged off. The VLANs assigned to an online user before and after re-authentication can be the same or different.
RADIUS server unreachable can cause an online user being re-authenticated to be logged off.
Configuring an 802.1X guest VLAN
Configuration guidelines
Follow these guidelines when you configure an 802.1X guest VLAN:
· 802.1X guest VLAN is supported only on a port that performs MAC-based access control.
· You can configure only one 802.1X guest VLAN on a port. The 802.1X guest VLANs on different ports can be different.
· Assign different IDs to the PVID and the 802.1X guest VLAN on a port, so the port can correctly process incoming VLAN tagged traffic.
· Use Table 2 when configuring multiple security features on a port.
Table 2 Relationships of the 802.1X guest VLAN and other security features
Feature |
Relationship description |
Reference |
MAC authentication guest VLAN on a port that performs MAC-based access control |
Only the 802.1X guest VLAN take effect. A user that fails MAC authentication will not be assigned to the MAC authentication guest VLAN. |
See "Configuring MAC authentication." |
802.1X Auth-Fail VLAN on a port that performs MAC-based access control |
The 802.1X Auth-Fail VLAN has a higher priority. |
|
Port intrusion protection on a port that performs MAC-based access control |
The 802.1X guest VLAN feature has higher priority than the block MAC action but lower priority than the shutdown port action of the port intrusion protection feature. |
See "Configuring port security." |
Configuration prerequisites
· Create the VLAN to be specified as the 802.1X guest VLAN.
· On the 802.1X-enabled port that performs MAC-based access control, configure the port as a hybrid port, enable MAC-based VLAN on the port, and assign the port to the 802.1X guest VLAN as an untagged member. For more information about the MAC-based VLAN feature, see Layer 2 Configuration Guide.
Configuration procedure
To configure an 802.1X guest VLAN:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure an 802.1X guest VLAN for one or more ports in system view, Layer 2 Ethernet interface view, or WLAN-ESS interface view. |
· In system view: · In Layer 2 Ethernet interface view or WLAN-ESS interface view: a. interface interface-type interface-number b. dot1x guest-vlan guest-vlan-id |
By default, no 802.1X guest VLAN is configured on any port. |
Configuring an Auth-Fail VLAN
Configuration guidelines
Follow these guidelines when configuring an 802.1X Auth-Fail VLAN:
· 802.1X Auth-Fail VLAN is supported only on ports that perform MAC-based access control.
· Assign different IDs to the PVID and the 802.1X Auth-Fail VLAN on a port, so the port can correctly process VLAN tagged incoming traffic.
· You can configure only one 802.1X Auth-Fail VLAN on a port. The 802.1X Auth-Fail VLANs on different ports can be different.
· Use Table 3 when configuring multiple security features on a port.
Table 3 Relationships of the 802.1X Auth-Fail VLAN with other features
Feature |
Relationship description |
Reference |
MAC authentication guest VLAN on a port that performs MAC-based access control |
The 802.1X Auth-Fail VLAN has a high priority. |
See "Configuring MAC authentication." |
Port intrusion protection on a port that performs MAC-based access control |
The 802.1X Auth-Fail VLAN feature has higher priority than the block MAC action but lower priority than the shutdown port action of the port intrusion protection feature. |
See "Configuring port security." |
Configuration prerequisites
· Create the VLAN to be specified as the 802.1X Auth-Fail VLAN.
· On the 802.1X-enabled port that performs MAC-based access control, configure the port as a hybrid port, enable MAC-based VLAN on the port, and assign the port to the Auth-Fail VLAN as an untagged member. For more information about the MAC-based VLAN feature, see Layer 2 Configuration Guide.
Configuration procedure
To configure an Auth-Fail VLAN:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. |
interface interface-type interface-number |
N/A |
3. Configure the Auth-Fail VLAN on the port. |
dot1x auth-fail vlan authfail-vlan-id |
By default, no Auth-Fail VLAN is configured. |
Specifying supported domain name delimiters
By default, the access device supports the at sign (@) as the delimiter. You can also configure the access device to accommodate 802.1X users that use other domain name delimiters.
The configurable delimiters include the at sign (@), back slash (\), and forward slash (/).
If an 802.1X username string contains multiple configured delimiters, the leftmost delimiter is the domain name delimiter. For example, if you configure @, /, and \ as delimiters, the domain name delimiter for the username string 123/22\@abc is the forward slash (/).
If a username string contains none of the delimiters, the access device authenticates the user in the mandatory or default ISP domain. The access selects a domain delimiter from the delimiter set in this order: @, /, and \.
To specify a set of domain name delimiters:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Specify a set of domain name delimiters for 802.1X users. |
dot1x domain-delimiter string |
By default, only the at sign (@) delimiter is supported. |
|
NOTE: If you configure the access device to include the domain name in the username sent to the RADIUS server, make sure the domain delimiter in the username can be recognized by the RADIUS server. For username format configuration, see the user-name-format command in Security Command Reference. |
Configuring the accounting delay feature
The accounting delay feature enables the device to delay sending the accounting request for an authenticated 802.1X user. If the device gets the user's IP address within the delay period, it includes the IP address in the accounting request and starts the accounting process for the user. If the device fails to get the user's IP address, it starts the accounting process or logs off the user depending on your configuration.
H3C recommends that you enable the accounting delay feature when the following conditions exist:
· 802.1X users obtain IP addresses through DHCP.
· The accounting server requires user IP addresses for accounting management.
For a network that deploys iNode clients, follow these configuration guidelines:
· If the iNode clients can upload their IP addresses during authentication, disable the accounting delay feature for efficiency.
· If the iNode clients cannot upload their IP addresses, make sure the delay setting is equal to or less than the accounting delay that the EAD policy allows to prevent access failures. H3C recommends a delay equal to or less than 20 seconds.
To configure the accounting delay feature on an 802.1X-enabled port:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter Layer 2 Ethernet interface view or WLAN-ESS interface view. |
interface interface-type interface-number |
N/A |
3. Configure the accounting delay settings. |
dot1x accounting-delay [ logoff | time time ] * |
By default, accounting delay is disabled. The device sends an accounting request to the accounting server for an 802.1X user immediately after the user passes authentication, regardless of whether it gets the user's IP address. |
Displaying and maintaining 802.1X
Task |
Command |
Remarks |
Display 802.1X session information, statistics, or configuration information of specified or all ports. |
display dot1x [ sessions | statistics ] [ interface interface-list ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. |
Display 802.1X stateful failover information. |
display dot1x synchronization { connection | statistics | status } [ interface interface-type interface-number ] [ | { begin | exclude | include } regular-expression ] |
Available in any view. Support for this command depends on the device model. For more information, see About the H3C Access Controllers Command References. |
Clear 802.1X statistics. |
reset dot1x statistics [ interface interface-list ] |
Available in user view. |
Clear 802.1X stateful failover packet statistics. |
reset dot1x synchronization statistics [ interface interface-type interface-number ] |
Available in any view. Support for this command depends on the device model. For more information, see About the H3C Access Controllers Command References. |
802.1X with ACL assignment configuration example
For more 802.1X configuration examples in WLAN, see WLAN Configuration Guide.
Network requirements
As shown in Figure 11, the client at 192.168.1.10 connects to port WLAN-ESS 1 of the AC.
Perform 802.1X authentication on the port, and set the port security mode to userlogin-secure-ext.
Use the RADIUS server at 10.1.1.1 as the authentication and authorization server and the RADIUS server at 10.1.1.2 as the accounting server.
Assign an ACL to WLAN-ESS 1 to deny the access of 802.1X users to the FTP server at 10.0.0.1.
Configuration procedure
# Assign IP addresses to interfaces. (Details not shown.)
# Configure the RADIUS server and specify the ACL to be assigned. (Details not shown.)
# Configure the RADIUS scheme.
<AC> system-view
[AC] radius scheme 2000
[AC-radius-2000] primary authentication 10.1.1.1
[AC-radius-2000] primary accounting 10.1.1.2
[AC-radius-2000] key authentication abc
[AC-radius-2000] key accounting abc
[AC-radius-2000] user-name-format without-domain
[AC-radius-2000] quit
# Create an ISP domain and specify the RADIUS scheme 2000 as the default AAA schemes for the domain.
[AC] domain 2000
[AC-isp-2000] authentication default radius-scheme 2000
[AC-isp-2000] authorization default radius-scheme 2000
[AC-isp-2000] accounting default radius-scheme 2000
[AC-isp-2000] quit
# Configure ACL 3000 to deny packets destined for the FTP server at 10.0.0.1.
[AC] acl number 3000
[AC-acl-adv-3000] rule 0 deny ip destination 10.0.0.1 0
# Set the authentication method to EAP.
[AC] dot1x authentication-method eap
# Enable port security.
[AC] port-security enable
# Set the port security mode to userlogin-secure-ext, and enable port-security tx-key-type 11key.
[AC] interface wlan-ess 1
[AC-WLAN-ESS1] port link-type hybrid
[AC-WLAN-ESS1] port hybrid vlan 2 untagged
[AC-WLAN-ESS1] port hybrid pvid vlan 2
[AC-WLAN-ESS1] mac-vlan enable
[AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext
[AC-WLAN-ESS1] port-security tx-key-type 11key
[AC-WLAN-ESS1] dot1x mandatory-domain 2000
# Disable the multicast trigger feature and online user handshake feature.
[AC-WLAN-ESS1] undo dot1x multicast-trigger
[AC-WLAN-ESS1] undo dot1x handshake
[AC-WLAN-ESS1] quit
# Create service template 1 of crypto type, configure its SSID as dot1x, and configure the tkip and ccmp cipher suite.
[AC] wlan service-template 1 crypto
[AC-wlan-st-1] ssid dot1x
[AC-wlan-st-1] bind wlan-ess 1
[AC-wlan-st-1] cipher-suite tkip
[AC-wlan-st-1] cipher-suite ccmp
[AC-wlan-st-1] security-ie rsn
[AC-wlan-st-1] service-template enable
[AC-wlan-st-1] quit
# Create an AP template named ap1 and its model is WA3628i-AGN, and configure the serial ID of the AP as 210235A29G007C000020.
[AC] wlan ap ap1 model WA3628i-AGN
[AC-wlan-ap-ap1] serial-id 210235A29G007C000020
[AC-wlan-ap-ap1] radio 1 type dot11an
# Bind service template 1 to radio 1.
[AC-wlan-ap-ap1-radio-1] service-template 1
[AC-wlan-ap-ap1-radio-1] radio enable
Verifying the configuration
# Verify that the 802.1X connection has been set up.
[AC] display connection
Index=1,Username=localuser@2000
MAC=00-40-96-B3-8A-77
IP=192.168.1.10
IPv6=N/A
Online=00h00m53s
Total 1 connection(s) matched.
[AC] display connection ucibindex 1
Index=1, Username= localuser@2000
MAC=00-40-96-B3-8A-77
IP=192.168.1.10
IPv6=N/A
Access=8021X ,AuthMethod=EAP
Port Type=Wireless-802.11,Port Name=WLAN-DBSS1:1
Initial VLAN=2, Authorization VLAN=N/A
ACL Group=3000
User Profile=N/A
CAR=Disable
InputOctets =12121212 OutputOctets =12120
InputGigawords=1 OutputGigawords=0
Priority=Disable
SessionTimeout=86236(s), Terminate-Action=Default
Start=2013-06-30 17:29:39 ,Current=2013-06-30 17:30:51 ,Online=00h01m13s
Total 1 connection matched.
# Use the user account to pass authentication, and then ping the FTP server.
C:\>ping 10.0.0.1
Pinging 10.0.0.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
The output shows that ACL 3000 has taken effect on the user, and the user cannot access the FTP server.