Login
- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 02-802.1X Configuration | 332.22 KB |
Table of Contents
Authentication Modes of 802.1X
802.1X Authentication Triggering
Authentication Process of 802.1X
Features Working Together with 802.1X
802.1X Configuration Task List
Configuring the Online User Handshake Function
Enabling the Proxy Detection Function
Enabling the Multicast Trigger Function
Specifying a Mandatory Authentication Domain for a Port
Enabling the Quiet Timer Function
Enabling the Re-Authentication Function
Displaying and Maintaining 802.1X
WPA, 802.1X, and IAS Configuration Example
l Support of the H3C WA series WLAN access points (APs) for features may vary by AP model. For more information, see Feature Matrix.
l The interface types and the number of interfaces vary by AP model. This document uses Ethernet interfaces to show how to configure Ethernet interfaces.
l The term AP in this document refers to common APs, wireless bridges, and mesh APs.
l The models listed in this document are not applicable to all regions. Please consult your local sales office for the models applicable to your region.
This chapter includes these sections:
l 802.1X Configuration Task List
l Displaying and Maintaining 802.1X
l 802.1X Configuration Example
802.1X Overview
The 802.1X protocol was proposed by IEEE802 LAN/WAN committee for security of wireless LANs (WLAN). It has been widely used on Ethernet as a common port access control mechanism.
As a port-based access control protocol, 802.1X authenticates and controls accessing devices at the port level. A device connected to an 802.1X-enabled port of an access control device can access the resources on the LAN only after passing authentication.
The port security feature provides rich security modes that combine or extend 802.1X authentication and MAC address authentication. In a networking environment that requires flexible use of 802.1X authentication and MAC address authentication, you are recommended to configure the port security feature. In a network environment where there are no special authentication requirements, you are recommended to configure 802.1X only. For how to use the port security feature, see Port Security in the Security Configuration Guide.
To get more information about 802.1X, go to these topics:
l Authentication Modes of 802.1X
l 802.1X Authentication Triggering
l Authentication Process of 802.1X
l 802.1X Access Control Methods
l Features Working Together with 802.1X
Architecture of 802.1X
802.1X operates in the typical client/server model and defines three entities: Client, Device, and Server, as shown in Figure 1-1.
Figure 1-1 Architecture of 802.1X
Client is an entity seeking access to the LAN. It resides at one end of a LAN segment and is authenticated by Device at the other end of the LAN segment. Client is usually a user-end device such as a PC. 802.1X authentication is triggered when an 802.1X-capable client program is launched on Client. The client program must support Extensible Authentication Protocol over LAN (EAPOL).
Device, residing at the other end of the LAN segment, is the entity that authenticates connected clients. Device is usually an 802.1X-enabled network device and provides access ports for clients to the LAN.
Server is the entity that provides authentication services to Device. Server, normally a RADIUS (Remote Authentication Dial-in User Service) server, serves to perform authentications, authorization, and accounting services for users.
Authentication Modes of 802.1X
The 802.1X authentication system employs the Extensible Authentication Protocol (EAP) to exchange authentication information between the client, device, and authentication server.
l Between the client and the AP, EAP protocol packets are encapsulated using EAPOL.
l Between the AP and the RADIUS server, EAP protocol packets can be exchanged in two modes: EAP relay and EAP termination. In EAP relay mode, EAP packets are encapsulated in the EAP over RADIUS (EAPOR) packets on the AP, which then can relay the packets to the RADIUS server. In EAP termination mode, EAP packets are terminated at the AP, converted to the RADIUS packets either with the Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) attribute, and then transferred to the RADIUS server.
Basic Concepts of 802.1X
Controlled port and uncontrolled port
A device provides ports for clients to access the LAN. Each port can be regarded as a unity of two logical ports: a controlled port and an uncontrolled port.
l The uncontrolled port is always open in both the inbound and outbound directions to allow EAPOL protocol packets to pass, guaranteeing that the client can always send and receive authentication packets.
l The controlled port is open to allow data traffic to pass only when it is in the authorized state.
l The controlled port and uncontrolled port are two parts of the same port. Any packets arriving at the port are visible to both of them.
Authorized state and unauthorized state
The controlled port can be set in either the authorized or unauthorized status, which depends on the authentication result. Figure 1-2 illustrates how the authorization status of a controlled port affects packets passing through this port. In authenticator system 1, the controlled port is in the unauthorized status, that is, the port is disabled; in authenticator system 2, the controlled port is in the authorized status, that is, the port is enabled.
Figure 1-2 Authorized/unauthorized status of a controlled port
You can set the authorization mode of a specified port to control the port authorization status. The authorization modes include:
l authorized-force: Places the port in the authorized state, allowing users of the ports to access the network without authentication.
l unauthorized-force: Places the port in the unauthorized state, denying any access requests from users of the ports.
l auto: Places the port in the unauthorized state initially to allow only EAPOL packets to pass, and turns the ports into the authorized state to allow access to the network after the users pass authentication. This is the most common choice.
Control direction
In the unauthorized state, the controlled port can be set to deny traffic to and from the client or just the traffic from the client.
Currently, your AP can only be set to deny traffic from the client.
EAP over LAN
EAPOL packet format
EAPOL, defined in 802.1X, is intended to carry EAP protocol packets between clients and devices over LANs. Figure 1-3 shows the EAPOL packet format.
Figure 1-3 EAPOL packet format
l PAE Ethernet type: Protocol type. It takes the value 0x888E.
l Protocol version: Version of the EAPOL protocol supported by the EAPOL packet sender.
l Type: Type of the EAPOL packet. Table 1-1 lists the types that the AP currently supports.
Table 1-1 Types of EAPOL packets
|
Type |
Description |
|
EAP-Packet (a value of 0x00) |
A packet of this type is repackaged and transferred by RADIUS on the AP to get through complex networks to reach the authentication server. |
|
EAPOL-Start (a value of 0x01) |
Packet for initiating authentication, present between a client and a device. |
|
EAPOL-Logoff (a value of 0x02) |
Packet for logoff request, present between a client and a device. |
l Length: Length of the data, that is, length of the Packet body field, in bytes. If the value of this field is 0, no subsequent data field is present.
l Packet body: Content of the packet. The format of this field varies with the value of the Type field.
EAP Packet Format
An EAPOL packet of the type of EAP-Packet carries an EAP packet in its Packet body field. The format of the EAP packet is shown in Figure 1-4.
l Code: Type of the EAP packet, which can be Request, Response, Success, or Failure.
An EAP packet of the type of Success or Failure has no Data field, and has a length of 4.
An EAP packet of the type of Request or Response has a Data field in the format shown in Figure 1-5. The Type field indicates the EAP authentication type. A value of 1 represents Identity, indicating that the packet is for querying the identity of the client. A value of 4 represents MD5-Challenge, which corresponds closely to the PPP CHAP protocol.
Figure 1-5 Format of the Data field in an EAP request/response packet
l Identifier: Used to match request and response messages.
l Length: Length of the EAP packet, including the Code, Identifier, Length, and Data fields, in bytes.
l Data: Content of the EAP packet. This field is zero or more bytes and its format is determined by the Code field.
EAP over RADIUS
Two attributes of RADIUS are intended for supporting EAP authentication: EAP-Message and Message-Authenticator. For information about RADIUS packet format, see AAA in the Security Configuration Guide.
EAP-Message
The EAP-Message attribute is used to encapsulate EAP packets. Figure 1-6 shows its encapsulation format. The value of the Type field is 79. The String field can be up to 253 bytes. If the EAP packet is longer than 253 bytes, it can be fragmented and encapsulated into multiple EAP-Message attributes.
Figure 1-6 Encapsulation format of the EAP-Message attribute
Message-Authenticator
Figure 1-7 shows the encapsulation format of the Message-Authenticator attribute. The Message-Authenticator attribute is used to prevent access requests from being snooped during EAP or CHAP authentication. It must be included in any packet with the EAP-Message attribute; otherwise, the packet will be considered invalid and get discarded.
Figure 1-7 Encapsulation format of the Message-Authenticator attribute
802.1X Authentication Triggering
802.1X authentication can be initiated by either a client or the AP.
Unsolicited triggering of a client
A client initiates authentication by sending an EAPOL-Start packet to the AP. The destination address of the packet is 01-80-C2-00-00-03, the multicast address specified by the IEEE 802.1X protocol.
Some devices in the network may not support multicast packets with the above destination address, causing the authentication device unable to receive the authentication request of the client. To solve the problem, the AP also supports EAPOL-Start packets whose destination address is a broadcast MAC address. In this case, the H3C iNode 802.1X client is required.
Unsolicited triggering of the AP
The AP can trigger authentication by sending EAP-Request/Identity packets to unauthenticated clients periodically (every 30 seconds by default). This method can be used to authenticate clients which cannot send EAPOL-Start packets and therefore cannot trigger authentication, for example, the 802.1X client provided by Windows XP.
Authentication Process of 802.1X
An 802.1X device communicates with a remotely located RADIUS server in two modes: EAP relay and EAP termination. The following description takes the EAP relay as an example to show the 802.1X authentication process.
EAP relay
EAP relay is an IEEE 802.1X standard mode. In this mode, EAP packets are carried in an upper layer protocol, such as RADIUS, so that they can go through complex networks and reach the authentication server. Generally, relaying EAP requires that the RADIUS server support the EAP attributes of EAP-Message and Message-Authenticator, which are used to encapsulate EAP packets and protect RADIUS packets carrying the EAP-Message attribute respectively.
Figure 1-8 shows the message exchange procedure with EAP-MD5.
Figure 1-8 Message exchange in EAP relay mode
1) When a user launches the 802.1X client software and enters the registered username and password, the 802.1X client software generates an EAPOL-Start packet and sends it to the AP (Device in the figure) to initiate an authentication process.
2) Upon receiving the EAPOL-Start packet, the AP responds with an EAP-Request/Identity packet for the username of the client.
3) When the client receives the EAP-Request/Identity packet, it encapsulates the username in an EAP-Response/Identity packet and sends the packet to the AP.
4) Upon receiving the EAP-Response/Identity packet, the AP relays the packet in a RADIUS Access-Request packet to the authentication server.
5) When receiving the RADIUS Access-Request packet, the RADIUS server compares the identify information against its user information table to obtain the corresponding password information. Then, it encrypts the password information using a randomly generated challenge, and sends the challenge information through a RADIUS Access-Challenge packet to the AP.
6) After receiving the RADIUS Access-Challenge packet, the AP relays the contained EAP-Request/MD5 Challenge packet to the client.
7) When receiving the EAP-Request/MD5 Challenge packet, the client uses the offered challenge to encrypt the password part (this process is not reversible), creates an EAP-Response/MD5 Challenge packet, and then sends the packet to the AP.
8) After receiving the EAP-Response/MD5 Challenge packet, the AP relays the packet in a RADIUS Access-Request packet to the authentication server.
9) When receiving the RADIUS Access-Request packet, the RADIUS server compares the password information encapsulated in the packet with that generated by itself. If the two are identical, the authentication server considers the user valid and sends to the AP a RADIUS Access-Accept packet.
10) Upon receiving the RADIUS Access-Accept packet, the AP opens the port to grant the access request of the client. After the client gets online, the AP periodically sends handshake requests to the client to check whether the client is still online. By default, if two consecutive handshake attempts end up with failure, the AP concludes that the client has gone offline and performs the necessary operations, guaranteeing that the AP always knows when a client goes offline.
In EAP relay mode, a client must use the same authentication method as that of the RADIUS server. On the AP, however, you only need to execute the dot1x authentication-method eap command to enable EAP relay.
EAP termination
In EAP termination mode, EAP packets are terminated at the AP and then repackaged into the PAP or CHAP attributes of RADIUS and transferred to the RADIUS server for authentication, authorization, and accounting. Figure 1-9 shows the message exchange procedure with CHAP authentication.
Figure 1-9 Message exchange in EAP termination mode
802.1X Access Control Methods
H3C APs not only implement the port-based access control method defined in the 802.1X protocol, but also extend and optimize the protocol by supporting the MAC-based access control method.
l Port-based access control: With this method configured on a port, after a user connected to the port passes authentication, all subsequent users of the port can access network resources without authentication. However, when the authenticated user goes offline, the others are denied as well.
l MAC-based access control: With this method configured on a port, all users of the port must be authenticated separately, and when a user goes offline, no other users are affected.
802.1X Timers
This section describes the timers used on an 802.1X AP to guarantee that the client, the AP, and the RADIUS server can interact with each other in a reasonable manner.
l Username request timeout timer (tx-period): The AP starts this timer when it sends an EAP-Request/Identity packet to a client. If it receives no response before this timer expires, the AP retransmits the request. When cooperating with a client that sends EAPOL-Start requests only when requested, the AP multicasts EAP-Request/Identity packets to the client at an interval set by this timer.
l Supplicant timeout timer (supp-timeout): Once an AP sends an EAP-Request/MD5 Challenge packet to a client, it starts this timer. If this timer expires but it receives no response from the client, it retransmits the request.
l Server timeout timer (server-timeout): Once an AP sends a RADIUS Access-Request packet to the authentication server, it starts this timer. If this timer expires but it receives no response from the server, it retransmits the request.
l Handshake timer (handshake-period): After a client passes authentication, the AP sends to the client handshake requests at this interval to check whether the client is online. If the AP receives no response after sending the allowed maximum number of handshake requests, it considers that the client is offline.
l Periodic re-authentication timer (reauth-period): If periodic re-authentication is enabled on a port, the AP re-authenticates online users on the port at the interval specified by this timer.
Features Working Together with 802.1X
VLAN assignment
After an 802.1X user passes the authentication, the server will send an authorization message to the AP. If the server is enabled with the VLAN assignment function, the assigned VLAN information will be included in the message. The AP, depending on the link type of the port used to log in, adds the port to the assigned VLAN according to the following rules:
If the port link type is Access, the port leaves its current VLAN and joins the assigned VLAN.
If the port link type is Trunk, the assigned VLAN is allowed to pass the current trunk port. The default VLAN ID of the port is that of the assigned VLAN.
If the port link type is Hybrid, the assigned VLAN is allowed to pass the current port without carrying the tag. The default VLAN ID of the port is that of the assigned VLAN. Note that if the Hybrid port is assigned a MAC-based VLAN, the AP will dynamically create a MAC-based VLAN according to the VLAN assigned by the authentication server, and keep the default VLAN ID of the port unchanged.
The assigned VLAN neither changes nor affects the configuration of a port. However, as the assigned VLAN has higher priority than the user-configured VLAN, it is the assigned VLAN that takes effect after a user passes authentication. After the user goes offline, the port returns to the initial VLAN of the port.
For more information about VLAN configuration, see VLAN in the Layer 2 – LAN Switching Configuration Guide.
l With a Hybrid port, the VLAN assignment will fail if you have configured the assigned VLAN to carry tags.
l With a Hybrid port, you cannot configure an assigned VLAN to carry tags after the VLAN has been assigned.
l If you enable the MAC VLAN function on a port where one or more online 802.1X users exist, the MAC VLAN function takes effect for such a user only after the user passes re-authentication and gets a VLAN different from that assigned for the previous authentication.
Auth-Fail VLAN
The Auth-Fail VLAN feature allows users failing authentication to access a specified VLAN, which is called the Auth-Fail VLAN. Note that failing authentication means being denied by the authentication server due to reasons such as wrong password. Authentication failures caused by authentication timeout or network connection problems do not fall into this category.
Similar to a guest VLAN, an Auth-Fail VLAN can be a port-based Auth-Fail VLAN (PAFV) or a MAC-based Auth-Fail VLAN (MAFV), depending on the port access control method.
1) PAFV
A PAFV refers to AN Auth-Fail VLAN configured on a port that uses the port-based access control method. With PAFV configured on a port, if a user on the port fails authentication, the port will be added to the Auth-Fail VLAN according to the port’s link type, which is similar with adding a port to an assigned VLAN. After that, all users accessing the port will be authorized to access the resources in the Auth-Fail VLAN.
If a user initiates authentication through the port in the Auth-Fail VLAN but fails the authentication, the port stays in the Auth-Fail VLAN. If the user passes the authentication successfully, the port leaves the Auth-Fail VLAN, and:
l If the authentication server assigns a VLAN, the port joins the assigned VLAN. After the user goes offline, the port returns to its initial VLAN, that is, the VLAN the port was in before it was added to any authorized VLAN.
l If the authentication server assigns no VLAN, the port returns to its initial VLAN. After the client goes offline, the port still stays in its initial VLAN.
2) MAFV
An MAFV refers to the Auth-Fail VLAN configured on a port that uses the MAC-based access control method. With MAFV configured on a port, if a user on the port fails authentication, the user will be authorized to access the resources in the Auth-Fail VLAN only. If the user initiates authentication again and passes the authentication, the AP will add the user to the assigned VLAN or return the user to the initial VLAN of the port, depending on whether the authentication server assigns a VLAN.
ACL assignment
ACLs provide a way of controlling access to network resources and defining access rights. When a user logs in through a port, and the RADIUS server is configured with authorization ACLs, the AP will permit or deny data flows traversing through the port according to the authorization ACLs. Before specifying authorization ACLs on the server, you need to configure the ACL rules on the AP. You can change the access rights of users by modifying authorization ACL settings on the RADIUS server or changing the corresponding ACL rules on the AP.
Mandatory authentication domain for a specified port
The mandatory authentication domain function provides a security control mechanism for 802.1X access. With a mandatory authentication domain specified for a port, the system uses the mandatory authentication domain for authentication, authorization, and accounting of all 802.1X users on the port. In this way, users accessing the port cannot use any account in other domains.
Meanwhile, for EAP relay mode 802.1X authentication that uses certificates, the certificate of a user determines the authentication domain of the user. However, you can specify different mandatory authentication domains for different ports even if the user certificates are from the same certificate authority (that is, the user domain names are the same). This allows you to deploy 802.1X access policies flexibly.
802.1X Configuration Task List
Complete the following tasks to configure 802.1X:
|
Task |
Remarks |
|
Required |
|
|
Optional |
|
|
Optional |
|
|
Optional |
|
|
Optional |
|
|
Optional |
|
|
Optional |
Configuring 802.1X
Configuration Prerequisites
802.1X provides a user identity authentication scheme. However, 802.1X cannot implement the authentication scheme solely by itself. RADIUS or local authentication must be configured to work with 802.1X.
Configure the ISP domain to which the 802.1X user belongs and the AAA scheme to be used (that is, local authentication or RADIUS).
For remote RADIUS authentication, the username and password information must be configured on the RADIUS server.
For local authentication, the username and password information must be configured on the AP and the service type must be set to lan-access.
For more information about RADIUS client configuration, see AAA in the Security Configuration Guide.
Configuring 802.1X Globally
Follow these steps to configure 802.1X globally:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enable 802.1X globally |
dot1x |
Required Disabled by default |
|
Specify the authentication method |
dot1x authentication-method { chap | eap | pap } |
Optional CHAP by default |
|
Specify the port authorization mode for specified or all ports |
dot1x port-control { authorized-force | auto | unauthorized-force } [ interface interface-list ] |
Optional auto by default |
|
Specify the port access control method for specified or all ports |
dot1x port-method { macbased | portbased } [ interface interface-list ] |
Optional macbased by default |
|
Set the maximum number of users for specified or all ports |
dot1x max-user user-number [ interface interface-list ] |
Optional 128 by default. |
|
Set the maximum number of attempts to send an authentication request to a client |
dot1x retry max-retry-value |
Optional 2 by default |
|
Set timers |
dot1x timer { handshake-period handshake-period-value | quiet-period quiet-period-value | reauth-period reauth-period-value | server-timeout server-timeout-value | supp-timeout supp-timeout-value | tx-period tx-period-value } |
Optional The defaults are as follows: 15 seconds for the handshake timer, 60 seconds for the quiet timer, 3600 seconds for the periodic re-authentication timer, 100 seconds for the server timeout timer, 30 seconds for the client timeout timer, and 30 seconds for the username request timeout timer. |
l For 802.1X to take effect on a port, you must enable it both globally in system view and for the port in system view or interface view.
l You can enable 802.1X and specify the port authorization mode, port access control method, and maximum number of users for a port in interface view. For more information about the configuration, see Configuring 802.1X for a Port. The only difference between configuring 802.1X globally and configuring 802.1X for a port lies in the applicable scope. If both a global setting and a local setting exist for an argument of a port, the last configured one is in effect.
l 802.1X timers only need to be changed in some special or extreme network environments. For example, you can give the client timeout timer a higher value in a low-performance network, give the quiet timer a higher value in a vulnerable network or a lower value for quicker authentication response, or adjust the server timeout timer to suit the performance of different authentication servers.
Configuring 802.1X for a Port
Enabling 802.1X for a port
Follow these steps to enable 802.1X for a port:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enable 802.1X for one or more ports |
In system view |
dot1x interface interface-list |
Required Use either approach. Disabled by default |
|
In interface view |
interface interface-type interface-number |
||
|
dot1x |
|||
Configuring 802.1X parameters for a port
Follow these steps to configure 802.1X parameters for a port:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter interface view |
interface interface-type interface-number |
— |
|
Set the port access control mode for the port |
dot1x port-control { authorized-force | auto | unauthorized-force } |
Optional auto by default |
|
Set the port access control method for the port |
dot1x port-method { macbased | portbased } |
Optional macbased by default |
|
Set the maximum number of users for the port |
dot1x max-user user-number |
Optional The default value is 128 |
l In EAP relay authentication mode, the AP encapsulates the 802.1X user information in the EAP attributes of RADIUS packets and sends the packets to the RADIUS server for authentication. In this case, you can configure the user-name-format command but it does not take effect. For information about the user-name-format command, see AAA in the Security Command Reference.
l If the username of a client contains the version number or one or more blank spaces, you can neither retrieve information nor disconnect the client by using the username. However, you can use items such as IP address and connection index number to do so.
Configuring the Online User Handshake Function
The online user handshake function allows the AP to send handshake messages to online users to check whether the users are still online at the interval specified with the dot1x timer handshake-period command. If the AP does not receive any response from an online user after the AP has sent the handshake packet for the maximum number of times, which is set with the dot1x retry command, the AP will set the user’s state to offline.
Follow these steps to configure the online user handshake function:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter interface view |
interface interface-type interface-number |
— |
|
Enable the online handshake function |
dot1x handshake |
Optional Enabled by default |
l You need to disable proxy detection before disabling the online user handshake function.
l Some 802.1X clients do not support exchanging handshake packets with the AP. In this case, you need to disable the online user handshake function on the AP; otherwise the AP will tear down the connections with such online users for not receiving handshake responses.
Enabling the Proxy Detection Function
With the proxy detection function enabled, the AP can prevent users from logging in through authenticated 802.1X clients (proxies), so that no user can access network resources through a proxy or bypass monitoring and accounting. If detecting that a user is logging in through a proxy, the AP will send a trap message to the network management system or/and force the user to go offline by sending an offline message.
The proxy detection function is based on the online user handshake function. Before enabling the proxy detection function, make sure that the online user handshake function is enabled. For how to configure the online user handshake function, see Configuring the Online User Handshake Function.
Follow these steps to configure the proxy detection function:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enable the proxy detection function globally |
dot1x supp-proxy-check { logoff | trap } |
Required Disabled by default |
|
|
Enable the proxy detection function on one or more ports |
In system view |
dot1x supp-proxy-check { logoff | trap } interface interface-list |
Required Use either approach. Disabled by default |
|
In interface view |
interface interface-type interface-number |
||
|
dot1x supp-proxy-check { logoff | trap } |
|||
l The proxy detection function requires the cooperation of the H3C 802.1X client software.
l For the proxy detection function to take effect on one or more ports, you need to enable the function both globally and on the ports.
Enabling the Multicast Trigger Function
With the 802.1X multicast trigger function enabled, a port will periodically send multicast messages to clients to initiate authentication. This function is used for clients that cannot initiate authentication.
Follow these steps to configure the multicast trigger function:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter interface view |
interface interface-type interface-number |
— |
|
Enable the multicast trigger function |
dot1x multicast-trigger |
Optional Enabled by default |
In a wireless LAN, it is not necessary for a port to periodically send multicast trigger messages to initiate authentication. This is because wireless clients can initiate authentication unsolicitedly and the wireless module can also trigger authentication upon detecting a user. What’s more, the multicast trigger messages consume bandwidth. Therefore, you are recommended to disable the multicast trigger function in wireless LANs.
Specifying a Mandatory Authentication Domain for a Port
With a mandatory authentication domain specified for a port, the system uses the mandatory authentication domain for authentication, authorization, and accounting of all 802.1X users on the port.
Follow these steps to specify a mandatory authentication domain for a port:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter interface view |
interface interface-type interface-number |
— |
|
Specify a mandatory authentication domain for the port |
dot1x mandatory-domain domain-name |
Required Not specified by default |
Enabling the Quiet Timer Function
After the quiet timer is enabled on the AP, when a client fails 802.1X authentication, the AP refuses further authentication requests from the client in a period of time, which is specified by the quiet timer (using the dot1x timer quiet-period command).
Follow these steps to enable the quiet timer:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enable the quiet timer |
dot1x quiet-period |
Required Disabled by default |
Enabling the Re-Authentication Function
If periodic re-authentication is enabled on a port, the AP will re-authenticate online users on the port at the interval specified by the periodic re-authentication timer. This is intended to track the connection status of online users and update the authorization attributes assigned by the server, such as the ACL, VLAN, and QoS Profile, ensuring that the users are in normal online state.
Follow these steps to enable the periodic re-authentication function:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter interface view |
interface interface-type interface-number |
— |
|
Enable periodic re-authentication |
dot1x re-authenticate |
Required Disabled by default |
After an 802.1X user passes authentication, if the authentication server assigns a re-authentication interval for the user through the session-timeout attribute, the assigned re-authentication interval will take effect instead of that specified on the AP. The re-authentication interval assignment varies by server type. For more information, see the specific authentication server implementation.
Displaying and Maintaining 802.1X
|
To do… |
Use the command… |
Remarks |
|
Clear 802.1X statistics |
reset dot1x statistics [ interface interface-list ] |
Available in user view |
802.1X Configuration Example
WPA, 802.1X, and IAS Configuration Example
Network requirements
As shown in Figure 1-10, it is required to configure the access point (AP) to use the RADIUS server to perform authentication and accounting for users logging into the AP.
l The RADIUS server, whose IP address is 8.20.1.2/8, is connected with the AP through the switch.
l On the AP, configure the shared key for packet exchange with the RADIUS server as h3c, and configure the system to remove the domain name of a username before sending it to the RADIUS server.
l On the RADIUS server, configure the shared key for packet exchange with the AP as h3c.
l Configure the AP to send real-time accounting packets to the RADIUS server every three minutes.
l Configure the AP to drop the buffered stop-accounting packets getting no responses.
l Enable the accounting-on function on the AP, so that the AP sends accounting-on packets to the RADIUS server whenever it reboots. This function allows the server to log out the users that have logged in through the AP before reboot, solving the problem that users online before the reboot cannot re-log in after the reboot.
Figure 1-10 Network diagram for WPA, 802.1X, and IAS configuration
Configuration procedure
1) Configure the AP
# Enable port security, and specify the 802.1X authentication method as EAP.
[AP] port-security enable
[AP] dot1x authentication-method eap
# Configure RADIUS scheme ias.
[AP] radius scheme ias
[AP-radius-ias] server-type extended
[AP-radius-ias] primary authentication 8.20.1.2
[AP-radius-ias] primary accounting 8.20.1.2
[AP-radius-ias] key authentication h3c
[AP-radius-ias] key accounting h3c
[AP-radius-ias] user-name-format without-domain
[AP-radius-ias] timer realtime-accounting 3
[AP-radius-ias] undo stop-accounting-buffer enable
[AP-radius-ias] accounting-on enable
# Configure the authentication, authorization, and accounting methods to be used by the authentication domain.
[AP-radius-ias] domain ias
[AP-isp-ias] authentication lan-access radius-scheme ias
[AP-isp-ias] authorization lan-access radius-scheme ias
[AP-isp- ias] accounting lan-access radius-scheme ias
# Configure authentication domain ias as the default domain of the system.
[AP-isp-ias] domain default enable ias
# Configure wireless port WLAN-BSS 2, specify the 802.1X authentication method on the interface as EAP (the port security mode is userLoginSecureExt).
[AP] interface WLAN-BSS 2
[AP-WLAN-BSS2] port-security port-mode userlogin-secure-ext
[AP-WLAN-BSS2] port-security tx-key-type 11key
# Configure a WLAN service template.
[AP-wlan-rp-rp] wlan service-template 2 crypto
[AP-wlan-st-2] ssid h3c-dot1x
[AP-wlan-st-2] authentication-method open-system
[AP-wlan-st-2] cipher-suite tkip
[AP-wlan-st-2] security-ie wpa
[AP-wlan-st-2] service-template enable
# On the radio port, bind the wireless port and the service template.
[AP] interface WLAN-Radio 1/0/1
[AP-WLAN-Radio1/0/1] service-template 2 interface WLAN-BSS 2
[AP-WLAN-Radio1/0/1] quit
# Configure the VLAN interface.
[AP] interface Vlan-interface1
[AP-Vlan-interface1] ip address 192.168.1.50 255.255.255.0
# Configure a default route.
[AP-Vlan-interface1] ip route-static 0.0.0.0 0.0.0.0 192.168.1.1
2) Configure the RADIUS server
# Configure the RADIUS client.
# Configure the remote access policy.
# Edit the dial-in configuration file.
For RADIUS server related configurations such as the certificates needed for certificate authentication and users in the AD, see the related Windows help files.
