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

Fat AP and Cloud AP V200R008C00 CLI-based Configuration Guide

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 AAA

Understanding AAA

Domain-based User Management

A NAS device performs domain-based user management. A domain is a group of users and each user belongs to a domain. A user uses only AAA configuration information in the domain to which the user belongs.

NOTE:

The AAA scheme, server template, and authorization information of NAC users can be configured in the authentication profile and non-domain-based management can be performed for NAC users to meet requirements of the user authentication management policy. If the preceding information is configured both in the domain and in the authentication profile, the configuration in the authentication profile is used preferentially. For details about the authentication profile, see NAC Configuration.

As shown in Figure 25-37, the domain manages configuration information including the AAA scheme, server template, authorization information in a unified manner.

  • AAA scheme: is divided into authentication, authorization, and accounting schemes that are used to define authentication, authorization, and accounting methods and the order in which the methods take effect. For details about the AAA scheme, see AAA Scheme.
  • Server template: is used to configure a server for authentication, authorization, and accounting.

    If local authentication or authorization is used, you need to configure information related to the local user.

  • Authorization information: can be configured in a domain.
Figure 25-37  AAA configuration information in a domain

Domain to Which a User Belongs

As shown in Figure 25-38, the domain to which a user belongs is determined by the user name for logging in to the NAS device. If the user name does not contain the domain name or the NAS device cannot determine the domain to which the user belongs, the NAS device adds the user to the default domain based on the user type.

Figure 25-38  Determining domains based on user names

As shown in Table 25-14, AAA divides users into administrators and access users to provide more refined and differentiated authentication, authorization, and accounting services. A NAS device has two global default domains, namely, the global default administrative domain default_admin and the global default common domain default. The two domains are used as the global default domains for administrators and access users, respectively. Default configurations in the two domains are different.
NOTE:

The accounting scheme default is bound to the two global default domains. Modifying the accounting scheme may affect configurations of the two domains.

The two global default domains cannot be deleted and can only be modified.

Table 25-14  Global default domain

User Type

User Access Mode

Global Default Domain

Default Configurations in the Global Default Domain
Authentication Scheme Accounting Scheme Authorization Scheme

Administrator

Is also called a login user and refers to the user who can log in to devices through FTP, HTTP, SSH, Telnet, and the console port.

default

radius

default

None

Access user

Includes PPP users and NAC users (including 802.1X authenticated, MAC address authenticated, and Portal authenticated users).

default_admin

default

default

None

You can flexibly define the global default domain based on actual requirements. The customized global default domain can be the global default common domain and the global default management domain at the same time.

You can run the display aaa configuration command to check the current global default common domain and the global default management domain on the device. The command output is as follows:
<Huawei> display aaa configuration
  Domain Name Delimiter            : @
  Domainname parse direction       : Left to right
  Domainname location              : After-delimiter
  Administrator user default domain: default_admin    //Global default management domain
  Normal user default domain       : default    //Global default common domain

For some access modes, you can specify the domain to which a user ultimately belongs using the command provided in the corresponding authentication profile to meet requirements of the user authentication management policy. For example, you can configure the default domain and forcible domain for NAC access users on the NAS device based on the authentication profile and specify the user type (802.1X, MAC address, or Portal authenticated), achieving flexible configuration. The forcible domain, user-defined domain, and default domain are listed in descending order of the priority.

Forcible domain with specified authentication method in the authentication profile > Forcible domain in the authentication profile > User-defined domain > Default domain with specified authentication method in the authentication profile > Default domain in the authentication profile > Global default domain
NOTE:

A forcible domain specified for MAC address authenticated users within a MAC address range has the highest priority and takes precedence over that configured in an authentication profile.

Format of User Names Sent by the NAS Device to the RADIUS Server
NOTE:
  • Only RADIUS authentication supports modification of the user-entered original user names.
  • You can change the user-entered original user name based on the RADIUS server template.

As shown in Figure 25-39, you can determine whether the user name sent to the RADIUS server contains the domain name on the NAS device based on the RADIUS server requirements. By default, the user name sent by the NAS device to the RADIUS server is the user-entered original user name without being changed.

Figure 25-39  Format of user names sent by the NAS device to the RADIUS server

You can set the format of user names sent by the NAS device to the RADIUS server using the commands in Table 25-15.

The following command modifies only the user name format in the RADIUS packets sent to the server and does not modify the user name format in the EAP packets. During 802.1X authentication, the RADIUS server checks whether the user name carried in the EAP packets is the same as that on the RADIUS server. Therefore, you cannot modify the previous user name of users using the radius-server user-name domain-included or undo radius-server user-name domain-included command during 802.1X authentication; otherwise, authentication may fail.

Table 25-15  Format of User names sent by the NAS device to the RADIUS server

Command

User Name Format

User-entered User Name User Name Sent by the NAS Device to the RADIUS Server

radius-server user-name original

User-entered original user name (default configuration)

user-name@huawei.com user-name@huawei.com
user-name user-name

radius-server user-name domain-included

Domain name included

user-name@huawei.com user-name@huawei.com
user-name

user-name@default

Assume that users use the default domain default.

undo radius-server user-name domain-included

Domain name excluded

user-name@huawei.com user-name
user-name user-name

undo radius-server user-name domain-included except-eap

Domain name excluded

NOTE:
This command takes effect only for non-EAP authenticated users.
user-name@huawei.com user-name
user-name user-name

AAA Scheme

During AAA implementation process, you can define a set of AAA configuration policies using an AAA scheme. An AAA scheme contains a collection of authentication, authorization, and accounting methods defined on the device. Such methods can be used in combination depending on access features of users and security requirements.

Authentication Scheme

An authentication scheme is used to define methods for user authentication and the order in which authentication methods take effect. An authentication scheme is finally applied to the domain. It is combined with the authorization scheme, accounting scheme, and server template in the domain for user authentication, authorization, and accounting.

Authentication Methods Supported by a Device
  • RADIUS authentication: User information is configured on the RADIUS server through which user authentication is performed.
  • HWTACACS authentication: User information is configured on the HWTACACS server through which user authentication is performed.
  • Local authentication: A device functions as an authentication server and user information is configured on the device. This mode features fast processing and low operation costs. However, the information storage of local authentication is subject to the device hardware capacity.
  • Non-authentication: Users are completely trusted without validity check. This mode is rarely used.
Order in Which Authentication Methods Take Effect

One or more authentication methods can be specified in an authentication scheme. When multiple authentication methods are specified, the configuration sequence determines the order in which each authentication method takes effect. The authentication method configured earlier takes effect preferentially. The later authentication method is triggered only after the earlier authentication method does not respond. If an authentication failure message is returned in the earlier method, the AAA server denies user access. In this case, authentication ends and the later authentication method is not used.

Authorization Scheme

An authorization scheme is used to define methods for user authorization and the order in which authorization methods take effect. An authorization scheme is finally applied to the domain. It is combined with the authentication scheme, accounting scheme, and server template in the domain for user authentication, authorization, and accounting.

Authorization Methods Supported by a Device
  • HWTACACS authorization: An HWTACACS server is used to authorize users.
  • Local authorization: A device functions as an authorization server to authorize users based on user information configured on the device.
  • Non-authorization: Authenticated users have unrestricted access rights on a network.
  • if-authenticated authorization: If passing authentication, a user passes authorization; otherwise, the user fails authorization. This mode applies to scenarios where users must be authenticated and the authentication process is separated from the authorization process.
NOTE:

RADIUS authentication is combined with authorization and cannot be separated. If authentication succeeds, authorization also succeeds. If RADIUS authentication is used, you do not need to configure an authorization scheme.

In addition, the "authentication + rights level" method is typically used to control access of the administrators (a login user) to the device and improve the device operation security. Authentication restricts the administrator's access to a network device and the rights level defines commands that the administrator can enter after logging in to the network device. For details about the method, see Configuring User Login.

Order in Which Authorization Methods Take Effect

One or more authorization methods can be specified in an authorization scheme. When multiple authorization methods are specified, the configuration sequence determines the order in which each authorization method takes effect. The authorization method configured earlier takes effect preferentially. The later authorization method is triggered only after the earlier authorization method does not respond. If an authorization failure message is returned in the earlier method, the AAA server does not provide services for the user. In this case, authorization ends and the later authorization method is not used.

Authorization Information
Authorization information can be delivered by a server or configured in a domain. Whether a user obtains authorization information delivered by a server or in a domain depends on the authorization method configured in the authorization scheme. For details, see Figure 25-40.
  • If local authorization is used, the user obtains authorization information from the domain.
  • If server-based authorization is used, the user obtains authorization information from the server or domain. Authorization information configured in a domain has lower priority than that delivered by a server. If the two types of authorization information conflicts, authorization information delivered by the server takes effect. If no conflict occurs, the two types of authorization information take effect simultaneously. In this manner, you can increase authorization flexibly by means of domain management, regardless of the authorization attributes provided by the AAA server.
Figure 25-40  Two types of authorization information

Table 25-16 shows authorization information typically used by a server. Table 25-17 shows authorization information that can be configured in a domain.

Table 25-16  Common authorization information of the RADIUS server

Authorization Information

Description

ACL number ACL number is delivered by the server. You need to configure ACL number-related rules on the device.
VLAN

If dynamic VLAN delivery is configured on the server, the authorization information sent to the access device includes the VLAN attribute. After the device receives the authorization information, it changes the VLAN of the user to the delivered VLAN.

The delivered VLAN does not change or affect the interface configuration. The delivered VLAN, however, takes precedence over the VLAN configured on the interface. That is, the delivered VLAN takes effect after the authentication succeeds, and the configured VLAN takes effect after the user goes offline.

User group The server delivers the user group name to the device. You need to configure the corresponding group and network resources in the group on the device.
CAR The server delivers authorization to control the committed information rate (CIR), peak information rate (PIR), committed burst size (CBS), and peak burst size (PBS) for access between the user and device.
Administrator level Management user (such as Telnet user) priority, ranging from 0 to 15. The value greater than or equal to 16 is invalid.
Service scheme Name of the service scheme delivered by the server. You need to configure the corresponding service scheme and the network authorization and policy in the scheme on the device.
Idle-cut Idle-cut time delivered by the server. After a user goes online, if the consecutive non-operation period or the duration when traffic is lower than a specified value exceeds the idle-cut time, the user is disconnected.
Reauthentication or forcing a user to go offline Remaining service availability period delivered by the server. If the period expires, reauthentication is performed for the user or the user is forced to go offline according to the server-delivered action.
Table 25-17  Authorization information that can be configured in a domain

Authorization Parameter

Description

VLAN

VLAN-based authorization is easy to deploy and maintenance costs are low. It applies to scenarios where employees in an office or a department have the same access rights.

In local authorization, you only need to configure VLANs and corresponding network resources in the VLAN on the device.

If a user uses Portal authentication or a hybrid authentication mode (including Portal authentication), the device cannot authorize the user based on a VLAN. After a user is authorized based on a VLAN, the user needs to manually request an IP address using DHCP.

Service scheme

A service scheme and corresponding network resources need to be configured on the device.

User group

A user group consists of users (terminals) with the same attributes such as the role and rights. For example, you can divide users on a campus network into the R&D group, finance group, marketing group, and guest group based on the enterprise department structure, and grant different security policies to different departments.

You need to configure a user group and network resources in the group on the device.

Accounting Scheme

An accounting scheme is used to define methods for user accounting. An accounting scheme is finally applied to the domain. It is combined with the authentication scheme, authorization scheme, and server template in the domain for user authentication, authorization, and accounting.

Accounting Methods Supported by a Device
  • RADIUS accounting: A RADIUS server is used to perform user accounting.
  • HWTACACS accounting: An HWTACACS server is used to perform user accounting.
  • Non-accounting: Users can access a network without being charged.
Order in Which Accounting Methods Take Effect

You can only specify an accounting method at one time in an accounting scheme.

RADIUS accounting packets in RADIUS Packets indicate that accounting packets are divided into Accounting-Request and Accounting-Response packets. Accounting succeeds if each Accounting-Request packet sent by a device is responded by the server with an Accounting-Response packet. If no Accounting-Response packet is received from the server, accounting fails. If accounting fails, the device determines whether the user can still be online using a corresponding policy. This policy is called accounting failure policy.

Accounting Failure Policy
After the accounting function is enabled, the device sends Accounting-Request packets recording user activities to the AAA server. The AAA server then performs user accounting and auditing based on information in the packets. Take RADIUS accounting as an example. Accounting-Request packets are divided into three types:
  • Accounting-Request (Start) packet: When a user is successfully authenticated and begins to access network resources, the device sends an Accounting-Request (Start) packet to the RADIUS server.
  • Accounting-Request (Stop) packet: When a user is disconnected proactively (or forcibly by the access server), the device sends an Accounting-Request (Stop) packet to the server.
  • Accounting-Request (Interim-update) packet: To reduce accounting deviation and ensure that the accounting server can receive Accounting-Request (Stop) packets and stop user accounting, you can configure the real-time accounting function on the device. In this case, the device periodically sends an Accounting-Request (Interim-update) packet to the RADIUS server.
Typically, each Accounting-Request packet sent by a device is responded by the server with an Accounting-Response packet. If the device does not receive a corresponding Accounting-Response packet due to network faults, accounting fails. In this case, the device determines whether the user can still be online depending on the type of the Accounting-Request packet as follows:
  • Accounting-start failure: Users go offline by default.
  • Real-time accounting failure: Users are allowed to go online by default.
  • stop_acct_fail: The device retransmits the Accounting-Request(Stop) packet.

Local Authentication and Authorization

Local AAA Server

A device functioning as an AAA server is called a local AAA server that performs user authentication and authorization and does not support user accounting.

Similar to the remote AAA server, the local AAA server requires a local user database, containing the user name, password, and authorization information of local users. The authentication and authorization speed of a local AAA server is faster than that of a remote AAA server, which reduces operation costs. However, the storage capacity of a local AAA server is limited by the device hardware.

Security Policy for Local User Password

Password Length and Complexity

When an administrator creates local users, the length and complexity of local users' passwords have been controlled by commands on the device. The complexity check requires that the password must be a combination of at least two of the following: digits, lowercase letters, uppercase letters, and special characters. In addition, a password must consist of at least six characters.

Password Validity Period

The validity period of a local user password is 90 days, which can be changed by the administrator.

If the password expires and the local user still uses this password to log in to the device, the device allows the user to log in, prompts the user that the password has expired, and asks the user whether to change the password. The device then performs the following operations depending on the user selection:
  • If the user enters Y, the user needs to enter the old password, new password, and confirm password. The password can be successfully changed only when the old password is correct and the new password and confirm password are the same and meet password length and complexity requirements.
  • If the user enters N or fails to change the password, the user cannot log in to the device.
The device also supports the password expiration prompt function. When a user logs in to the device, the device checks how many days the password is valid for. If the number of days is less than the prompt days set in the command, the device notifies the user in how many days the password will expire and asks the user whether to change the password.
  • If the user changes the password, the device records the new password and modification time.
  • If the user does not change the password or fails to change the password, the user can still log in as long as the password has not expired.

Password Modification Policy

During password modification, you are not advised to use old passwords. By default, the new password can be the same as those used for the last five times.

The local administrator can change the password of an equal- or lower-level local user.

RADIUS AAA

Overview of RADIUS

AAA can be implemented using multiple protocols. RADIUS is most frequently used in actual scenarios.

RADIUS is a protocol that uses the client/server model in distributed mode and protects a network from unauthorized access. It is often used in network environments that require high security and control remote user access. It defines the UDP-based RADIUS packet format and transmission mechanism, and specifies UDP ports 1812 and 1813 as the authentication and accounting ports respectively.

At the very beginning, RADIUS was only the AAA protocol used for dial-up users. When diverse user access modes are used, such as Ethernet, RADIUS can also be applied to these access modes. RADIUS provides the access service through authentication and authorization, and records the network resource usage through accounting.

RADIUS has the following characteristics:

  • Client/Server model

  • Secure message exchange mechanism

  • Fine scalability

Client/Server model
  • RADIUS client

    RADIUS clients run on the network access servers (NASs) to transmit user information to a specified RADIUS server and process requests (for example, accept or reject user access) based on the responses from the server. RADIUS clients can locate at any node on a network.

    As a RADIUS client, the device supports:

    • standard RADIUS protocol and its extensions, including Request For Comments (RFC) 2865 and RFC 2866

    • Huawei extended RADIUS attributes

    • RADIUS server status detection

    • retransmission for Accounting Stop packets in the local buffer

    • active/standby and load balancing between RADIUS servers

  • RADIUS server

    RADIUS servers run on central computers and workstations to maintain user authentication and network service access information. The servers receive connection requests from users, authenticate the users, and send the responses (to accept or reject the requests) to the clients. A RADIUS server needs to maintain three databases, as shown in Figure 25-41.

    Figure 25-41  Databases maintained by a RADIUS server

    • Users: store user information such as user names, passwords, protocols, and IP addresses.
    • Clients: store RADIUS client information, such as the shared key and IP address.
    • Dictionary: stores the attributes in the RADIUS protocol and their value descriptions.
Secure message exchange mechanism

Authentication messages between a RADIUS server and RADIUS clients are exchanged using a shared key. The shared key is a character string that is transmitted in out-of-band mode, is known to both clients and the server, and does not need to be transmitted independently on the network. A RADIUS packet has a 16-byte Authenticator field that contains the digital signature data of the whole packet. The signature data is calculated using the MD5 algorithm and shared key. The RADIUS packet receiver needs to verify whether the signature is correct and discards the packet if the signature is incorrect. This mechanism improves security of message exchange between RADIUS clients and the RADIUS server. In addition, user passwords contained in RADIUS packets are encrypted using shared keys before the packets are transmitted to prevent the user passwords from being stolen during transmission on an insecure network.

Fine scalability

A RADIUS packet consists of the packet header and a certain number of attributes. After new attributes are added to a RADIUS packet, the protocol implementation remains unchanged.

RADIUS Packets
RADIUS Packet Format

RADIUS is based on the UDP protocol. Figure 25-42 shows the RADIUS packet format.

Figure 25-42  RADIUS packet format

Fields in a RADIUS packet include:
  • Code: 1 byte. It describes the RADIUS packet type. The Code value varies in different types of RADIUS packets. For example, the value 1 indicates an Access-Request packet and the value 2 indicates an Access-Accept packet.
  • Identifier: 1 byte. It is used to match request packets and reply packets, and to detect the request packets retransmitted within a certain period. After a client sends a request packet, the server sends a reply packet with the same Identifier value as the request packet.
  • Length: 2 bytes. It specifies the RADIUS packet length. Bytes exceeding the specified length are treated as padding and ignored on the receiver. If the length of a received packet is smaller than the Length value, the packet is discarded.
  • Authenticator: 16 bytes. It is used to verify the reply packets sent by the RADIUS server and encrypt user passwords.
  • Attribute: variable length. It is the content of a packet carrying authentication, authorization, and accounting information and providing configuration details of request and reply packets. The Attribute field may contain multiple attributes, each of which consists of Type, Length, and Value. For details, see RADIUS Attributes.

    • Type: indicates the attribute ID. The length is 1 byte and the value ranges from 1 to 255.
    • Length: indicates the length of an attribute (including type, length, and attribute). The length is measured in bytes.
    • Value: indicates the attribute information. The format and content depend on Type and Length. The maximum length is 253 bytes.
RADIUS Packet Type

RADIUS defines 16 types of packets. Table 25-18 describes types of the authentication packets, Table 25-19 describes types of the accounting packets.

Table 25-18  RADIUS authentication packet

Packet Name

Description

Access-Request

This is the first packet transmitted in a RADIUS interaction process. This packet carries user authentication information, such as user name and password. The Access-Request packet is from a RADIUS client to a RADIUS server. The RADIUS server determines whether a user is allowed to access the network according to the user information carried in this packet.

Access-Accept

This packet is sent by a RADIUS server to respond to an Access-Request packet sent by a RADIUS client. If all attributes in the Access-Request packet are acceptable, the server determines that the user passes the authentication and sends this packet. The user passes authentication and is granted with network access rights only after the RADIUS client receives this packet.

Access-Reject

This packet is sent by a RADIUS server to respond to an Access-Request packet sent by a RADIUS client. If any attribute in the Access-Request packet is unacceptable, the RADIUS server determines that the user fails the authentication and sends this packet.

Access-Challenge

During an EAP relay authentication, when a RADIUS server receives an Access-Request packet carrying the user name, it generates a random MD5 challenge and sends the MD5 challenge to a client through this packet. After the client encrypts the user password using the MD5 challenge, the client sends the encrypted password in an Access-Request packet to the RADIUS server. The RADIUS server compares the encrypted password received from the client with the locally encrypted password. If they are the same, the server determines the user is valid.

Table 25-19  RADIUS accounting packet

Packet Name

Description

Accounting-Request(Start)

If a RADIUS client uses RADIUS accounting, the client sends this packet to a RADIUS server before accessing network resources.

Accounting-Response(Start)

This packet is returned by the RADIUS server after the server successfully receives and records an Accounting-Request(Start) packet.

Accounting-Request(Interim-update)

You can configure the real-time accounting function on a RADIUS client to prevent the RADIUS server from continuing user accounting if it fails to receive the Accounting-Request(Stop) packet. The client then periodically sends Accounting-Request(Interim-update) packets to the server, reducing accounting deviation.

Accounting-Response(Interim-update)

This packet is returned by the RADIUS server after the server successfully receives and records an Accounting-Request(Start) packet.

Accounting-Request(Stop)

When a user goes offline voluntarily or is forcibly disconnected by the NAS, the RADIUS client sends this packet carrying the network resource usage information (including online duration and number of incoming/outgoing bytes) to the RADIUS server, requesting the server to stop accounting.

Accounting-Response(Stop)

After receiving an Accounting-Request(Stop) packet, the RADIUS server needs to return this packet.

RADIUS Authentication, Authorization, and Accounting Process

A device that functions as a RADIUS client collects user information, including the user name and password, and sends the information to the RADIUS server. The RADIUS server authenticates users according to the information, after which it performs authorization and accounting for the users. Figure 25-43 shows information exchanged between a user, the RADIUS client, and the RADIUS server.

Figure 25-43  RADIUS authentication, authorization, and accounting process

  1. A user needs to access an external network and sends a connection request carrying the user name and password to the RADIUS client (device).
  2. A RADIUS client sends a RADIUS Access-Request packet containing the user name and password to the RADIUS server.
  3. The RADIUS server verifies the user identity:

    • If the user identity is valid, the RADIUS server returns an Access-Accept packet to the RADIUS client. The Access-Accept packet contains authorization information because RADIUS provides both authentication and authorization functions.
    • If the user identity is invalid, the RADIUS server returns an Access-Reject packet to the RADIUS client to reject access from the user.
  4. The RADIUS client notifies the user of whether authentication is successful.
  5. The RADIUS client permits or rejects the user according to the authentication result. If the user is permitted, the RADIUS client sends an Accounting-Request (Start) packet to the RADIUS server.
  6. The RADIUS server sends an Accounting-Response (Start) packet to the RADIUS client and starts accounting.
  7. The user starts to access network resources.
  8. (Optional) If interim accounting is enabled, the RADIUS client periodically sends Accounting-Request (Interim-update) packets to the RADIUS server, preventing incorrect accounting result caused by unexpected user disconnection.
  9. (Optional) The RADIUS server returns Accounting-Response (Interim-update) packets and performs interim accounting.
  10. The user sends a logout request.
  11. The RADIUS client sends an Accounting-Request (Stop) packet to the RADIUS server.
  12. The RADIUS server sends an Accounting-Response (Stop) packet to the RADIUS client and stops accounting.
  13. The RADIUS client notifies the user of the processing result, and the user stops accessing network resources.
RADIUS Packet Retransmission Mechanism

When a user is authenticated, a device sends an Access-Request packet to the RADIUS server. During this packet sending process, a retransmission upon timeout mechanism ensures that the device can receive the response packet from the server even if a network fault or delay occurs. The retransmission times and retransmission intervals are controlled using timers.

As shown in Figure 25-44, 802.1X authentication and client-initiated authentication are used as an example. After receiving an EAP packet (EAP-Response/Identity) containing the user name of the client, the device encapsulates the packet into a RADIUS Access-Request packet and sends the packet to the RADIUS server. The retransmission timer is enabled at the same time. The retransmission timer is composed of the retransmission interval and retransmission times. If the device does not receive any response packet from the RADIUS server when the retransmission interval expires, it sends a RADIUS Access-Request packet again.

Figure 25-44  RADIUS authentication packet retransmission diagram
The device stops packet retransmission if any of the following conditions is met:
  • The device receives a response packet from the RADIUS server. After receiving the response packet, the device stops packet retransmission and sets the RADIUS server status to Up.
  • The device detects that the RADIUS server status is Down. After the device sets the RADIUS server status to Down:
    • If the number of retransmitted packets has reached the maximum value, the device stops retransmitting the packets and retains the RADIUS server status to Down.
    • If the number of retransmitted packets has not reached the maximum value, the device retransmits an Access-Request packet once to the RADIUS server. If the device receives a response packet from the server, it stops packet retransmission and restores the RADIUS server status to Up. Otherwise, it still stops packet retransmission and retains the RADIUS server status to Down.
  • After the number of retransmitted packets reaches the maximum value, the device stops packet retransmission and performs the following:
    • If the device receives a response packet from the RADIUS server, it sets the RADIUS server status to Up.
    • If the device has detected that the RADIUS server status is Down, it sets the server status to Down.
    • If the device receives no response packet from the RADIUS server and does not detect that the server status is Down, the device does not change the server status. Actually, the server does not respond. Note that the device does not definitely set the status of the server that does not respond to Down. The device sets the server status to Down only if the corresponding conditions are met.

For the RADIUS server status introduction and conditions for the device to set the server status to Down, see RADIUS Server Status Detection.

RADIUS packet retransmission discussed here applies only to a single server. If multiple servers are configured in a RADIUS server template, the overall retransmission period depends on the retransmission interval, retransmission times, RADIUS server status, number of servers, and algorithm for selecting the servers.

You can set the timer using the following commands:

Command

Description

radius-server retransmit retry-times

Specifies the retransmission times. The default value is 3.

radius-server timeout time-value

Specifies the timeout interval. The default value is 5 seconds.

RADIUS Server Selection Mechanism

Typically, multiple RADIUS servers are deployed on a large-scale enterprise network. If a server is faulty, user access will not be disrupted. In addition, load balancing is performed between these servers, preventing resources of a single server from being exhausted in the event that a large number of users access the network. If multiple servers are configured in a RADIUS server template and a device needs to send a packet to a server, select one of the following algorithms to select the RADIUS server based on the command configuration.
  • RADIUS server primary/secondary algorithm (default)
  • RADIUS server load balancing algorithm
RADIUS Server Primary/Secondary Algorithm

The primary and secondary roles are determined by the weights configured for the RADIUS authentication servers or RADIUS accounting servers. The server with the heaviest weight is the primary server. If the weight values are the same, the earliest configured server is the primary server. As shown in Figure 25-45, the device preferentially sends an authentication or accounting packet to the primary server among all servers in Up status. If the primary server does not respond, the device then sends the packet to the secondary server.

Figure 25-45  Diagram for the RADIUS server primary/secondary algorithm
RADIUS Server Load Balancing Algorithm

If a device sends an authentication or accounting packet to a server using the load balancing algorithm, the device selects a server based on the weights configured for the RADIUS authentication servers or RADIUS accounting servers. As shown in Figure 25-46, RADIUS server-1 is in Up status and its weight is 80, and RADIUS server-2 is also in Up status and its weight is 20. The possibility for the device to send packets to RADIUS server-1 is 80% [80/(80 + 20)], and that for RADIUS server-2 is 20% [20/(80 + 20)].

Figure 25-46  Diagram for the RADIUS server load balancing algorithm

If all the servers in Up status do not respond to the packet sent by a device, the device retransmits the packet to a server among the servers whose status is originally set to Down (to which the device has not sent any authentication or accounting packets) based on the weight value. If the device does not receive any response in the current authentication mode, the backup authentication mode is used, for example, local authentication mode. The backup authentication mode needs to be configured in the authentication scheme. Otherwise, the authentication process ends.

RADIUS Server Status Detection

Availability and maintainability of the RADIUS server are the prerequisites of user access authentication. If a device cannot communicate with the RADIUS server, the server cannot perform authentication or authorization for users. To resolve this issue, the device supports the user escape function upon transition of the RADIUS server status to Down. To be specific, if the RADIUS server goes Down, users cannot obtain authorization from the server but still have certain network access rights.

The user escape function upon transition of the RADIUS server status to Down can be enabled only after the device sets the RADIUS server status to Down. If the RADIUS server status is not set to Down and the device cannot communicate with the RADIUS server, users cannot obtain authorization from the server and the escape function is also unavailable. As a result, users have no network access rights. Therefore, the device must be capable of detecting the RADIUS server status in a timely manner. In this case, if the RADIUS server status transitions to Down, users can obtain escape rights; if the RADIUS server status reverts to Up, escape rights are removed from the users and the users are reauthenticated.

RADIUS Server Status

A device can set the RADIUS server status to Up, Down, or Force-up. The following table lists descriptions of the three RADIUS server status and their corresponding scenarios.

Status

Description

Scenario

Up The RADIUS server is available.
  • The device initially sets the RADIUS server status to Up.
  • The device sets the RADIUS server status to Up if receiving packets from the server.
Down The RADIUS server is unavailable. The conditions for setting the RADIUS server status to Down are met.
Force-up When no RADIUS server is available, the device selects the RADIUS server in Force-up status. The device sets the RADIUS server status to Force-up if the timer specified by dead-time expires.

The RADIUS server status is initially set to Up. After a RADIUS Access-Request packet is received and the conditions for setting the RADIUS server status to Down are met, the RADIUS server status transitions to Down. The RADIUS Access-Request packet that triggers the server status transition can be sent during user authentication or constructed by the administrator. For example, the RADIUS Access-Request packet can be a test packet sent when the test-aaa command is run or detection packet sent during automatic detection.

The device changes toe RADIUS server status from Down to Up or to Force-up in the following scenarios:
  • Down to Force-up: The timer specified by dead-time starts after the device sets the RADIUS server status to Down. The timer indicates the duration for which the server status remains Down. After the timer expires, the device sets the RADIUS server status to Force-up. If a new user needs to be authenticated in RADIUS mode and no RADIUS server is available, the device attempts to re-establish a connection with a RADIUS server in Force-up status.
  • After receiving packets from the RADIUS server, the device changes the RADIUS server status from Down to Up. For example, after automatic detection is configured, the device receives response packets from the RADIUS server.
Conditions for Setting the RADIUS Server Status to Down

Whether the status of a RADIUS server can be set to Down depends on the following factors:

  • Number of times RADIUS Access-Request packets are sent
  • Interval for the RADIUS Access-Request packets to be sent
  • RADIUS server detection interval
  • Maximum number of consecutive unacknowledged packets in each detection interval
As shown in Figure 25-47, the conditions for setting the RADIUS server status to Down are as follows:
  1. In a detection interval, if the number of times the device receives no response packet after sending RADIUS Access-Request packets (n) is greater than or equal to the maximum number of consecutive unacknowledged packets (dead-count), the device records a communication interruption.
  2. If the device records communication interruptions with one RADIUS server in consecutive two detection intervals, the device considers that the RADIUS server is unavailable and the conditions for the device to set the RADIUS server status to Down are met.
    NOTE:
    If the device does not record any communication interruption in the second detection interval, the first communication interruption record is cleared.
  3. When the device sends an Access-Request packet to the server for the (2n+1)th time, it sets the server status to Down.
    • If the device receives a response packet from the server, the server status reverts to Up.
    • If no response packet is received from the server and the number of packet retransmission times is not reached, the device sends an Access-Request packet to the server for the (2n+2)th time. If the server still does not respond, the device no longer sends any Access-Request packet to the server.

If multiple servers are configured in the RADIUS server template, the overall status detection time is related to the number of servers and the server selection algorithm. If a user terminal uses the client software for authentication and the timeout period of the terminal client software is less than the summary of all the status detection time, the terminal client software may dial up repeatedly and cannot access the network. If the user escape function is configured, the summary of all the status detection time must be less than the timeout period of the terminal client software to ensure that escape rights can be added to the users.

Figure 25-47  Logic flowchart for setting the RADIUS server status to Down

The following table lists the related commands.

Command

Description

radius-server { dead-interval dead-interval | dead-count dead-count }

Configures conditions for setting the RADIUS server status to Down during the RADIUS server status detection.

  • dead-interval dead-interval: Specifies the detection interval. The default value is 5 seconds.
  • dead-count dead-count: Specifies the maximum number of consecutive unacknowledged packets. The default value is 2.
Automatic Detection

After the RADIUS server status is set to Down, you can configure the automatic detection function to test the RADIUS server reachability.

The device then periodically detects servers whose status is set to Down.

The automatic detection function needs to be manually enabled. The automatic server status detection function can be enabled only if the user name and password for automatic detection are configured in the RADIUS server template view on the device rather than on the RADIUS server. Authentication success is not mandatory. If the device can receive the authentication failure response packet, the RADIUS server is properly working and the device sets the RADIUS server status to Up. If the device cannot receive the response packet, the RADIUS server is unavailable and the device sets the RADIUS server status to Down.

The following table lists commands related to automatic detection.

Command

Description

  • radius-server testuser username user-name password cipher password
  • radius-server detect-server interval interval

Automatic detection:

  • user-name: Specifies the user name for automatic detection.
  • password: Specifies the password for automatic detection.
  • interval: Specifies the automatic detection interval. The default value is 60 seconds.
Consecutive Processing After the RADIUS Server Status Is Set to Down

After the device sets the RADIUS server status to Down, you can configure the escape function to make users obtain escape authorization. After the device detects that the RADIUS server status reverts to Up, you can configure the reauthentication function to make users obtain authorization from the server through reauthentication, as shown in Figure 25-48.

NOTE:

For 802.1X authenticated users and MAC address authenticated users, after the RADIUS server status reverts to Up, users exist from escape authorization and are reauthenticated. For Portal authenticated users, after the RADIUS server status reverts to Up, users obtain pre-connection authorization and can be redirected to the Portal server for authentication only if the users attempt to access network resources.

Figure 25-48  Consecutive processing after the RADIUS server status is set to Down

The following table lists the commands for configuring the escape rights upon transition of the RADIUS server status to Down and configuring the reauthentication function, respectively.

Command

Description

authentication event authen-server-down action authorize user-group user-group-name

Configures the escape function upon transition of the RADIUS server status to Down.

authentication event authen-server-up action re-authen

Configures the reauthentication function for users in escape status when the RADIUS server status reverts to Up.

RADIUS CoA/DM

The device supports the RADIUS Change of Authorization (CoA) and Disconnect Message (DM) functions defined in RFC 5176. CoA provides a mechanism to change the rights of online users, and DM provides a mechanism to forcibly disconnect users. This section contains the following contents:
RADIUS CoA/DM packet

Table 25-20 describes types of the CoA/DM packets.

Table 25-20  RADIUS CoA/DM packet

Packet Name

Description

CoA-Request

When an administrator needs to modify the rights of an online user (for example, prohibit the user from accessing a website), the RADIUS server sends this packet to the RADIUS client, requesting the client to modify the user rights.

CoA-ACK

If the RADIUS client successfully modifies the user rights, it returns this packet to the RADIUS server.

CoA-NAK

If the RADIUS client fails to modify the user rights, it returns this packet to the RADIUS server.

DM-Request

When an administrator needs to disconnect a user, the server sends this packet to the RADIUS client, requesting the client to disconnect the user.

DM-ACK

If the RADIUS client has disconnected the user, it returns this packet to the RADIUS server.

DM-NAK

If the RADIUS client fails to disconnect the user, it returns this packet to the RADIUS server.

Exchange Procedure

CoA allows the administrator to change the rights of an online user or perform reauthentication for the user through RADIUS after the user passes authentication. Figure 25-49 shows the CoA interaction process.

Figure 25-49  CoA interaction process

  1. The RADIUS server sends a CoA-Request packet to the device according to service information, requesting the device to modify user authorization information. This packet can contain authorization information including the ACL.
  2. Upon receiving the CoA-Request packet, the device performs a match check between the packet and user information on the device to identify the user. If the match succeeds, the device modifies authorization information of the user. Otherwise, the device retains the original authorization information of the user.
  3. The device returns a CoA-ACK or CoA-NAK packet as follows:
    • If authorization information is successfully modified, the device sends a CoA-ACK packet to the RADIUS server.
    • If authorization information fails to be modified, the device sends a CoA-NAK packet to the RADIUS server.

When a user needs to be disconnected forcibly, the RADIUS server sends a DM packet to the device. Figure 25-50 shows the DM interaction process.

Figure 25-50  DM interaction process

  1. The administrator forcibly disconnects a user on the RADIUS server. The RADIUS server sends a DM-Request packet to the device, requesting the device to disconnect the user.
  2. Upon receiving the DM-Request packet, the device performs a match check between the packet and user information on the device to identify the user. If the match succeeds, the user is notified to go offline. Otherwise, the user remains online.
  3. The device returns a DM-ACK or DM-NAK packet as follows:

    • If the user successfully goes offline, the device sends a DM-ACK packet to the RADIUS server.
    • Otherwise, the device sends a DM-NAK packet to the RADIUS server.

Different from the process in which authorization is performed for an online user or a user proactively goes offline, the server sends a request packet and the device sends a response packet in the CoA/DM process. If CoA/DM succeeds, the device returns an ACK packet. Otherwise, the device returns a NAK packet.

Session Flag

Each service provided by the NAS to a user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended.

After the device receives a CoA-Request or DM-Request packet from the RADIUS server, it identifies the user depending on some RADIUS attributes in the packet. The following RADIUS attributes can be used to identify users:
  • Standard RADIUS attribute: User-Name (1)
  • Standard RADIUS attribute: Acct-Session-ID (4)
  • Standard RADIUS attribute: Framed-IP-Address (8)
  • Standard RADIUS attribute: Calling-Station-Id (31)

The match methods are as follows:

  • any method

    The device performs a match check between an attribute and user information on the device. The priority for identifying the RADIUS attributes used by the users is as follows: Acct-Session-ID (4) > Calling-Station-Id (31) > Framed-IP-Address (8). The device searches for the attributes in the request packet based on the priority, and performs a match check between the first found attribute and user information on the device. If the attribute is successfully matched, the device responds with an ACK packet; otherwise, the device responds with a NAK packet.

  • all method

    The device performs a match check between all attributes and user information on the device. The device identifies the following RADIUS attributes used by the users: Acct-Session-ID (4), Calling-Station-Id (31), Framed-IP-Address (8), and User-Name (1). The device performs a match check between all the preceding attributes in the Request packet and user information on the device. If all the preceding attributes are successfully matched, the device responds with an ACK packet; otherwise, the device responds with a NAK packet.

Error Code Description

When the CoA-Request or DM-Request packet from the RADIUS server fails to match user information on the device, the device describes the failure cause using the error code in the CoA-NAK or DM-NAK packet. For the error code description, see Table 25-21 and Table 25-22.

Table 25-21  Error codes in a CoA-NAK packet

Name

Value

Description

RD_DM_ERRCODE_MISSING_ATTRIBUTE 402 The request packet lacks key attributes, so that the integrity check of the RADIUS attributes fails.
RD_DM_ERRCODE_INVALID_REQUEST 404 Parsing the attributes in the request packet fails.
RD_DM_ERRCODE_INVALID_ATTRIBUTE_VALUE 407 The request packet contains attributes that are not supported by the device or do not exist, so that the attribute check fails.

Contents of the authorization check include VLAN, ACL, CAR, number of the ACL used for redirection, and whether Huawei RADIUS extended attributes RD_hw_URL_Flag and RD_hw_Portal_URL can be authorized to the interface-based authenticated user.

Errors that may occur are as follows:
  • The authorized service scheme does not exist.
  • The authorized QoS profile does not exist or no user queue is configured in the QoS profile.
  • The authorized values of upstream and downstream priorities exceed the maximum values.
  • The authorized index value of the UCL group is not within the specification.
  • The ISP VLAN and outbound interface information are incorrectly parsed.
  • Reauthentication attributes and other attributes are authorized simultaneously.
RD_DM_ERRCODE_SESSION_CONTEXT_NOT_FOUND 503 The session request fails. The cause includes:
  • Authorization for the current request user is being processed.
  • The temporary RADIUS table fails to be requested.
  • User information does not match or no user is found.
  • The user is a non-RADIUS authentication user.
RD_DM_ERRCODE_RESOURCES_UNAVAILABLE 506 This error code is used for other authorization failures.
Table 25-22  Error codes in a DM-NAK packet

Name

Value

Description

RD_DM_ERRCODE_INVALID_REQUEST 404 Parsing the attributes in the request packet fails.
RD_DM_ERRCODE_SESSION_CONTEXT_NOT_REMOVABLE 504 The user fails to be deleted or the user does not exist.
RADIUS Attributes
RADIUS attributes are Attribute fields in RADIUS packets, which carry dedicated authentication, authorization, and accounting information. This chapter covers the following sections:
Standard RADIUS Attributes

RFC2865, RFC2866, RFC3576, and RFC5176 define standard RADIUS attributes that are supported by all mainstream vendors. For details, see Table 25-23.

Table 25-23  Standard RADIUS attributes

Attribute No.

Attribute Name

Attribute Type

Description

1

User-Name

string

User name for authentication. The user name format can be user name@domain name, or just user name.

2

User-Password

string

User password for authentication, which is only valid for the Password Authentication Protocol (PAP).

3

CHAP-Password

string

User password for authentication, which is only valid for the Challenge Handshake Authentication Protocol (CHAP).

4

NAS-IP-Address

ipaddr

Internet Protocol (IP) address of the AC carried in authentication request packets. By default, the attribute value is the source IP address of the authentication request packets sent by the AC. You can change the attribute value to the specified IP address on the AC using the radius-attribute nas-ip ip-address command.

5

NAS-Port

integer

Physical port for user access, which is in either of the following formats:
  • new: slot ID (8 bits) + sub-slot ID (4 bits) + port number (8 bits) + Virtual Local Area Network (VLAN) ID (12 bits)
  • old: slot ID (12 bits) + port number (8 bits) + VLAN ID (12 bits)

6

Service-Type

integer

Service type of the user to be authenticated:
  • 1 (Login): web user
  • 2 (Framed): PPP user
  • 8 (Authenticate Only): reauthentication only
  • 10 (Call Check): MAC address authentication user

7

Framed-Protocol

integer

Encapsulation protocol of Frame services:
  • For a non-management user, the value is fixed as 1.
  • For a management user, the value is fixed as 6.

8

Framed-IP-Address

ipaddr

User IP address.

11

Filter-Id

string

User group name or IPv4 Access Control List (ACL) ID.

NOTE:
  • When this attribute carries the IPv4 ACL ID, the IPv4 ACL IDs must range from 3000 to 3999 (wired users) or 3000 to 3031 (wireless users).

  • A RADIUS packet cannot carry the user group name or IPv4 ACL ID simultaneously.

12

Framed-Mtu

integer

Maximum transmission unit (MTU) of the data link between user and NAS. For example, in 802.1X Extensible Authentication Protocol (EAP) authentication, the NAS specifies the maximum length of the EAP packet in this attribute. An EAP packet larger than the link MTU may be lost.

14

Login-IP-Host

ipaddr

Management user IP address:
  • If the value is 0 or 0xFFFFFFFF, the IP address of management user is not checked.
  • If this attribute uses other values, the device checks whether the management user IP address is the same as the delivered attribute value.

15

Login-Service

integer

Service type available to management users:
  • 0: Telnet
  • 5: X25-PAD
  • 50: SSH
  • 51: FTP
  • 52: Terminal
NOTE:

An attribute can contain multiple service types.

18

Reply-Message

string

This attribute determines whether a user is authenticated:
  • When an Access-Accept packet is returned, the user is successfully authenticated.
  • When an Access-Reject packet is returned, the user fails authentication.

19

Callback-Number

string

Information sent from the authentication server and to be displayed to a user, such as a mobile number.

24

State

string

If the RADIUS server sends a RADIUS Access-Challenge packet carrying the State attribute to a device, the subsequent RADIUS Access-Request packets sent from the device must carry the State attribute with the same value.

25

Class

string

If the RADIUS server sends a RADIUS Access-Accept packet carrying the Class attribute to the NAS, the subsequent RADIUS Accounting-Request packets sent from the NAS must carry the Class attribute with the same value.

26

Vendor-Specific

string

Vendor-specific attribute. For details, see Table 25-24. A packet can carry one or more private attributes. Each private attribute contains one or more sub-attributes.

27

Session-Timeout

integer

In the Access-Request packet, this attribute indicates the maximum number of seconds a user should be allowed to remain connected.

In the Access-Challenge packet, this attribute indicates the duration for which EAP authentication users are reauthenticated.

The value of this attribute must be larger than 0.

NOTE:

This attribute is only valid for 802.1X, MAC address, and Portal authentication users.

When the RADIUS server delivers only this attribute, the value of attribute 29 Termination-Action is set to 0 (users are forced offline) by default.

28

Idle-Timeout

integer

Maximum number of consecutive seconds of idle connection the user is allowed before termination of the session or prompt.

NOTE:

This attribute is only valid for administrators.

29

Termination-Action

integer

Action taken by the NAS to finish user services:
  • 0: forcible disconnection
  • 1: reauthentication
NOTE:

This attribute is only valid for 802.1X and MAC address authentication users.

When the RADIUS server delivers only this attribute, the value of attribute 27 Session-Timeout is set to 3600s (for 802.1X authentication users) or 1800s (for MAC address authentication users) by default.

30

Called-Station-Id

string

Number of the NAS.
  • For wired users, it is the NAS MAC address.
  • For wireless users, it is the SSID and MAC address of the AP by default.

31

Calling-Station-Id

string

Identification number of the client. Generally, it is the MAC address of the client.

32

NAS-Identifier

string

NAS device identifier. By default, the attribute value is the host name of the user. You can change the attribute value to the VLAN ID of the user using the radius-server nas-identifier-format { hostname | vlan-id } command.

40

Acct-Status-Type

integer

Accounting-Request type:
  • 1: Accounting-Start packet
  • 2: Accounting-Stop packet
  • 3: Interim-Accounting packet

41

Acct-Delay-Time

integer

Number of seconds the client has been trying to send the accounting packet (excluding the network transmission time).

42

Acct-Input-Octets

integer

Number of bytes in upstream traffic, corresponding to the lower 32 bits in the data structure for storing the upstream traffic. Contents of this attribute and the RADIUS attribute 52 (Acct-Input-Gigawords) compose the upstream traffic.

The traffic unit must be the same as that of the RADIUS server and can be Byte, KByte, MByte, and GByte. To set the traffic unit for each RADIUS server, run the radius-server traffic-unit command. By default, the unit is Byte.

43

Acct-Output-Octets

integer

Number of bytes in downstream traffic, corresponding to the lower 32 bits in the data structure for storing the downstream traffic. Contents of this attribute and the RADIUS attribute 53 (Acct-Output-Gigawords) compose the downstream traffic.

The traffic unit must be the same as that of the RADIUS server and can be Byte, KByte, MByte, and GByte. To set the traffic unit for each RADIUS server, run the radius-server traffic-unit command. By default, the unit is Byte.

44

Acct-Session-Id

string

Accounting session ID. The Accounting-Start, Interim-Accounting, and Accounting-Stop packets of the same accounting session must have the same session ID.

The format of this attribute is: Host name (7 bits) + Slot ID (2 bits) + Subcard number (1 bit) + Port number (2 bits) + Outer VLAN ID (4 bits) + Inner VLAN ID (5 bits) + Central Processing Unit (CPU) Tick (6 bits) + User ID prefix (2 bits) + User ID (5 bits).

45

Acct-Authentic

integer

User authentication mode:
  • 1: RADIUS authentication
  • 2: Local authentication
  • 3: Other remote authentications

46

Acct-Session-Time

integer

Duration that a user has been online, in seconds.

NOTE:

If the administrator modifies the system time after the user goes online, the online time calculated by the device may be incorrect.

47

Acct-Input-Packets

integer

Number of incoming packets.

48

Acct-Output-Packets

integer

Number of outgoing packets.

49

Acct-Terminate-Cause

string

Cause of a terminated session:
  • User-Request (1): The user requests termination of service.
  • Lost Carrier (2): The connection is torn down due to a handshake failure or heartbeat timeout, such as an ARP probe failure or PPP handshake failure.
  • Lost Service (3): The connection initiated by the peer device is torn down.
  • Idle Timeout (4): The idle timer expires.
  • Session Timeout (5): The session times out or the traffic threshold is reached.
  • Admin Reset (6): The administrator forces the user to go offline.
  • Admin Reboot (7): The administrator restarts the NAS.
  • Port Error (8): A port fails.
  • NAS Error (9): The NAS encounters an internal error.
  • NAS Request (10): The NAS ends the session due to resource changes.
  • NAS Reboot (11): The NAS automatically restarts.
  • Port Unneeded (12): The port is Down.
  • Port Preempted (13): The port is preempted.
  • Port Suspended (14): The port is suspended.
  • Service Unavailable (15): The service is unavailable.
  • Callback (16): NAS is terminating the current session to perform a callback for a new session.
  • User Error (17): User authentication fails or times out.
  • Host Request (18): A host sends a request.

52

Acct-Input-Gigawords

integer

Number of times the number of bytes in upstream traffic is greater than 4 GB (2^32), corresponding to the higher 32 bits in the data structure for storing the upstream traffic. Contents of this attribute and the RADIUS attribute 42 (Acct-Input-Octets) compose the upstream traffic.

The traffic unit must be the same as that of the RADIUS server and can be Byte, KByte, MByte, and GByte. To set the traffic unit for each RADIUS server, run the radius-server traffic-unit command. By default, the unit is Byte.

53

Acct-Output-Gigawords

integer

Number of times the number of bytes in downstream traffic is greater than 4 GB (2^32), corresponding to the higher 32 bits in the data structure for storing the downstream traffic. Contents of this attribute and the RADIUS attribute 43 (Acct-Output-Octets) compose the downstream traffic.

The traffic unit must be the same as that of the RADIUS server and can be Byte, KByte, MByte, and GByte. To set the traffic unit for each RADIUS server, run the radius-server traffic-unit command. By default, the unit is Byte.

55

Event-Timestamp

integer

Time when an Accounting-Request packet is generated, represented by is the number of seconds elapsed since 00:00:00 of January 1, 1970.

60

CHAP-Challenge

string

Challenge field in CHAP authentication. This field is generated by the NAS for Message Digest algorithm 5 (MD5) calculation.

61

NAS-Port-Type

integer

NAS port type. The attribute value can be configured in the interface view. By default, the type is Ethernet (15).

64

Tunnel-Type

integer

Protocol type of the tunnel. The value is fixed as 13, indicating VLAN.

65

Tunnel-Medium-Type

integer

Medium type used on the tunnel. The value is fixed as 6, indicating Ethernet.

66

Tunnel-Client-Endpoint

string

Tunnel client address.

67

Tunnel-Server-Endpoint

string

Tunnel server address.

79

EAP-Message

string

Encapsulates Extended Access Protocol (EAP) packets so that RADIUS supports EAP authentication. When an EAP packet is longer than 253 bytes, the packet is encapsulated into multiple attributes. A RADIUS packet can carry multiple EAP-Message attributes.

80

Message-Authenticator

string

Authenticates and verifies authentication packets to prevent spoofing packets.

81

Tunnel-Private-Group-ID

string

Tunnel private group ID, which is used to deliver user VLAN IDs.

NOTE:
To make the VLAN authorization function take effect, ensure the correct access control mode is configured:
  • When the link type is hybrid in untagged mode, the access control mode can be MAC address or interface.
  • When the link type is access or trunk, the access control mode can only be interface.

85

Acct-Interim-Interval

integer

Interim accounting interval. The value ranges from 60 to 3932100, in seconds. It is recommended that the interval be at least 600 seconds.

87

NAS-Port-Id

string

User access port. The NAS-Port-Id attribute has the following formats:
  • New:

    For Ethernet access users, the NAS port ID is in the format "slot=xx; subslot=xx; port=xxx; VLAN ID=xxxx", in which "slot" ranges from 0 to 15, "subslot" 0 to 15, "port" 0 to 255, and "VLAN ID" 1 to 4094.

  • Old:

    For Ethernet access users, the NAS port ID is in the format "port number (2 characters) + sub-slot ID (2 bytes) + card number (3 bytes) + VLAN ID (9 characters)."

90

Tunnel-Client-Auth-Id

string

Client tunnel ID used for authentication during tunnel setup.

91

Tunnel-Server-Auth-Id

string

Server tunnel ID used for authentication during tunnel setup.

95

NAS-IPv6-Address

ipaddr

IPv6 address carried in the authentication request packet sent by the NAS. Both the NAS-IPv6-Address and NAS-IP-Address fields can be included in a packet.

195

HW-SecurityStr

string

Security information of users in EAP relay authentication.

Huawei Proprietary RADIUS Attributes

RADIUS is a fully extensible protocol. The No. 26 attribute (Vendor-Specific) defined in RFC2865 can be used to extend RADIUS for implementing functions not supported by standard RADIUS attributes. Table 25-24 describes Huawei proprietary RADIUS attributes.

NOTE:

Extended RADIUS attributes contain the vendor ID of the device. The vendor ID of Huawei is 2011.

Table 25-24  Huawei proprietary RADIUS attributes

Attribute No.

Attribute Name

Attribute Type

Description

26-1

HW-Input-Peak-Information-Rate

integer

Peak rate at which the user accesses the NAS, in bit/s. The value is a 4-byte integer.

26-2

HW-Input-Committed-Information-Rate

integer

Average rate at which the user accesses the NAS, in bit/s. The value is a 4-byte integer.

26-3

HW-Input-Committed-Burst-Size

integer

Committed burst size (CBS) at which the user accesses the NAS, in bit/s. The value is a 4-byte integer.

26-4

HW-Output-Peak-Information-Rate

integer

Peak rate at which the NAS connects to the user, in bit/s. The value is a 4-byte integer.

26-5

HW-Output-Committed-Information-Rate

integer

Average rate at which the NAS connects to the user, in bit/s. The value is a 4-byte integer.

26-6

HW-Output-Committed-Burst-Size

integer

Committed burst size at which the NAS connects to the user, in bit/s. The value is a 4-byte integer.

26-15

HW-Remanent-Volume

integer

Remaining traffic. The unit is KB.

26-26

HW-Connect-ID

integer

Index of a user connection.

26-28

HW-FTP-Directory

string

Initial directory of an FTP user.

26-29

HW-Exec-Privilege

integer

Management user (such as Telnet user) priority, ranging from 0 to 15. The priority that is greater than or equal to 16 is ineffective.

26-59

HW-NAS-Startup-Time-Stamp

integer

NAS start time, represented by the number of seconds elapsed since 00:00:00 of January 1, 1970.

26-60

HW-IP-Host-Address

string

User IP address and MAC address carried in authentication and accounting packets, in the format A.B.C.D hh:hh:hh:hh:hh:hh. The IP address and MAC address are separated by a space.

If the user's IP address is detected to be invalid during authentication, the IP address is set to 255.255.255.255.

26-61

HW-Up-Priority

integer

Upstream priority of user services.

26-62

HW-Down-Priority

integer

Downstream priority of user services.

26-77

HW-Input-Peak-Burst-Size

integer

Upstream peak rate, in bit/s.

26-78

HW-Output-Peak-Burst-Size

integer

Downstream peak rate, in bit/s.

26-138

HW-Domain-Name

string

Name of the domain used for user authentication. This attribute can be the domain name contained in a user name or the name of a forcible domain.

26-141

HW-AP-Information

string

AP's MAC and IP addresses carried in the attribute during wireless user authentication. Whether the IP address is carried in the attribute can be configured using the radius-server hw-ap-info-format include-ap-ip command. After this command is run, the encapsulation format of this attribute is AP-MAC AP-IP.

NOTE:

Currently, IPv6 addresses cannot be encapsulated.

26-142

HW-User-Information

string

User security check information delivered by the RADIUS server to an Extensible Authentication Protocol over LAN (EAPoL) user to notify the user of items that require security checks.

26-146

HW-Service-Scheme

string

Service scheme name. A service scheme contains user authorization information and policies.

26-153

HW-Access-Type

integer

User access type carried in the authentication and accounting request packets sent by the RADIUS client to the RADIUS server:
  • 1: Dot1x user
  • 2: MAC address authentication user or MAC address bypass authentication
  • 3: Portal authentication user
  • 4: Static user
  • 6: Management user
  • 7: PPP users

26-155

HW-URL-Flag

integer

This attribute specifies whether a Uniform Resource Locator (URL) is forcibly pushed when it is used with another attribute, for example, HW-Portal-URL:
  • 0: No
  • 1: Yes (After this attribute is delivered, the URL address is pushed when you visit the website for the first time.)
  • 2: The URL address is pushed for forbidden websites.

26-156

HW-Portal-URL

string

Forcibly pushed URL.

If information delivered by the RADIUS server matches the configured URL template, the URL configured in the template is used. Otherwise, the character string delivered by the RADIUS server is used.

26-157

HW-Terminal-Type

string

Terminal type of a user.

26-158

HW-DHCP-Option

string

DHCP Option, encapsulated in Type-Length-Value (TLV) format. A packet may contain multiple HW-DHCP-Option attributes to carry Option information.

26-159

HW-HTTP-UA

string

User-Agent information in Hypertext Transfer Protocol (HTTP) packets.

26-173

HW-Redirect-ACL

string

Redirection ACL. Redirection is performed for only the users matching the ACL rules. The ACL number or ACL name can be delivered. The ACL name must start with a character.

26-201

HW-User-Extend-Info

string

Extended user information. This attribute is contained in authentication and accounting request packets. A packet can contain multiple HW-User-Extend-Info attributes. The following describes extended user information:

  • User-Position: Service code of the location where a user goes online
  • User-Position-Type: Type of the location where a user goes online
  • AP-Device-Code: AP code
  • AP-POS-X: Longitude of a moving AP
  • AP-POS-Y: Latitude of a moving AP
  • Wifi-Density: Field strength
  • TERMINAL-POS-X: X coordinate of the terminal against AP, in meters
  • TERMINAL-POS-Y: Y coordinate of the terminal against AP, in meters
  • HW-Access-Time: user access time. The value is the number of seconds elapsed since 00:00:00 of January 1, 1970.

This attribute applies only to MAC address authentication and Portal authentication.

26-237 HW-Web-Authen-Info

string

Information sent from the portal server via the device (which transparently transmits the information) to the RADIUS server. For example, a user selects the authentication-free option and time information for next login, based on which the RADIUS server saves the MAC address of the user for a period of time. Upon the next login of the user, the login page is not displayed. Instead, MAC address authentication is preferentially used. This attribute can be used for transparent transmission in complex modes such as EAP.

26-238 HW-Ext-Specific

string

User extended attributes:
  • user-dscp-in: DSCP value of inbound user packets. The value ranges from 0 to 63.
  • user-dscp-out: DSCP value of outbound user packets. The value ranges from 0 to 63.
  • user-command: user reauthentication. This field has a fixed value of 1, indicating that reauthentication will be performed.
NOTE:

When the value of user-command is 1, other authorization attributes are not supported.

26-253

HW-Framed-IPv6-Address

ipaddr

IPv6 address to be configured for the user.

26-254

HW-Version

string

Software version of the device.

26-255

HW-Product-ID

string

NAS product name.

Huawei-supported Extended RADIUS Attributes of Other Vendors

Huawei devices support some extended RADIUS attributes of Microsoft. For details, see Table 25-25.

Table 25-25  Huawei-supported extended RADIUS attributes of other vendors
Attribute No. Attribute Name Attribute Type Description
MICROSOFT-16 MS-MPPE-Send-Key

string

MPPE sending key.
MICROSOFT-17 MS-MPPE-Recv-Key

string

MPPE receiving key.
RADIUS Attributes Available in Packets
Different RADIUS packets carry different RADIUS attributes.
  • For the RADIUS attributes available in authentication packets, see Table 25-26.
  • For the RADIUS attributes available in accounting packets, see Table 25-27.
  • For the RADIUS attributes available in authorization packets, see Table 25-28.
NOTE:

The following describes the values in the tables:

  • 1: indicates that the attribute must appear once in the packet.
  • 0: indicates that the attribute cannot appear in the packet (it will be discarded if it is contained).
  • 0-1: indicates that the attribute can appear once or does not appear in the packet.
  • 0+: indicates that the attribute may appear multiple times or does not appear in the packet.
Table 25-26  RADIUS attributes available in authentication packets

Attribute No.

Access-Request

Access-Accept

Access-Reject

Access-Challenge

User-Name(1)

1

0-1

0

0

User-Password(2)

0-1

0

0

0

CHAP-Password(3)

0-1

0

0

0

NAS-IP-Address(4)

1

0

0

0

NAS-Port(5)

1

0

0

0

Service-Type(6)

1

0-1

0

0

Framed-Protocol(7)

1

0-1

0

0

Framed-IP-Address(8)

0-1

0-1

0

0

Filter-Id(11)

0

0-1

0

0

Framed-Mtu(12)

0-1

0

0

0

Login-IP-Host(14)

0-1

0-1

0

0

Login-Service(15)

0

0-1

0

0

Reply-Message(18)

0

0-1

0-1

0-1

Callback-Number(19)

0

0-1

0

0

State(24)

0-1

0-1

0

0-1

Class(25)

0

0-1

0

0

Session-Timeout(27)

0

0-1

0-1

0-1

Idle-Timeout(28)

0

0-1

0

0

Termination-Action(29)

0

0-1

0

0-1

Called-Station-Id(30)

0-1

0

0

0

Calling-Station-Id(31)

1

0-1

0

0

NAS-Identifier(32)

1

0

0

0

Acct-Session-id(44)

1

0

0

0

CHAP-Challenge(60)

0-1

0

0

0

NAS-Port-Type(61)

1

0

0

0

Tunnel-Type(64)

0

0-1

0

0

Tunnel-Medium-Type(65)

0

0-1

0

0

Tunnel-Client-Endpoint(66)

0-1

0-1

0

0

Tunnel-Server-Endpoint(67)

0-1

0-1

0

0

EAP-Message(79)

0-1

0-1

0-1

0-1

Message-Authenticator(80)

0-1

0-1

0-1

0-1

Tunnel-Private-Group-ID(81)

0

0-1

0-1

0

NAS-Port-Id(87)

0-1

0

0

0

Tunnel-Client-Auth-Id(90)

0

0-1

0

0

Tunnel-Server-Auth-Id(91)

0

0-1

0

0

NAS-IPv6-Address(95)

0-1

0

0

0

HW-SecurityStr(195)

0-1

0

0

0

HW-Input-Peak-Information-Rate(26-1)

0

0-1

0

0

HW-Input-Committed-Information-Rate(26-2)

0

0-1

0

0

HW-Input-Committed-Burst-Size(26-3)

0

0-1

0

0

HW-Output-Peak-Information-Rate(26-4)

0

0-1

0

0

HW-Output-Committed-Information-Rate(26-5)

0

0-1

0

0

HW-Output-Committed-Burst-Size(26-6)

0

0-1

0

0

HW-Remanent-Volume(26-15)

0

0-1

0

0

HW-Connect-ID(26-26)

1

0

0

0

Ftp-directory(26-28)

0

0-1

0

0

HW-Exec-Privilege(26-29)

0

0-1

0

0

HW-NAS-Startup-Time-Stamp(26-59)

1

0

0

0

HW-IP-Host-Address(26-60)

1

0

0

0

HW-Up-Priority(26-61)

0

0-1

0

0

HW-Down-Priority(26-62)

0

0-1

0

0

HW-Input-Peak-Burst-Size(26-77)

0

0-1

0

0

HW-Output-Peak-Burst-Size(26-78)

0

0-1

0

0

HW-Domain-Name(26-138)

1

0

0

0

HW-AP-Information(26-141)

1

0

0

0

HW-User-Information(26-142)

0

0-1

0

0

HW-Service-Scheme(26-146)

0

0-1

0

0

HW-Access-Type(26-153)

1

0-1

0

0

HW-URL-Flag(26-155)

0

0-1

0

0

HW-Portal-URL(26-156)

0

0-1

0

0

HW-Terminal-Type(26-157)

0-1

0

0

0

HW-DHCP-Option(26-158)

0+

0

0

0

HW-User-Extend-Info(26-201)

0-1

0

0

0

HW-Web-Authen-Info(26-237)

1

0

0

0

HW-Framed-IPv6-Address(26-253)

0-1

0

0

0

HW-Version(26-254)

1

0

0

0

HW-Product-ID(26-255)

1

0

0

0

MS-MPPE-Send-Key(MICROSOFT-16)

0

0-1

0

0

MS-MPPE-Recv-Key(MICROSOFT-17)

0

0-1

0

0

Table 25-27  RADIUS attributes available in accounting packets

Attribute No.

Accounting-Request

(Start)

Accounting-Request

(Interim-Update)

Accounting-Request

(Stop)

Accounting-Response

(start)

Accounting-Response (Interim-Update)

Accounting-Response

(Stop)

User-Name(1)

1

1

1

0

0

0

NAS-IP-Address(4)

1

1

1

0

0

0

NAS-Port(5)

1

1

1

0

0

0

Service-Type(6)

1

1

1

0

0

0

Framed-Protocol(7)

1

1

1

0

0

0

Framed-IP-Address(8)

1

1

1

0

0

0

Class(25)

0-1

0-1

0-1

0

0

0

Session-Timeout(27)

0

0

0

0-1

0-1

0

Called-Station-Id(30)

NOTE:
For users who access the network through PPP authentication, this attribute is optional. If the authentication request packet does not carry this attribute, then neither does the accounting request packet.

1

1

1

0

0

0

Calling-Station-Id(31)

1

1

1

0

0

0

NAS-Identifier(32)

1

1

1

0

0

0

Acct-Status-Type(40)

1

1

1

0

0

0

Acct-Delay-Time(41)

0-1

1

1

0

0

0

Acct-Input-Octets(42)

0-1

0-1

0-1

0

0

0

Acct-Output-Octets(43)

0-1

0-1

0-1

0

0

0

Acct-Session-Id(44)

1

1

1

0

0

0

Acct-Authentic(45)

1

1

1

0

0

0

Acct-Session-Time(46)

0

1

1

0

0

0

Acct-Input-Packets(47)

0-1

0-1

0-1

0

0

0

Acct-Output-Packets(48)

0-1

0-1

0-1

0

0

0

Acct-Terminate-Cause(49)

0

0

1

0

0

0

Acct-Input-Gigawords(52)

0-1

0-1

0-1

0

0

0

Acct-Output-Gigawords(53)

0-1

0-1

0-1

0

0

0

Event-Timestamp(55)

1

1

1

0

0

0

NAS-Port-Type(61)

1

1

1

0

0

0

Tunnel-Client-Endpoint(66)

0-1

0-1

0-1

0

0

0

Tunnel-Server-Endpoint(67)

0-1

0-1

0-1

0

0

0

NAS-Port-Id(87)

1

1

1

0

0

0

Tunnel-Client-Auth-Id(90)

0-1

0-1

0-1

0

0

0

Tunnel-Server-Auth-Id(91)

0-1

0-1

0-1

0

0

0

NAS-IPv6-Address(95)

0-1

0-1

0-1

0

0

0

HW-Input-Committed-Information-Rate(26-2)

1

1

1

0

0

0

HW-Output-Committed-Information-Rate(26-5)

1

1

1

0

0

0

HW-Connect-ID(26-26)

1

1

1

0

0

0

HW-IP-Host-Address(26-60)

1

1

1

0

0

0

HW-Domain-Name(26-138)

1

1

1

0

0

0

HW-AP-Information(26-141)

0-1

0-1

0-1

0

0

0

HW-User-Information(26-142)

0

0

0

0-1

0-1

0

HW-Access-Type(26-153)

0-1

0-1

0-1

0

0

0

HW-Terminal-Type(26-157)

0-1

0-1

0-1

0

0

0

HW-DHCP-Option(26-158)

0+

0+

0+

0

0

0

HW-HTTP-UA(26-159)

0-1

0-1

0-1

0

0

0

HW-User-Extend-Info(26-201)

0-1

0-1

0-1

0

0

0

HW-Framed-IPv6-Address(26-253)

0-1

0-1

0-1

0

0

0

MS-MPPE-Send-Key(MICROSOFT-16)

0

0

0

0

0

0

MS-MPPE-Recv-Key(MICROSOFT-17) 0 0 0 0 0 0
Table 25-28  RADIUS attributes available in CoA/DM packets

Attribute No.

CoA REQUEST

CoA ACK

CoA NAK

DM REQUEST

DM ACK

DM NAK

User-Name(1)

0-1

0-1

0-1

0-1

0-1

0-1

NAS-IP-Address(4)

0-1

0-1

0-1

0-1

0-1

0-1

NAS-Port(5)

0-1

0

0

0-1

0

0

Framed-IP-Address(8)

0-1

0-1

0-1

0-1

0-1

0-1

Filter-Id(11)

0-1

0

0

0

0

0

Session-Timeout(27)

0-1

0

0

0

0

0

Idle-Timeout(28)

0-1

0

0

0

0

0

Termination-Action(29)

0-1

0

0

0

0

0

Calling-Station-Id(31)

0-1

0-1

0-1

0-1

0-1

0-1

NAS-Identifier(32)

0

0-1

0-1

0

0

0

Acct-Session-Id(44)

1

1

1

1

1

1

Tunnel-Type(64)

0-1

0

0

0

0

0

Tunnel-Medium-Type(65)

0-1

0

0

0

0

0

Tunnel-Private-Group-ID(81)

0-1

0

0

0

0

0

Acct-Interim-Interval(85)

0-1

0

0

0

0

0

NAS-Port-Id(87)

0-1

0

0

0-1

0

0

HW-Input-Peak-Information-Rate(26-1)

0-1

0

0

0

0

0

HW-Input-Committed-Information-Rate(26-2)

0-1

0

0

0

0

0

HW-Output-Peak-Information-Rate(26-4)

0-1

0

0

0

0

0

HW-Output-Committed-Information-Rate(26-5)

0-1

0

0

0

0

0

HW-Output-Committed-Burst-Size(26-6)

0-1

0

0

0

0

0

HW-Up-Priority(26-61)

0-1

0

0

0

0

0

HW-Down-Priority(26-62)

0-1

0

0

0

0

0

HW-Input-Peak-Burst-Size(26-77)

0-1

0

0

0

0

0

HW-Output-Peak-Burst-Size(26-78)

0-1

0

0

0

0

0

HW-Data-Filter(26-82)

0-1

0

0

0

0

0

HW-Service-Scheme(26-146)

0-1

0

0

0

0

0

MS-MPPE-Send-Key(MICROSOFT-16) 0 0 0 0 0 0
MS-MPPE-Recv-Key(MICROSOFT-17) 0 0 0 0 0 0
RADIUS Attribute Disablement and Translation

Different vendors support different collections of RADIUS attributes and each vendor may have their private attributes. As a result, RADIUS attributes of different vendors may be incompatible and RADIUS attributes sent between devices from different vendors fail to be parsed. The RADIUS attribute disablement and translation functions are often used in interconnection and replacement scenarios to resolve this issue.

RADIUS Attribute Disablement

The RADIUS server may have RADIUS attributes with the same attribute IDs and names but different encapsulation formats or contents from those on the device. In this case, you can configure the RADIUS attribute disablement function to disable such attributes. The device then does not parse the attributes after receiving them from the RADIUS server, and does not encapsulate these attributes into RADIUS packets to be sent to the server.

Currently, Huawei-supported RADIUS attributes (with Huawei-supported attribute names and IDs) in sent or received packets can be disabled on a device.

RADIUS Attribute Translation

RADIUS attribute translation is used for compatibility between RADIUS attributes defined by different vendors. For example, a Huawei device delivers the priority of the administrator using the Huawei proprietary attribute Exec-Privilege (26-29), whereas another vendor's access device and the RADIUS server deliver it by using the Login-service(15) attribute. In a scenario where the Huawei device and another vendor's access device share one RADIUS server, users want the Huawei device to be compatible with the Login-service(15) attribute. After RADIUS attribute translation is configured on the Huawei device, the device automatically processes the Login-service(15) attribute in a received RADIUS authentication response packet as the Exec-Privilege (26-29) attribute.

Devices translate RADIUS attributes in a sent or received packet based on a 3-tuple (Type, Length, and Value) of the RADIUS attributes.
  • If translation between attributes A and B is configured in the transmit direction on the device and the device sends a packet containing attribute A, the Type field of the attribute is attribute B but the Value field is encapsulated based on the content and format of attribute A.
  • If translation between attributes A and B is configured in the receive direction on the device and the device receives a packet containing attribute A, it parses the Value field of attribute A as that of attribute B. To be specific, from the perspective of the device, it receives a packet containing attribute B instead of attribute A after attribute translation is configured.

Huawei and non-Huawei RADIUS attributes can be translated into each other. Table 25-29 shows the mode for translating Huawei and non-Huawei RADIUS attributes into each other.

NOTE:

The device can translate a RADIUS attribute of another vendor only if the length of the Type field in the attribute is 1 byte.

Table 25-29  RADIUS attribute translation mode
Whether Huawei Supports the Source RADIUS Attribute Whether Huawei Supports the Destination RADIUS Attribute Supported Translation Direction Configuration Command (RADIUS Server Template View)
Supported Supported Transmit and receive directions

radius-attribute translate src-attribute-name dest-attribute-name { receive | send | access-accept | access-request | account-request | account-response } *

Supported Not supported Transmit direction

radius-attribute translate extend src-attribute-name vendor-specific dest-vendor-id dest-sub-id { access-request | account-request } *

Not supported Supported Receive direction

radius-attribute translate extend vendor-specific src-vendor-id src-sub-id dest-attribute-name { access-accept | account-response } *

HWTACACS AAA

Overview of HWTACACS

HWTACACS is a protocol that serves as an enhancement to TACACS (RFC 1492).

HWTACACS is used to perform authentication, authorization, and accounting for users accessing the Internet through Point-to-Point Protocol (PPP) or Virtual Private Dial-up Network (VPDN) and management users.

Both HWTACACS and RADIUS protocols can implement authentication, authorization, and accounting. They are similar in that they both have the following characteristics:
  • Client/Server model
  • Share key used for encrypting user information
  • Good flexibility and extensibility

HWTACACS is more reliable in transmission and encryption than RADIUS, and is more suitable for security control. Table 25-30 lists the differences between HWTACACS and RADIUS.

Table 25-30  Comparisons between HWTACACS and RADIUS

Item

HWTACACS

RADIUS

Data transmission

Uses TCP, which is more reliable.

Uses UDP, which is more efficient.

Encryption

Encrypts the entire packet, except the standard HWTACACS header.

Encrypts only the password field in the packet.

Authentication and authorization

Separates authentication from authorization so that they can be implemented on different security servers.

Combines authentication and authorization.

Command line authorization

Supported. The command line use is restricted by both the command level and AAA. When a user enters a command, the command is executed only after being authorized by the HWTACACS server.

Not supported. The commands that a user can use depend on their user level. A user can only use the commands of the same level as or lower level than their user level.

Application

Security control.

Accounting.

HWTACACS Packets

Unlike RADIUS packets, which all use the same format, HWTACACS packets (including HWTACACS Authentication Packet, HWTACACS Authorization Packet, and HWTACACS Accounting Packet) use different formats. Despite this, HWTACACS packets all share the same HWTACACS Packet Header.

HWTACACS Packet Header

The length of the HWTACACS packet header is 12 bytes, as shown in Figure 25-51.

Figure 25-51  HWTACACS packet header
Table 25-31  Fields in HWTACACS packet header
Field Description
major version Major version of the HWTACACS protocol. The current version is 0xc.
minor version Minor version of the HWTACACS protocol. The current version is 0x0.
type HWTACACS protocol packet type, including authentication (0x01), authorization (0x02), and accounting (0x03).
seq_no Packet sequence number in a session, ranging from 1 to 254.
flags Encryption flag on the packet body. This field contains 8 bits, of which only the first bit has a valid value. The value 0 indicates that the packet body is encrypted, and the value 1 indicates that the packet body is not encrypted.
session_id Session ID, which is the unique identifier of a session.
length Length of the HWTACACS packet body, excluding the packet header.
HWTACACS Authentication Packet Format
There are three types of HWTACACS authentication packets:
  • Authentication Start: When an authentication starts, the client sends this packet carrying the authentication type, user name, and authentication data to the server.
  • Authentication Continue: When receiving the Authentication Reply packet from the server, the client returns this packet if the authentication process has not ended.
  • Authentication Reply: When the server receives the Authentication Start or Authentication Continue packet from the client, the server sends this packet to the client to notify the client of the current authentication status.

HWTACACS Authentication Start packets.

Figure 25-52  HWTACACS Authentication Start packet format
Table 25-32  Fields in HWTACACS Authentication Start packet
Field Description
action Authentication action. Only the login authentication (0x01) action is supported.
priv_lvl User privilege level.
authen_type Authentication type, including:
  • CHAP(0x03)
  • PAP(0x02)
  • ASCII(0x01)
service

Type of the service requesting authentication, which varies depending on the user type:

  • PPP users: PPP(0x03)
  • Administrators: LOGIN(0x01)
  • Other users: NONE(0x00)
user len Length of the user name entered by a login user.
port len Length of the port field.
rem_addr len rem_addr field length.
data len Authentication data length.
user Name of the user requesting authentication. The maximum length is 129.
port

Name of the user interface requesting authentication. The maximum length is 47.

  • For management users, this field indicates the user terminal interface, such as console0 and vty1. For example, the authen_type of Telnet users is ASCII, service is LOGIN, and port is vtyx.
  • For other users, this field indicates the user access interface.
rem_addr IP address of the login user.
data Authentication data. Different data is encapsulated depending on the values of action and authen_type. For example, when PAP authentication is used, the value of this field is PAP plain-text password.

HWTACACS Authentication Continue packets.

Figure 25-53  HWTACACS Authentication Continue packet format
Table 25-33  Fields in HWTACACS Authentication Continue packet
Field Description
user_msg len Length of the character string entered by a login user.
data len Authentication data length.
flags Authentication continue flag.
  • 0: The authentication continues.
  • 1: The authentication has ended.
user_msg Character string entered by the login user. This field carries the user login password to respond to the server_msg field in the Authentication Reply packet.
data Authentication data. Different data is encapsulated depending on the values of action and authen_type. For example, when PAP authentication is used, the value of this field is PAP plain-text password.

HWTACACS Authentication Reply packets.

Figure 25-54  HWTACACS Authentication Reply packet format
Table 25-34  Fields in HWTACACS Authentication Reply packet
Field Description
status

Authentication status, including:

  • PASS (0x01): Authentication is successful.
  • FAIL (0x02): Authentication fails.
  • GETDATA (0x03): Request user information.
  • GETUSER (0x04): Request user name.
  • GETPASS (0x05): Request password.
  • RESTART (0x06): Request reauthentication.
  • ERROR (0x07): The authentication packets received by the server have errors.
  • FOLLOW (0x21): The server requests reauthentication.
flags Indicates whether the client displays the password entered by user in plain text. The value 1 indicates that the password is not displayed in plain text.
server_msg len Length of the server_msg field.
data len Authentication data length.
server_msg Optional field. This field is sent by the server to the user to provide additional information.
data Authentication data, providing information to client.
HWTACACS Authorization Packet Format
There are two types of HWTACACS authorization packets:
  • Authorization Request: HWTACACS separates authentication from authorization. Therefore, a user can be authenticated by HWTACACS, and authorized using another protocol. If a user is authorized by HWTACACS, the client sends an Authorization Request packet carrying authorization information to the server.
  • Authorization Response: After receiving the Authorization Request packet, the server sends this packet carrying the authorization result to the client.

HWTACACS Authorization Request packets.

Figure 25-55  HWTACACS Authorization Request packet format
NOTE:

The meanings of the following fields in the Authorization Request packet are the same as those in the Authentication Start packet, and are therefore not described here: priv_lvl, authen_type, authen_service, user len, port len, rem_addr len, port, and rem_addr.

Table 25-35  Fields in HWTACACS Authorization Request packet
Field Description
authen_method

Authentication method, including:

  • No authentication method configured (0x00)
  • None authentication (0x01)
  • Local authentication (0x05)
  • HWTACACS authentication (0x06)
  • RADIUS authentication (0x10)
authen_service Type of the service requesting authentication, which varies depending on the user type:
  • PPP users: PPP(0x03)
  • Administrators: LOGIN(0x01)
  • Other users: NONE(0x00)
arg_cnt Number of attributes carried in the Authorization Request packet.
argN Attribute of the Authorization Request packet. The value can be:
  • cmd: Indicates the first keyword of the command line to be authorized.
  • cmd-arg: Indicates the parameter in the command line to be authorized. The cmd-arg=<cr> is added at the end of the command line.

HWTACACS Authentication Reply packets.

Figure 25-56  HWTACACS Authorization Response packet format
NOTE:

The meanings of the following fields are the same as those in HWTACACS Authentication Reply packet, and are therefore not described here: server_msg len, data len, and server_msg.

Table 25-36  Fields in HWTACACS Authorization Response packet
Field Description
status

Authorization status, including:

  • Authorization is successful (0x01)
  • The attributes in Authorization Request packets are modified by the TACACS server (0x02)
  • Authorization fails (0x10)
  • An error occurs on the authorization server (0x11)
  • An authorization server is respecified (0x21)
arg_cnt

Number of attributes carried in the Authorization Response packet.

argN Authorization attribute delivered by the HWTACACS authorization server.
HWTACACS Accounting Packet Format
There are two types of HWTACACS accounting packets:

HWTACACS Accounting Request packets.

Figure 25-57  HWTACACS Accounting Request packet format
NOTE:

The meanings of the following fields in the Accounting Request packet are the same as those in the Authorization Request packet, and are therefore not described here: authen_method, priv_lvl, authen_type, user len, port len, rem_addr len, port, and rem_addr.

Table 25-37  Fields in HWTACACS Accounting Request packet
Field Description
flags Accounting type:
  • Start accounting (0x02)
  • Stop accounting (0x04)
  • Interim accounting (0x08)
authen_service Type of the service requesting authentication, which varies depending on the user type:
  • PPP users: PPP(0x03)
  • Administrators: LOGIN(0x01)
  • Other users: NONE(0x00)
arg_cnt Number of attributes carried in the Accounting Request packet.
argN Attribute of the Accounting Request packet.

HWTACACS Accounting Response packets.

Figure 25-58  HWTACACS Accounting Response packet format
Table 25-38  Fields in HWTACACS Accounting Response packet
Field Description
server_msg len Length of the server_msg field.
data len Length of the data field.
status Accounting status:
  • Accounting is successful (0x01)
  • Accounting fails (0x02)
  • No response (0x03)
  • The server requests reaccounting (0x21)
server_msg Information sent by the accounting server to the client.
data Information sent by the accounting server to the administrator.
HWTACACS Authentication, Authorization, and Accounting Process

This section describes how HWTACACS performs authentication, authorization, and accounting for Telnet users. Figure 25-59 shows the message exchange process.
Figure 25-59  HWTACACS message interaction

The following describes the HWTACACS message exchange process shown in Figure 25-59:
  1. A Telnet user sends a request packet.
  2. After receiving the request packet, the HWTACACS client sends an Authentication Start packet to the HWTACACS server.
  3. The HWTACACS server sends an Authentication Response packet to request the user name.
  4. After receiving the Authentication Response packet, the HWTACACS client sends a packet to query the user name.
  5. The user enters the user name.
  6. The HWTACACS client sends an Authentication Continue packet containing the user name to the HWTACACS server.
  7. The HWTACACS server sends an Authentication Response packet to request the password.
  8. After receiving the Authentication Response packet, the HWTACACS client queries the password.
  9. The user enters the password.
  10. The HWTACACS client sends an Authentication Continue packet containing the password to the HWTACACS server.
  11. The HWTACACS server sends an Authentication Response packet, indicating that the user has been authenticated.
  12. The HWTACACS client sends an Authorization Request packet to the HWTACACS server.
  13. The HWTACACS server sends an Authorization Response packet, indicating that the user has been authorized.
  14. The HWTACACS client receives the Authorization Response packet and displays the login page.
  15. The HWTACACS client sends an Accounting Request (start) packet to the HWTACACS server.
  16. The HWTACACS server sends an Accounting Response packet.
  17. The user requests to go offline.
  18. The HWTACACS client sends an Accounting Request (stop) packet to the HWTACACS server.
  19. The HWTACACS server sends an Accounting Response packet.
NOTE:

HWTACACS and TACACS+ protocols of other vendors can implement authentication, authorization, and accounting. HWTACACS is compatible with other TACACS+ protocols because their authentication procedures and implementations are the same.

HWTACACS Attributes

In the HWTACACS authorization or accounting packets, the argN field carries the information exchanged between a server and a client in the form of HWTACACS. This section describes the HWTACACS attributes in detail.

Overview of HWTACACS Attributes

Table 25-39 describes the HWTACACS attributes supported by the device. The device can only parse the attributes included in the table.

Table 25-39  Common HWTACACS attributes

Attribute Name

Description

acl

Authorization ACL ID.

addr

User IP address.

autocmd

Commands the system automatically execute after a user logs in.

bytes_in

Traffic received by the device. K, M, and G represent KByte, MByte, and GByte. No unit is displayed if byte is used.

bytes_out

Traffic sent by the device. K, M, and G represent KByte, MByte, and GByte. No unit is displayed if byte is used.

callback-line

Information sent from the authentication server and to be displayed to a user, such as a mobile number.

cmd

Commands executed by the system shell. The maximum length is 251 characters. The complete command is encapsulated when the command is recorded and the first keyword is encapsulated when the command is authorized.

cmd-arg

Parameter in the command line to be authorized. The cmd-arg=<cr> is added at the end of the command line.

disc_cause

Reason for disconnection. Only accounting stop packets carry this attribute. The reasons for disconnection include:
  • A user requests to go offline (1)
  • Data forwarding is interrupted (2)
  • Service is interrupted (3)
  • Idle timeout (4)
  • Session timeout (5)
  • The administrator requests to go offline (7)
  • The NAS is faulty (9)
  • The NAS requests to go offline (10)
  • The port is suspended (12)
  • User information is incorrect (17)
  • A host requests to go offline (18)

disc_cause_ext

Extended reason for disconnection. Only accounting stop packets carry this attribute. The extended reasons for disconnection include:
  • Unknown reason (1022)
  • The EXEC terminal tears down the connection (1020)
  • An online Telnet user forcibly disconnects this user (1022)
  • The user cannot be switched to the SLIP/PPP client due to no remote IP address (1023)
  • PPP PAP authentication fails (1042)
  • PPP receives a Terminate packet from the remote end (1045)
  • The upper-layer device requests the device to tear down the PPP connection (1046)
  • PPP handshake fails (1063)
  • Session times out (1100)

dnaverage

Downstream average rate, in bit/s.

dnpeak

Downstream peak rate, in bit/s.

dns-servers

IP address of the primary DNS server.

elapsed_time

Online duration, in seconds.

ftpdir

Initial directory of an FTP user.

gw-password

Tunnel password. The value is a string of 1 to 248 characters. If the value contains more than 248 characters, only the first 248 characters are valid.

idletime

Idle session timeout period. If a user does not perform any operation within this period, the system disconnects the user.

l2tp-hello-interval

Interval for sending L2TP Hello packets. The device does not support this attribute.

l2tp-hidden-avp

The attribute value pair (AVP) of L2TP. The device does not support this attribute.

l2tp-nosession-timeout

If no session exists within this period, the L2TP tunnel is torn down. The device does not support this attribute.

l2tp-group-num

L2TP group number. Other L2TP attributes take effect only if this attribute is delivered. Otherwise, other L2TP attributes are ignored.

l2tp-tos-reflect

TOS of L2TP. The device does not support this attribute.

l2tp-tunnel-authen

Indicates whether the L2TP tunnel is authenticated:

  • 0: not authenticated
  • 1: authenticated

l2tp-udp-checksum

UPD packet checksum.

nocallback-verify

No authentication is required for callback.

nohangup

Indicates whether the device automatically disconnects a user. This attribute is valid only after the autocmd attribute is configured. It decides whether to disconnect a user who has executed the autocmd command. The value can be true or false:

  • true: does not disconnect the user
  • false: disconnects the user

paks_in

Number of packets received by the device.

paks_out

Number of packets sent by the device.

priv-lvl

User level.

protocol

Protocol type. It belongs to service type, and is only valid for PPP and connection services. The device supports four protocol types: pad, telnet, ip, and vpdn. The protocol used depends on the service type:
  • When the service type is connection, the protocol type can be pad or telnet.
  • When the service type is ppp, the protocol type can be ip or vpdn.
  • For other service types, this attribute is not used.

task_id

Task ID. The task IDs recorded when a task starts and ends must be the same.

timezone

Local time zone.

tunnel-id

Local user name of the tunnel. The value is a string of 1 to 29 characters. If the value contains more than 29 characters, only the first 29 characters are valid.

tunnel-type

Tunnel type. The device only supports the L2TP tunnel. The value of tunnel-type is 3.

service

Service type, which can be accounting or authorization.

source-ip

Local IP address of the tunnel.

upaverage

Upstream average rate, in bit/s.

uppeak

Upstream peak rate, in bit/s.

HWTACACS Attributes Available in Packets
There are two types of HWTACACS authorization packets: Authorization Request packets and Authorization Response packets. However, HWTACACS authorization packets can also be classified into EXEC authorization packets, command line authorization packets, and access user authorization packets, depending on the usage scenario. Different authorization packets carry different attributes. For details, see Table 25-40. The following describes the use of HWTACACS authorization packets for different usage scenarios:
  • EXEC authorization packets: Used by the HWTACACS server to control rights of the management users logging in through Telnet, console port, SSH, and FTP.
  • Command line authorization packets: Used by the device to authorize each command line executed by the user. Only authorized command lines can be executed.
  • Access user authorization packets: Used by the HWTACACS server to control the rights of NAC users such as 802.1X and Portal users.
Just as with HWTACACS authorization packets, there are two types of HWTACACS accounting packets: Accounting Request packets and Accounting Response packets. HWTACACS accounting packets can also be classified into network accounting packets, connection accounting packets, EXEC accounting packets, system accounting packets, and command accounting packets, depending on the connection type. Different accounting packets carry different attributes. For details, see Table 25-41. The following describes the use of HWTACACS accounting packets for different connection types:
  • Network accounting packets: Used when networks are accessed by PPP users. For example, when a PPP user connects to a network, the server sends an accounting start packet; when the user is using network services, the server periodically sends interim accounting packets; when the user goes offline, the server sends an accounting stop packet.
  • Connection accounting packets: Used when users log in to the server through Telnet or FTP clients. When a user connects to the device, the user can run commands to access a remote server and obtain files from the server. The device sends an accounting start packet when the user connects to the remote server and an accounting stop packet when the user disconnects from the remote server.
  • EXEC accounting packets: Used when users log in to the device through Telnet or FTP. When a user connects to a network, the server sends an accounting start packet; when the user is using network services, the server periodically sends interim accounting packets; when the user goes offline, the server sends an accounting stop packet.
  • System accounting packets: Used during fault diagnosis. The server records the system-level events to help administrators monitor the device and locate network faults.
  • Command accounting packets: When an administrator runs any command on the device, the device sends the command to the HWTACACS server through a command accounting stop packet so that the server can record the operations performed by the administrator.
NOTE:
  • Y: The packet supports this attribute.
  • N: The packet does not support this attribute.
Table 25-40  HWTACACS attributes available in authorization packets

Attribute

Command Line Authorization Packet

EXEC Authorization Response Packet

Access User Authorization Response Packet

acl

N

Y

N

addr

N

N

Y

addr-pool

N

N

Y

autocmd

N

Y

N

callback-line

N

Y

Y

cmd

Y

N

N

cmd-arg

Y

N

N

dnaverage

N

N

Y

dnpeak

N

N

Y

dns-servers

N

N

Y

ftpdir

N

Y

N

gw-password

N

N

Y

idletime

N

Y

N

ip-addresses

N

N

Y

l2tp-group-num

N

N

Y

l2tp-tunnel-authen

N

N

Y

nocallback-verify

N

Y

N

nohangup

N

Y

N

priv-lvl

N

Y

N

source-ip

N

N

Y

tunnel-type

N

N

Y

tunnel-id

N

N

Y

upaverage

N

N

Y

Table 25-41  HWTACACS attributes available in accounting packets

Attribute

Network Accounting Start Packet

Network Accounting Stop Packet

Network Interim Accounting Packet

Connection Accounting Start Packet

Connection Accounting Stop Packet

EXEC Accounting Start Packet

EXEC Accounting Stop Packet

EXEC Interim Accounting Packet

System Accounting Stop Packet

Command Line Accounting Stop Packet

addr

Y

Y

Y

Y

Y

N

N

N

N

N

bytes_in

N

Y

Y

N

Y

N

Y

Y

N

N

bytes_out

N

Y

Y

N

Y

N

Y

Y

N

N

cmd

N

N

N

Y

Y

N

N

N

N

Y

disc_cause

N

Y

N

N

N

N

Y

Y

N

N

disc_cause_ext

N

Y

N

N

N

N

Y

Y

N

N

elapsed_time

N

Y

Y

N

Y

N

Y

Y

Y

N

paks_in

N

Y

Y

N

Y

N

Y

Y

N

N

paks_out

N

Y

Y

N

Y

N

Y

Y

N

N

priv-lvl

N

N

N

N

N

N

N

N

N

Y

protocol

Y

Y

Y

Y

Y

N

N

N

N

N

service

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

task_id

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

timezone

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

tunnel-id

N

N

N

N

N

N

N

N

N

N

tunnel-type

Y

N

N

N

N

N

N

N

N

N

Translation
Download
Updated: 2019-01-11

Document ID: EDOC1000176006

Views: 118962

Downloads: 309

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