No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

S600-E V200R013C00 Configuration Guide - User Access and Authentication

This document describes the configurations of User Access and Authentication Configuration, including AAA, NAC, and Policy Association.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Understanding Portal Authentication

Understanding Portal Authentication

Overview of Portal Authentication

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 a user accesses the Internet, the user must be first authenticated 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 2-18.

Figure 2-18  Portal authentication system
  • Client: a host that has a browser running Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) installed.
  • Access device: a switch or router, which provides the following functions:
    • Redirects all HTTP or HTTPS requests of users on authentication subnets to the Portal server before authentication.
    • Interacts with the Portal server and authentication server to implement user identity authentication, authorization, and accounting during authentication.
    • Grants users access to specified network resources after successful authentication.
  • Portal server: a server system that receives authentication requests from clients, provides free Portal services and authentication pages, and exchanges client authentication information with an access device.
  • Authentication server: interacts with the access device to implement user authentication, authorization, and accounting.
NOTE:

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.

Portal Authentication Protocol

During Portal authentication, HTTP/HTTPS and Portal protocols are used.

The client first sends a connection request and an authentication request carrying the user name and password in sequence to the Portal server through HTTP or HTTPS. Upon receipt of the authentication request, the Portal server starts authentication in either of the following ways:
  • The Portal server sends a Portal authentication request carrying the user name and password to an access device through the Portal protocol. The Portal protocol is compatible with the Portal 2.0 protocol of China Mobile Communications Corporation (CMCC), and supports basic functions of the Portal 2.0 protocol. For details, see Portal Authentication Process Based on the Portal Protocol.
  • The Portal server instructs the client to initiate a Portal authentication request to the access device through the HTTP or HTTPS protocol. The client then initiates a Portal authentication request carrying the user name and password to the access device through the HTTP or HTTPS protocol. For details, see HTTP- or HTTPS-based Portal Authentication Process.
NOTE:

It is recommended that an access device use the Portal protocol to communicate with the Portal server. If the Portal server does not support the Portal protocol, the access device can use the HTTP or HTTPS protocol.

If a built-in Portal server is used for Portal authentication, the access device supports only the Portal protocol.

The HTTP or HTTPS protocol can be used as the Portal access protocol or Portal authentication protocol. This section describes the Portal authentication protocols supported by access devices.

Portal Protocol
Packet Format

A Portal packet consists of a fixed-length header and variable-length attribute fields in the type, length, value (TLV) format. Figure 2-19 shows the Portal packet format.

Figure 2-19  Portal packet format

Packet Fields

Version

Portal protocol version. The length is 1 byte, and the default value is 0x02.

Type

Portal protocol packet type. The length is 1 byte.

Packet Type Value Description
REQ_CHALLENGE 0x01 Challenge request packet sent from the Portal server to an access device.
ACK_CHALLENGE 0x02 Packet sent from the access device to the Portal server in response to a challenge request packet.
REQ_AUTH 0x03 Authentication request packet sent from the Portal server to the access device.
ACK_AUTH 0x04 Packet sent from the access device to the Portal server in response to an authentication request packet.
REQ_LOGOUT 0x05 Logout request packet sent from the Portal server to the access device.
ACK_LOGOUT 0x06 Packet sent from the access device to the Portal server in response to a logout request packet.
AFF_ACK_AUTH 0x07 Authentication success response packet sent from the Portal server to the access device.
NTF_LOGOUT 0x08 Packet sent from the access device to the Portal server to notify forcible user logout.
REQ_INFO 0x09 Information query packet sent from the Portal server to the access device.
ACK_INFO 0x0a Packet sent from the access device to the Portal server in response to an information query packet.
ACK_NTF_LOGOUT 0x0e Packet sent from the Portal server to notify the access device that users have been forced to go offline.
USER_SYN 0x10 User information synchronization request packet sent from the Portal server to the access device.
ACK_USER_SYN 0x11 Packet sent from the access device to the Portal server in response to a user information synchronization request packet.
STATUS_NOTIFY 0x81 Status notification packet periodically sent from the Portal server to the access device.
ACK_STATUS_NOTIFY 0x82 Packet sent from the access device to the Portal server in response to a status notification packet.
MAC_QUERY 0x30 MAC cache query packet sent from the access device to the Portal server.
ACK_MAC_QUERY 0x31 MAC cache query response packet sent by the Portal server to the access device.

AuthType

Authentication mode. The length is 1 byte. Two authentication modes are supported:

  • CHAP authentication: is three-way handshake authentication and transmits user names and passwords in cipher text. The AuthType field for CHAP authentication is 0.

  • PAP authentication: is two-way handshake authentication and transmits user names and passwords in plain text. The AuthType field for PAP authentication is 0x01.

REQ_CHALLENGE and ACK_CHALLENGE are exchanged only in CHAP authentication. CHAP authentication is more secure and reliable than PAP, and is recommended if high security is required.

Rsvd

Reserved for future use. It is 1 byte in length and is 0 in all packets.

SerialNo

Serial number of a packet. It is 2 bytes in length and is randomly generated by the Portal server. The Portal server must ensure that the serial numbers of all packets in the same authentication process are the same and that the serial numbers of packets in different authentication processes are different within a certain period.

RequestID

Packet ID. It is 2 bytes in length and is generated by an access device. A packet ID must be unique.

UserIP

IP address of a Portal user. It is 4 bytes in length.

UserPort

Reserved for future use. It is 2 bytes in length and is 0 in all packets.

ErrCode

Error code. It is 1 byte in length and is used together with the Type field.

  • When the Type field displays 0x01, 0x03, 0x07, 0x09, 0x0e, 0x10, 0x11, 0x30, 0x31, 0x81, or 0x82:

    The ErrCode field is meaningless and the value is 0.

  • When the Type field displays 0x02:

    • If the ErrCode field displays 0, the access device notifies the Portal server that the challenge request is successful.
    • If the ErrCode field displays 0x01, the access device notifies the Portal server that the challenge request is denied.
    • If the ErrCode field displays 0x02, the access device notifies the Portal server that the connection has been established.
    • If the ErrCode field displays 0x03, the access device notifies the Portal server that a user is being authenticated and it should try again later.
    • If the ErrCode field displays 0x04, the access device notifies the Portal server that the challenge request of the user fails.
    • If the ErrCode field displays 0xfd, the access device notifies the Portal server that the user is not found (the user has roamed or gone offline).
  • When the Type field displays 0x04:

    • If the ErrCode field displays 0, the access device notifies the Portal server that the user has been authenticated successfully.
    • If the ErrCode field displays 0x01, the access device notifies the Portal server that the user authentication request is denied.
    • If the ErrCode field displays 0x02, the access device notifies the Portal server that the connection has been established.
    • If the ErrCode field displays 0x03, the access device notifies the Portal server that a user is being authenticated and it should try again later.
    • If the ErrCode field displays 0x04, the access device notifies the Portal server that the user fails the authentication due to an error, for example, incorrect user name.
    • If the ErrCode field displays 0x05, the access device notifies the Portal server that the user fails the authentication because the number of online Portal users has reached the maximum value.
    • If the ErrCode field displays 0x06, the access device notifies the Portal server that the user authentication fails because it is authenticating the user in another mode.
    • If the ErrCode field displays 0xfd, the access device notifies the Portal server that the user is not found (the user has roamed or gone offline).
  • When the Type field displays 0x05:

    • If the ErrCode field displays 0, the Portal server sends a logout request packet to the access device.
    • If the ErrCode field displays 0x01, the Portal server sends a packet to the access device if the Portal server does not receive any response packet from the access device with the period defined by the corresponding timer.
  • When the Type field displays 0x06:

    • If the ErrCode field displays 0, the access device notifies the Portal server that the user has gone offline.
    • If the ErrCode field displays 0x01, the access device notifies the Portal server that the user's logout request is denied.
    • If the ErrCode field displays 0x02, the access device notifies the Portal server that the user fails to go offline.
  • When the Type field displays 0x08:

    If the ErrCode field displays 0x02, the access device notifies the Portal server that the user is forced to go offline.

  • When the Type field displays 0x0a:

    • If the ErrCode field displays 0, the access device notifies the Portal server that the information query packet has been processed successfully.
    • If the ErrCode field displays 0x01, the access device notifies the Portal server that the information query packet fails to be processed because this function is not supported.
    • If the ErrCode field displays 0x02, the access device notifies the Portal server that the information query packet fails to be processed due to an error, for example, incorrect information query packet format.

AttrNum

Number of attributes in the Attribute field. It is 1 byte in length. The Attribute field contains a maximum of 255 attributes.

Authenticator

Authentication key. It is 16 bytes and is calculated using the MD5 algorithm.

Attribute

Variable-length field. It is composed of multiple attributes in the TLV format.

  • AttrType: indicates an attribute type. The length is 1 byte.

  • AttrLen: indicates the length (1 byte) of the Attribute field, which is the sum of the lengths of the AttrType, AttrLen, and AttrValue fields.

  • AttrValue: indicates a specific attribute value, for example, user name and password. The length cannot exceed 253 bytes.

AttrValue AttrType AttrValue Length (Bytes) Description Packet Type Carrying This Attribute
UserName 0x01 1-253 User name in the format of user name@domain name, for example, test@huawei.com. REQ_AUTH
PassWord 0x02

1-128

User-entered password. REQ_AUTH
Challenge 0x03 16 Authentication key encrypted in CHAP mode. ACK_CHALLENGE
ChapPassWord 0x04 16 Password encrypted in CHAP mode. REQ_AUTH
TextInfo 0x05 2-253 Used to transparently transmit the prompt information provided by a third-party authentication device, such as a RADIUS server, to the Portal server. This attribute carries a character string without the end character \0. A packet may carry multiple such attributes but is recommended to carry only one attribute. ACK_AUTH, REQ_AUTH (only in Portal 1.0)
Port 0x08 1-51

Port number in the following formats:

  • Type + length (in REQ_INFO packets)
  • Type + length + content (in ACK_INFO packets)
REQ_INFO, ACK_INFO
Bas_IP 0x0a 4 IP address of the AC to which a user roams. ACK_AUTH, ACK_CHALLENGE
User_Mac 0x0b 6 User MAC address. ACK_AUTH, ACK_LOGOUT, NTF_LOGOUT, ACK_CHALLENGE, ACK_INFO, REQ_CHALLENGE, REQ_AUTH, REQ_LOGOUT
User_Private_IP 0x0d 4-252 User IPv4 address. USER_SYN, ACK_USER_SYN
WebAuthenInfo 0x40 1-247 Used to transmit the user input on web pages to the RADIUS server. A packet may carry multiple such attributes. REQ_AUTH
User_IPV6 0xf1 16 User IPv6 address. REQ_CHALLENGE, ACK_CHALLENGE, REQ_AUTH, ACK_AUTH, REQ_LOGOUT, ACK_LOGOUT, AFF_ACK_AUTH, NTF_LOGOUT, REQ_INFO, ACK_INFO
HTTP/HTTPS Protocol
Introduction
The device can interact with a client using the HTTP or HTTPS protocol:
  • HTTP is a transport protocol used to transport World Wide Web (WWW) data.

  • HTTPS is a secure HTTP and also known as HyperText Transfer Protocol over Transport Layer Security (HTTP over TLS) or HyperText Transfer Protocol over Secure Socket Layer (HTTP over SSL). HTTPS uses HTTP for communication and SSL/TLS for data encryption.

    HTTPS is primarily used for identity authentication to protect data privacy and integrity.

Client Request Methods

During Portal authentication, the Portal server instructs the client to use the HTTP or HTTPS protocol to initiate a Portal authentication request to an access device. The client then sends an authentication request to the access device. The request packet carries the HTTP request method and HTTP request body (the requested data includes the user name, password, and other parameters).

Currently, the device supports the following HTTP request methods:

  • POST: The requested data is stored in the body of an HTTP request packet and is not a part of a URL. Therefore, the data is not easy to intercept and has high security. The device supports this request method by default.

  • GET: The requested data is appended to a URL and separated from the URL by a question mark (?). The data is a part of the URL, so it is visible to all users, is easy to intercept, and has poor security.

After receiving an authentication request packet, the access device parses the request packet to obtain parameters including the user name and password. The access device then sends the obtained user name and password to the RADIUS server for authentication. The parameter names in a request packet must comply with specific specifications. Otherwise, the device cannot parse the request packet, leading to user authentication failures. Table 2-10 lists the parameters in a request packet. For example, after receiving a POST request packet (username=abc&password=abc&client_mac=112233445566&initurl=http://portalserver.example.com/login), the device using default parameter names fails to parse the packet. This is because the client_mac parameter specifying the user MAC address in the packet is different from the default macaddress parameter used on the device.

Therefore, when HTTP or HTTPS is used for Portal authentication, ensure that the parameter names configured on the Portal server are the same as those configured on the device.

Table 2-10  Parameters in a request packet
Default Parameter Name Description
cmd User operation commands.
login User login.
logout User logout.
initurl Initial login URL.
username User name.
password Password.
ipaddress User IP address.
macaddress User MAC address.

Portal Authentication Modes

Two Portal authentication modes are available based on the network layer where it is used: Layer 2 authentication and Layer 3 authentication.

  • Layer 2 authentication is recommended when the client and access device are either directly connected or have only Layer 2 devices between them. In this scenario, the device can learn users' MAC addresses and identify the users using their MAC addresses and IP addresses.

    Layer 2 authentication provides a simple authentication process while ensures high security. However, users must be in the same network segment as the access device, causing inflexible networking.

  • Layer 3 authentication is recommended when Layer 3 forwarding devices exist between the client and access device. In this scenario, the device cannot obtain the MAC address of a client and uses only the IP address of the client to identify the user.

    Layer 3 authentication allows for flexible networking and facilitates remote control. However, users can only be identified using their IP addresses, leading to poor security.

Portal Authentication Process

The first thing to do during authentication is to initiate authentication. There are two methods for triggering Portal authentication:

  • Active authentication

    In this mode, a user actively accesses the Portal server for identity authentication. The user accesses the Portal authentication website through a browser, enters the IP address of the Portal server in the browser, and then enters the user name and password on the displayed web page for authentication.

  • Redirect authentication

    In this mode, a user enters a non-authentication website address and is redirected to the Portal authentication website for authentication.

Portal Authentication Process Based on the Portal Protocol

This section describes the Layer 2 authentication process of an external Portal server. The authentication process of a built-in Portal server is similar to that of an external Portal server.

Figure 2-20 shows the packet exchange in the Layer 2 Portal authentication process based on the Portal protocol. The Layer 3 Portal authentication process is the same as the Layer 2 Portal authentication process, except that no pre-connection is established between the client and access device.

Figure 2-20  Portal authentication process based on the Portal protocol

The authentication process is described as follows:

  1. Before authentication, the client establishes a pre-connection with the access device. The access device creates a user online entry for the client and grants the client access to certain network resources.

  2. The client initiates an HTTP connection request.

  3. Upon receipt of the HTTP connection request packet, the access device determines whether to permit the packet. If the HTTP packet is destined for the Portal server or a publicly available network resource, the access device permits the packet. If the HTTP packet is destined for other addresses, the access device sends the URL of the Portal authentication page to the client.

  4. The client sends an HTTP connection request to the Portal server based on the obtained URL.

  5. The Portal server returns the Portal authentication page to the client.

  6. The user enters the user name and password on the Portal authentication page. The client then sends a Portal authentication request to the Portal server.
  7. (Optional) The Portal server sends a Portal challenge request packet (REQ_CHALLENGE) to the access device. This step is performed only when CHAP authentication is used between the Portal server and access device. If PAP authentication is used, steps 7 and 8 are not performed.
  8. (Optional) The access device sends a Portal challenge response packet (ACK_CHALLENGE) to the Portal server.
  9. The Portal server encapsulates the entered user name and password into a Portal authentication request packet (REQ_AUTH) and sends the packet to the access device.
  10. The access device encapsulates the entered user name and password into a RADIUS authentication request packet (ACCESS-REQUEST) and sends the packet to the RADIUS server.
  11. The RADIUS server authenticates the user name and password. If authentication succeeds, the RADIUS server sends an authentication accept packet (ACCESS-ACCEPT) to the access device. If authentication fails, the RADIUS server sends an authentication reject packet (ACCESS-REJECT) to the access device.

    The ACCESS-ACCEPT packet also contains user authorization information because RADIUS authorization is combined with authentication and cannot be separated.

  12. The access device permits or denies the user access according to the authentication result. If the user access is permitted, the access device sends an accounting start request packet (ACCOUNTING-REQUEST) to the RADIUS server.
  13. The RADIUS server replies with an accounting start response packet (ACCOUNTING-RESPONSE), starts accounting, and adds the user to the local online user list.
  14. The access device sends the Portal authentication result (ACK_AUTH) to the Portal server and adds the user to the local online user list.
  15. The Portal server sends the Portal authentication result to the client to inform the client of successful authentication and adds the user to the local online user list.
  16. The Portal server sends an authentication acknowledgment packet (AFF_ACK_AUTH) to the access device.
HTTP- or HTTPS-based Portal Authentication Process

Figure 2-21 shows the packet exchange in the Layer 2 HTTP-based Portal authentication process. The Layer 3 Portal authentication process is the same as the Layer 2 Portal authentication process, except that no pre-connection is established between the client and access device.

The exchange of HTTPS packets is similar to that of HTTP packets except that HTTPS packets need to be encrypted and decrypted.

Figure 2-21  HTTP-based Portal authentication process

The authentication process is described as follows:

  1. Before authentication, the client establishes a pre-connection with the access device. The access device creates a user online entry for the client and grants the client access to some network resources.

  2. The client initiates an HTTP connection request.

  3. Upon receipt of the HTTP connection request packet, the access device determines whether to permit the packet. If the HTTP packet is destined for the Portal server or a publicly available network resource, the access device permits the packet. If the HTTP packet is destined for other addresses, the access device redirects the client to the Portal authentication page.

  4. The client sends an HTTP connection request to the Portal server based on the obtained URL.

  5. The Portal server returns the Portal authentication page to the client.

  6. The user enters the user name and password on the Portal authentication page. The client then sends a Portal authentication request to the Portal server.
  7. The Portal server instructs the client to send a Portal authentication request to the access device.
  8. The client sends a Portal authentication request (HTTP POST/GET) to the access device.
  9. The access device sends a RADIUS authentication request packet (ACCESS-REQUEST) to the RADIUS server based on the obtained user name and password.
  10. The RADIUS server authenticates the user name and password. If authentication succeeds, the RADIUS server sends an authentication accept packet (ACCESS-ACCEPT) to the access device. If authentication fails, the RADIUS server sends an authentication reject packet (ACCESS-REJECT) to the access device.

    The ACCESS-ACCEPT packet also contains user authorization information because RADIUS authorization is combined with authentication and cannot be separated.

  11. The access device permits or denies the user access according to the authentication result. If the user access is permitted, the access device sends an accounting start request packet (ACCOUNTING-REQUEST) to the RADIUS server.
  12. The RADIUS server replies with an accounting start response packet (ACCOUNTING-RESPONSE), starts accounting, and adds the user to the local online user list.
  13. The access device returns the Portal authentication result to the client and adds the user to the local online user list.

Portal Authorization

Authentication is used to check whether the identity of the user who attempts to access the network is valid. Authorization is used to specify the network access rights that an authorized user can have, that is, the resources that the authorized user can access. ACLs and UCL groups are often used for authorization. RADIUS authorization is used as an example. For details about other authorization methods and more authorization parameters, see AAA Authorization Scheme.

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 extended by Huawei 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.
UCL
A User Control List (UCL) is a collection of network terminals such as PCs and smartphones. The administrator can add users having the same network access requirements to a UCL, and configure a network access policy for the UCL, greatly reducing the administrator's workload. The RADIUS server assigns a UCL to a specified user in either of the following modes:
  • Assigns the UCL name through the standard RADIUS attribute Filter-Id.
  • Assigns the UCL ID through the RADIUS attribute HW-UCL-Group extended by Huawei.
You must configure the UCL and its network access policy on the access device in advance regardless of the UCL authorization mode used.
Free Rule

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

Logout of Portal Authentication Users

When users go offline but the access device, RADIUS server, and Portal server do not detect the offline events, the following problems may occur:
  • The RADIUS server still performs accounting for the users, causing incorrect accounting.
  • Unauthorized users may spoof IP addresses and MAC addresses of authorized users to access the network.
  • If there are many offline users, these users are still counted as access users of the device. As a result, other users may fail to access the network.

The access device needs to detect user logout immediately, delete the user entry, and instruct the RADIUS server to stop accounting.

User logouts may occur in the following situations:
  • A client logs out proactively.
  • An access device controls user logout.
  • The authentication server or Portal server forces a user to go offline.
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 2-22 shows the logout process.

Figure 2-22  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 2-23 shows the logout process. HTTP is used as an example.
Figure 2-23  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

The access device controls user logout using either of the following ways:

  • Run the cut access-user command to force a user to go offline.
  • Configure user detection to check whether a user is online. If the user does not respond within a specified period, the access device considers the user to be offline and deletes the user entry.

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

Figure 2-24  User logout detection flowchart
  1. The access device obtains the client IP address, and starts the logout detection timer configured by time-length in the portal timer offline-detect time-length command. When receiving a packet from the client within T (T = time-length/3), the access device considers the user to be online and resets the logout detection timer at T. If the access device does not receive a packet from the client within T, the access device sends an ARP request packet to the client at an interval of T. If the access device does not receive any response packet or other packets from the client after sending two consecutive ARP request packets (that is, no packet from the client is received within the logout detection period), the access device considers the user to be offline.

  2. The access device sends an NTF_LOGOUT message to the Portal server and disconnects the user. In addition, the access device sends an ACCOUNTING-REQUEST message to the RADIUS 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 Authentication Server Forces a User to Log Out

The authentication server forces a user to log out using either of the following methods:

  • Sends a Disconnect Message (DM) to an access device.
  • 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 2-25 shows the user logout process controlled by the authentication server by sending a DM.

Figure 2-25  The authentication server forces a user to log out
  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.

  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 Forces a User to Log Out

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 2-26 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 2-26  The Portal server forces a user to log out
  1. The Portal server sends an REQ_LOGOUT message to the access device.
  2. The access device sends an ACCOUNTING-REQUEST message to the RADIUS server and disconnects the user. The access device sends an ACK_LOGOUT message 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.

Portal Timers

As described in Table 2-11, an access device supports the following timers.

Table 2-11  Portal timers
Portal Timer Purpose Application Scenario
Quiet Timer

To prevent frequent authentication upon user authentication failures. Frequent authentication may cause DoS attacks and waste system resources.

External Portal server that uses the Portal or HTTP/HTTPS protocol or built-in Portal server that uses the Portal protocol
Portal Server Detection Timer

To ensure that online Portal users can go offline and new Portal authentication users can go online if communication between the access device and Portal server is interrupted due to a network fault or the Portal server is faulty.

External Portal server that uses the Portal protocol
User Information Synchronization Timer

To ensure that online Portal users can go offline and correct accounting is performed for users who have already gone offline if communication between the access device and Portal server is interrupted due to a network fault or the Portal server is faulty.

External Portal server that uses the Portal protocol
User Logout Retransmission Timer

To prevent the following situation: If the network between the access device and Portal server is unstable or packets are lost, the Portal server may fail to receive the user logout packet from the access device. In this case, the user is displayed as disconnected on the access device but is still displayed as online on the Portal server.

External Portal server that uses the Portal protocol
User Heartbeat Detection Timer

To prevent the following situation: When a user goes offline due to browser closing or network disconnection, user information is still retained on the access device. As a result, accounting is inaccurate or other users cannot go online.

Built-in Portal server that uses the Portal protocol
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 a user fails Portal authentication, 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 2-27 shows the operation of the quiet timer by using the Portal protocol as an example.

Figure 2-27  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.

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.

Figure 2-28 shows the portal server detection process.

NOTE:

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 2-28  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. When the access device receives a heartbeat packet or other authentication packets (for example, a user logout packet) from the Portal server, 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 forces the user to go offline.
  • 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 2-29 shows the process of synchronizing user information.

Figure 2-29  Process of synchronizing user information
NOTE:

This function is applicable only to the external Portal server that uses the Portal protocol. The access device can synchronize user information with Huawei Symantec TSM Portal server only.

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 force users to go offline 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 2-30 shows the operation of the user logout retransmission timer.

Figure 2-30  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 setup 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 to be offline and logs out the user. Figure 2-31 shows the process of detecting user heartbeats by the built-in Portal server.

Figure 2-31  User heartbeat detection by the built-in Portal server
The built-in Portal server detects user heartbeats in either of the following modes:
  • Forcible mode: If the access device does not receive a heartbeat packet from a user before the user heartbeat detection timer expires, the access device logs out the user.
  • Automatic mode: The access device checks whether the client browser supports the heartbeat program. If so, the forcible mode is used. If not, the access device does not detect user heartbeats. This mode is recommended to prevent user logout if the browser does not support the heartbeat program.
NOTE:

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.

Customizing the Built-in Portal Server Login Page

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. You can load the logo, advertisement image, usage instructions, and warranty disclaimer on the login page, and change the background image or color of the login page.

Figure 2-32 shows the initial login page.

Figure 2-32  Initial login page

In Figure 2-33, a logo image is loaded on the login page. This is done by running the portal local-server logo load logo-file command. The size of a logo image must be equal to or less than 128 KB. An image of 591 x 80 pixels is recommended.

Figure 2-33  Login page with a logo image

In Figure 2-34, an advertisement image is loaded on the login page. This is done by running the portal local-server ad-image load ad-image-file command. The size of an advertisement image must be equal to or less than 256 KB. An image of 670 x 405 pixels is recommended.

Figure 2-34  Login page with an advertisement image

In Figure 2-35, usage instructions are added to the login page. This is done by running the portal local-server page-text load string command.

Figure 2-35  Login page with a usage instruction

In Figure 2-36, a warranty disclaimer is added to the login page. This is done by running the portal local-server policy-text load string command.

Figure 2-36  Login page with a warranty disclaimer

In Figure 2-37, the background image of the login page is changed. This is done by running the portal local-server background-image load { background-image-file | default-image1 } command.

Figure 2-37  New background image of the login page
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100066170

Views: 20214

Downloads: 6

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next