Table of Contents X Configuration 1-1

Transcription

1 Table of Contents X Configuration X Overview 1-1 Architecture of 802.1X 1-1 Authentication Modes of 802.1X 1-2 Basic Concepts of 802.1X 1-2 EAP over LAN 1-3 EAP over RADIUS X Authentication Triggering 1-5 Authentication Process of 802.1X X Access Control Method X Timers 1-9 Features Working Together with 802.1X X Configuration Task List X Basic Configuration 1-13 Configuration Prerequisites 1-13 Configuring 802.1X Globally 1-13 Configuring 802.1X for a Port 1-14 Enabling the Online User Handshake Function 1-15 Enabling the Multicast Trigger Function 1-16 Specifying a Mandatory Authentication Domain for a Port 1-16 Enabling the Quiet Timer 1-16 Enabling the Re-Authentication Function 1-17 Configuring a Guest VLAN 1-17 Configuring an Auth-Fail VLAN 1-18 Displaying and Maintaining 802.1X X Configuration Example 1-19 Guest VLAN and VLAN Assignment Configuration Example 1-22 ACL Assignment Configuration Example 1-24 i

2 X Configuration This chapter includes these sections: 802.1X Overview 802.1X Configuration Task List 802.1X Configuration Example Guest VLAN and VLAN Assignment Configuration Example ACL Assignment Configuration Example 802.1X Overview The 802.1X protocol was proposed by IEEE 802 LAN/WAN committee for security of wireless LANs (WLANs). However, it has been widely used on Ethernet as a common port access control mechanism. As a port-based network access control protocol, 802.1X authenticates devices connected to the 802.1X-enabled LAN ports to control their access to the LAN. To get more information about 802.1X, go to these topics: Architecture of 802.1X Authentication Modes of 802.1X Basic Concepts of 802.1X EAP over LAN EAP over RADIUS 802.1X Authentication Triggering Authentication Process of 802.1X 802.1X Access Control Method 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 X 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). 1-1

3 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. Between the client and the device, EAP protocol packets are encapsulated using EAPOL to be transferred on the LAN. Between the device 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 device, which then can relay the packets to the RADIUS server. In EAP termination mode, EAP packets are terminated at the device, 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 These basic concepts are involved in 802.1X: controlled port/uncontrolled port, authorized state/unauthorized state, and control direction. 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. 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. The controlled port is open to allow data traffic to pass only when it is in the authorized state. The controlled port and uncontrolled port are two parts of the same port. Any packets arriving at the port are available 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, as shown in Figure

4 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: authorized-force: Places the port in the authorized state, allowing 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 in the unauthorized state initially to allow only EAPOL packets to pass, and turns the port 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 device 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. 1-3

5 Figure 1-3 EAPOL packet format PAE Ethernet type: Protocol type. It takes the value 0x888E. Protocol version: Version of the EAPOL protocol supported by the EAPOL packet sender. Type: Type of the EAPOL packet. Table 1-1 lists the types that the device 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 device to get through complex networks to reach the authentication server. EAPOL-Start (a value of 0x01) EAPOL-Logoff (a value of 0x02) Packet for initiating authentication, present between a client and a device. Packet for logoff request, present between a client and a device. 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. 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. Figure 1-4 EAP packet format Code Identifier 2 Length 4 Data N 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

6 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 Identifier: Used to match request and response messages. Length: Length of the EAP packet, including the Code, Identifier, Length, and Data fields, in bytes. 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, refer to AAA Configuration. 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 N Type Length String EAP packets 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 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 device. 1-5

7 Unsolicited triggering of a client A client initiates authentication by sending an EAPOL-Start packet to the device. The destination address of the packet is C , 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 device 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 device The device 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 defined in IEEE 802.1X. 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 EAP packet exchange procedure with EAP-MD5. 1-6

8 Figure X authentication procedure in EAP relay mode Client Device Server EAPOL EAPOR EAPOL-Start EAP-Request / Identity EAP-Response / Identity EAP-Request / MD5 challenge EAP-Response / MD5 challenge EAP-Success RADIUS Access-Request (EAP-Response / Identity) RADIUS Access-Challenge (EAP-Request / MD5 challenge) RADIUS Access-Request (EAP-Response / MD5 challenge) RADIUS Access-Accept (EAP-Success) Port authorized Handshake request [ EAP-Request / Identity ] Handshake response [ EAP-Response / Identity ] Handshake timer... EAPOL-Logoff Port unauthorized 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 device to initiate an authentication process. 2) Upon receiving the EAPOL-Start packet, the device 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 device. 4) Upon receiving the EAP-Response/Identity packet, the device 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 database 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 device. 6) After receiving the RADIUS Access-Challenge packet, the device 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 device. 1-7

9 8) After receiving the EAP-Response/MD5 Challenge packet, the device 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 device a RADIUS Access-Accept packet. 10) Upon receiving the RADIUS Access-Accept packet, the device opens the port to grant the access request of the client. After the client gets online, the device 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 device concludes that the client has logged off and performs the necessary operations, guaranteeing that the device always knows when a client logs off. 11) The client can also send an EAPOL-Logoff packet to the device to log off unsolicitedly. In this case, the device changes the status of the port from authorized to unauthorized and sends an EAP-Failure packet to the client. In EAP relay mode, a client must use the same authentication method as that of the RADIUS server. On the device, 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 device 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. 1-8

10 Figure 1-9 Message exchange in EAP termination mode Client Device Server EAPOL EAPOR EAPOL-Start EAP-Request / Identity EAP-Response / Identity EAP-Request / MD5 challenge EAP-Response / MD5 challenge RADIUS Access-Request (CHAP-Response / MD5 challenge) RADIUS Access-Accept (CHAP-Success) EAP-Success Port authorized Handshake request [ EAP-Request / Identity ] Handshake response [ EAP-Response / Identity ] Handshake timer... EAPOL-Logoff Port unauthorized Different from the authentication process in EAP relay mode, it is the device that generates the random challenge for encrypting the user password information in EAP termination authentication process. Consequently, the device sends the challenge together with the username and encrypted password information from the client to the RADIUS server for authentication X Access Control Method H3C devices 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. 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 logs off, the others are denied as well. MAC-based access control: With this method configured on a port, all users of the port must be authenticated separately, and when a user logs off, no other users are affected X Timers This section describes the timers used on an 802.1X device to guarantee that the client, the device, and the RADIUS server can interact with each other in a reasonable manner. 1-9

11 Username request timeout timer (tx-period): This timer is triggered by the device in two cases. The first case is when the client requests for authentication. The device starts this timer when it sends an EAP-Request/Identity packet to a client. If it receives no response before this timer expires, the device retransmits the request. The second case is when the device authenticates the 802.1X client that cannot request for authentication actively. The device sends multicast EAP-Request/Identity packets periodically through the port enabled with 802.1X function. In this case, this timer sets the interval between sending the multicast EAP-Request/Identity packets. Client timeout timer (supp-timeout): Once a device 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. Server timeout timer (server-timeout): Once a device 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. Handshake timer (handshake-period): After a client passes authentication, the device sends to the client handshake requests at this interval to check whether the client is online. If the device receives no response after sending the allowed maximum number of handshake requests, it considers that the client is logged off. Quiet timer (quiet-period): When a client fails the authentication, the device refuses further authentication requests from the client in this period of time. Periodic re-authentication timer (reauth-period): If periodic re-authentication is enabled on a port, the device re-authenticates online users on the port at the interval specified by this timer. Features Working Together with 802.1X These features are: VLAN assignment Guest VLAN Auth-Fail VLAN ACL assignment Mandatory authentication domain for a specified port VLAN assignment After an 802.1X user passes the authentication, the server will send an authorization message to the device. If the server is configured with the VLAN assignment function, the assigned VLAN information will be included in the message. The device, depending on the link type of the port used to log on, adds the port to the assigned VLAN according to the following rules: If the port link type is Access, the port leaves its initial VLAN, that is, the VLAN configured for it 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 configured with MAC-based VLAN, the device will dynamically create a MAC-based VLAN according to the VLAN assigned by the authentication server, and remain the default VLAN ID of the port unchanged. 1-10

12 The assigned VLAN neither changes nor affects the configuration of a port. However, as the assigned VLAN has higher priority than the initial VLAN of the port, it is the assigned VLAN that takes effect after a user passes authentication. After the user logs off, the port returns to the initial VLAN of the port. For details about VLAN configuration, refer to VLAN Configuration. With a Hybrid port, the VLAN assignment will fail if you have configured the assigned VLAN to carry tags. With a Hybrid port, you cannot configure an assigned VLAN to carry tags after the VLAN has been assigned. Guest VLAN Guest VLAN allows unauthenticated users to access a specified VLAN, where the users can, for example, download or upgrade the client software, or execute some user upgrade programs. This VLAN is called the guest VLAN. Depending on the port access control method, a guest VLAN can be a port-based guest VLAN (PGV) or a MAC-based guest VLAN (MGV). Currently, on the switch, a guest VLAN can be only a port-based guest VLAN (PGV). PGV refers to the guest VLAN configured on a port that uses the port-based access control method. With PGV configured on a port, if no user initiates authentication on the port in a certain period of time (90 seconds by default), the port will be added to the guest VLAN and all users accessing the port will be authorized to access the resources in the guest VLAN. The device adds a PGV-configured port into the guest VLAN according to the port s link type in the similar way as described in VLAN assignment. If a user of a port in the guest VLAN initiates authentication but fails the authentication, the port will be added to the Auth-Fail VLAN configured for the port, if any. If no Auth-Fail VLAN is configured, the port will stay in the guest VLAN. For details about Auth-Fail VLAN, refer to Auth-Fail VLAN. If a user of a port in the guest VLAN initiates authentication and passes authentication successfully, the port leaves the guest VLAN, and: If the authentication server assigns a VLAN, the port joins the assigned VLAN. After the user logs off, the port returns to its initial VLAN, that is, the VLAN the port was in before it was added to any authorized VLAN. If the authentication server assigns no VLAN, the port returns to its initial VLAN. After the client logs off, the port still stays in its initial VLAN. 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. 1-11

13 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. Currently, on the switch, An Auth-Fail VLAN can be only a port-based Auth-Fail VLAN (PAFV). PAFV refers to the 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 and all users accessing the port will be authorized to access the resources in the Auth-Fail VLAN. The device adds a PAFV-configured port into the Auth-Fail VLAN according to the port s link type in the similar way as described in VLAN assignment. If a user of a port in the Auth-Fail VLAN initiates authentication 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: 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. 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. ACL assignment ACLs provide a way of controlling access to network resources and defining access rights. When a user logs on through a port, and the RADIUS server is configured with authorization ACLs, the device 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 device. 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 device. 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 X Configuration Task List Complete the following tasks to configure 802.1X: Task Remarks 802.1X Basic Configuration Required Enabling the Online User Handshake Function Enabling the Multicast Trigger Function Specifying a Mandatory Authentication Domain for a Port 1-12

14 Task Remarks Enabling the Quiet Timer Enabling the Re-Authentication Function Configuring a Guest VLAN Configuring an Auth-Fail VLAN 802.1X Basic Configuration Configuration Prerequisites 802.1X provides a method for implementing user identity authentication. 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 device and the service type must be set to lan-access. For detailed configuration of the RADIUS client, refer to AAA Configuration. 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 } CHAP by default Specify the port authorization mode for specified or all ports Specify the port access control method for specified or all ports dot1x port-control { authorized-force auto unauthorized-force } [ interface interface-list ] dot1x port-method { macbased portbased } [ interface interface-list ] auto by default macbased by default Set the maximum number of users for specified or all ports dot1x max-user user-number [ interface interface-list ] 256 by default 1-13

15 To do Use the command Remarks Set the maximum number of attempts to send an authentication request to a client Set timers dot1x retry max-retry-value 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 } 2 by default 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. Note that: For 802.1X to take effect on a port, you must enable it both globally and on the port. You can enable 802.1X and specify the port authorization mode, port access control method, and maximum number of users for a port in both system view and interface view. For detailed configuration, refer to Configuring 802.1X for a Port. The only difference between global configurations and configurations on a port lies in the applicable scope. If both a global setting and a local setting exist for an argument of a port, the one configured later takes effect X timers only need to be changed in 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 In Ethernet interface view dot1x interface interface-list interface interface-type interface-number dot1x Required Use either approach. Disabled by default Configuring 802.1X parameters for a port Follow these steps to configure 802.1X parameters for a port: 1-14

16 To do Use the command Remarks Enter system view system-view Enter Ethernet interface view Specify the port authorization mode for the port Specify the port access control method for the port Set the maximum number of users for the port interface interface-type interface-number dot1x port-control { authorized-force auto unauthorized-force } dot1x port-method { macbased portbased } dot1x max-user user-number auto by default macbased by default 256 by default Note that: Enabling 802.1X on a port is mutually exclusive with adding the port to an aggregation group. For a user-side device sending untagged traffic, the voice VLAN function and 802.1X are mutually exclusive and cannot be configured together on the same port. For details about voice VLAN, refer to VLAN Configuration. In EAP relay authentication mode, the device 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, refer to AAA Commands. 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. Enabling the Online User Handshake Function The online user handshake function allows the device to send handshake messages to online users to check whether the users are still online at the interval specified by the dot1x timer handshake-period command. If the device does not receive any response from an online user after the device has sent the handshake packet for the maximum number of times, which is set by the dot1x retry command, the device will set the user 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 Ethernet interface view Enable the online handshake function interface interface-type interface-number dot1x handshake Enabled by default 1-15

17 You need to disable proxy detection before disabling the online user handshake function. Some 802.1X clients do not support exchanging handshake packets with the device. In this case, you need to disable the online user handshake function on the device; otherwise the device will tear down the connections with such online users for not receiving handshake responses. 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 unsolicitedly. Follow these steps to configure the multicast trigger function: To do Use the command Remarks Enter system view system-view Enter Ethernet interface view Enable the multicast trigger function interface interface-type interface-number dot1x multicast-trigger Enabled by default 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 Ethernet interface view Specify a mandatory authentication domain for the port interface interface-type interface-number dot1x mandatory-domain domain-name Required Not specified by default Enabling the Quiet Timer After the quiet timer is enabled on the device, when a client fails 802.1X authentication, the device 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: 1-16

18 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 device 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 Ethernet interface view Enable periodic re-authentication interface interface-type interface-number 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 device. The re-authentication interval assignment varies by server type. Refer to the specific authentication server implementation for further details. Configuring a Guest VLAN If the traffic from a user-side device carry VLAN tags and the 802.1X authentication and guest VLAN functions are configured on the access port, you are recommended to configure different VLAN IDs for the voice VLAN, default VLAN of the port, and 802.1X guest VLAN. This is to ensure the normal use of the functions. Configuration prerequisites Create the VLAN to be specified as the guest VLAN. 1-17

19 To configure a port-based guest VLAN, make sure that the port access control method is portbased, and the 802.1X multicast trigger function is enabled. Configuration procedure Follow these steps to configure a guest VLAN: To do Use the command Remarks Enter system view system-view Configure the guest VLAN for one or more ports In system view In Ethernet interface view dot1x guest-vlan guest-vlan-id [ interface interface-list ] interface interface-type interface-number dot1x guest-vlan guest-vlan-id Required Use either approach. By default, a port is configured with no guest VLAN. Different ports can be configured with different guest VLANs, but a port can be configured with only one guest VLAN. Configuring an Auth-Fail VLAN If the traffic from a user-side device carries VLAN tags and the 802.1X authentication and guest VLAN functions are configured on the access port, you are recommended to configure different VLAN IDs for the voice VLAN, default VLAN of the port, and 802.1X guest VLAN. This is to ensure the normal use of the functions. Configuration prerequisites Create the VLAN to be specified as the Auth-Fail VLAN. To configure a port-based Auth-Fail VLAN, make sure that the port access control method is portbased, and the 802.1X multicast trigger function is enabled. Configuration procedure Follow these steps to configure an Auth-Fail VLAN: To do Use the command Remarks Enter system view system-view 1-18

20 To do Use the command Remarks Enter Ethernet interface view Configure the Auth-Fail VLAN for the port interface interface-type interface-number dot1x auth-fail vlan authfail-vlan-id Required By default, a port is configured with no Auth-Fail VLAN. Different ports can be configured with different Auth-Fail VLANs, but a port can be configured with only one Auth-Fail VLAN. Displaying and Maintaining 802.1X To do Use the command Remarks Display 802.1X session information, statistics, or configuration information of specified or all ports Clear 802.1X statistics display dot1x [ sessions statistics ] [ interface interface-list ] reset dot1x statistics [ interface interface-list ] Available in any view Available in user view 802.1X Configuration Example Network requirements It is required to use the access control method of macbased on the port GigabitEthernet1/0/1 to control clients. All clients belong to default domain aabbcc.net, which can accommodate up to 30 users. RADIUS authentication is performed at first, and then local authentication when no response from the RADIUS server is received. If the RADIUS accounting fails, the device logs users off. A server group with two RADIUS servers is connected to the switch. The IP addresses of the servers are and respectively. Use the former as the primary authentication/ accounting server, and the latter as the secondary authentication/ accounting server. Set the shared key for the device to exchange packets with the authentication server as name, and that for the device to exchange packets with the accounting server as money. Specify the device to try up to five times at an interval of 5 seconds in transmitting a packet to the RADIUS server until it receives a response from the server, and to send real time accounting packets to the accounting server every 15 minutes. Specify the device to remove the domain name from the username before passing the username to the RADIUS server. 1-19

21 Set the username of the 802.1X user as localuser and the password as localpass and specify to use clear text mode. Enable the idle cut function to log the user off whenever the user remains idle for over 20 minutes. Figure 1-10 Network diagram for 802.1X configuration Configuration procedure The following configuration procedure covers most AAA/RADIUS configuration commands for the device, while configuration on the 802.1X client and RADIUS server are omitted. For information about AAA/RADIUS configuration commands, refer to AAA Configuration. # Configure the IP addresses for each interface. (Omitted) # Add local access user localuser, enable the idle cut function, and set the idle cut interval. <Switch> system-view [Switch] local-user localuser [Switch-luser-localuser] service-type lan-access [Switch-luser-localuser] password simple localpass [Switch-luser-localuser] authorization-attribute idle-cut 20 [Switch-luser-localuser] quit # Create RADIUS scheme radius1 and enter its view. [Switch] radius scheme radius1 # Configure the IP addresses of the primary authentication and accounting RADIUS servers. [Switch-radius-radius1] primary authentication [Switch-radius-radius1] primary accounting # Configure the IP addresses of the secondary authentication and accounting RADIUS servers. [Switch-radius-radius1] secondary authentication [Switch-radius-radius1] secondary accounting # Specify the shared key for the device to exchange packets with the authentication server. 1-20

22 [Switch-radius-radius1] key authentication name # Specify the shared key for the device to exchange packets with the accounting server. [Switch-radius-radius1] key accounting money # Set the interval for the device to retransmit packets to the RADIUS server and the maximum number of transmission attempts. [Switch-radius-radius1] timer response-timeout 5 [Switch-radius-radius1] retry 5 # Set the interval for the device to send real time accounting packets to the RADIUS server. [Switch-radius-radius1] timer realtime-accounting 15 # Specify the device to remove the domain name of any username before passing the username to the RADIUS server. [Switch-radius-radius1] user-name-format without-domain [Switch-radius-radius1] quit # Create domain aabbcc.net and enter its view. [Switch] domain aabbcc.net # Set radius1 as the RADIUS scheme for users of the domain and specify to use local authentication as the secondary scheme. [Switch-isp-aabbcc.net] authentication default radius-scheme radius1 local [Switch-isp-aabbcc.net] authorization default radius-scheme radius1 local [Switch-isp-aabbcc.net] accounting default radius-scheme radius1 local # Set the maximum number of users for the domain as 30. [Switch-isp-aabbcc.net] access-limit enable 30 # Enable the idle cut function and set the idle cut interval. [Switch-isp-aabbcc.net] idle-cut enable 20 [Switch-isp-aabbcc.net] quit # Configure aabbcc.net as the default domain. [Switch] domain default enable aabbcc.net # Enable 802.1X globally. [Switch] dot1x # Enable 802.1X for port GigabitEthernet1/0/1. [Switch] interface gigabitethernet 1/0/1 [Switch-GigabitEthernet1/0/1] dot1x [Switch-GigabitEthernet1/0/1] quit # Set the port access control method. (. The default settings meet the requirement.) [Switch] dot1x port-method macbased interface gigabitethernet 1/0/1 You can use the display dot1x interface gigabitethernet 1/0/1 command to view the 802.1X configuration information. After an 802.1X user passes the RADIUS authentication with the username in the format of username@aabbcc.net, you can use the display connection command to view the connection information of the user. If the user fails the RADIUS authentication, local authentication of the user will be performed. 1-21

23 Guest VLAN and VLAN Assignment Configuration Example Network requirements As shown in Figure 1-11: A host is connected to port GigabitEthernet 1/0/2 of the device and must pass 802.1X authentication to access the Internet. GigabitEthernet 1/0/2 is in VLAN 1. The authentication server runs RADIUS and is in VLAN 2. The update server, which is in VLAN 10, is for client software download and upgrade. Port GigabitEthernet 1/0/3 of the device, which is in VLAN 5, is for accessing the Internet. As shown in Figure 1-12: On port GigabitEthernet 1/0/2, enable 802.1X and set VLAN 10 as the guest VLAN of the port. If the device sends an EAP-Request/Identity packet from the port for the maximum number of times but still receives no response, the device adds the port to its guest VLAN. In this case, the host and the update server are both in VLAN 10, so that the host can access the update server and download the 802.1X client. As shown in Figure 1-13: After the host passes the authentication and logs on, the host is added to VLAN 5. In this case, the host and GigabitEthernet 1/0/3 are both in VLAN 5, so that the host can access the Internet. Figure 1-11 Network diagram for guest VLAN configuration Update server Authenticator server VLAN 10 GE1/0/1 VLAN 2 GE1/0/4 VLAN 1 GE1/0/2 Switch VLAN 5 GE1/0/3 Internet Supplicant 1-22

24 Figure 1-12 Network diagram with the port in the guest VLAN Figure 1-13 Network diagram after the client passes authentication Configuration procedure The following configuration procedure uses many AAA/RADIUS commands. For detailed configuration of these commands, refer to AAA Configuration. Configurations on the 802.1X client and RADIUS server are omitted. # Configure RADIUS scheme <Switch> system-view [Switch] radius scheme

25 [Switch-radius-2000] primary authentication [Switch-radius-2000] primary accounting [Switch-radius-2000] key authentication abc [Switch-radius-2000] key accounting abc [Switch-radius-2000] user-name-format without-domain [Switch-radius-2000] quit # Configure authentication domain system and specify to use RADIUS scheme 2000 for users of the domain. [Switch] domain system [Switch-isp-system] authentication default radius-scheme 2000 [Switch-isp-system] authorization default radius-scheme 2000 [Switch-isp-system] accounting default radius-scheme 2000 [Switch-isp-system] quit # Enable 802.1X globally. [Switch] dot1x # Enable 802.1X for port GigabitEthernet 1/0/2. [Switch] interface gigabitethernet 1/0/2 [Switch-GigabitEthernet1/0/2] dot1x # Set the port access control method to portbased. [Switch-GigabitEthernet1/0/2] dot1x port-method portbased # Set the port authorization mode to auto. [Switch-GigabitEthernet1/0/2] dot1x port-control auto [Switch-GigabitEthernet1/0/2] quit # Create VLAN 10. [Switch] vlan 10 [Switch-vlan10] quit # Specify port GigabitEthernet 1/0/2 to use VLAN 10 as its guest VLAN. [Switch] dot1x guest-vlan 10 interface gigabitethernet 1/0/2 You can use the display current-configuration or display interface gigabitethernet 1/0/2 command to view your configuration. You can also use the display vlan 10 command to verify whether the configured guest VLAN functions normally when the device sends authentication triggering packets (EAP-Request/Identity) for more than the specified number of times in the following cases: When no users log in. When a user goes offline. After a user passes the authentication successfully, you can use the display interface gigabitethernet 1/0/2 command to verity that port GigabitEthernet 1/0/2 has been added to the assigned VLAN 5. ACL Assignment Configuration Example Network requirements As shown in Figure 1-14, a host is connected to port GigabitEthernet 1/0/1 of the device and must pass 802.1X authentication to access the Internet. 1-24

26 Configure the RADIUS server to assign ACL Enable 802.1X authentication on port GigabitEthernet 1/0/1 of the switch, and configure ACL After the host passes 802.1X authentication, the RADIUS server assigns ACL 3000 to port GigabitEthernet 1/0/1. As a result, the host can access the Internet but cannot access the FTP server, whose IP address is Figure 1-14 Network diagram for ACL assignment Configuration procedure # Configure the IP addresses of the interfaces. (Omitted) # Configure the RADIUS scheme. <Switch> system-view [Switch] radius scheme 2000 [Switch-radius-2000] primary authentication [Switch-radius-2000] primary accounting [Switch-radius-2000] key authentication abc [Switch-radius-2000] key accounting abc [Switch-radius-2000] user-name-format without-domain [Switch-radius-2000] quit # Create an ISP domain and specify the AAA schemes. [Switch] domain 2000 [Switch-isp-2000] authentication default radius-scheme 2000 [Switch-isp-2000] authorization default radius-scheme 2000 [Switch-isp-2000] accounting default radius-scheme 2000 [Switch-isp-2000] quit # Configure ACL 3000 to deny packets destined for [Switch] acl number 3000 [Switch-acl-adv-3000] rule 0 deny ip destination # Enable 802.1X globally. [Switch] dot1x # Enable 802.1X for port GigabitEthernet 1/0/1. [Switch] interface gigabitethernet 1/0/1 [Switch-GigabitEthernet1/0/1] dot1x 1-25

27 After logging in successfully, a user can use the ping command to verify whether the ACL 3000 assigned by the RADIUS server functions. C:\>ping Pinging with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for : Packets: Sent = 4, Received = 0, Lost = 4 (100% loss) C:\> 1-26