Definition

802.1X defines a port-based network access control and authentication protocol that prevents unauthorized clients from connecting to a LAN through publicly accessible ports unless they are properly authenticated.

Benefits

• 802.1X is a Layer 2 protocol and does not involve Layer 3 processing. It does not require high performance of access devices, reducing network construction costs.
• Authentication packets and data packets are transmitted through different logical interfaces, improving network security.

802.1X Authentication System

As shown in Figure 25-77, the 802.1X authentication system uses a standard client/server architecture with three components: client, access device, and authentication server.

Figure 25-77 802.1X authentication system

Overview

EAP Packet

Figure 25-78 EAP packet

EAPoL Packet

EAPoL is a packet encapsulation format defined by the 802.1X protocol. EAPoL is mainly used to transmit EAP packets over a LAN between the client and access device. The following figure shows the format of an EAPoL packet.

Figure 25-79 EAPoL packet

EAPoR

To support EAP relay, the following attributes are added to the RADIUS protocol:

• EAP-Message: is used to encapsulate EAP packets.
• Message-Authenticator: is used to authenticate and verify authentication packets to protect against spoofed packets.

The following figure shows the format of an EAPoR packet.

Figure 25-80 EAPoR packet

Guidelines for Selecting Authentication Modes

• The EAP relay mode simplifies the processing on the access device and supports various authentication methods. However, the authentication server must support EAP and have high processing capability. The commonly used authentication modes include EAP-TLS, EAP-TTLS, and EAP-PEAP. EAP-TLS has the highest security because it requires a certificate to be loaded on both the client and authentication server. EAP-TTLS and EAP-PEAP are easier to deploy since the certificate needs to be loaded only on the authentication server, but not the client.
• The main advantage of the EAP termination mode is that mainstream RADIUS servers support both Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) authentication, meaning that there is no need to upgrade servers. However, because this mode must extract client authentication information from EAP packets sent by clients and encapsulate it into standard RADIUS packets, the EAP termination mode results in a heavy workload on the device. In addition, the device does not support other EAP authentication methods except MD5-Challenge. In CHAP authentication, passwords are transmitted in cipher text; in PAP authentication, passwords are transmitted in plain text. CHAP provides higher security and is recommended.

802.1X Authentication Triggering

Authentication Processes in EAP Relay and EAP Termination Modes

In the 802.1X authentication system, the access device exchanges information with the RADIUS server in EAP relay or EAP termination mode. Figure 25-81 and Figure 25-82 show the 802.1X authentication processes in EAP relay and EAP termination modes, respectively. In the following processes, a client associates with the access device to trigger 802.1X authentication.

Figure 25-81 Authentication process in EAP relay mode

1. A client associates with the access device to trigger 802.1X authentication.

2. The access device sends an EAP-Request/Identity packet to request the identity information of the client.

3. The client sends an EAP-Response/Identity packet carrying its identity information to the access device.

4. The access device encapsulates the received EAP-Response/Identity packet into a RADIUS Access-Request packet, and sends the resulting packet to the RADIUS server.

5. The RADIUS server receives the RADIUS Access-Request packet carrying the client's identity information, and starts to negotiate the EAP authentication method with the client. The RADIUS server encapsulates a RADIUS Access-Challenge packet with an EAP authentication method for negotiation with the client, and sends the packet to the access device.

6. The access device forwards the EAP information in the received RADIUS Access-Challenge packet to the client.

7. The client parses the received EAP information to obtain the EAP authentication method selected by the RADIUS server. If the client supports this method, it sends an EAP-Response packet encapsulated with this method to the access device. If the client does not support this method, it encapsulates an EAP-Response packet with the EAP authentication method it supports, and sends the packet to the access device.

8. The access device encapsulates a RADIUS packet with the EAP information carried in the received EAP-Response packet, and sends the RADIUS packet to the RADIUS server.
9. Upon receipt of the RADIUS packet, the RADIUS server checks whether it supports the EAP authentication method specified in the packet. If so, negotiation of the EAP authentication method succeeds, and authentication starts. The following assumes that the negotiated EAP authentication method is EAP-PEAP authentication. The server then encapsulates a RADIUS packet with its certificate and sends the packet to the access device. After receiving the RADIUS packet, the access device forwards the certificate information to the client. The client verifies the server certificate (optional), negotiates TLS parameters with the RADIUS server, and establishes a TLS tunnel with the server. This tunnel is used to transmit TLS-encrypted user information among the client, access device, and RADIUS server. If negotiation of the EAP authentication method between the client and server fails, the authentication process is terminated, and the access device is notified of the authentication failure and disconnects the client.
10. After authenticating the client, the RADIUS server sends a RADIUS Access-Accept packet to notify the access device of successful authentication, and delivers a key to the access device. The access device will use this key to perform handshake with the client.
11. After receiving the RADIUS Access-Accept packet, the access device sends an EAP-Success packet to the client, changes the port state to authorized, and allows the user to access the network through the port. The access device performs handshake with the client using the key received from the RADIUS server. When the handshake is successful, the client successfully associates with the access device.
12. To go offline, the client sends an EAPoL-Logoff packet to the access device.
13. The access device changes the port state from authorized to unauthorized and sends an EAP-Failure packet to the client.

Figure 25-82 Authentication process in EAP termination mode

In EAP termination mode, the access device negotiates the EAP authentication method with the client, and sends user information to the RADIUS server for authentication. In EAP relay mode, in contrast, such negotiation is performed between the client and server; the access device is only responsible for encapsulating RADIUS packets with EAP packets and transparently transmitting the RADIUS packets to the authentication server.

VLAN

ACL

After a user is authenticated, the authentication server assigns an ACL to the user. Then, the access device controls the user packets according to the ACL.

• If the user packets match the permit rule in the ACL, the packets are allowed to pass through.
• If the user packets match the deny rule in the ACL, the packets are discarded.

The RADIUS server can assign an ACL to a user in either of the following modes:

• Static ACL assignment: The RADIUS server uses the standard RADIUS attribute Filter-Id to assign an ACL ID to the user. In this mode, the ACL and corresponding rules are configured on the access device in advance.
• Dynamic ACL assignment: The RADIUS server uses the RADIUS attribute HW-Data-Filter to assign an ACL ID and corresponding rules to the user. In this mode, the ACL ID and ACL rules are configured on the RADIUS server.

User Group

A user group consists of users (terminals) with the same attributes such as the role and rights, which is similar to the user group in the Windows system.

User group-based authorization applies to scenarios where a large number of users need to go online concurrently while resources are limited. Each user group can be associated with different ACLs, CAR policies, user VLANs, and packet priorities for access control. To use user group-based authorization delivered by the RADIUS server, ensure that the user group has been configured on the device (the user group does not need to be applied to the AAA domain).

Like static ACL-based authorization, the RADIUS server also uses the standard attribute Filter-Id to deliver user group information. The device preferentially considers the parsing result of Filter-Id to be an ACL ID. If this ACL ID does not exist on the device, the device considers the parsing result to be a user group. If the user group also does not exist on the device, authorization fails.

User group-based authorization delivered by the RADIUS server takes precedence over that configured on the device. If user group-based authorization delivered by the RADIUS server fails, user group-based authorization configured on the device is used.

Re-authentication for 802.1X-Authenticated Users

If the administrator modifies parameters such as access rights and authorization attributes of an online user on the authentication server, re-authentication of the user must be performed to ensure user validity. After re-authentication is configured for online 802.1X-authenticated users, the device sends the locally saved online user authentication information to the authentication server. If the user authentication information is the same as that on the authentication server, the user keeps online. Otherwise, the user is logged out and needs to be re-authenticated. Table 25-68 lists the re-authentication modes for 802.1X-authenticated users.

Re-authentication for Users in Abnormal Authentication State

The access device records entries for users in pre-connection state (that is, users who have not been authenticated or have failed the authentication), and grants corresponding network access rights to the users. You can configure the access device to re-authenticate these users based on user entries, so that they can obtain normal network access rights in a timely manner.

If a user fails the re-authentication before the user entry aging time expires, the access device deletes the user entry and revokes the granted network access rights. If a user is successfully re-authenticated before the user entry aging time expires, the access device adds a user-authenticated entry and grants corresponding network access rights to the user. Table 25-69 lists the methods of configuring re-authentication modes for users in abnormal authentication state.

A Client Logs Out

A user sends an EAPoL-Logoff packet through the client software to log out. Upon receipt of the packet, the access device returns an EAP-Failure packet to the client and changes the port status from authorized to unauthorized.

Figure 25-83 Client logout process

The Access Device Controls User Logout

An administrator can run the cut access-user command on an access device to log out users. If an administrator detects that an unauthorized user is online or wants a user to go offline and then go online during a test, the administrator can run a command on the access device to log out the user.

The RADIUS Server Logs Out a User

The RADIUS server logs out a user using either of the following methods:

• Sends a Disconnect Message (DM) to an access device to log out a user.
• Uses the standard RADIUS attributes Session-Timeout and Termination-Action. The Session-Timeout attribute specifies the online duration timer of a user. The value of Termination-Action is set to 0, indicating that the user is disconnected by the RADIUS server when the online duration timer expires.

Timeout Timers for EAP-Request/Identity Packets

This section discusses the timers that control the timeout and retry behavior of an 802.1X-enabled interface for sending EAP-Request/Identity packets.

During 802.1X authentication, the device sends an EAP-Request/Identity packet for the user name. The device waits for a period of time defined by a timer, and then sends another EAP-Request/Identity packet if no response is received. The number of times it resends the EAP-Request/Identity packets is defined by the dot1x retry max-retry-value variable.

Figure 25-84 shows the operation of the timer. If EAP-Request/Identity packets time out, the device sends an EAP failure packet to the client and starts a failover mechanism (Portal authentication or granting specified access permissions) if configured. In this situation, the timer is defined by the dot1x timer tx-period tx-period command. The total time it takes for 802.1X to time out is determined by the following formula:

Timeout = (max-retry-value +1) x tx-period-value

Figure 25-84 Timeout timer for EAP-Request/Identity packets when MAC address bypass authentication is not configured

Timeout Timers for EAP-Request/MD5 Challenge Packets

This section discusses the timers that control the timeout and retry behavior of an 802.1X-enabled interface for sending EAP-Request/MD5 Challenge packets.

During 802.1X authentication, the device sends an EAP-Request/MD5 Challenge packet to request the client's password in ciphertext. It waits for a period of time defined by the client timeout timer, and then sends another EAP-Request/MD5 Challenge packet. The number of times it resends the EAP-Request/MD5 Challenge packets is defined by the dot1x retry max-retry-value variable. This prevents repeated retransmission of authentication requests, which occupies lots of resources.

As shown in Figure 25-85, EAP-Request/MD5 Challenge packets time out, and then the device sends an EAP Failure packet to the client and starts a failover mechanism (MAC address authentication, Portal authentication, or granting specified access permissions) if configured. The total time it takes for EAP-Request/MD5 Challenge packets to time out is determined by the following formula:

Timeout = (max-retry-value + 1) x client-timeout-value

Figure 25-85 Timeout timer for EAP-Request/MD5 Challenge packets

Quiet Timer

This section discusses the timer that controls when 802.1X restarts after the number of failed 802.1X authentication attempts within 60 seconds reaches the value specified by the dot1x quiet-times fail-times command.

If 802.1X authentication fails and there are no failover mechanisms enabled, the device waits for a period of time known as the quiet-period (configured by the dot1x timer quiet-period quiet-period-value command). During this period of time, the device discards users' 802.1X authentication request packets, avoiding frequent authentication failures.

Figure 25-86 Quiet timer

Definition

MAC address authentication controls network access rights of users based on interfaces and MAC addresses of terminals.

Benefits

• No client software needs to be installed on terminals.
• During MAC address authentication, users do not need to enter a user name or password.
• Dumb terminals that do not support 802.1X authentication, such as printers and fax machines, can be authenticated.

Authentication System

As shown in Figure 25-87, the MAC address authentication system is a typical client/server structure which consists of three types of entities: terminal, access device, and authentication server.

Figure 25-87 MAC address authentication system

• Terminal: refers to a terminal that attempts to access the network.
• Access device: functions as the network access control point that enforces enterprise security policies. It allows, rejects, isolates, or restricts network access of users based on the security policies customized for enterprise networks.
• Authentication server: checks whether the identities of users who attempt to access the network are valid and assigns network access rights to users who have valid identities.

User Name Format

The user name and password used by a terminal for MAC address authentication must be configured on the access device in a format listed in the following table. By default, the user name and password are both the MAC address of a terminal.

VLAN

ACL

After a user is authenticated, the authentication server assigns an ACL to the user. Then, the access device controls the user packets according to the ACL.

• If the user packets match the permit rule in the ACL, the packets are allowed to pass through.
• If the user packets match the deny rule in the ACL, the packets are discarded.

The RADIUS server can assign an ACL to a user in either of the following modes:

• Static ACL assignment: The RADIUS server uses the standard RADIUS attribute Filter-Id to assign an ACL ID to the user. In this mode, the ACL and corresponding rules are configured on the access device in advance.
• Dynamic ACL assignment: The RADIUS server uses the RADIUS attribute HW-Data-Filter to assign an ACL ID and corresponding rules to the user. In this mode, the ACL ID and ACL rules are configured on the RADIUS server.

User Group

A user group consists of users (terminals) with the same attributes such as the role and rights, which is similar to the user group in the Windows system.

User group-based authorization applies to scenarios where a large number of users need to go online concurrently while resources are limited. Each user group can be associated with different ACLs, CAR policies, user VLANs, and packet priorities for access control. To use user group-based authorization delivered by the RADIUS server, ensure that the user group has been configured on the device (the user group does not need to be applied to the AAA domain).

Like static ACL-based authorization, the RADIUS server also uses the standard attribute Filter-Id to deliver user group information. The device preferentially considers the parsing result of Filter-Id to be an ACL ID. If this ACL ID does not exist on the device, the device considers the parsing result to be a user group. If the user group also does not exist on the device, authorization fails.

User group-based authorization delivered by the RADIUS server takes precedence over that configured on the device. If user group-based authorization delivered by the RADIUS server fails, user group-based authorization configured on the device is used.

Users Who Have Passed MAC Address Authentication

If the administrator modifies parameters such as access rights and authorization attributes of an online user on the authentication server, the user needs to be re-authenticated to ensure user validity. Table 25-70 describes the re-authentication mode for users who have passed MAC address authentication.

Users in Abnormal Authentication State

According to Logical Process of MAC Address Authentication, exceptions may occur during MAC address authentication. For example, the RADIUS server may go Down or user authentication may fail. By default, users in abnormal authentication state have no network access rights. Generally, the users are granted with some network access rights. When the online period of a user reaches the user entry aging time, the device deletes the user entry and revokes the network access rights granted to the user. You can configure the access device to re-authenticate these users based on user entries, so that they can obtain normal network access rights in a timely manner. Table 25-71 describes the method of configuring re-authentication for users in abnormal authentication state.

The Access Device Controls User Logout

Run a command to log out the user.

The RADIUS Server Logs Out a User

The RADIUS server controls user logout in either of the following methods:

• Sends a Disconnect Message (DM) to an access device to log out a user.
• Uses the standard RADIUS attributes Session-Timeout and Termination-Action. The Session-Timeout attribute specifies the online duration timer of a user. The value of Termination-Action is set to 0, indicating that the user is disconnected by the RADIUS server when the online duration timer expires.

Definition

Portal authentication, also known as web authentication, authenticates end users on host systems that do not run an IEEE 802.1X client. Portal authentication websites are typically referred to as Portal websites. When accessing the Internet, a user must first perform authentication on the Portal website. If the authentication fails, the user can access only certain network resources. After the authentication succeeds, the user can access more network resources.

Benefits

• Ease of use: In most cases, Portal authentication directly authenticates a user on a web page, without any additional software required on the terminal.
• Convenient operations: Portal authentication allows for value-added services on the Portal page, including advertisement push and enterprise publicity.
• Mature technology: Portal authentication has been widely used in networks of carriers, fast food chains, hotels, and schools.
• Flexible deployment: Portal authentication implements access control at the access layer or at the ingress of key data.
• Flexible user management: Portal authentication can be performed on users based on the combination of user names and any one of VLANs, IP addresses, and MAC addresses.

Device Roles

The Portal authentication system primarily consists of four components: client, access device, Portal server, and authentication server, as shown in Figure 25-91.

Figure 25-91 Portal authentication system

A Portal server can be an external Portal server or a built-in Portal server integrated into an access device. The access device with a built-in Portal server implements basic Portal server functions, including web-based login and logout, and improves flexibility of Portal authentication. However, it cannot completely replace an independent Portal server, and does not support extended functions of an external Portal server, such as MAC address-prioritized Portal authentication.

Due to limited storage space, functions, and performance of access devices, the built-in Portal server applies to scenarios requiring simple functions and having a smaller number of access users, for example, small restaurants that provide Internet access services.

ACL

After a user is authenticated, the authentication server assigns an ACL to the user. Then, the access device controls the user packets according to the ACL.

• If the user packets match the permit rule in the ACL, the packets are allowed to pass through.
• If the user packets match the deny rule in the ACL, the packets are discarded.

The RADIUS server can assign an ACL to a user in either of the following modes:

• Static ACL assignment: The RADIUS server uses the standard RADIUS attribute Filter-Id to assign an ACL ID to the user. In this mode, the ACL and corresponding rules are configured on the access device in advance.
• Dynamic ACL assignment: The RADIUS server uses the RADIUS attribute HW-Data-Filter to assign an ACL ID and corresponding rules to the user. In this mode, the ACL ID and ACL rules are configured on the RADIUS server.

User Group

A user group consists of users (terminals) with the same attributes such as the role and rights, which is similar to the user group in the Windows system.

User group-based authorization applies to scenarios where a large number of users need to go online concurrently while resources are limited. Each user group can be associated with different ACLs, CAR policies, and packet priorities for access control. To use user group-based authorization delivered by the RADIUS server, ensure that the user group has been configured on the device (the user group does not need to be applied to the AAA domain).

Like static ACL-based authorization, the RADIUS server also uses the standard attribute Filter-Id to deliver user group information. The device preferentially considers the parsing result of Filter-Id to be an ACL ID. If this ACL ID does not exist on the device, the device considers the parsing result to be a user group. If the user group also does not exist on the device, authorization fails.

User group-based authorization delivered by the RADIUS server takes precedence over that configured on the device. If user group-based authorization delivered by the RADIUS server fails, user group-based authorization configured on the device is used.

free-rule

A free rule allows users to obtain certain network access rights before they are authenticated, to meet basic network access requirements.

A Client Logs Out

A user proactively initiates logout. For example, when the user clicks the logout button, the client sends a logout request to the Portal server.

For Portal authentication using the Portal protocol, after receiving a logout request from a user, the Portal server notifies the client that the user goes offline, without waiting for the access device to confirm the logout. For Portal authentication based on the HTTP or HTTPS protocol, after receiving a logout request from a user, the Portal server instructs the client to send a logout notification to the access device.

Portal authentication based on the Portal protocol

Figure 25-98 shows the logout process.

Figure 25-98 A client logs out

1. The client sends a logout request to the Portal server.
2. The Portal server sends a user logout response to the client and sends a logout notification packet (REQ_LOGOUT) to the access device.

3. The access device sends an accounting stop request packet (ACCOUNTING-REQUEST) to the RADIUS server and disconnects the user. The access device sends a logout response packet (ACK_LOGOUT) to the Portal server.

   After receiving the ACK_LOGOUT message, the Portal server disconnects the user.

4. The RADIUS server returns an accounting stop response packet (ACCOUNTING-RESPONSE) and disconnects the user.

Portal authentication based on the HTTP or HTTPS protocol

Figure 25-99 shows the logout process. HTTP is used as an example.

Figure 25-99 A client logs out

1. The client sends a logout request to the Portal server.
2. The Portal server instructs the client to send a user logout request to the access device and disconnects the user.
3. The client sends a logout request to the access device.
4. The access device sends an ACCOUNTING-REQUEST message to the RADIUS server and disconnects the user. The access device sends a logout response packet (ACK_LOGOUT) to the client.
5. The RADIUS server returns an ACCOUNTING-RESPONSE message and disconnects the user.

The Access Device Controls User Logout

An administrator can run a command on an access device to log out users. If an administrator detects that an unauthorized user is online or wants a user to go offline and then go online during a test, the administrator can run a command on the access device to log out the user.

The Authentication Server Logs Out a User

The authentication server logs out a user using either of the following methods:

• Sends a Disconnect Message (DM) to an access device to log out a user.
• Uses the standard RADIUS attributes Session-Timeout and Termination-Action. The Session-Timeout attribute specifies the online duration timer of a user. The value of Termination-Action is set to 0, indicating that the user is disconnected by the RADIUS server when the online duration timer expires.

Figure 25-100 shows the user logout process controlled by the RADIUS server by sending a DM.

Figure 25-100 The authentication server logs out a user

1. The RADIUS server sends a DM Request to the access device.

2. The access device sends an NTF_LOGOUT message to the Portal server and disconnects the user. In addition, the access device sends a DM ACK and an ACCOUNTING-REQUEST message to the RADIUS server.

   When HTTP or HTTPS is used, the access device does not send an NTF_LOGOUT message to the Portal server.

3. The Portal server sends an AFF_ACK_LOGOUT message to the access device and disconnects the user. The RADIUS server sends an ACCOUNTING-RESPONSE message to the access device and disconnects the user.

The Portal Server Logs Out a User

When an administrator deregisters a user or the Portal server detects that a user is offline, the Portal server disconnects the user and sends a REQ_LOGOUT message to the access device.

Figure 25-101 shows the user logout process controlled by the Portal server. The Portal protocol is used as an example. For the HTTP/HTTPS protocol, the process is similar except that the Portal server does not send a logout notification to the access device.

Figure 25-101 The Portal server logs out a user

1. The Portal server sends an REQ_LOGOUT message to the access device.

2. The access device sends an accounting stop request packet (ACCOUNTING-REQUEST) to the RADIUS server and disconnects the user. The access device sends a logout response packet (ACK_LOGOUT) to the Portal server.

   After receiving the ACK_LOGOUT message, the Portal server disconnects the user.

3. The RADIUS server returns an ACCOUNTING-RESPONSE message and disconnects the user.

Quiet Timer

This section discusses the timer that controls when Portal authentication restarts after the number of failed Portal authentication attempts within 60 seconds reaches the value specified by the portal quiet-times fail-times command.

If the number of a user's failed Portal authentication attempts within 60 seconds reaches the specified value, the access device waits for a period of time specified by the portal timer quiet-period quiet-period-value command. During this period, the access device discards the Portal authentication requests sent from the user. Figure 25-102 shows the operation of the quiet timer by using the Portal protocol as an example.

Figure 25-102 Quiet timer

Portal Server Detection Timer

This section discusses the timer that controls the interval at which the Portal server state is detected. The value of the timer is specified by the server-detect interval interval-period command.

There are two Portal server detection modes: Portal-based and HTTP-based. For Portal-based Portal authentication, the device supports both of the two modes. For HTTP- or HTTPS-based Portal authentication, the device supports only HTTP-based Portal server detection.

In Portal-based Portal server detection mode: The Portal server periodically (at an interval of Ts) sends heartbeat packets to the access device. If the access device receives Portal heartbeat packets or other authentication packets from the Portal server before the Portal server detection timer expires, detection is successful and the access device considers the Portal server to be reachable and in Up state. Otherwise, Portal server detection fails. When the number of consecutive detection failures reaches the maximum number specified by the server-detect max-times times command, the access device changes the status of the Portal server from Up to Down.

In HTTP-based Portal server detection mode: The access device periodically sends HTTP packets to the Portal server and expects a response packet from the Portal server. If the access device receives a response packet within the specified detection interval (configured using server-detect interval interval-period), the detection is successful. Otherwise, the detection fails. When the number of consecutive detection failures reaches the maximum number specified by the server-detect max-times times command, the access device changes the status of the Portal server from Up to Down.

The Portal server detection process is shown in Figure 25-103 and Figure 25-104.

It is recommended that the value of interval-period configured on the access device be greater than the heartbeat packet interval configured on the Portal server.

Figure 25-103 Portal-based Portal server detection process

Figure 25-104 HTTP-based Portal server detection process

Additionally, the access device takes the following actions to inform administrators of the Portal server states in real time and ensure that users have certain network access rights:

• Sends alarms: When the status of a Portal server is changed, the access device sends an alarm to the NMS. The alarm information records the IP address and status of the Portal server.
• Sends logs: When the status of a Portal server is changed, the access device sends a log to the NMS. The log information records the IP address and status of the Portal server.
• Enables the Portal escape mechanism. If the number of Portal servers in Up state is equal to or less than the minimum number (specified by the server-detect critical-num critical-num command), the access device disables Portal authentication so that all Portal users can access specified network resources. For details about authorization methods, see "The Portal server is Down" in NAC Escape Mechanism. When the access device receives a heartbeat packet or other authentication packets (for example, a user logout packet) from the Portal server, or HTTP-based Portal server detection success, the access device changes the status of the Portal server to Up. If the number of Portal servers in Up state is greater than the minimum value, Portal authentication is restored.

User Information Synchronization Timer

This section discusses the timer that controls the interval at which user information is synchronization. The value of the timer is specified by the user-sync interval interval-period command.

The Portal server periodically (at an interval of Tps) encapsulates online user information into a USER_SYN message (a user synchronization request packet) and sends it to the access device. Upon receipt of the USER_SYN message, the access device compares the online user information in the USER_SYN message with the local online user information.

• For user information that exists both in the USER_SYN message and on the access device, the access device marks the user information as synchronized.
• For user information that exists only on the access device but not in the USER_SYN message, the access device considers that user information fails to be synchronized. If information about a user fails to be synchronized before the synchronization timer expires, the synchronization failure is counted as 1. When the number of synchronization failures reaches the value specified by the user-sync max-times times command, the access device deletes the user information and logs out the user.
• For user information that exists only in the USER_SYN message but not on the access device, the access device encapsulates the user information into an ACK_USER_SYN message and sends the message to the Portal server. The Portal server then deletes the corresponding user information.

Figure 25-105 shows the process of synchronizing user information.

Figure 25-105 Process of synchronizing user information

This function is applicable only to the external Portal server that uses the Portal protocol. Currently, the access device can synchronize user information only with Agile Controller-Campus, iMaster NCE-Campus, and Huawei Symantec TSM Portal server. When the Portal server is Agile Controller-Campus or iMaster NCE-Campus, you need to enable online user information synchronization on the server.

It is recommended that the product of interval-period and times be greater than the interval for the Portal server to send USER_SYN messages. Otherwise, the access device may log out users if it receives no USER_SYN message from the Portal server after the maximum number of synchronization failures is reached.

User Logout Retransmission Timer

This section discusses the timer that controls the timeout and retry behavior of a Portal authentication-enabled interface for sending NTF-LOGOUT messages.

During Portal authentication, after a Portal authentication user goes offline, the access device sends an NTF-LOGOUT message to instruct the Portal server to delete the user information. The access device waits for a period of time defined by the user logout retransmission timer, and sends another NTF-LOGOUT message if no response is received. The timer and the number of times it resends the NTF-LOGOUT messages are configured by the portal logout resend times timeout period command.

Figure 25-106 shows the operation of the user logout retransmission timer.

Figure 25-106 User logout retransmission timer

User Heartbeat Detection Timer

This section discusses the timer that controls the interval at which a built-in Portal server detects heartbeats of clients. The interval is specified by the portal local-server keep-alive interval interval-value command.

After a user is authenticated, the Portal server pushes a connection holding page that has a heartbeat program embedded to the user. The client then periodically sends heartbeat packets to the access device, indicating that the user is online. If the access device receives a heartbeat packet from the client, it resets the user heartbeat detection timer. If the access device does not receive any heartbeat packet or authentication packet from the client before the user heartbeat detection timer expires, the access device considers the user offline and logs out the user. Figure 25-107 shows the process of detecting user heartbeats by the built-in Portal server.

Figure 25-107 User heartbeat detection by the built-in Portal server

On the Windows 7 system, the heartbeat program is supported by Internet Explorer 8, FireFox 3.5.2, Google Chrome 28.0.1500.72, and Opera 12.00.

Browsers using Java1.7 and later versions do not support the heartbeat program.

Built-in Portal Server Page Customization Specifications

File Naming Specifications

The file names of primary index pages cannot be customized and must be the file name listed in Table 25-76. Users can customize other file names. Ensure that the file name does not contain Chinese characters and the file name length does not exceed 127 characters.

Page Request Specifications

• The built-in Portal server accepts only Get and Post requests.

  • Get requests are used to obtain static files on authentication pages, including .png and .css files.

  • Post requests are used to submit user names and passwords and to log in and log out.

• The background image, advertisement image, and logo image used by the PC must be named background-1.jpg, ad.png, and logo.png, respectively. The background image, advertisement image, and logo image used by a phone must be bg_phone.jpg, ad_phone.png, and logo_phone.png, respectively. The background image, advertisement image, and logo image used by WeChat must be bg_wechat.jpg, ad_wechat.png, and logo_wechat.png, respectively. Additionally, these images must be stored in /custom. Otherwise, the device does not support customization of these images.

Attribute Specifications in Post Requests

• Forms on authentication pages must be edited according to the following rules:

  • The URL must contain the protocol type, gateway address, and port number, such as "<%=HuaWei_GetProtocol()%>://<%=HuaWei_GetUserGateWayIP()%>:<%=HuaWei_GetPort()%>/login". Otherwise, user information cannot be sent to the Portal server.

  • The fixed user name attribute is username and the fixed password attribute is password.

  • There must be an attribute that indicates the user login or logout: type = submit. The value is Login or Logout.

  • A login Post request must contain three attributes: username, password, and Login.

  • A logout Post request must contain the Logout attribute.

• The page that must contain a login Post request is login.html.

  The following example lists some scripts of the login.html page.

  <form id="LoginForm" name="LoginForm" method="post" action="<%=HuaWei_GetProtocol()%>://<%=HuaWei_GetUserGateWayIP()%>:<%=HuaWei_GetPort()%>/login" onSubmit ='return CheckSubmit()' style="height:310px; margin-left:0px; margin-top:0px;" target="_top">
  <INPUT type="submit" id="sub1" name="Login" style="height:100px; margin-top:3px; margin-bottom:3px;" />
  
  <div id="lab_Username" style="display:none">Username:</div>
  <input type="text" name="username" maxlength="66" class="loginTxt" autocomplete="off" disableautocomplete placeholder="Username"  style="background-image:(./image/user.jpg);background-repeat:no-repeat;padding-left:30px;height:45px;width:300px;background-position:left center;background-color:white;border:1px solid gray;display:inline" />
  
  <div id="lab_PassWord" style="display:none">Password:</div>
  <input name="password" type="password" id="password" maxlength="128" class="loginTxt" autocomplete="off" disableautocomplete placeholder="Password" style="background-image:(./image/passcode.jpg);background-repeat:no-repeat;padding-left:30px;height:45px;width:300px;background-position:left center;background-color:white;border:1px solid gray;" /> 
  <INPUT type="hidden" name="RedirectUrl" value="">
  <INPUT type="hidden" name="anonymous" value="<%=HuaWei_GetAnonymous()%>">
  <INPUT type="hidden" name="anonymousurl" value="<%=HuaWei_GetAnonymous()%>">
  </form>

• The pages that must contain a logout Post request are hasonline.html, auth_success.html, and logout_failure.html.

  The following example lists some scripts of the hasonline.html page.

  <form name=LogoutForm method=post action="<%=HuaWei_GetProtocol()%>://<%=HuaWei_GetUserGateWayIP()%>:<%=HuaWei_GetPort()%>/logout">
  <input onClick="logout()" name="submit" type=submit value="Logout" class="none">
  </form>

Page Content Modification Specifications

Currently, the default page file package (portalpage.zip) only provides HTML files in Chinese and English. If a user needs to change the language, the user can only modify the descriptive content displayed on the page.

1. Visit Huawei enterprise technical support website, download the product software package, and decompress the product software package to obtain the portalpage.zip file.

2. Decompress the portalpage.zip file. You can modify the descriptive content displayed on the page in the HTML file, but cannot modify names and directory structure of the primary index pages in the folder. For example, you can modify the Login Time displayed on the auth_success.html page.

   <tr bgcolor="#B0DFFF"><td width="35%" align="center">Login Time:</td>
    <td >
    <INPUT type="hidden"  name="HiddenLoginTime" size=25 value="<%=HuaWei_GetLoginTime()%>">
    <INPUT name="LoginTime" size=20 maxlength="80" style="HEIGHT: 20Px; BACKGROUND-COLOR: #B0DFFF; BORDER-BOTTOM: #B0DFFF 1px double; BORDER-LEFT: #B0DFFF 1px double; BORDER-RIGHT: #B0DFFF 1px double; BORDER-TOP: #B0DFFF 1px double; COLOR: #000000" readonly >
    </td>
   </tr>
   

3. After modifying the content, perform operations based on the page file compression and storage specifications.

Page File Compression and Storage Specifications

• After all authentication pages have been edited, these pages must be compressed into a ZIP file. The ZIP file name cannot contain spaces.

• The ZIP file can be uploaded to the device using FTP and stored in the root directory of the device.

The following example shows the storage directory of a ZIP file.

<HUAWEI> dir *.zip
Directory of sdcard:/
  Idx  Attr     Size(Byte)  Date        Time(LMT)  FileName
    0  -rw-        146,825  Aug 30 2016 04:19:19   portalpage-normal.zip
    1  -rw-        251,704  Aug 25 2016 18:07:28   portalpage.zip
    2  -rw-        251,711  Aug 25 2016 19:01:37   portalpage1.zip
    3  -rw-        251,709  Aug 25 2016 19:07:44   portalpage2.zip
1,969,388 KB total (1,681,124 KB free)

Script Functions on Pages

Table 25-77 lists script functions on pages. Select these script functions as required.

Customizing the Login Page of the Built-in Portal Server

When a built-in Portal server is used for authentication, the device used as the built-in Portal server forcibly pushes the login page to users. The users can enter the user name and password on the login page for authentication.

The device supports login page customization to meet various user requirements. For example, you can load the logo, advertisement image, usage instruction, and warranty disclaimer on the login page, and change the background image or color of the login page.

In Figure 25-108, a user uses the login page of the default package portalpage.zip.

Figure 25-108 Initial login page

In Figure 25-109, the portal local-server logo load logo-file command is used to load the logo image on the login page. The size of the logo image must be equal to or less than 128 KB. The image of 591 x 80 pixels is recommended.

Figure 25-109 Login page with a logo image

In Figure 25-110, the portal local-server ad-image load ad-image-file command is used to load the advertisement image on the login page. The size of the advertisement image must be equal to or less than 256 KB. The image of 670 x 405 pixels is recommended.

Figure 25-110 Login page with the advertisement image

In Figure 25-111, the portal local-server page-text load string command is used to load the usage instruction on the login page.

Figure 25-111 Login page with the usage instruction

In Figure 25-112, the portal local-server policy-text load string command is used to load the warranty disclaimer on the login page.

Figure 25-112 Login page with the warranty disclaimer

In Figure 25-113, the portal local-server background-image load { background-image-file | default-image1 } command is used to change the background image of the login page.

Figure 25-113 Changing the background image of the login page

Authentication Process

On the network shown in Figure 25-114, when a client is to be authenticated for the first time, the access device sends the client's MAC address to the RADIUS server. However, authentication fails because the RADIUS server does not find the client's MAC address. Then Portal authentication is triggered for the client. After successful Portal authentication, the RADIUS server saves the client's MAC address. When the client attempts to connect to the wireless network after unexpected logout due to unstable wireless signals or switching between different signal coverage areas, the access device sends the client's MAC address to the RADIUS server for identity authentication.

• If the client's MAC address is stored on the RADIUS server, the RADIUS server verifies the user name and password (both are the client's MAC address) and authorizes the client. Then the client can access the network without entering the user name and password.
• If the client's MAC address has expired on the RADIUS server and the RADIUS server has deleted the client's MAC address, MAC address authentication fails. The access device then pushes the Portal authentication page to the client. The client user needs to enter the user name and password to pass identity authentication.

Figure 25-114 MAC address-prioritized Portal authentication process

Authentication Process

Figure 25-115 shows packet exchange in the MAC address authentication process in the scenario where a Portal server is deployed.

Figure 25-115 MAC address authentication in the scenario where a Portal server is deployed

Introduction

For security purposes, enterprises allow only specified terminals to access the enterprise network. After MAC address + 802.1X hybrid authentication is configured, the device performs MAC address authentication and 802.1X authentication on terminals in sequence. Terminals can access the network only after passing both authentications.

In this authentication mode, the device performs 802.1X authentication on user terminals only after they pass MAC address authentication, significantly reducing the workload on the RADIUS server.

Authentication Process

The MAC address + 802.1X hybrid authentication process is a combination of MAC address authentication and 802.1X authentication. For details, see 802.1X Authentication Process and MAC Address Authentication Process.