Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing network access management. This feature specifies the following security functions:

· Authentication—Identifies users and verifies their validity.

· Authorization—Grants different users different rights, and controls the users' access to resources and services. For example, you can permit office users to read and print files and prevent guests from accessing files on the device.

· Accounting—Records network usage details of users, including the service type, start time, and traffic. This function enables time-based and traffic-based charging and user behavior auditing.

AAA network diagram

AAA uses a client/server model. The client runs on the access device, or the network access server (NAS), which authenticates user identities and controls user access. The server maintains user information centrally. See Figure 1.

Figure 1 AAA network diagram

‌

To access networks or resources beyond the NAS, a user sends its identity information to the NAS. The NAS transparently passes the user information to AAA servers and waits for the authentication, authorization, and accounting result. Based on the result, the NAS determines whether to permit or deny the access request.

AAA has various implementations, including RADIUS, LDAP, and HWTACACS. RADIUS is most often used.

You can use different servers to implement different security functions. For example, you can use an HWTACACS server for authentication and authorization, and use a RADIUS server for accounting.

You can choose the security functions provided by AAA as needed. For example, if your company wants employees to be authenticated before they access specific resources, you would deploy an authentication server. If network usage information is needed, you would also configure an accounting server.

The device performs dynamic password authentication.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. The protocol can protect networks against unauthorized access and is often used in network environments that require both high security and remote user access.

The RADIUS authorization process is combined with the RADIUS authentication process, and user authorization information is piggybacked in authentication responses. RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting.

RADIUS was originally designed for dial-in user access, and has been extended to support additional access methods, such as Ethernet and ADSL.

Client/server model

The RADIUS client runs on the NASs located throughout the network. It passes user information to RADIUS servers and acts on the responses to, for example, reject or accept user access requests.

The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network service access.

The RADIUS server operates using the following process:

1. Receives authentication, authorization, and accounting requests from RADIUS clients.

2. Performs user authentication, authorization, or accounting.

3. Returns user access control information (for example, rejecting or accepting the user access request) to the clients.

The RADIUS server can also act as the client of another RADIUS server to provide authentication proxy services.

The RADIUS server maintains the following databases:

· Users—Stores user information, such as the usernames, passwords, applied protocols, and IP addresses.

· Clients—Stores information about RADIUS clients, such as shared keys and IP addresses.

· Dictionary—Stores RADIUS protocol attributes and their values.

Figure 2 RADIUS server databases

Information exchange security mechanism

The RADIUS client and server exchange information between them with the help of shared keys, which are preconfigured on the client and server. A RADIUS packet has a 16-byte field called Authenticator. This field includes a signature generated by using the MD5 algorithm, the shared key, and some other information. The receiver of the packet verifies the signature and accepts the packet only when the signature is correct. This mechanism ensures the security of information exchanged between the RADIUS client and server.

The shared keys are also used to encrypt user passwords that are included in RADIUS packets.

User authentication methods

The RADIUS server supports multiple user authentication methods, such as PAP, CHAP, and EAP.

Basic RADIUS packet exchange process

Figure 3 illustrates the interactions between a user host, the RADIUS client, and the RADIUS server.

Figure 3 Basic RADIUS packet exchange process

RADIUS uses in the following workflow:

1. The host sends a connection request that includes the user's username and password to the RADIUS client.

2. The RADIUS client sends an authentication request (Access-Request) to the RADIUS server. The request includes the user's password, which has been processed by the MD5 algorithm and shared key.

3. The RADIUS server authenticates the username and password. If the authentication succeeds, the server sends back an Access-Accept packet that contains the user's authorization information. If the authentication fails, the server returns an Access-Reject packet.

4. The RADIUS client permits or denies the user according to the authentication result. If the result permits the user, the RADIUS client sends a start-accounting request (Accounting-Request) packet to the RADIUS server.

5. The RADIUS server returns an acknowledgment (Accounting-Response) packet and starts accounting.

6. The user accesses the network resources.

7. The host requests the RADIUS client to tear down the connection.

8. The RADIUS client sends a stop-accounting request (Accounting-Request) packet to the RADIUS server.

9. The RADIUS server returns an acknowledgment (Accounting-Response) and stops accounting for the user.

10. The RADIUS client notifies the user of the termination.

RADIUS packet format

RADIUS uses UDP to transmit packets. The protocol also uses a series of mechanisms to ensure smooth packet exchange between the RADIUS server and the client. These mechanisms include the timer mechanism, the retransmission mechanism, and the backup server mechanism.

Figure 4 RADIUS packet format

Descriptions of the fields are as follows:

· The Code field (1 byte long) indicates the type of the RADIUS packet. Table 1 gives the main values and their meanings.

Table 1 Main values of the Code field

Code	Packet type	Description
1	Access-Request	From the client to the server. A packet of this type includes user information for the server to authenticate the user. It must contain the User-Name attribute and can optionally contain the attributes of NAS-IP-Address, User-Password, and NAS-Port.
2	Access-Accept	From the server to the client. If all attribute values included in the Access-Request are acceptable, the authentication succeeds, and the server sends an Access-Accept response.
3	Access-Reject	From the server to the client. If any attribute value included in the Access-Request is unacceptable, the authentication fails, and the server sends an Access-Reject response.
4	Accounting-Request	From the client to the server. A packet of this type includes user information for the server to start or stop accounting for the user. The Acct-Status-Type attribute in the packet indicates whether to start or stop accounting.
5	Accounting-Response	From the server to the client. The server sends a packet of this type to notify the client that it has received the Accounting-Request and has successfully recorded the accounting information.

· The Identifier field (1 byte long) is used to match response packets with request packets and to detect duplicate request packets. The request and response packets of the same exchange process for the same purpose (such as authentication or accounting) have the same identifier.

· The Length field (2 bytes long) indicates the length of the entire packet (in bytes), including the Code, Identifier, Length, Authenticator, and Attributes fields. Bytes beyond this length are considered padding and are ignored by the receiver. If the length of a received packet is less than this length, the packet is dropped.

· The Authenticator field (16 bytes long) is used to authenticate responses from the RADIUS server and to encrypt user passwords. There are two types of authenticators: request authenticator and response authenticator.

· The Attributes field (variable in length) includes authentication, authorization, and accounting information. This field can contain multiple attributes, each with the following subfields:

¡ Type—Type of the attribute.

¡ Length—Length of the attribute in bytes, including the Type, Length, and Value subfields.

¡ Value—Value of the attribute. Its format and content depend on the Type subfield.

Extended RADIUS attributes

The RADIUS protocol features excellent extensibility. The Vendor-Specific attribute (attribute 26) allows a vendor to define extended attributes. The extended attributes can implement functions that the standard RADIUS protocol does not provide.

A vendor can encapsulate multiple subattributes in the TLV format in attribute 26 to provide extended functions. As shown in Figure 5, a subattribute encapsulated in attribute 26 consists of the following parts:

· Vendor-ID—ID of the vendor. The most significant byte is 0. The other three bytes contains a code compliant to RFC 1700.

· Vendor-Type—Type of the subattribute.

· Vendor-Length—Length of the subattribute.

· Vendor-Data—Contents of the subattribute.

The device supports the vendor-specific RADIUS subattributes with a vendor ID of 25506. For more information, see "Appendix C RADIUS subattributes (vendor ID 25506)."

Figure 5 Format of attribute 26

HWTACACS

HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security protocol based on TACACS (RFC 1492). HWTACACS is similar to RADIUS, and uses a client/server model for information exchange between the NAS and the HWTACACS server.

HWTACACS typically provides AAA services for terminal users that need to log in to the NAS. Working as the HWTACACS client, the NAS sends users' usernames and passwords to the HWTACACS server for authentication. After passing authentication and obtaining authorized rights, a user can access the device and performs authorized operations. The HWTACACS server records the operations that each user performs.

Differences between HWTACACS and RADIUS

HWTACACS and RADIUS have many features in common, such as using a client/server model, using shared keys for data encryption, and providing flexibility and scalability. Table 2 lists the primary differences between HWTACACS and RADIUS.

Table 2 Primary differences between HWTACACS and RADIUS

HWTACACS	RADIUS
Uses TCP, which provides reliable network transmission.	Uses UDP, which provides high transport efficiency.
Encrypts the entire packet except for the HWTACACS header.	Encrypts only the user password field in an authentication packet.
Protocol packets are complicated and authorization is independent of authentication. Authentication and authorization can be deployed on different HWTACACS servers.	Protocol packets are simple and the authorization process is combined with the authentication process.
Supports authorization of configuration commands. Access to commands depends on both the user's roles and authorization. A user can use only commands that are permitted by the user roles and authorized by the HWTACACS server.	Does not support authorization of configuration commands. Access to commands solely depends on the user's roles. For more information about user roles, see Fundamentals Configuration Guide.

Basic HWTACACS packet exchange process

Figure 6 describes how HWTACACS performs user authentication, authorization, and accounting for a Telnet user.

Figure 6 Basic HWTACACS packet exchange process for a Telnet user

HWTACACS operates using in the following workflow:

1. A Telnet user requests to Telnet to the device (HWTACACS client) and provides the username and password as instructed by the system.

2. The HWTACACS client sends a start-authentication request that includes the username to the HWTACACS server when it receives the Telnet request.

3. The HWTACACS server sends back an authentication response to request the login password.

4. Upon receipt of the response, the HWTACACS client sends the HWTACACS server a continue-authentication packet that includes the login password.

5. If the authentication succeeds, the HWTACACS server sends back an authentication response to indicate that the user has passed authentication.

6. The HWTACACS client sends a user authorization request packet to the HWTACACS server.

7. If the authorization succeeds, the HWTACACS server sends back an authorization response, indicating that the user is now authorized.

8. Knowing that the user is now authorized, the HWTACACS client pushes its CLI to the user and permits the user to log in.

9. The HWTACACS client sends a start-accounting request to the HWTACACS server.

10. The HWTACACS server sends back an accounting response, indicating that it has received the start-accounting request.

11. The user logs off.

12. The HWTACACS client sends a stop-accounting request to the HWTACACS server.

13. The HWTACACS server sends back a stop-accounting response, indicating that the stop-accounting request has been received.

LDAP

The Lightweight Directory Access Protocol (LDAP) provides standard multiplatform directory service. LDAP was developed on the basis of the X.500 protocol. It improves the following functions of X.500:

· Read/write interactive access.

· Browse.

· Search.

LDAP is suitable for storing data that does not often change. The protocol is used to store user information. For example, LDAP server software Active Directory Server is used in Microsoft Windows operating systems. The software stores the user information and user group information for user login authentication and authorization.

LDAP directory service

LDAP uses directories to maintain the organization information, personnel information, and resource information. The directories are organized in a tree structure and include entries. An entry is a set of attributes with distinguished names (DNs). The attributes are used to store information such as usernames, passwords, emails, computer names, and phone numbers.

LDAP uses a client/server model, and all directory information is stored in the LDAP server. Commonly used LDAP server products include Microsoft Active Directory Server, IBM Tivoli Directory Server, and Sun ONE Directory Server.

LDAP authentication and authorization

AAA can use LDAP to provide authentication and authorization services for users. LDAP defines a set of operations to implement its functions. The main operations for authentication and authorization are the bind operation and search operation.

· The bind operation allows an LDAP client to perform the following operations:

¡ Establish a connection with the LDAP server.

¡ Obtain the access rights to the LDAP server.

¡ Check the validity of user information.

· The search operation constructs search conditions and obtains the directory resource information of the LDAP server.

In LDAP authentication, the client completes the following tasks:

1. Uses the LDAP server administrator DN to bind with the LDAP server. After the binding is created, the client establishes a connection to the server and obtains the right to search.

2. Constructs search conditions by using the username in the authentication information of a user. The specified root directory of the server is searched and a user DN list is generated.

3. Binds with the LDAP server by using each user DN and password. If a binding is created, the user is considered legal.

In LDAP authorization, the client performs the same tasks as in LDAP authentication. When the client constructs search conditions, it obtains both authorization information and the user DN list.

Basic LDAP authentication process

The following example illustrates the basic LDAP authentication process for a Telnet user.

Figure 7 Basic LDAP authentication process for a Telnet user

The following shows the basic LDAP authentication process:

1. A Telnet user initiates a connection request and sends the username and password to the LDAP client.

2. After receiving the request, the LDAP client establishes a TCP connection with the LDAP server.

3. To obtain the right to search, the LDAP client uses the administrator DN and password to send an administrator bind request to the LDAP server.

4. The LDAP server processes the request. If the bind operation is successful, the LDAP server sends an acknowledgment to the LDAP client.

5. The LDAP client sends a user DN search request with the username of the Telnet user to the LDAP server.

6. After receiving the request, the LDAP server searches for the user DN by the base DN, search scope, and filtering conditions. If a match is found, the LDAP server sends a response to notify the LDAP client of the successful search. There might be one or more user DNs found.

7. The LDAP client uses the obtained user DN and the entered user password as parameters to send a user DN bind request to the LDAP server. The server will check whether the user password is correct.

8. The LDAP server processes the request, and sends a response to notify the LDAP client of the bind operation result. If the bind operation fails, the LDAP client uses another obtained user DN as the parameter to send a user DN bind request to the LDAP server. This process continues until a DN is bound successfully or all DNs fail to be bound. If all user DNs fail to be bound, the LDAP client notifies the user of the login failure and denies the user's access request.

9. The LDAP client saves the user DN that has been bound and exchanges authorization packets with the authorization server.

¡ If LDAP authorization is used, see the authorization process shown in Figure 8.

¡ If another method is expected for authorization, the authorization process of that method applies.

10. After successful authorization, the LDAP client notifies the user of the successful login.

Basic LDAP authorization process

The following example illustrates the basic LDAP authorization process for a Telnet user.

Figure 8 Basic LDAP authorization process for a Telnet user

The following shows the basic LDAP authorization process:

1. A Telnet user initiates a connection request and sends the username and password to the device. The device will act as the LDAP client during authorization.

2. After receiving the request, the device exchanges authentication packets with the authentication server for the user:

¡ If LDAP authentication is used, see the authentication process shown in Figure 7.

- If the device (the LDAP client) uses the same LDAP server for authentication and authorization, skip to step 6.

- If the device (the LDAP client) uses different LDAP servers for authentication and authorization, skip to step 4.

¡ If another authentication method is used, the authentication process of that method applies. The device acts as the LDAP client. Skip to step 3.

3. The LDAP client establishes a TCP connection with the LDAP authorization server.

4. To obtain the right to search, the LDAP client uses the administrator DN and password to send an administrator bind request to the LDAP server.

5. The LDAP server processes the request. If the bind operation is successful, the LDAP server sends an acknowledgment to the LDAP client.

6. The LDAP client sends an authorization search request with the username of the Telnet user to the LDAP server. If the user uses the same LDAP server for authentication and authorization, the client sends the request with the saved user DN of the Telnet user to the LDAP server.

7. After receiving the request, the LDAP server searches for the user information by the base DN, search scope, filtering conditions, and LDAP attributes. If a match is found, the LDAP server sends a response to notify the LDAP client of the successful search.

8. After successful authorization, the LDAP client notifies the user of the successful login.

User management based on ISP domains and user access types

AAA manages users based on the users' ISP domains and access types.

On a NAS, each user belongs to one ISP domain. Typically, the NAS determines the ISP domain to which a user belongs based on the username entered by the user at login. For flexible access management, the NAS also supports ISP domain assignment. The ISP domains to be assigned to users can be specified in access modules, in interface view, or in system view.

AAA manages users in the same ISP domain based on the users' access types. The device supports the following user access types:

· LAN—LAN access users.

· Login—Login users include SSH, Telnet, FTP, and terminal users that log in to the device. Terminal users can access through a console port.

· PPP.

· IPoE—IPoE users include Layer 2 and Layer 3 leased line users and Set Top Box (STB) users.

· HTTP/HTTPS—Web users log in to the Web interface of the device through HTTP or HTTPS.

NOTE:

The device also provides authentication modules for implementation of user authentication management policies. If you configure these authentication modules, the ISP domains for users of the access types depend on the configuration of the authentication modules.

‌

Authentication, authorization, and accounting methods

AAA supports configuring different authentication, authorization, and accounting methods for different types of users in an ISP domain. The NAS determines the ISP domain and access type of a user. The NAS also uses the methods configured for the access type in the domain to control the user's access.

AAA also supports configuring a set of default methods for an ISP domain. These default methods are applied to users for whom no AAA methods are configured.

Authentication methods

The device supports the following authentication methods:

· No authentication—This method trusts all users and does not perform authentication. For security purposes, do not use this method.

· Local authentication—The NAS authenticates users by itself, based on the locally configured user information including the usernames, passwords, and attributes. Local authentication allows high speed and low cost, but the amount of information that can be stored is limited by the size of the storage space.

· Remote authentication—The NAS works with a RADIUS, LDAP, or HWTACACS server to authenticate users. The server manages user information in a centralized manner. Remote authentication provides high capacity, reliable, and centralized authentication services for multiple NASs. You can configure backup methods to be used when the remote server is not available.

Authorization methods

The device supports the following authorization methods:

· No authorization—The NAS performs no authorization exchange. The following default authorization information applies after users pass authentication:

¡ Non-login users can access the network.

¡ Login users obtain the level-0 user role. For more information about the level-0 user role, see RBAC configuration in Fundamentals Configuration Guide.

¡ The working directory for FTP, SFTP, and SCP login users is the root directory of the NAS. However, the users do not have permission to access the root directory.

· Local authorization—The NAS performs authorization according to the user attributes locally configured for users.

· Remote authorization—The NAS works with a server to authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS authorization can work only after RADIUS authentication is successful, and the authorization information is included in the Access-Accept packet. HWTACACS authorization is separate from HWTACACS authentication, and the authorization information is included in the authorization response after successful authentication. You can configure backup methods to be used when the remote server is not available.

Accounting methods

The device supports the following accounting methods:

· No accounting—The NAS does not perform accounting for the users.

· Local accounting—Local accounting is implemented on the NAS. It counts and controls the number of concurrent users that use the same local user account, but does not provide statistics for charging.

· Remote accounting—The NAS works with a RADIUS server or HWTACACS server for accounting. You can configure backup methods to be used when the remote server is not available.

Authorization attribute configuration methods

You can configure authorization attributes for an ISP domain on the NAS, on a server, or on both the NAS and a server. Typically, server-assigned authorization attributes have higher priority than NAS-assigned settings. NAS-assigned attributes can take effect only if they do not conflict with server-assigned attributes. If a NAS-assigned attribute conflicts with a server-assigned attribute, the server-assigned attribute takes effect.

AAA extended functions

The device provides the following login services to enhance device security:

· Command authorization—Enables the NAS to let the authorization server determine whether a command entered by a login user is permitted. Login users can execute only commands permitted by the authorization server. For more information about command authorization, see controlling user access to the device in Fundamentals Configuration Guide.

· Command accounting—When command authorization is disabled, command accounting enables the accounting server to record all valid commands executed on the device. When command authorization is enabled, command accounting enables the accounting server to record all authorized commands. For more information about command accounting, see controlling user access to the device in Fundamentals Configuration Guide.

· User role authentication—Authenticates each user that wants to obtain another user role without logging out or getting disconnected. For more information about user role authentication, see Fundamentals Configuration Guide.

AAA for VPNs

You can deploy AAA across VPNs to enable forwarding of authentication, authorization, and accounting packets across VPNs. For example, as shown in Figure 9, the PE at the left side of the MPLS backbone acts as a NAS. The NAS transparently delivers the AAA packets of private users in VPN 1 and VPN 2 to the AAA servers in VPN 3 for centralized authentication. Authentication packets of private users in different VPNs do not affect each other.

Figure 9 Network diagram

‌

AAA for PPPoE agency dialup

Application scenarios

In a campus and ISP unification scenario, PPPoE agency dialup can be configured on the BRAS device in the campus network to provide self-service ISP selection and automatic PPPoE dialup. This feature simplifies unified operation between campus and ISP and provides the optimal network experience for campus network users.

Figure 10 Network diagram

Operating mechanism

In a campus and ISP unification scenario, campus network users can apply for different ISP services as needed and obtain the ISP account bound to the campus network account. For an IPoE or PPPoE user requesting ISP network access, the campus AAA server authorizes a user group marked with PPPoE agency dialup and the BRAS devices perform PPPoE agency dialup.

During PPPoE agency dialup, the campus BRAS device acts as the PPPoE client and the ISP BRAS device acts as the PPPoE server. The users are called PPPoE agency dialup (PPPoEA) users.

For example, when an IPoE user comes online, PPPoE agency dialup operates as follows:

1. The IPoE user sends an online request that carries a campus network account and password, and selects the target ISP service on the authentication page.

2. The campus BRAS device sends an authentication request to the AAA server. The request carries a username with the domain name included. The domain name identifies the selected ISP.

3. The AAA server verifies the campus network account and password and sends an authentication response to the campus BRAS device. If user authentication succeeds, the AAA server sends authorization attributes to the user at the same time.

For a user requesting an ISP service, the campus BRAS device assigns a user group marked with PPPoE agency dialup to the user. The user group name can be deployed by the AAA server or configured in the authentication domain on the BRAS device by the administrator. The AAA server-deployed username has a higher priority.

4. If user authentication succeeds, the campus BRAS device sends an accounting start request to the AAA server.

5. The AAA server sends an accounting start response to the campus BRAS device and sends a CoA request to notify the campus BRAS device to initiate the PPPoE agency dialup process.

The CoA request carries the following information:

¡ PPPoE agency dialup group name (Framed-Pool attribute).

¡ Campus network username.

¡ ISP account and password bound to the campus network account.

¡ Agency dialup scenario identifier (Filter-id attribute).

6. The IPoE user comes online successfully, and the campus BRAS device establishes an IPoE session for the user.

7. The campus BRAS device sends a CoA response to the AAA server to notify the start of the PPPoE agency dialup process, and uses the interface bound to the PPPoE agency dialup group as the PPPoE client. Then, the campus BRAS device sends a PPPoE dialup request to the ISP PPPoE server.

8. The ISP PPPoE server performs PPP negotiation with the PPPoE client, verifies the ISP account and password of the PPPoEA user, and assigns an ISP IP address to user if the user passes the verification.

9. Upon receiving the dialup response from the PPPoE server, the campus BRAS device sends a DM request to the AAA server to notify the dialup result. If the dialup succeeds, the campus BRAS device records the user as a PPPoEA user and associates the PPPoEA user with the corresponding IPoE session.

If the campus BRAS device receives a packet from the user that matches the external network ACL rule of the authorized user group, the device performs PPPoE encapsulation and directly forwards the packet to the corresponding ISP.

10. If the campus BRAS device is configured with an accounting scheme for PPPoEA users, the device sends an accounting start request to the AAA accounting server. The request carries the IPoE session information.

11. The AAA server sends an accounting start response to the campus BRAS device. Secondary accounting of PPPoEA users is performed on the campus AAA server for auditing and monitoring of external network traffic of campus users.

Figure 11 PPPoE agency dialup process

Protocols and standards

· RFC 2865, Remote Authentication Dial In User Service (RADIUS)

· RFC 2866, RADIUS Accounting

· RFC 2867, RADIUS Accounting Modifications for Tunnel Protocol Support

· RFC 2868, RADIUS Attributes for Tunnel Protocol Support

· RFC 2869, RADIUS Extensions

· RFC 3576, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)

· RFC 4818, RADIUS Delegated-IPv6-Prefix Attribute

· RFC 5176, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)

· RFC 1492, An Access Control Protocol, Sometimes Called TACACS

· RFC 1777, Lightweight Directory Access Protocol

· RFC 2251, Lightweight Directory Access Protocol (v3)

Restrictions and guidelines: AAA configuration

The configuration for IPoE, PPPoE, user profiles, and session group profiles is supported only when the device is placed in standard operating mode by using the system-working-mode command.

AAA tasks at a glance

To configure AAA, perform the following tasks:

1. Configuring AAA schemes

If local authentication is used, configure local users and the related attributes. If remote authentication is used, configure the required RADIUS, LDAP, or HWTACACS schemes.

¡ Configuring local users

¡ Configuring RADIUS

¡ Configuring HWTACACS

¡ Configuring LDAP

2. Configuring an ISP domain

a. Creating an ISP domain

b. Configuring ISP domain attributes

3. Configuring AAA methods for an ISP domain

Configure authentication, authorization, and accounting methods for an ISP domain as needed. These methods use existing AAA schemes.

¡ Configuring authentication methods for an ISP domain

¡ Configuring authorization methods for an ISP domain

¡ Configuring accounting methods for an ISP domain

4. Configuring AAA fail-permit and recovery

5. (Optional.) Configuring advanced AAA features

¡ Configuring ISP domains on an interface

¡ Setting the maximum number of concurrent login users

¡ Processing shared-account users as non-family users

¡ Configuring NetStream sampling for users

¡ Configuring the local bill cache feature

¡ Configuring a NAS-ID

¡ Setting the SSID on an interface

¡ Configuring the device ID

¡ Enabling password change prompt logging

¡ Configuring user online and offline recording

¡ Configuring the AAA test feature

¡ Enabling offline reason conversion for PPP users

¡ Enabling SNMP notifications for ISP domains

¡ Configuring SNMP notification for AAA

¡ Configuring the RADIUS proxy feature

Configuring local users

About local users

To implement local authentication, authorization, and accounting, create local users and configure user attributes on the device. The local users and attributes are stored in the local user database on the device. A local user is uniquely identified by the combination of a username and a user type. Local users are classified into the following types:

· Device management user—User that logs in to the device for device management.

· Network access user—User that accesses network resources through the device. Network access users also include guests that access the network temporarily. Guests can use only LAN services.

The following shows the configurable local user attributes:

· Service type—Services that the user can use. Local authentication checks the service types of a local user. If none of the service types is available, the user cannot pass authentication.

· User state—Whether or not a local user can request network services. There are two user states: active and blocked. A user in active state can request network services, but a user in blocked state cannot.

· Upper limit of concurrent logins using the same user name—Maximum number of users that can concurrently access the device by using the same user name. When the number reaches the upper limit, no more local users can access the device by using the user name.

· User group—Each local user belongs to a local user group and has all attributes of the group. The attributes include the password control attributes and authorization attributes. For more information about local user group, see "Configuring user group attributes."

· Binding attributes—Binding attributes control the scope of users, and are checked during local authentication of a user. If the attributes of a user do not match the binding attributes configured for the local user account, the user cannot pass authentication.

· Authorization attributes—Authorization attributes indicate the user's rights after it passes local authentication.

Configure the authorization attributes based on the service type of local users. For example, you do not need to configure the FTP/SFTP/SCP working directory attribute for a PPP user.

You can configure an authorization attribute in user group view or local user view. The setting of an authorization attribute in local user view takes precedence over the attribute setting in user group view.

¡ The attribute configured in user group view takes effect on all local users in the user group.

¡ The attribute configured in local user view takes effect only on the local user.

· Password control attributes—Password control attributes help control password security for device management users. Password control attributes include password aging time, minimum password length, password composition checking, password complexity checking, and login attempt limit.

You can configure a password control attribute in system view, user group view, or local user view. A password control attribute with a smaller effective range has a higher priority. For more information about password management and global password configuration, see "Configuring password control."

Local user configuration tasks at a glance

To configure local users, perform the following tasks:

1. Configuring local user attributes

¡ Configuring attributes for device management users

¡ Configuring attributes for network access users

¡ Configuring local guest attributes

2. (Optional.) Configuring user group attributes

3. (Optional.) Managing local guests

4. (Optional.) Enabling SNMP notification for user group

Configuring attributes for device management users

Restrictions and guidelines

If password control is enabled globally by using the password-control enable command, the device does not display the passwords of local device management users or retain them in the running configuration. When you globally disable the password control feature, local user passwords are automatically restored to the running configuration. To display the running configuration, use the display current-configuration command.

You can configure authorization attributes and password control attributes in local user view or user group view. The setting in local user view takes precedence over the setting in user group view.

Procedure

1. Enter system view.

system-view

2. Add a device management user and enter device management user view.

local-user user-name [ class manage ]

3. Configure a password for the local user.

password [ { hash | simple } string ]

A non-password-protected user passes authentication if the user provides the correct username and passes attribute checks. To enhance security, configure a password for each device management user.

4. Assign services to the local user.

service-type { ftp | { http | https | ssh | telnet | terminal } * }

By default, no services are authorized to a local user.

5. (Optional.) Set the status of the local user.

state { active | block }

By default, a local user is in active state and can request network services.

6. (Optional.) Set the upper limit of concurrent logins using the local user name.

access-limit max-user-number

By default, the number of concurrent logins is not limited for the local user.

This command takes effect only when local accounting is configured for the local user. This command does not apply to FTP, SFTP, or SCP users that do not support accounting.

7. (Optional.) Configure authorization attributes for the local user.

authorization-attribute { idle-cut minutes | user-role role-name | work-directory directory-name } *

The following default settings apply:

¡ The working directory for FTP, SFTP, and SCP users is the root directory of the NAS. However, the users do not have permission to access the root directory.

¡ The network-operator user role is assigned to local users that are created by a network-admin or level-15 user.

8. (Optional.) Configure password control attributes for the local user. Choose the following tasks as needed:

¡ Set the password aging time.

password-control aging aging-time

¡ Set the minimum password length.

password-control length length

¡ Configure the password composition policy.

password-control composition type-number type-number [ type-length type-length ]

¡ Configure the password complexity checking policy.

password-control complexity { same-character | user-name } check

¡ Configure the maximum login attempts and the action to take if there is a login failure.

password-control login-attempt login-times [ exceed { lock | lock-time time | unlock } ]

By default, a local user uses password control attributes of the user group to which the local user belongs.

9. (Optional.) Assign the local user to a user group.

group group-name

By default, a local user belongs to user group system.

Configuring attributes for network access users

Restrictions and guidelines

You can configure authorization attributes in local user view or user group view. The setting in local user view takes precedence over the setting in user group view.

Procedure

1. Enter system view.

system-view

2. Add a network access user and enter network access user view.

local-user user-name class network

3. (Optional.) Configure a password for the local user.

password { cipher | simple } string

4. Assign services to the local user.

service-type { ipoe | lan-access | ppp }

By default, no services are authorized to a local user.

5. (Optional.) Set the status of the local user.

state { active | block }

By default, a local user is in active state and can request network services.

6. (Optional.) Set the upper limit of concurrent logins using the local user name.

access-limit max-user-number

By default, the number of concurrent logins is not limited for the local user.

7. (Optional.) Configure binding attributes for the local user.

bind-attribute { call-number call-number [ : subcall-number ] | location interface interface-type interface-number | mac mac-address | vlan vlan-id } *

By default, no binding attributes are configured for a local user.

8. (Optional.) Configure authorization attributes for the local user.

authorization-attribute { acl acl-number | callback-number callback-number | idle-cut minutes | ip ipv4-address | ip-pool ipv4-pool-name | ipv6 ipv6-address | ipv6-pool ipv6-pool-name | ipv6-prefix ipv6-prefix prefix-length | netstream-sampler sampler-name [ inbound | outbound ] | { primary-dns | secondary-dns } { ip ip-address | ipv6 ipv6-address } | session-group-profile session-group-profile-name | session-timeout minutes | subscriber-id subscriber-id | url url-string | user-profile user-profile-name | vlan vlan-id | vpn-instance vpn-instance-name } *

By default, a network access user does not have authorization attributes.

9. (Optional.) Assign the local user to a user group.

group group-name

By default, a local user belongs to user group system.

10. (Optional.) Specify the validity period for the local user.

validity-datetime { from start-date start-time to expiration-date expiration-time | from start-date start-time | to expiration-date expiration-time }

By default, the validity period for a network access user does not expire.

Configuring local guest attributes

About this task

Create local guests and configure guest attributes to control temporary network access behavior. Guests can access the network after passing local authentication. You can configure the recipient addresses and email attribute information to the local guests and guest sponsors.

Procedure

1. Enter system view.

system-view

2. Create a local guest and enter local guest view.

local-user user-name class network guest

3. (Optional.) Configure a password for the local guest.

password { cipher | simple } string

4. Configure basic information for the local guest. Choose the following tasks as needed:

¡ Configure a description for the local guest.

description text

By default, no description is configured for a local guest.

¡ Specify the name of the local guest.

full-name name-string

By default, no name is specified for a local guest.

¡ Specify the company of the local guest.

company company-name

By default, no company is specified for a local guest.

¡ Specify the phone number of the local guest.

phone phone-number

By default, no phone number is specified for a local guest.

¡ Specify the email address of the local guest.

email email-string

By default, no email address is specified for a local guest.

¡ Specify the sponsor name for the local guest.

sponsor-full-name name-string

By default, no sponsor name is specified for a local guest.

¡ Specify the sponsor department for the local guest.

sponsor-department department-string

By default, no sponsor department is specified for a local guest.

¡ Specify the sponsor email address for the local guest.

sponsor-email email-string

By default, no sponsor email address is specified for a local guest.

5. (Optional.) Configure the validity period for the local guest.

validity-datetime start-date start-time to expiration-date expiration-time

By default, a local guest does not expire.

6. (Optional.) Assign the local guest to a user group.

group group-name

By default, a local guest belongs to the system-defined user group system.

7. (Optional.) Configure the local guest status.

state { active | block }

By default, a local guest is in active state and is allowed to request network services.

Configuring user group attributes

About this task

User groups simplify local user configuration and management. A user group contains a group of local users and has a set of local user attributes. You can configure local user attributes for a user group to implement centralized user attributes management for the local users in the group. Local user attributes that are manageable include authorization attributes.

Procedure

1. Enter system view.

system-view

2. Create a user group and enter user group view.

user-group group-name

By default, a system-defined user group exists. The group name is system.

3. Configure authorization attributes for the user group.

authorization-attribute { acl acl-number | callback-number callback-number | idle-cut minutes | ip-pool ipv4-pool-name | ipv6-pool ipv6-pool-name | ipv6-prefix ipv6-prefix prefix-length | { primary-dns | secondary-dns } { ip ipv4-address | ipv6 ipv6-address } | session-group-profile session-group-profile-name | session-timeout minutes | subscriber-id subscriber-id | url url-string | user-profile profile-name | vlan vlan-id | vpn-instance vpn-instance-name | work-directory directory-name } *

By default, no authorization attributes are configured for a user group.

4. (Optional.) Configure password control attributes for the user group. Choose the following tasks as needed:

¡ Set the password aging time.

password-control aging aging-time

¡ Set the minimum password length.

password-control length length

¡ Configure the password composition policy.

password-control composition type-number type-number [ type-length type-length ]

¡ Configure the password complexity checking policy.

password-control complexity { same-character | user-name } check

¡ Configure the maximum login attempts and the action to take for login failures.

password-control login-attempt login-times [ exceed { lock | lock-time time | unlock } ]

By default, a user group uses the global password control settings. For more information, see "Configuring password control."

Password control attributes are applicable only to device management users.

5. (Optional.) Configure the forwarding policy for PPPoE agency dialup.

pppoe-agency forward { ipv4 | ipv6 } acl { acl-number | name acl-name }

By default, the forwarding policy is not configured for PPPoE agency dialup.

Perform this task only when PPPoE agency dialup is configured. For more information about this command, see PPPoE commands in BRAS Services Command Reference.

6. (Optional.) Specify the authentication domain for PPPoE agency dialup.

pppoe-agency authentication domain domain-name

By default, the authentication domain is not configured for PPPoE agency dialup.

Perform this task only when PPPoE agency dialup is configured. For more information about this command, see PPPoE commands in BRAS Services Command Reference.

Managing local guests

About this task

The local guest management features are for registration, approval, maintenance, and access control of local guests.

The device provides the following local guest management features:

· Email notification—The device notifies the local guests, guest sponsors, or guest managers by email of the guest account information or guest registration requests.

· Local guest creation in batch—Create a batch of local guests.

· Local guest import—Import guest account information from a .csv file to create local guests on the device based on the imported information.

· Local guest export—Export local guest account information to a .csv file. You can import the account information to other devices as needed.

· Guest auto-delete—The device regularly checks the validity status of each local guest and automatically deletes expired local guests.

Procedure

1. Enter system view

system-view

2. Configure the email notification feature for local guests.

a. Configure the subject and body of email notifications.

local-guest email format to { guest | manager | sponsor } { body body-string | subject sub-string }

By default, no subject or body is configured.

b. Configure the email sender address in the email notifications sent by the device for local guests.

local-guest email sender email-address

By default, no email sender address is configured for the email notifications sent by the device.

c. Specify an SMTP server for sending email notifications of local guests.

local-guest email smtp-server url-string

By default, no SMTP server is specified.

3. (Optional.) Import guest account information from a .csv file in the specified path to create local guests based on the imported information.

local-user-import class network guest url url-string validity-datetime start-date start-time to expiration-date expiration-time [ auto-create-group | override | start-line line-number ] *

4. (Optional.) Create local guests in batch.

local-guest generate username-prefix name-prefix [ password-prefix password-prefix ] suffix suffix-number [ group group-name ] count user-count validity-datetime start-date start-time to expiration-date expiration-time

Batch generated local guests share the same name prefix. You can also configure a password prefix to be shared by the guests.

5. (Optional.) Export local guest account information to a .csv file in the specified path.

local-user-export class network guest url url-string

6. (Optional.) Enable the guest auto-delete feature.

local-guest auto-delete enable

By default, the guest auto-delete feature is disabled.

7. (Optional.) Send email notifications to the local guest or the guest sponsor.

a. Return to user view.

quit

b. Send email notifications to the local guest or the guest sponsor. The email contents include the user name, password, and validity period of the guest account.

local-guest send-email user-name user-name to { guest | sponsor }

Enabling SNMP notification for user group

About this task

With SNMP notification for user group quantity enabled, the system generates an upper limit reaching threshold when the number of user groups configured on the device reaches the upper limit. When the user group quantity drops below the 90% of the upper limit, the system generates an alarm removal message.

The generated alarm messages are sent to the SNMP module of the device. For SNMP notifications to be sent correctly, you must also configure SNMP on the device. For more information about SNMP configuration, see Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view

system-view

2. Enable SNMP notification for user group.

snmp-agent trap enable user-group [ max-count-threshold ]

By default, SNMP notification for user group is disabled.

Display and maintenance commands for local users and local user groups

Execute display commands in any view and execute reset commands in user view.

Task	Command
Display the local user configuration and online user statistics.	display local-user [ class { manage \| network [ guest ] } \| idle-cut { disable \| enable } \| service-type { ftp \| http \| https \| ipoe \| lan-access \| ppp \| ssh \| telnet \| terminal } \| state { active \| block } \| user-name user-name class { manage \| network [ guest ] } \| vlan vlan-id ]
Display user group configuration.	display user-group { all \| name group-name }
Display active identity groups.	display user-group identity-active

Configuring RADIUS

RADIUS tasks at a glance

To configure RADIUS, perform the following tasks:

1. Configuring a test profile for RADIUS server status detection

To detect the RADIUS server status, you must configure a test profile and configure the RADIUS server to use the test profile in a RADIUS scheme.

2. Creating a RADIUS scheme

3. Specifying RADIUS authentication servers

4. Specifying the RADIUS accounting servers

5. Specifying the shared keys for secure RADIUS communication

Perform this task if no shared keys are specified when configuring RADIUS authentication or accounting servers.

6. Specifying the MPLS L3VPN instance for a RADIUS scheme

Perform this task if no MPLS L3VPN instances are specified when configuring RADIUS authentication or accounting servers.

7. (Optional.) Setting the status of RADIUS servers

8. (Optional.) Setting RADIUS timers

9. (Optional.) Configuring parameters for RADIUS packets

¡ Specifying the source IP address of outgoing RADIUS packets

¡ Setting the username format and traffic statistics units

¡ Setting the maximum number of RADIUS request transmission attempts

¡ Setting the maximum number of real-time accounting attempts

¡ Setting the DSCP priority for RADIUS packets

¡ Setting the maximum number of pending RADIUS requests

10. (Optional.) Configuring parameters for RADIUS attributes

¡ Specifying the NAS IP address of RADIUS packets

¡ Configuring the format of the RADIUS NAS-Port attribute

¡ Setting the value of the RADIUS Service-Type attribute

¡ Configuring the Login-Service attribute check method for SSH, FTP, and terminal users

¡ Interpreting the RADIUS class attribute as CAR parameters

¡ Configuring the MAC address format of RADIUS attribute 31

¡ Configuring the device to prefer RADIUS server-assigned real-time accounting interval

¡ Configuring the format of RADIUS attribute 87

¡ Setting the data measurement unit for the Remanent_Volume attribute

¡ Specifying a server version for interoperating with servers with a vendor ID of 2011

¡ Configuring the RADIUS attribute translation feature

11. (Optional.) Configuring extended RADIUS features

¡ Specifying the action to take for AAA requests if all RADIUS servers are blocked

¡ Configuring RADIUS stop-accounting packet buffering

¡ Enabling forcibly sending RADIUS stop-accounting packets

¡ Enabling the RADIUS server load sharing feature

¡ Configuring the RADIUS accounting-on feature

¡ Configuring the RADIUS session-control feature

¡ Configuring the RADIUS DAS feature

¡ Configuring the device to preferentially process RADIUS authentication requests

¡ Setting the available data threshold

¡ Using server-assigned usernames for AAA processes subsequent to authentication

¡ Enabling SNMP notifications for RADIUS

Configuring a test profile for RADIUS server status detection

About this task

Use a test profile to detect whether a RADIUS authentication server is reachable at a detection interval. To detect the RADIUS server status, you must configure the RADIUS server to use this test profile in a RADIUS scheme.

With the test profile specified, the device sends a detection packet to the RADIUS server within each detection interval. The detection packet is a simulated authentication request that includes the specified user name in the test profile.

· If the device receives a response from the server within the interval, it sets the server to the active state.

· If the device does not receive any response from the server within the interval, it sets the server to the blocked state.

The device refreshes the RADIUS server status at each detection interval according to the detection result.

Restrictions and guidelines

You can configure multiple test profiles in the system.

The device starts detecting the status of the RADIUS server only if an existing test profile is specified for the RADIUS authentication server.

The device stops detecting the status of the RADIUS server when one of the following operations is performed:

· The RADIUS server is removed from the RADIUS scheme.

· The test profile configuration is removed for the RADIUS server in RADIUS scheme view.

· The test profile is deleted.

· The RADIUS server is manually set to the blocked state.

· The RADIUS scheme is deleted.

Procedure

1. Enter system view.

system-view

2. Configure a test profile for detecting the status of RADIUS authentication servers.

radius-server test-profile profile-name username name [ interval [ second ] interval ]

Creating a RADIUS scheme

Restrictions and guidelines

You can configure a maximum of 16 RADIUS schemes. A RADIUS scheme can be used by multiple ISP domains.

Procedure

1. Enter system view.

system-view

2. Create a RADIUS scheme and enter RADIUS scheme view.

radius scheme radius-scheme-name

Specifying RADIUS authentication servers

About this task

A RADIUS authentication server completes authentication and authorization together, because authorization information is piggybacked in authentication responses sent to RADIUS clients.

You can specify one primary authentication server and a maximum of 16 secondary authentication servers for a RADIUS scheme. Secondary servers provide AAA services when the primary server becomes unreachable. The device searches for an active server in the order the secondary servers are configured.

When RADIUS server load sharing is enabled, the device distributes the workload over all servers without considering the primary and secondary server roles. The device checks the weight value and number of currently served users for each active server, and then determines the most appropriate server in performance to receive an authentication request.

Restrictions and guidelines

If redundancy is not required, specify only the primary server.

A RADIUS authentication server can function as the primary authentication server for one scheme and a secondary authentication server for another scheme at the same time.

Two authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address, VPN instance, and port number.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Specify the primary RADIUS authentication server.

primary authentication { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | test-profile profile-name | vpn-instance vpn-instance-name | weight weight-value ] *

By default, no primary RADIUS authentication server is specified.

The weight keyword takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme.

4. (Optional.) Specify a secondary RADIUS authentication server.

secondary authentication { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | test-profile profile-name | vpn-instance vpn-instance-name | weight weight-value ] *

By default, no secondary RADIUS authentication servers are specified.

The weight keyword takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme.

Specifying the RADIUS accounting servers

About this task

You can specify one primary accounting server and a maximum of 16 secondary accounting servers for a RADIUS scheme. Secondary servers provide AAA services when the primary server becomes unavailable. The device searches for an active server in the order the secondary servers are configured.

Restrictions and guidelines

If redundancy is not required, specify only the primary server.

A RADIUS accounting server can function as the primary accounting server for one scheme and a secondary accounting server for another scheme at the same time.

Two accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address, VPN instance, and port number.

RADIUS does not support accounting for FTP, SFTP, and SCP users.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Specify the primary RADIUS accounting server.

primary accounting { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | vpn-instance vpn-instance-name | weight weight-value ] *

By default, no primary RADIUS accounting server is specified.

The weight keyword takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme.

4. (Optional.) Specify a secondary RADIUS accounting server.

secondary accounting { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | vpn-instance vpn-instance-name | weight weight-value ] *

By default, no secondary RADIUS accounting servers are specified.

The weight keyword takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme.

Specifying the shared keys for secure RADIUS communication

About this task

The RADIUS client and server use the MD5 algorithm and shared keys to generate the Authenticator value for packet authentication and user password encryption. The client and server must use the same key for each type of communication.

A key configured in this task is for all servers of the same type (accounting or authentication) in the scheme. The key has a lower priority than a key configured individually for a RADIUS server.

Restrictions and guidelines

The shared key configured on the device must be the same as the shared key configured on the RADIUS server.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Specify a shared key for secure RADIUS communication.

key { accounting | authentication } { cipher | simple } string

By default, no shared key is specified for secure RADIUS communication.

Specifying the MPLS L3VPN instance for a RADIUS scheme

About this task

The VPN instance specified for a RADIUS scheme applies to all authentication and accounting servers in that scheme. If a VPN instance is also configured for an individual RADIUS server, the VPN instance specified for the RADIUS scheme does not take effect on that server.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Specify a VPN instance for the RADIUS scheme.

vpn-instance vpn-instance-name

By default, a RADIUS scheme belongs to the public network.

Setting the status of RADIUS servers

About this task

To control the RADIUS servers with which the device communicates when the current servers are no longer available, set the status of RADIUS servers to blocked or active. You can specify one primary RADIUS server and multiple secondary RADIUS servers. The secondary servers function as the backup of the primary server.

When the RADIUS server load sharing feature is enabled, the device chooses servers based on the following rules in a RADIUS scheme:

· If active servers exist, the device checks the workload on each active server, and then selects the most appropriate active server in performance for communication.

· If all authentication servers are blocked, the device first tries to send an authentication request to the authentication server that has the largest weight value. If multiple servers have the largest weight value, the device selects a server from these servers in the order they are configured. The last configured server is selected.

If the authentication request times out, the device starts a 1-minute timer. If no authentication server becomes active before the timer expires, the device does not try to communicate with any other authentication server. If an active authentication server is available before the timer expires, the device tries to communicate with that active server.

· If all accounting servers are blocked, the device only tries to communicate with the accounting server that has the largest weight value. If multiple accounting servers have the largest weight value, the device selects a server from these servers in the order they are configured. The last configured server is selected.

When the RADIUS server load sharing feature is disabled, the device chooses servers based on the following rules in a RADIUS scheme:

· When the primary server is in active state, the device first tries to communicate with the primary server. If the primary server is unreachable, the device searches for an active secondary server in the order the servers are configured.

· When one or more servers are in active state, the device tries to communicate with these active servers only, even if the servers are unavailable.

· If all authentication servers are blocked, the device first tries to send an authentication request to the primary authentication server. If no primary authentication server is configured, the device searches for a secondary authentication server in the order the servers are configured. The first configured server is selected. If the authentication request times out, the device starts a 1-minute timer. If no authentication server becomes active before the timer expires, the device does not try to communicate with any other authentication server. If an active authentication server is available before the timer expires, the device tries to communicate with that active server.

· If all accounting servers are blocked, the device tries to communicate with the primary accounting server. If no primary accounting server is configured, the device searches for a secondary accounting server in the order the servers are configured. The first configured server is selected.

· If a server is unreachable, the device performs the following operations:

¡ Changes the server status to blocked.

¡ Starts a quiet timer for the server.

¡ Tries to communicate with the next secondary server in active state that has the highest priority.

· When the quiet timer of a server expires or you manually set the server to the active state, the status of the server changes back to active. The device does not check the server again during the authentication or accounting process.

· The search process continues until the device finds an available secondary server or has checked all secondary servers in active state. If no server is reachable, the device considers the authentication or accounting attempt a failure.

· When you remove a server in use, communication with the server times out. The device looks for a server in active state by first checking the primary server, and then checking secondary servers in the order they are configured.

· When a RADIUS server's status changes automatically, the device changes this server's status accordingly in all RADIUS schemes in which this server is specified.

· When a RADIUS server is manually set to blocked, server detection is disabled for the server, regardless of whether a test profile has been specified for the server. When the RADIUS server is set to active state, server detection is enabled for the server on which an existing test profile is specified.

By default, the device sets the status of all RADIUS servers to active. However, in some situations, you must change the status of a server. For example, if a server fails, you can change the status of the server to blocked to avoid communication attempts to the server.

Restrictions and guidelines

The configured server status cannot be saved to any configuration file, and can only be viewed by using the display radius scheme command.

After the device restarts, all servers are restored to the active state.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Set the RADIUS server status. Choose the following tasks as needed:

¡ Set the status of the primary RADIUS authentication server.

state primary authentication { active | block }

¡ Set the status of the primary RADIUS accounting server.

state primary accounting { active | block }

¡ Set the status of a secondary RADIUS authentication server.

state secondary authentication [ { ipv4-address | ipv6 ipv6-address } [ port-number | vpn-instance vpn-instance-name ] * ] { active | block }

¡ Set the status of a secondary RADIUS accounting server.

state secondary accounting [ { ipv4-address | ipv6 ipv6-address } [ port-number | vpn-instance vpn-instance-name ] * ] { active | block }

By default, a RADIUS server is in active state.

Setting RADIUS timers

About this task

The device uses the following types of timers to control communication with a RADIUS server:

· Server response timeout timer (response-timeout)—Defines the RADIUS request retransmission interval. The timer starts immediately after a RADIUS request is sent. If the device does not receive a response from the RADIUS server before the timer expires, it resends the request.

· Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If one server is not reachable, the device changes the server status to blocked, starts this timer for the server, and tries to communicate with another server in active state. After the server quiet timer expires, the device changes the status of the server back to active.

· Real-time accounting timer (realtime-accounting)—Defines the interval at which the device sends real-time accounting packets to the RADIUS accounting server for online users.

Restrictions and guidelines

Consider the number of secondary servers when you configure the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout timer. If the RADIUS scheme includes many secondary servers, the retransmission process might be too long and the client connection in the access module, such as Telnet, can time out.

When the client connections have a short timeout period, a large number of secondary servers can cause the initial authentication or accounting attempt to fail. In this case, reconnect the client rather than adjusting the RADIUS packet transmission attempts and server response timeout timer. Typically, the next attempt will succeed, because the device has blocked the unreachable servers to shorten the time to find a reachable server.

Make sure the server quiet timer is set correctly. A timer that is too short might result in frequent authentication or accounting failures. This is because the device will continue to attempt to communicate with an unreachable server that is in active state. A timer that is too long might temporarily block a reachable server that has recovered from a failure. This is because the server will remain in blocked state until the timer expires.

A short real-time accounting interval helps improve accounting precision but requires many system resources. When there are 1000 or more users, set the interval to 15 minutes or longer.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Set RADIUS timers. Choose the following tasks as needed:

¡ Set the RADIUS server response timeout timer.

timer response-timeout seconds

The default setting is 3 seconds.

¡ Set the quiet timer for the servers.

timer quiet minutes

The default setting is 5 minutes.

¡ Set the real-time accounting timer.

timer realtime-accounting interval [ second ]

The default setting is 12 minutes.

Specifying the source IP address of outgoing RADIUS packets

About this task

A RADIUS server identifies a NAS by its IP address and processes a RADIUS packet only when the source IP address of the packet is the IP address of a managed NAS. You must make sure the source IP address of RADIUS packets that a NAS sends matches the IP address of the NAS configured on the RADIUS server.

When the device acts as a NAS, it selects a source IP address for outgoing RADIUS packets in the following order:

1. The source IP address specified by using the source-ip command in RADIUS scheme view.

2. The source IP address specified by using the radius source-ip command in system view.

3. The NAS IP address specified by using the nas-ip command in RADIUS scheme view.

4. The NAS IP address specified by using the radius nas-ip command in system view.

5. The IP address of the outbound interface for the outgoing RADIUS packets.

Restrictions and guidelines for source IP address configuration

As a best practice to avoid RADIUS packet loss caused by physical port errors, specify a loopback interface address as the source IP address of outgoing RADIUS packets.

Specifying a source IP address for outgoing RADIUS packets in system view

1. Enter system view.

system-view

2. Specify a source IP address for outgoing RADIUS packets.

radius source-ip { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ]

By default, no IP address is specified as the source IP address of outgoing RADIUS packets.

Specifying a source IP address for outgoing RADIUS packets in RADIUS scheme view

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Specify a source IP address for outgoing RADIUS packets.

source-ip { ipv4-address | ipv6 ipv6-address }

By default, the source IP address specified by using the radius source-ip command in system view is used.

Setting the username format and traffic statistics units

About this task

A username is in the userid@isp-name format, where the isp-name part represents the user's ISP domain name. By default, the ISP domain name is included in a username. However, older RADIUS servers might not recognize usernames that contain the ISP domain names. In this case, you can configure the device to remove the domain name of each username to be sent.

The device reports online user traffic statistics in accounting packets. The traffic measurement units are configurable.

Restrictions and guidelines

If two or more ISP domains use the same RADIUS scheme, configure the RADIUS scheme to keep the ISP domain name in usernames for domain identification.

For accounting accuracy, make sure the traffic statistics units configured on the device and on the RADIUS accounting servers are the same.

To ensure the correct operation of PPPoE agency dialup, set the format of usernames sent to the RADIUS servers to keep-original.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Set the format for usernames sent to the RADIUS servers.

user-name-format { keep-original | with-domain | without-domain }

By default, the ISP domain name is included in a username.

4. Set the data flow and packet measurement units for traffic statistics.

data-flow-format { data { byte | giga-byte | kilo-byte | mega-byte } | packet { giga-packet | kilo-packet | mega-packet | one-packet } }*

By default, traffic is counted in bytes and packets.

Setting the maximum number of RADIUS request transmission attempts

About this task

RADIUS uses UDP packets to transfer data. Because UDP communication is not reliable, RADIUS uses a retransmission mechanism to improve reliability. A RADIUS request is retransmitted if the NAS does not receive a server response for the request within the response timeout timer. For more information about the RADIUS server response timeout timer, see "Setting the status of RADIUS servers."

You can set the maximum number for the NAS to retransmit a RADIUS request to the same server. When the maximum number is reached, the NAS tries to communicate with other RADIUS servers in active state. If no other servers are in active state at the time, the NAS considers the authentication or accounting attempt a failure.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Set the maximum number of RADIUS request transmission attempts.

retry retries

By default, the maximum number is 3 for RADIUS request transmission attempts.

Setting the maximum number of real-time accounting attempts

About this task

If you set the maximum number of real-time accounting attempts, the device will disconnect users from whom no accounting responses are received within the permitted attempts.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Set the maximum number of real-time accounting attempts.

retry realtime-accounting retries

By default, the maximum number is 5 for real-time accounting attempts.

Setting the DSCP priority for RADIUS packets

About this task

The DSCP priority in the ToS field determines the transmission priority of RADIUS packets. A larger value represents a higher priority.

Procedure

1. Enter system view.

system-view

2. Set the DSCP priority for RADIUS packets.

radius [ ipv6 ] dscp dscp-value

By default, the DSCP priority is 0 for RADIUS packets.

Setting the maximum number of pending RADIUS requests

About this task

This feature controls the rate of RADIUS requests that are sent to the RADIUS server. Use this feature if the RADIUS server has a limited performance and cannot concurrently process too many RADIUS requests.

The device has two types of pending packet counters, one for the RADIUS authentication server and the other for the RADIUS accounting server. A pending packet counter is used to record the number of sent RADIUS requests for which no responses are received from the RADIUS server. The maximum value of a pending packet counter is determined by this command.

If you set the maximum number of pending authentication or accounting requests, a pending packet counter will be started for each RADIUS authentication or accounting server.

1. The device starts a pending packet counter for a RADIUS authentication or accounting server after sending the first authentication or accounting request to the server.

2. The device keeps sending the corresponding type of requests to the server before the counter reaches the maximum value. The number of requests that can be sent to the server is the difference between the counter value and the maximum number.

The counter increases by 1 each time the device sends a corresponding request.

The counter decreases by 1 each time the device receives a respond from the server or the respond timeout timer for a request expires.

3. The device buffers the subsequent requests when the counter reaches the maximum value.

If the value of the counter falls below the maximum value, the device sends the buffered requests in the sequence the requests are buffered.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Set the maximum number of pending RADIUS requests.

response-pending-limit { accounting | authentication } max-number

By default, the number of pending RADIUS requests is not restricted.

Specifying the NAS IP address of RADIUS packets

About this task

The NAS IP address refers to the IP address carried in the NAS-IP-Address or NAS-IPv6-Address attribute in RADIUS packets. The NAS IP address must be unique for a RADIUS server to identify the NAS.

Use this feature to specify a NAS IP address for the NAS to carry in the NAS-IP-Address or NAS-IPv6-Address attribute in outgoing RADIUS requests. In addition, the NAS uses the NAS IP address as a criterion to match users by matching the NAS IP address in incoming RADIUS DAE packets. For more information about user matching, see "Configuring the RADIUS DAS feature."

Restrictions and guidelines for NAS IP address configuration

You can specify the NAS IP address in interface view, RADIUS scheme view, and system view.

· The NAS IP address specified by using the aaa nas-ip command in interface view applies only to users that access the network through the interface.

· The NAS IP address specified by using the nas-ip command in RADIUS scheme view applies only to the RADIUS scheme.

· The NAS IP address specified by using the radius nas-ip command in system view applies to all RADIUS schemes.

The priority order is as follows:

1. The NAS IP address specified in interface view.

2. The NAS IP address specified in RADIUS scheme view.

3. The NAS IP address specified in system view.

Specifying a NAS IP address for RADIUS packets in interface view

1. Enter system view.

system-view

2. Enter Layer 3 interface view.

interface interface-type interface-number

3. Specify a NAS IP address for RADIUS packets.

aaa nas-ip { ipv4-address | ipv6 ipv6-address }

By default, no NAS IP address is specified on a Layer 3 interface.

Specifying a NAS IP address for RADIUS packets in system view

1. Enter system view.

system-view

2. Specify a NAS IP address for RADIUS packets.

radius nas-ip { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ]

By default, the NAS IP address of RADIUS packets is the primary IPv4 address or the IPv6 address of the outbound interface.

Specifying a NAS IP address for RADIUS packets in RADIUS scheme view

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Specify a NAS IP address for RADIUS packets.

nas-ip { ipv4-address | ipv6 ipv6-address }

By default, the NAS IP address specified by using the radius nas-ip command in system view is used.

Configuring the format of the RADIUS NAS-Port attribute

About the format of the RADIUS NAS-Port attribute

The device supports the following formats for the RADIUS NAS-Port attribute (attribute 5):

· QinQ encapsulation format—The format is SlotIDSubslotIDIfIndexSVlanIDCVlanID, which is applicable to a QinQ network.

· Single-VLAN encapsulation format—The format is SlotIDSubslotIDIfIndexVlanID, which is applicable to a non-QinQ network.

Restrictions and guidelines

As a best practice, use the QinQ encapsulation format for the RADIUS NAS-Port attribute in a QinQ network.

If the QinQ encapsulation format is configured in a non-QinQ network, the device pads the SVlanID part in this attribute with 0s.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Configure the format of the RADIUS NAS-Port attribute as the QinQ encapsulation format.

attribute 5 format qinq

By default, the RADIUS NAS-Port attribute uses the single-VLAN encapsulation format: SlotIDSubslotIDIfIndexVlanID.

Setting the value of the RADIUS Service-Type attribute

About the value of the RADIUS Service-Type attribute

Set the value of the RADIUS Service-Type attribute (attribute 6) in outgoing RADIUS packets to meet the requirements of RADIUS servers.

If the service provider requires that the Service-Type attribute in authentication and accounting requests for IPoE users uses value 5 (Outbound), execute the attribute 6 value outbound user-type ipoe command. If the service provider has the same requirements for authentication and accounting requests of IPoE users' value-added services (including ITA and EDSG services), execute the attribute 6 value outbound user-type ipoe value-added-service command.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Set the value of the RADIUS Service-Type attribute in outgoing RADIUS packets.

attribute 6 value outbound user-type ipoe [ value-added-service ]

By default, the value of the RADIUS Service-Type attribute in outgoing RADIUS packets varies by user type.

¡ For device management users, the value is 1 (Login).

¡ For the other types of users, the value is 2 (Framed).

Configuring the Login-Service attribute check method for SSH, FTP, and terminal users

About this task

During authentication, the device checks the value of the Login-Service attribute (RADIUS attribute 15) in Access-Accept messages against user login service types. If the service type indicated by the attribute is not consistent with the actual login service, authentication fails.

RFC does not define the attribute values for FTP, SSH, and terminal services. For login service consistency check for these types of services, H3C defines extended values as described in Table 3.

Table 3 Values for the Login-Service attribute

Service type	Standard value	Extended value
SSH	0	50
FTP	0	51
Terminal	0	52

For SSH, FTP, terminal, HTTP, and HTTPS users, the device supports the following check methods for the Login-Service attribute:

· Strict—Matches extended Login-Service attribute values.

· Loose—Matches standard Login-Service attribute values.

Restrictions and guidelines

Use the loose check method only when the RADIUS server does not support extended Login-Service attribute values for FTP, SSH, and terminal users.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Configure the Login-Service attribute check method.

attribute 15 check-mode { loose | strict }

By default, the check method is strict.

Interpreting the RADIUS class attribute as CAR parameters

About this task

A RADIUS server may deliver CAR parameters for user-based traffic monitoring and control by using the RADIUS class attribute (attribute 25) in RADIUS packets. You can configure the device to interpret the class attribute to CAR parameters.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Interpret the RADIUS class attribute as CAR parameters.

attribute 25 car

By default, the RADIUS class attribute is not interpreted as CAR parameters.

Configuring the MAC address format of RADIUS attribute 31

Restrictions and guidelines

RADIUS servers of different types might have different requirements for the MAC address format in RADIUS attribute 31. Configure the MAC address format of RADIUS attribute 31 to meet the requirements of the RADIUS servers.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Configure the MAC address format of RADIUS attribute 31.

attribute 31 mac-format section { six | three } separator separator-character { lowercase | uppercase }

By default, a MAC address is in the format of HH-HH-HH-HH-HH-HH. The MAC address is separated by hyphen (-) into six sections with letters in upper case.

Configuring the device to prefer RADIUS server-assigned real-time accounting interval

About this task

The real-time accounting interval can be set by the timer realtime-accounting command in RADIUS scheme view or assigned by the server through the RADIUS Acct-Interim-Interval attribute. By default, a non-zero interval in RADIUS scheme view takes precedence over the server-assigned interval. To configure the device to prefer the server-assigned interval, perform this task.

Restrictions and guidelines

Execution of the attribute 85 preferred command does not change the real-time accounting interval of users that have been online.

Execution of the undo attribute 85 preferred command applies the real-time accounting interval set by the timer realtime-accounting command to users that have been online.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Configure the device to prefer the real-time accounting interval assigned by the server through the RADIUS Acct-Interim-Interval attribute.

attribute 85 preferred

By default, the real-time accounting interval set in RADIUS scheme view takes precedence over the real-time accounting interval assigned by the server through the RADIUS Acct-Interim-Interval attribute.

Configuring the format of RADIUS attribute 87

About this task

RADIUS attribute 87 is the NAS-Port-Id attribute. This attribute has the following format types:

· Vendor-specific format—The attribute format is defined by a vendor. For more information about the formats, see AAA commands in Security Command Reference.

· Custom format—The attribute format is user defined. You can define the fields to be included in the attribute, the sequence of the fields, and the delimiters to separate the fields by using the attribute 87 format command.

Restrictions and guidelines

RADIUS servers of different types might have different requirements for the format of the NAS-Port-Id attribute. Configure the format of the NAS-Port-Id attribute to meet the requirements of the RADIUS servers.

The format of the NAS-Port-Id attribute configured by using the attribute 87 format command takes precedence over the format defined by the access module.

Procedure

1. Enter system view.

system-view

2. (Optional.) Configure the device to use uppercase string VLANID in the RADIUS NAS-Port-Id attribute instead of lowercase string vlanid.

aaa nas-port-id vlanid uppercase

By default, the device uses lowercase string vlanid in the RADIUS NAS-Port-Id attribute.

3. Enter RADIUS scheme view.

radius scheme radius-scheme-name

4. Configure the format of RADIUS attribute 87.

attribute 87 format { custom { c-vid [ delimiter ] | interface-type [ delimiter ] | port [ delimiter ] | s-vid [ delimiter ] | slot [ delimiter ] | string string [ delimiter ] | subslot [ delimiter ] | vxlan-id [ delimiter ] } * | vendor vendor-id }

By default, no format is configured for RADIUS attribute 87 and the device uses the attribute format defined by each access module. For more information about the attribute 87 formats defined by access modules, see AAA commands in Security Command Reference.

Setting the data measurement unit for the Remanent_Volume attribute

About this task

The RADIUS server uses the Remanent_Volume attribute in authentication or real-time accounting responses to notify the device of the current amount of data available for online users.

Restrictions and guidelines

Make sure the configured measurement unit is the same as the user data measurement unit on the RADIUS server.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Set the data measurement unit for the Remanent_Volume attribute.

attribute remanent-volume unit { byte | giga-byte | kilo-byte | mega-byte }

By default, the data measurement unit is kilobyte.

Specifying a server version for interoperating with servers with a vendor ID of 2011

Restrictions and guidelines

For the device to correctly interpret RADIUS attributes from the servers with a vendor ID of 2011, specify a server version that is the same as the version of the RADIUS servers.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Specify a server version for interoperating with servers with a vendor ID of 2011.

attribute vendor-id 2011 version { 1.0 | 1.1 }

By default, version 1.0 is used.

Configuring the RADIUS attribute translation feature

About this task

The RADIUS attribute translation feature enables the device to work correctly with the RADIUS servers of different vendors that support RADIUS attributes incompatible with the device.

RADIUS attribute translation has the following implementations:

· Attribute conversion—Converts source RADIUS attributes into destination RADIUS attributes based on RADIUS attribute conversion rules.

· Attribute rejection—Rejects RADIUS attributes based on RADIUS attribute rejection rules.

When the RADIUS attribute translation feature is enabled, the device processes RADIUS packets as follows:

· For the sent RADIUS packets:

¡ Deletes the rejected attributes from the packets.

¡ Uses the destination RADIUS attributes to replace the attributes that match RADIUS attribute conversion rules in the packets.

· For the received RADIUS packets:

¡ Ignores the rejected attributes in the packets.

¡ Interprets the attributes that match RADIUS attribute conversion rules as the destination RADIUS attributes.

To identify proprietary RADIUS attributes, you can define the attributes as extended RADIUS attributes, and then convert the extended RADIUS attributes to device-supported attributes.

Restrictions and guidelines for RADIUS attribute translation configuration

Configure either conversion rules or rejection rules for a RADIUS attribute.

Configure either direction-based rules or packet type-based rules for a RADIUS attribute.

For direction-based translation of a RADIUS attribute, you can configure a rule for each direction (inbound or outbound). For packet type-based translation of a RADIUS attribute, you can configure a rule for each RADIUS packet type (RADIUS Access-Accept, RADIUS Access-Request, or RADIUS accounting).

Configuring the RADIUS attribute translation feature for a RADIUS scheme

1. Enter system view.

system-view

2. (Optional.) Define an extended RADIUS attribute.

radius attribute extended attribute-name [ vendor vendor-id ] code attribute-code type { binary | date | integer | interface-id | ip | ipv6 | ipv6-prefix | octets | string }

3. Enter RADIUS scheme view.

radius scheme radius-scheme-name

4. Enable the RADIUS attribute translation feature.

attribute translate

By default, this feature is disabled.

5. Configure a RADIUS attribute conversion rule or a RADIUS attribute reject rule. Choose the following tasks as needed:

¡ Configure a RADIUS attribute conversion rule.

attribute convert src-attr-name to dest-attr-name { { access-accept | access-request | accounting } * | { received | sent } * }

By default, no RADIUS attribute conversion rules are configured.

¡ Configure a RADIUS attribute rejection rule.

attribute reject attr-name { { access-accept | access-request | accounting } * | { received | sent } * }

By default, no RADIUS attribute rejection rules are configured.

Configuring the RADIUS attribute translation feature for a RADIUS DAS

1. Enter system view.

system-view

2. (Optional.) Define an extended RADIUS attribute.

radius attribute extended attribute-name [ vendor vendor-id ] code attribute-code type { binary | date | integer | interface-id | ip | ipv6 | ipv6-prefix | octets | string }

3. Enter RADIUS DAS view.

radius dynamic-author server [ port port-number ]

You can specify the RADIUS DAS port by using this command in system view or by using the port port-number command in RADIUS DAS view. The two configurations have the same priority and the most recent configuration takes effect.

4. Enable the RADIUS attribute translation feature.

attribute translate

By default, this feature is disabled.

5. Configure a RADIUS attribute conversion rule or a RADIUS attribute rejection rule. Choose the following tasks as needed:

¡ Configure a RADIUS attribute conversion rule.

attribute convert src-attr-name to dest-attr-name { { coa-ack | coa-request } * | { received | sent } * }

By default, no RADIUS attribute conversion rules are configured.

¡ Configure a RADIUS attribute rejection rule.

attribute reject attr-name { { coa-ack | coa-request } * | { received | sent } * }

By default, no RADIUS attribute rejection rules are configured.

Specifying the action to take for AAA requests if all RADIUS servers are blocked

About this task

If all servers in a RADIUS scheme are blocked, the device takes one of the following actions upon receiving AAA requests in the domain that uses the scheme:

· attempt—Attempts to connect to a server (except for servers set in block state manually) in the scheme. For more information about the RADIUS server selection mechanism, see "Setting the status of RADIUS servers."

· skip—Skips all servers in the scheme and turns to the backup method.

The attempt action gives the device a chance to use the scheme in case the server with the highest priority in the scheme might be available. However, the attempt to communicate with an unavailable server increases the response time for AAA requests. As a best practice, specify the skip action in scenarios that require quick responses to AAA requests.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Specify the action to take for AAA requests if all servers in the scheme are blocked.

server-block-action { attempt | skip }

By default, the attempt action applies.

Configuring RADIUS stop-accounting packet buffering

About this task

The device sends RADIUS stop-accounting requests when it receives connection teardown requests from hosts or connection teardown commands from an administrator. However, the device might fail to receive a response for a stop-accounting request in a single transmission. Enable the device to buffer RADIUS stop-accounting requests that have not received responses from the accounting server. The device will resend the requests until responses are received.

To limit the transmission times, set a maximum number of transmission attempts that can be made for individual RADIUS stop-accounting requests. When the maximum attempts are made for a request, the device discards the buffered request.

To reduce resource consumption caused by buffered RADIUS stop-accounting requests, you can limit the number of RADIUS stop-accounting requests that can be buffered. As a best practice, set the limit to a suitable value on an unstable network where users might go offline concurrently within a short time.

When the number of buffered stop-accounting requests reaches the upper limit or a minor memory alarm is generated, the device processes new stop-accounting requests in one of the following ways:

· Stop buffering new stop-accounting requests. This method provides accurate accounting for users that go offline earlier.

· Use a new stop-accounting request to overwrite the oldest one. This method provides accurate accounting for users that go offline later.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Enable buffering of RADIUS stop-accounting requests to which no responses have been received.

stop-accounting-buffer enable

By default, the buffering feature is enabled.

4. (Optional.) Set the maximum number of transmission attempts for individual RADIUS stop-accounting requests.

retry stop-accounting retries

The default setting is 500.

5. Return to system view.

quit

6. Set the maximum number of RADIUS stop-accounting packets that can be buffered.

radius stop-accounting-buffer cache max-packet-number

By default, the device can buffer a maximum of 256000 RADIUS stop-accounting packets.

7. Enable a new stop-accounting request to overwrite the oldest one when the number of buffered stop-accounting requests reaches the upper limit or a minor memory alarm is generated.

radius stop-accounting-buffer { exceed | memory-minor-threshold } overwrite-oldest

By default, when the number of buffered stop-accounting requests reaches the upper limit or a minor memory alarm is generated, the device stops buffering new stop-accounting requests.

Enabling forcibly sending RADIUS stop-accounting packets

About this task

Typically, if the device does not send a RADIUS start-accounting packet to the RADIUS server for an authenticated user, it does not send a RADIUS stop-accounting packet when the user goes offline. If the RADIUS server has generated a user entry for the user without start-accounting packets, it does not release the user entry when the user goes offline. This feature forces the device to send RADIUS stop-accounting packets to the RADIUS server when the user goes offline for timely releasing the user entry on the server.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Enable the device to send RADIUS stop-accounting packets when users for which no RADIUS start-accounting packets are sent go offline.

stop-accounting-packet send-force

By default, forcibly sending RADIUS stop-accounting packets is disabled. The device does not send RADIUS stop-accounting packets when users for which no RADIUS start-accounting packets are sent go offline.

Enabling the RADIUS server load sharing feature

About this task

By default, the device communicates with RADIUS servers based on the server roles. It first attempts to communicate with the primary server, and, if the primary server is unreachable, it then searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication. In this process, the workload is always placed on one active server.

Use the RADIUS server load sharing feature to dynamically distribute the workload over multiple servers based on their weight values and number of currently served users.

The device supports the following load sharing modes for RADIUS authentication servers:

· Session-based mode—The device forwards a RADIUS authentication request to the most appropriate server among all servers in the scheme after it compares their weights and number of concurrent active sessions.

Each time the device sends an authentication request to a server, the number of concurrent sessions to that server increases by one. Each time the device receives an authentication response from a server, the number of concurrent sessions to that server decreases by one.

This mode is applicable if the number of concurrent sessions on the network is large and the servers have similar performance.

· Packet-based mode—The device forwards a RADIUS authentication request to the most appropriate server among all servers in the scheme after it compares their weights and number of received authentication requests.

Each time the device sends an authentication request to a server, the number of received packets to that server increases by one.

To evenly distribute authentication requests to all active servers in the scheme, specify the packet-based RADIUS server load sharing mode.

In RADIUS server load sharing, once the device sends a start-accounting request to a server for a user, it forwards all subsequent accounting requests of the user to the same server. If the accounting server is unreachable, the device returns an accounting failure message rather than searching for another active accounting server.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Enable the RADIUS server load sharing feature.

server-load-sharing enable

By default, this feature is disabled.

4. Specify the RADIUS authentication server load sharing mode.

server-load-sharing mode { packet-based | session-based }

By default, the session-based RADIUS authentication server load sharing mode is used.

Configuring the RADIUS accounting-on feature

About this task

When the accounting-on feature is enabled, the device automatically sends an accounting-on packet to the RADIUS server after the entire device reboots. Upon receiving the accounting-on packet, the RADIUS server logs out all online users so they can log in again through the device. Without this feature, users cannot log in again after the reboot, because the RADIUS server considers them to come online.

You can configure the interval for which the device waits to resend the accounting-on packet and the maximum number of retries.

The extended accounting-on feature enhances the accounting-on feature in a distributed architecture.

The extended accounting-on feature is applicable to LAN users. The user data is saved to the cards through which the users access the device. When the extended accounting-on feature is enabled, the device automatically sends an accounting-on packet to the RADIUS server after a card reboots. The packet contains the card identifier. Upon receiving the accounting-on packet, the RADIUS server logs out all online users that access the device through the card. If no users have come online through the card, the device does not send an accounting-on packet to the RADIUS server after the card reboots.

Restrictions and guidelines

For the extended accounting-on feature to take effect, the RADIUS server must run on IMC and the accounting-on feature must be enabled.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Enable accounting-on.

accounting-on enable [ interval interval | send send-times ] *

By default, the accounting-on feature is disabled.

4. (Optional.) Enable extended accounting-on.

accounting-on extended

By default, extended accounting-on is disabled.

Configuring the RADIUS session-control feature

About this task

Enable this feature for the RADIUS server to dynamically change the user authorization information or forcibly disconnect users by using session-control packets. This task enables the device to receive RADIUS session-control packets on UDP port 1812.

To verify the session-control packets sent from a RADIUS server, specify the RADIUS server as a session-control client to the device.

By default, the RADIUS proxy feature uses UDP port 1812 to listen for authentication request packets. To use both RADIUS proxy and RADIUS session-control, make sure the two features use different UDP ports to listen for packets.

Restrictions and guidelines

The RADIUS session-control feature can only work with RADIUS servers running on IMC. The session-control client configuration takes effect only when the session-control feature is enabled.

Procedure

1. Enter system view.

system-view

2. Enable the session-control feature.

radius session-control enable

By default, the session-control feature is disabled.

3. Specify a session-control client.

radius session-control client { ip ipv4-address | ipv6 ipv6-address } [ key { cipher | simple } string | vpn-instance vpn-instance-name ] *

By default, no session-control clients are specified.

Configuring the RADIUS DAS feature

About this task

Dynamic Authorization Extensions (DAE) to RADIUS, defined in RFC 5176, can log off online users, change their authorization information, or shut down and then bring up their access interfaces. DAE uses the client/server model.

In a RADIUS network, the RADIUS server typically acts as the DAE client (DAC) and the NAS acts as the DAE server (DAS).

DAE defines the following types of packets:

· Disconnect Messages (DMs)—The DAC sends DM requests to the DAS to log off specific online users.

In PPPoE agency dialup, the NAS device sends DM requests to the RADIUS server to notify the agency dialup results. Possible results include:

¡ PPPoEA user comes online successfully.

¡ PPPoEA user fails to come online.

¡ PPPoEA user goes offline.

· Change of Authorization Messages (CoA Messages)—The DAC sends CoA requests to the DAS for the following purposes:

¡ Change the authorization information of specific online users.

¡ Shut down and then bring up the access interfaces of users.

When the RADIUS DAS feature is enabled, the NAS performs the following operations:

1. Listens to the default or specified UDP port to receive DAE requests.

2. Searches for matching users.

3. Logs off matching online users, changes their authorization information, or shuts down and then brings up their access interfaces.

4. Sends DAE responses to the DAC.

The NAS searches for matching users based on the user identification information and device identification information in DAE requests. (The user identification information includes the username, user IP address, EDSG service policy name, Acct-Session-Id, and Acct-Multi-Session-Id.) If matching users are found, the NAS logs out the users or changes the authorization information for the users. If no matching users are found, the NAS replies with a NAK message. When DAE loose check is enabled, the NAS checks only the user IP address, Acct-Session-Id, and Acct-Multi-Session-Id in a DAE request.

Restrictions and guidelines

When the device acts as both the DAS and the DAE proxy, make sure different UDP port numbers are used by the DAS and the DAE proxy to listen for DAE requests from DACs. This restriction ensures that DAE requests from DACs are correctly received and processed by the DAS or the DAE proxy. For more information about the DAE proxy, see configuring DAE proxy in Security Configuration Guide.

In PPPoE agency dialup, the destination port number of DM requests sent by the device must be the number of the port to which the RADIUS server listens for DAE requests.

Procedure

1. Enter system view.

system-view

2. Enable the RADIUS DAS feature and enter RADIUS DAS view.

radius dynamic-author server

By default, the RADIUS DAS feature is disabled.

3. Specify a RADIUS DAC.

client { ip ipv4-address | ipv6 ipv6-address } [ key { cipher | simple } string | vendor-id 2011 version { 1.0 | 1.1 } | vpn-instance vpn-instance-name ] *

By default, no RADIUS DACs are specified.

4. (Optional.) Specify the RADIUS DAS port.

port port-number

By default, the RADIUS DAS port is 3799.

5. (Optional.) Configure a trusted DAC.

IPv4:

trust ip ipv4-address [ vpn-instance vpn-instance-name ]

IPv6:

trust ipv6 ipv6-address [ vpn-instance vpn-instance-name ]

By default, no trusted DACs are configured.

6. (Optional.) Enable DAE loose check.

dae-loose-check enable

By default, DAE loose check is disabled.

As a best practice to avoid unnecessary drop of DAE requests, enable this feature when the user and device identification information on DACs are inconsistent with those on the DAS.

7. (Optional.) Specify the destination port to which the server listens for agency dialup responses in PPPoE agency dialup.

pppoe-agency reply-port port-number

By default, the server listens to port 3799 for agency dialup responses in PPPoE agency dialup.

Configuring the device to preferentially process RADIUS authentication requests

About this task

RADIUS requests include RADIUS authentication requests, RADIUS accounting-start requests, RADIUS accounting-update requests, and RADIUS accounting-stop requests. By default, the device processes the RADIUS requests in the sequence that the requests are initiated.

When a large number of users go offline and then try to come online immediately, authentication might fail for these users because of authentication request timeout. To resolve this issue, configure the device to preferentially process authentication requests.

Restrictions and guidelines

Do not perform this task if the RADIUS server identifies users by the username and does not allow repeated authentication for the same username. A violation might cause authentication failure for users that try to come online immediately after going offline.

As a best practice, do not perform this task when the device has online users.

Procedure

1. Enter system view.

system-view

2. Configure the device to preferentially process RADIUS authentication requests.

radius authentication-request first

By default, the device processes RADIUS requests in the sequence that the requests are initiated.

Setting the available data threshold

About this task

Perform this task if the RADIUS server divides the total data quota of an authenticated user into multiple equal portions and assigns one portion to the user each time. When the user's available data on the device reaches the threshold, the device sends a real-time accounting request to the RADIUS server to apply for a new data portion. This process continues till the user uses up the total data quota.

Restrictions and guidelines

The unit for the available data threshold is determined by using the attribute remanent-volume unit command.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Set the available data threshold.

threshold remanent-volume threshold-value

By default, the available data threshold is 0.

Using server-assigned usernames for AAA processes subsequent to authentication

About this task

A RADIUS server might add the User-Name attribute in an Access-Accept response. This feature enables the device to notify the access module of the User-Name attribute and use the server-assigned username for AAA processes subsequent to authentication. For example, the device includes the username in start-accounting requests sent to the RADIUS server and displays the username in command output instead of the username used in authentication.

The username assigned by the RADIUS server is different from the username used in authentication. How a server-assigned username is encapsulated in the RADIUS User-Name attribute by the device depends on the username format configuration in the RADIUS scheme.

· If the username format is keep-original, the username is encapsulated without any change.

· If the username format is without-domain, the username is encapsulated without any domain name.

· If the username format is with-domain, the username is encapsulated with the authentication domain name. If the server-assigned username contains a domain name other than the authentication domain name, the device replaces the domain name with the authentication domain name.

Restrictions and guidelines

This feature takes effect only on IPoE users.

Procedure

1. Enter system view.

system-view

2. Enter RADIUS scheme view.

radius scheme radius-scheme-name

3. Configure the device to use server-assigned usernames for AAA processes subsequent to authentication.

username-authorization apply

By default, the device uses the usernames used in authentication for AAA processes subsequent to authentication.

Enabling offline reason conversion for PPP users

About this task

This feature is applicable only to PPP users. It enables the device to convert user offline reason Lost Carrier (handshake failure) to User Request in RADIUS packets sent to the RADIUS server.

Restrictions and guidelines

Use this feature only to meet the definitions and requirements of user offline reasons determined by the RADIUS server.

This feature does not change the user offline reasons in user offline records displayed on the device.

Procedure

1. Enter system view.

system-view

2. Enable offline reason conversion for PPP users.

radius offline-reason-convert user-type ppp

By default, offline reason conversion is disabled for PPP users.

Enabling SNMP notifications for RADIUS

About this task

When SNMP notifications are enabled for RADIUS, the SNMP agent supports the following notifications generated by RADIUS:

· Minor memory alarm notification—A minor memory alarm is generated and the system starts to discard buffered stop-accounting requests or requests to be buffered.

· Notification for approaching of the stop-accounting request buffer upper limit—The number of buffered stop-accounting requests reaches a certain percent of the maximum number (radius stop-accounting-buffer cache).

¡ If the alarm triggering threshold is reached for the first time or the proportion increases from a value below the alarm clearing threshold to the alarm triggering threshold (upper-threshold), a threshold exceeding alarm is generated.

¡ If the proportion drops below the alarm clearing threshold (lower-threshold), an alarm removal notification is generated.

· RADIUS server unreachable notification—The RADIUS server cannot be reached. RADIUS generates this notification if it does not receive a response to an accounting or authentication request within the specified number of RADIUS request transmission attempts.

· RADIUS server reachable notification—The RADIUS server can be reached. RADIUS generates this notification for a previously blocked RADIUS server after the quiet timer expires.

· Excessive authentication failures notification—The number of authentication failures compared to the total number of authentication attempts exceeds the specified threshold.

For RADIUS SNMP notifications to be sent correctly, you must also configure SNMP on the device. For more information about SNMP configuration, see Network Management and Monitoring Configuration Guide.

Restrictions and guidelines

Make sure the RADIUS server status change notifications sent by the device can be recognized by the NMS. Choose a MIB node version depending on the NMS requirements. For more information about the MIB node versions, see AAA in Security Command Reference.

Procedure

1. Enter system view.

system-view

2. Enable SNMP notifications for RADIUS.

By default, all SNMP notifications are disabled for RADIUS.

3. Set the version of RADIUS server status change MIB nodes.

radius trap-version { v1 | v2 } [ accounting-server-down | accounting-server-up | authentication-server-down | authentication-server-up ] *

By default, the device sends notifications about RADIUS server status change MIB nodes over SNMPv1.

4. (Optional.) Set the alarm triggering threshold and alarm clearing threshold for the stop-accounting request buffer.

radius stop-accounting-buffer warning-threshold upper upper-threshold lower lower-threshold

By default, no threshold is configured for the stop-accounting request buffer.

Display and maintenance commands for RADIUS

Execute display commands in any view and reset commands in user view.

Task	Command
Display the RADIUS scheme configuration.	display radius scheme [ radius-scheme-name ]
Display authentication and accounting load statistics for all RADIUS servers.	display radius server-load statistics
Display RADIUS packet statistics.	display radius statistics [ server { ip ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ port port-number ] { accounting \| authentication } ]
Display information about buffered RADIUS stop-accounting requests to which no responses have been received.	display stop-accounting-buffer { radius-scheme radius-scheme-name \| session-id session-id \| time-range start-time end-time \| user-name user-name }
Clear history authentication and accounting load statistics for all RADIUS servers.	reset radius server-load statistics
Clear RADIUS packet statistics.	reset radius statistics [ server { ip ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ port port-number ] { accounting \| authentication } ]
Clear the buffered RADIUS stop-accounting requests to which no responses have been received.	reset stop-accounting-buffer { radius-scheme radius-scheme-name \| session-id session-id \| time-range start-time end-time \| user-name user-name }

Configuring HWTACACS

HWTACACS tasks at a glance

To configure HWTACACS, perform the following tasks:

1. Creating an HWTACACS scheme

2. Specifying the HWTACACS authentication servers

3. Specifying the HWTACACS authorization servers

4. Specifying the HWTACACS accounting servers

5. Specifying the shared keys for secure HWTACACS communication

Perform this task if no shared keys are specified when configuring HWTACACS servers.

6. Specifying an MPLS L3VPN instance for the scheme

Perform this task if no MPLS L3VPN instances are specified when configuring HWTACACS servers.

7. (Optional.) Setting HWTACACS timers

8. (Optional.) Configuring parameters for HWTACACS packets

¡ Specifying the source IP address of outgoing HWTACACS packets

¡ Setting the username format and traffic statistics units

9. (Optional.) Configuring HWTACACS stop-accounting packet buffering

10. (Optional.) Changing user passwords stored on HWTACACS servers

Creating an HWTACACS scheme

Restrictions and guidelines

You can configure a maximum of 16 HWTACACS schemes. An HWTACACS scheme can be used by multiple ISP domains.

Procedure

1. Enter system view.

system-view

2. Create an HWTACACS scheme and enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

Specifying the HWTACACS authentication servers

About this task

You can specify one primary authentication server and a maximum of 16 secondary authentication servers for an HWTACACS scheme. When the primary server is unreachable, the device searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.

Restrictions and guidelines

If redundancy is not required, specify only the primary server.

An HWTACACS server can function as the primary authentication server in one scheme and as the secondary authentication server in another scheme at the same time.

Two HWTACACS authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address, VPN instance, and port number.

Procedure

1. Enter system view.

system-view

2. Enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

3. Specify the primary HWTACACS authentication server.

primary authentication { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | single-connection | vpn-instance vpn-instance-name ] *

By default, no primary HWTACACS authentication server is specified.

4. (Optional.) Specify a secondary HWTACACS authentication server.

secondary authentication { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | single-connection | vpn-instance vpn-instance-name ] *

By default, no secondary HWTACACS authentication servers are specified.

Specifying the HWTACACS authorization servers

About this task

You can specify one primary authorization server and a maximum of 16 secondary authorization servers for an HWTACACS scheme. When the primary server is not available, the device searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.

Restrictions and guidelines

If redundancy is not required, specify only the primary server.

An HWTACACS server can function as the primary authorization server of one scheme and as the secondary authorization server of another scheme at the same time.

Two HWTACACS authorization servers in a scheme, primary or secondary, cannot have the same combination of IP address, VPN instance, and port number.

Procedure

1. Enter system view.

system-view

2. Enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

3. Specify the primary HWTACACS authorization server.

primary authorization { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | single-connection | vpn-instance vpn-instance-name ] *

By default, no primary HWTACACS authorization server is specified.

4. (Optional.) Specify a secondary HWTACACS authorization server.

secondary authorization { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | single-connection | vpn-instance vpn-instance-name ] *

By default, no secondary HWTACACS authorization servers are specified.

Specifying the HWTACACS accounting servers

About this task

You can specify one primary accounting server and a maximum of 16 secondary accounting servers for an HWTACACS scheme. When the primary server is not available, the device searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.

Restrictions and guidelines

If redundancy is not required, specify only the primary server.

An HWTACACS server can function as the primary accounting server of one scheme and as the secondary accounting server of another scheme at the same time.

Two HWTACACS accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address, VPN instance, and port number.

HWTACACS does not support accounting for FTP, SFTP, and SCP users.

Procedure

1. Enter system view.

system-view

2. Enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

3. Specify the primary HWTACACS accounting server.

primary accounting { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | single-connection | vpn-instance vpn-instance-name ] *

By default, no primary HWTACACS accounting server is specified.

4. (Optional.) Specify a secondary HWTACACS accounting server.

secondary accounting { ipv4-address | ipv6 ipv6-address } [ port-number | key { cipher | simple } string | single-connection | vpn-instance vpn-instance-name ] *

By default, no secondary HWTACACS accounting servers are specified.

Specifying the shared keys for secure HWTACACS communication

About this task

The HWTACACS client and server use the MD5 algorithm and shared keys to generate the Authenticator value for packet authentication and user password encryption. The client and server must use the same key for each type of communication.

Perform this task to configure shared keys for servers in an HWTACACS scheme. The keys take effect on all servers for which a shared key is not individually configured.

Restrictions and guidelines

Make sure the shared key configured on the device is the same as the shared key configured on the HWTACACS server.

Procedure

1. Enter system view.

system-view

2. Enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

3. Specify a shared key for secure HWTACACS authentication, authorization, or accounting communication.

key { accounting | authentication | authorization } { cipher | simple } string

By default, no shared key is specified for secure HWTACACS communication.

Specifying an MPLS L3VPN instance for the scheme

About this task

The VPN instance specified for an HWTACACS scheme applies to all servers in that scheme. If a VPN instance is also configured for an individual HWTACACS server, the VPN instance specified for the HWTACACS scheme does not take effect on that server.

Procedure

1. Enter system view.

system-view

2. Enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

3. Specify a VPN instance for the HWTACACS scheme.

vpn-instance vpn-instance-name

By default, an HWTACACS scheme belongs to the public network.

Setting HWTACACS timers

About this task

The device uses the following timers to control communication with an HWTACACS server:

· Server response timeout timer (response-timeout)—Defines the HWTACACS server response timeout timer. The device starts this timer immediately after an HWTACACS authentication, authorization, or accounting request is sent. If the device does not receive a response from the server within the timer, it sets the server to blocked. Then, the device sends the request to another HWTACACS server.

· Real-time accounting timer (realtime-accounting)—Defines the interval at which the device sends real-time accounting packets to the HWTACACS accounting server for online users.

· Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If a server is not reachable, the device changes the server status to blocked, starts this timer for the server, and tries to communicate with another server in active state. After the server quiet timer expires, the device changes the status of the server back to active.

The server quiet timer setting affects the status of HWTACACS servers. If the scheme includes one primary HWTACACS server and multiple secondary HWTACACS servers, the device communicates with the HWTACACS servers based on the following rules:

· When the primary server is in active state, the device communicates with the primary server. When the primary server is unreachable, the device researches a secondary server in active status in the order they are configured.

· When one or more servers are in active state, the device tries to communicate with these servers only, even if they are unreachable.

· When all servers are in blocked state, the device only tries to communicate with the primary server.

· If the primary server is unreachable, the device changes the server status to blocked and starts a quiet timer for the server. When the quiet timer of the server expires, the status of the server changes back to active. The device does not check the server again during the authentication, authorization, or accounting process.

· The search process continues until the device finds an available secondary server or has checked all secondary servers in active state. If no server is available, the device considers the authentication, authorization, or accounting attempt a failure.

· When an HWTACACS server's status changes automatically, the device changes this server's status accordingly in all HWTACACS schemes in which this server is specified.

Restrictions and guidelines

A short real-time accounting interval helps improve accounting precision but requires many system resources. When there are 1000 or more users, set a real-time accounting interval longer than 15 minutes.

Procedure

1. Enter system view.

system-view

2. Enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

3. Set the HWTACACS timers. Choose the following tasks as needed:

¡ Set the HWTACACS server response timeout timer.

timer response-timeout seconds

By default, the HWTACACS server response timeout timer is 5 seconds.

¡ Set the real-time accounting interval.

timer realtime-accounting minutes

By default, the real-time accounting interval is 12 minutes.

¡ Set the server quiet timer.

timer quiet minutes

By default, the server quiet timer is 5 minutes.

Specifying the source IP address of outgoing HWTACACS packets

About this task

The source IP address of HWTACACS packets that a NAS sends must match the IP address of the NAS configured on the HWTACACS server. An HWTACACS server identifies a NAS by IP address. When the HWTACACS server receives a packet, it checks the source IP address of the packet.

· If the IP address belongs to a managed NAS, the server processes the packet.

· If the IP address does not belong to a managed NAS, the server drops the packet.

Before sending an HWTACACS packet, the NAS selects a source IP address in the following order:

1. The source IP address specified for the HWTACACS scheme.

2. The source IP address specified in system view for the VPN or public network, depending on where the HWTACACS server resides.

3. The IP address of the outbound interface specified by the route.

Restrictions and guidelines for source IP address configuration

You can specify the source IP address of outgoing HWTACACS packets in HWTACACS scheme view or in system view.

· The IP address specified in HWTACACS scheme view applies to one HWTACACS scheme.

· The IP address specified in system view applies to all HWTACACS schemes whose servers are in a VPN or the public network.

The source IP address of HWTACACS packets that a NAS sends must match the IP address of the NAS that is configured on the HWTACACS server.

As a best practice to avoid HWTACACS packet loss caused by physical port errors, specify a loopback interface address as the source IP address of outgoing HWTACACS packets.

To communicate with the HWTACACS server, the source address of outgoing HWTACACS packets is typically the IP address of an egress interface on the NAS.

Specifying a source IP address for outgoing HWTACACS packets in system view

1. Enter system view.

system-view

2. Specify a source IP address for outgoing HWTACACS packets.

hwtacacs nas-ip { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ]

By default, the primary IP address of the HWTACACS packet outbound interface is used as the source IP address.

Specifying a source IP address for outgoing HWTACACS packets in HWTACACS scheme view

1. Enter system view.

system-view

2. Enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

3. Specify the source IP address of outgoing HWTACACS packets.

nas-ip { ipv4-address | ipv6 ipv6-address }

By default, the source IP address specified by using the hwtacacs nas-ip command in system view is used. If the source IP address is not specified, the primary IP address of the outbound interface is used.

Setting the username format and traffic statistics units

About this task

A username is typically in the userid@isp-name format, where the isp-name part represents the user's ISP domain name. By default, the ISP domain name is included in a username. If HWTACACS servers do not recognize usernames that contain ISP domain names, you can configure the device to send usernames without domain names to the servers.

The device reports online user traffic statistics in accounting packets.

Restrictions and guidelines

If two or more ISP domains use the same HWTACACS scheme, configure the HWTACACS scheme to keep the ISP domain name in usernames for domain identification.

For accounting accuracy, make sure the traffic measurement units configured on the device are the same as the traffic measurement units configured on the HWTACACS accounting servers.

Procedure

1. Enter system view.

system-view

2. Enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

3. Set the format of usernames sent to the HWTACACS servers.

user-name-format { keep-original | with-domain | without-domain }

By default, the ISP domain name is included in a username.

4. Set the data flow and packet measurement units for traffic statistics.

data-flow-format { data { byte | giga-byte | kilo-byte | mega-byte } | packet { giga-packet | kilo-packet | mega-packet | one-packet } }*

By default, traffic is counted in bytes and packets.

Configuring HWTACACS stop-accounting packet buffering

About this task

The device sends HWTACACS stop-accounting requests when it receives connection teardown requests from hosts or connection teardown commands from an administrator. However, the device might fail to receive a response for a stop-accounting request in a single transmission. Enable the device to buffer HWTACACS stop-accounting requests that have not received responses from the accounting server. The device will resend the requests until responses are received.

To limit the transmission times, set a maximum number of attempts that can be made for transmitting individual HWTACACS stop-accounting requests. When the maximum attempts are made for a request, the device discards the buffered request.

Procedure

1. Enter system view.

system-view

2. Enter HWTACACS scheme view.

hwtacacs scheme hwtacacs-scheme-name

3. Enable buffering of HWTACACS stop-accounting requests to which no responses have been received.

stop-accounting-buffer enable

By default, the buffering feature is enabled.

4. (Optional.) Set the maximum number of transmission attempts for individual HWTACACS stop-accounting requests.

retry stop-accounting retries

The default setting is 100.

Changing user passwords stored on HWTACACS servers

About this task

To change user passwords stored on remote HWTACACS authentication servers without logging in to them, perform this task.

You can configure the device to change user passwords on a specified authentication server, the first reachable authentication server, or all authentication servers in an HWTACACS scheme.

The device attempts to connect to each of the specified servers for you to change passwords. If a server is reachable, the device prompts you for the username and old password of a target user account, the new password, and confirmation of the new password. Then, the device sends this information to the server for a password change. This process differs slightly depending on the server parameters specified for the command:

· If you specify a particular server in an HWTACACS scheme, the device communicates only with that server for password change.

· If you specify the first reachable authentication server in an HWTACACS scheme, the device attempts to connect to the first authentication server in the HWTACACS scheme. If that server is reachable, the device communicates with that server for password change. If that server is not reachable, the device tries the next authentication server in the HWTACACS scheme. This process continues until one reachable authentication server is found or all the authentication servers in the HWTACACS scheme are exhausted.

· If you specify all the authentication servers in an HWTACACS scheme, the device connects to each of the servers for password change. After password change succeeds on one server, the device prompts you to choose whether you want to proceed with the next server.

¡ If you choose to proceed or does not make a choice within 3 seconds, the device tries the next server for a password change based on the provided user information.

¡ If you choose to not proceed further within 3 seconds, the password change process closes.

Likewise, if a server is not reachable or password change fails on a server, the device prompts you to choose whether you want to skip the server and proceed further.

Restrictions and guidelines

To execute this command, you must log in to the device through HWTACACS authentication. All HWTACACS authenticated users can change the passwords for their own user accounts. To change passwords for other HWTACACS users, you must have the network-admin or level-15 user role.

To execute this command successfully, make sure the specified server parameters are consistent with the settings for the specified HWTACACS scheme.

If the password for the target user account has expired, you will receive a password expired message from the server and will be unable to change the password.

Enter the username and password information at the prompt within 30 seconds. If you fail to do that, the password change process automatically terminates.

Procedure

To change user passwords stored on HWTACACS servers, execute the following command in user view:

hwtacacs-user change-password hwtacacs-scheme hwtacacs-scheme-name { all-servers | first-server | server-ip { ipv4-address | ipv6 ipv6-address } [ port-number | vpn-instance vpn-instance-name ] * }

To terminate a password change process, press Ctrl+C.

Display and maintenance commands for HWTACACS

Execute display commands in any view and reset commands in user view.

Task	Command
Display the configuration or server statistics of HWTACACS schemes.	display hwtacacs scheme [ hwtacacs-scheme-name [ statistics ] ]
Display information about buffered HWTACACS stop-accounting requests to which no responses have been received.	display stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name
Clear HWTACACS statistics.	reset hwtacacs statistics { accounting \| all \| authentication \| authorization }
Clear the buffered HWTACACS stop-accounting requests to which no responses have been received.	reset stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name

Configuring LDAP

LDAP tasks at a glance

To configure LDAP, perform the following tasks:

1. Configuring an LDAP server

a. Creating an LDAP server

b. Configuring the IP address of the LDAP server

c. (Optional.) Specifying the LDAP version

d. (Optional.) Setting the LDAP server timeout period

e. Configuring administrator attributes

f. Configuring LDAP user attributes

2. (Optional.) Configuring an LDAP attribute map

3. Creating an LDAP scheme

4. Specifying the LDAP authentication server

5. (Optional.) Specifying the LDAP authorization server

6. (Optional.) Specifying an LDAP attribute map for LDAP authorization

Creating an LDAP server

1. Enter system view.

system-view

2. Create an LDAP server and enter LDAP server view.

ldap server server-name

Configuring the IP address of the LDAP server

Restrictions and guidelines

You can configure either an IPv4 address or an IPv6 address for an LDAP server. If you configure the IP address for an LDAP server multiple times, the most recent configuration takes effect.

Procedure

1. Enter system view.

system-view

2. Enter LDAP server view.

ldap server server-name

3. Configure the IP address of the LDAP server.

{ ip ip-address | ipv6 ipv6-address } [ port port-number ] [ vpn-instance vpn-instance-name ]

By default, an LDAP server does not have an IP address.

Specifying the LDAP version

Restrictions and guidelines

The device supports LDAPv2 and LDAPv3.

A Microsoft LDAP server supports only LDAPv3.

The LDAP version specified on the device must be consistent with the version specified on the LDAP server.

Procedure

1. Enter system view.

system-view

2. Enter LDAP server view.

ldap server server-name

3. Specify the LDAP version.

protocol-version { v2 | v3 }

By default, LDAPv3 is used.

Setting the LDAP server timeout period

About this task

If the device sends a bind or search request to an LDAP server without receiving the server's response within the server timeout period, the authentication or authorization request times out. Then, the device tries the backup authentication or authorization method. If no backup method is configured in the ISP domain, the device considers the authentication or authorization attempt a failure.

Procedure

1. Enter system view.

system-view

2. Enter LDAP server view.

ldap server server-name

3. Set the LDAP server timeout period.

server-timeout time-interval

By default, the LDAP server timeout period is 10 seconds.

Configuring administrator attributes

About this task

To configure the administrator DN and password for binding with the LDAP server during LDAP authentication:

Procedure

1. Enter system view.

system-view

2. Enter LDAP server view.

ldap server server-name

3. Specify the administrator DN.

By default, no administrator DN is specified.

The administrator DN specified on the device must be the same as the administrator DN configured on the LDAP server.

4. Configure the administrator password.

By default, no administrator password is specified.

Configuring LDAP user attributes

About this task

To authenticate a user, an LDAP client must complete the following operations:

1. Establish a connection to the LDAP server.

2. Obtain the user DN from the LDAP server.

3. Use the user DN and the user's password to bind with the LDAP server.

LDAP provides a DN search mechanism for obtaining the user DN. According to the mechanism, an LDAP client sends search requests to the server based on the search policy determined by the LDAP user attributes of the LDAP client.

The LDAP user attributes include:

· Search base DN.

· Search scope.

· Username attribute.

· Username format.

· User object class.

Restrictions and guidelines

If the LDAP server contains many directory levels, a user DN search starting from the root directory can take a long time. To improve efficiency, you can change the start point by specifying the search base DN.

Procedure

1. Enter system view.

system-view

2. Enter LDAP server view.

ldap server server-name

3. Specify the user search base DN.

search-base-dn base-dn

By default, no user search base DN is specified.

4. (Optional.) Specify the user search scope.

search-scope { all-level | single-level }

By default, the user search scope is all-level.

5. (Optional.) Specify the username attribute.

user-parameters user-name-attribute { name-attribute | cn | uid }

By default, the username attribute is cn.

6. (Optional.) Specify the username format.

user-parameters user-name-format { with-domain | without-domain }

By default, the username format is without-domain.

7. (Optional.) Specify the user object class.

user-parameters user-object-class object-class-name

By default, no user object class is specified, and the default user object class on the LDAP server is used. The default user object class for this command varies by server model.

Configuring an LDAP attribute map

About this task

Configure an LDAP attribute map to define a list of LDAP-AAA attribute mapping entries. To apply the LDAP attribute map, specify the name of the LDAP attribute map in the LDAP scheme used for authorization.

The LDAP attribute map feature enables the device to convert LDAP attributes obtained from an LDAP authorization server to device-recognizable AAA attributes based on the mapping entries. Because the device ignores unrecognized LDAP attributes, configure the mapping entries to include important LDAP attributes that should not be ignored.

An LDAP attribute can be mapped only to one AAA attribute. Different LDAP attributes can be mapped to the same AAA attribute.

Procedure

1. Enter system view.

system-view

2. Create an LDAP attribute map and enter LDAP attribute map view.

ldap attribute-map map-name

3. Configure a mapping entry.

map ldap-attribute ldap-attribute-name [ prefix prefix-value delimiter delimiter-value ] aaa-attribute { user-group | user-profile }

Creating an LDAP scheme

Restrictions and guidelines

You can configure a maximum of 16 LDAP schemes. An LDAP scheme can be used by multiple ISP domains.

Procedure

1. Enter system view.

system-view

2. Create an LDAP scheme and enter LDAP scheme view.

ldap scheme ldap-scheme-name

Specifying the LDAP authentication server

1. Enter system view.

system-view

2. Enter LDAP scheme view.

ldap scheme ldap-scheme-name

3. Specify the LDAP authentication server.

authentication-server server-name

By default, no LDAP authentication server is specified.

Specifying the LDAP authorization server

1. Enter system view.

system-view

2. Enter LDAP scheme view.

ldap scheme ldap-scheme-name

3. Specify the LDAP authorization server.

authorization-server server-name

By default, no LDAP authorization server is specified.

Specifying an LDAP attribute map for LDAP authorization

About this task

Specify an LDAP attribute map for LDAP authorization to convert LDAP attributes obtained from the LDAP authorization server to device-recognizable AAA attributes.

Restrictions and guidelines

You can specify only one LDAP attribute map in an LDAP scheme.

Procedure

1. Enter system view.

system-view

2. Enter LDAP scheme view.

ldap scheme ldap-scheme-name

3. Specify an LDAP attribute map.

attribute-map map-name

By default, no LDAP attribute map is specified.

Display and maintenance commands for LDAP

Execute display commands in any view.

Task	Command
Display the configuration of LDAP schemes.	display ldap scheme [ ldap-scheme-name ]

Creating an ISP domain

About ISP domains

In a networking scenario with multiple ISPs, the device can connect to users of different ISPs. These users can have different user attributes, such as different username and password structures, different service types, and different rights. To manage users of different ISPs, configure authentication, authorization, and accounting methods and domain attributes for each ISP domain as needed.

The device supports a maximum of 1024 ISP domains, including the system-defined ISP domain system. The system ISP domain contains a set of default authentication, authorization, and accounting methods, which are local authentication, local authorization, and local accounting. By default, the system ISP domain is the default system ISP domain. However, you can specify another ISP domain as the default system ISP domain.

On the device, each user belongs to an ISP domain. If a user does not provide an ISP domain name at login, the device determines that the user belongs to the default system ISP domain.

Each ISP domain has a set of system-defined AAA methods, which are local authentication, local authorization, and local accounting. If you do not configure any AAA methods for an ISP domain, the device uses the system-defined AAA methods for users in the domain.

Typically, the device chooses an authentication domain for each user in the following order:

1. The authentication domain specified by the access module.

2. The ISP domain in the username.

3. The default system ISP domain.

If the chosen domain does not exist on the device, the device searches for the ISP domain that accommodates users assigned to nonexistent domains.

The device supports specifying default ISP domains, permitted domains, and denied domains for PPP, IPoE, and LAN users on an interface. For more information about interface-based domain selection rules, see "Configuring ISP domains on an interface."

Restrictions and guidelines for ISP domain configuration

An ISP domain cannot be deleted when it is the default system ISP domain. Before you use the undo domain command, change the domain to a non-default ISP domain by using the undo domain default enable command.

You can modify the settings of the system-defined ISP domain system, but you cannot delete the domain.

To avoid RADIUS authentication, authorization, or accounting failures, use short domain names to ensure that usernames containing a domain name do not exceed 253 characters.

To avoid RADIUS accounting failures, make sure the domain name contained in usernames sent to the RADIUS server does not exceed 247 characters.

Creating an ISP domain

1. Enter system view.

system-view

2. Create an ISP domain and enter ISP domain view.

domain name isp-name

By default, a system-defined ISP domain exists. The domain name is system.

Specifying the default system ISP domain

1. Enter system view.

system-view

2. Specify the default system ISP domain.

domain default enable isp-name

By default, the default system ISP domain is the system-defined ISP domain system.

Specifying an ISP domain for users that are assigned to nonexistent domains

1. Enter system view.

system-view

2. Specify the ISP domain to accommodate users that are assigned to nonexistent domains.

domain if-unknown isp-name

By default, no ISP domain is specified to accommodate users that are assigned to nonexistent domains.

Configuring ISP domain attributes

Setting ISP domain status

About this task

By setting the state of an ISP domain, you can allow or deny network service requests from users in the domain.

· Active—The device allows network service requests from users in the domain.

· Blocked—The device denies network service requests from users in the domain. To deny user network service requests during specific time, you can configure the device to place the domain in blocked state during the specified time ranges.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Set the status of the ISP domain.

state { active | block [ time-range ][ offline ] }

By default, an ISP domain is in active state, and users in the domain can request network services.

To log out users (including IPoE and PPP users) when the state of the ISP domain changes to blocked, specify the offline keyword.

4. Specify time ranges during which the ISP domain is placed in blocked state.

state block time-range name time-range-name

By default, no time ranges are specified during which an ISP domain is placed in blocked state.

Configuring authorization attributes for an ISP domain

About this task

The device supports the following authorization attributes:

· ACL—The device restricts authenticated users to access only the network resources permitted by the ACL.

· CAR action—The attribute controls the traffic flow of authenticated users.

· Idle cut—It enables the device to check the traffic of each online user at the specified direction in the domain at the idle timeout interval. The device logs out any users in the domain whose total traffic in the idle timeout period at the specified direction is less than the specified minimum traffic.

· IPv4 address pool—The device assigns IPv4 addresses from the pool to authenticated users in the domain.

· IPv4 address pool group—The device assigns an IPv4 address from the pool group to a PPP or IPoE user after it passes authentication in the domain.

· User profile—When a user passes authentication, it typically obtains an authorization user profile from the local or remote server. If the user does not obtain any user profile, the device authorizes the default user profile of the ISP domain to the user. The device will restrict the user's behavior based on the profile.

· Session group profile—The device restricts authenticated users' behaviors based on the settings in the authorization session group profile.

· Multicast user profile—The device restricts multicast traffic that authenticated IPoE and PPP users can receive based on the settings in the authorization multicast user profile. Use this attribute together with the multicast access control feature.

· Session timeout timer—The device logs out a user when the session timeout timer for the user expires.

· IPv6 address prefix—The device authorizes the IPv6 address prefix to authenticated users in the domain.

· IPv6 address pool—The device assigns IPv6 addresses from the pool to authenticated users in the domain.

· IPv6 address pool group—The device assigns an IPv6 address from the pool group to a PPP, L2TP, or IPoE user after it passes authentication in the domain.

· ND prefix pool—The device assigns ND prefixes from the specified DHCPv6 address pool to IPv6 PPP or IPoE users after the users pass authentication in the domain.

· ND prefix pool group—The device assigns ND prefixes from the specified DHCPv6 address pool group to IPv6 PPP or IPoE users after the users pass authentication in the domain.

· DNS server address—The attribute specifies the DNS server that offers DNS services to the authenticated users in the domain.

· Redirect URL—The device redirects IPoE, L2TP, and PPP users in the domain to the URL. For example, the device can redirect the users to the webpages that display advertisements or notices the first time the users access the network after they pass authentication. When the charge of a user is overdue, the device can redirect that user to the charge notification page.

· Redirect times—The device limits the number of times that it redirects a PPP, L2TP, or IPoE user to the redirect URL.

· User group—Authenticated users in the domain obtain all attributes of the user group.

· VPN instance—The device allows authenticated PPP and IPoE users in the domain to access network resources in the authorization VPN.

· Maximum number of multicast groups—The attribute restricts the maximum number of multicast groups that an authenticated IPoE or PPP user can join concurrently.

· User priority—The device uses the user priority to perform QoS priority mapping on user packets, and then assigns the user packets to a queue based on the target priority. Packets in a high-priority queue are preferentially scheduled when congestion occurs.

For IPoE users that perform Web authentication, authorization attributes can be configured in a preauthentication domain to restrict user behaviors before the users pass authentication.

The device assigns the authorization attributes (excluding the idle cut attribute) in the ISP domain to the authenticated users that do not receive these attributes from the server.

Restrictions and guidelines

Feature	Restrictions and guidelines
CAR	The lowest committed information rate you can set is 8 kbps.
Authorization user group	The user group to be specified as an authorization user group must already exist. For the authorization user group to take effect, do not delete the group if it has online users.

‌

IPoE or PPP users do not obtain authorization attributes from the user group assigned to them.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Configure authorization attributes for authenticated users in the ISP domain.

authorization-attribute { acl acl-number | car inbound cir committed-information-rate [ pir peak-information-rate ] outbound cir committed-information-rate [ pir peak-information-rate ] | idle-cut minutes [ flow ] [ traffic { both | inbound | outbound } ] | igmp max-access-number number | ip-pool ipv4-pool-name | ip-pool-group ipv4-pool-group-name | { ipv4 | ipv6 } multicast-user-profile profile-name | ipv6-nd-prefix-pool ipv6-prefix-pool-name | ipv6-nd-prefix-pool-group ipv6-prefix-pool-group-name | ipv6-pool ipv6-pool-name | ipv6-pool-group ipv6-pool-group-name | ipv6-prefix ipv6-prefix prefix-length | mld max-access-number number | { primary-dns | secondary-dns } { ip ipv4-address | ipv6 ipv6-address } | redirect-times times | session-group-profile session-group-profile-name | session-timeout timeout | url url-string [ unlimited ] | user-group user-group-name | user-priority { inbound | outbound } priority | user-profile [ inbound | outbound ] profile-name | vpn-instance vpn-instance-name }

The default settings are as follows:

¡ The idle cut feature is disabled.

¡ An IPv4 user can concurrently join a maximum of four IGMP multicast groups.

¡ An IPv6 user can concurrently join a maximum of four MLD multicast groups.

¡ The device redirects a maximum of two times of a user's Web requests to the redirect URL.

¡ No other authorization attributes exist.

Specifying effective authorization attributes for users assigned to one ISP domain from another ISP domain

About this task

Use this feature in an ISP domain to specify authorization attributes that will take effect on users that are assigned to this ISP domain from another ISP domain. This feature is applicable to the following situations:

· Users are assigned to the recovery domain from the critical domain after a RADIUS authentication server in the users' original authentication domain becomes available.

For the users to obtain authorization attributes in the recovery domain, you must execute the dynamic-authorization effect-attribute command in the recovery domain to specify effective authorization attributes.

· A RADIUS server assigns a new ISP domain to a user through CoA messages when the services of the user change.

When RADIUS DAS is enabled on the device, the device listens to the specified UDP port for CoA requests from the specified RADIUS servers. When the device receives a CoA request message from a RADIUS server, it matches the message to a user and changes the authorization information of the user accordingly. If the RADIUS server assigns a new ISP domain to the user, you can execute the dynamic-authorization effect-attribute command in the new ISP domain to specify effective authorization attributes.

The effective authorization attributes specified in an ISP domain are from the attributes specified by using the following commands in the same ISP domain:

· authorization-attribute.

· web-server { ip | ipv6 }.

· web-server { url | ipv6-url }.

· web-server url-parameter.

If you do not specify any effective authorization attributes in an ISP domain for users assigned to this ISP domain from another ISP domain, the following conditions exist:

· If the users are assigned to the recovery domain from the critical domain, they cannot obtain any authorization attributes.

· If the users are assigned to a new ISP domain through CoA messages, they use the authorization attributes obtained in the original ISP domain.

Restrictions and guidelines

This feature is applicable only to IPoE users.

If you specify effective authorization attributes for the new ISP domain assigned to a user through CoA messages, the final effective authorization attributes vary as follows:

· If the server does not assign an authorization attribute to the user through CoA messages, the authorization attribute configured in the new ISP domain takes effect. If the authorization attribute is not configured in the new ISP domain, the user uses the authorization attribute configured in the original ISP domain.

· If the server assigns an authorization attribute to the user through CoA messages, the authorization attribute always take effect.

For the user-group authorization attribute, the device assigns a user to a load sharing user group in the new ISP domain based on the NAT instance to which the user belongs.

· If the device finds a load sharing user group bound to the NAT instance in the new ISP domain, it assigns the user to that load sharing user group. If the device does not find such a load sharing user group, it does not perform user group assignment.

· If the user does not belong to a NAT instance, the device assigns the user to a load sharing user group specified in the new ISP domain. To specify a load sharing user group, use the load-sharing user-group command. If no load sharing user groups are specified in the new ISP domain, the authorization user group in that ISP domain applies.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Specify effective authorization attributes in the ISP domain for users that are assigned to the ISP domain from another ISP domain.

dynamic-authorization effective-attribute { car | session-group-profile | session-timeout | url | user-group | user-priority | user-profile | web-server } *

By default, no effective authorization attributes are specified in an ISP domain for users that are assigned to this ISP domain from another ISP domain.

Configuring authorization attributes for none-authentication users

About authorization attributes for none-authentication users

None-authentication users refer to the users that are allowed to come online without being authenticated.

Typically, a user's authorization attributes can be assigned by the authorization server or obtained from its ISP domain. The device does not distinguish the authentication methods of users when it issues the authorization attributes obtained from an ISP domain to the users.

To centrally manage authorization attributes for none-authentication users, perform this task to configure authorization attributes specific to these users in an ISP domain.

In the current software version, you can configure only the authorization session timeout timer for none-authentication users.

Restrictions and guidelines

For none-authentication users, the authorization attributes configured by using this feature take precedence over those configured by using the authorization-attribute command in ISP domain view.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Set the authorization session timeout timer for none-authentication users.

authentication-method none authorization-attribute session-timeout timeout

By default, the authorization session timeout timer assigned by the server is used. If the server does not assign a session timeout timer, the setting in the ISP domain is used.

Setting the maximum number of concurrent users in an ISP domain

About this task

Perform this task to limit the number of concurrent users allowed to access an ISP domain. This limit does not distinguish the service types of the users. When the maximum number of concurrent users reaches the upper limit, the system denies the subsequent users from accessing the ISP domain.

Restrictions and guidelines

The maximum number of concurrent login users is also restricted by the aaa session-limit command in system view.

This limit does not apply to reauthenticated users.

In addition, this limit does not apply to ITA users or EDSG users.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Set the maximum number of concurrent users allowed to access the ISP domain.

access-limit limit-number

By default, no limit is placed on the number of concurrent users allowed to access an ISP domain.

Including the idle timeout period in the user online duration to be sent to the server

About this task

If a user goes offline due to connection failure or malfunction, the user's online duration sent to the server includes the idle timeout period. The online duration that is generated on the server is longer than the actual online duration of the user. The idle timeout period is authorized by the authorization server after users pass authentication.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Configure the device to include the idle timeout period in the user online duration to be sent to the server.

session-time include-idle-time

By default, the user online duration sent to the server excludes the idle timeout period.

Specifying the user address type in an ISP domain

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Specify the user address type in the ISP domain.

user-address-type { ds-lite | ipv6 | nat64 | private-ds | private-ipv4 | public-ds | public-ipv4 }

By default, no user address type is specified.

Configuring parameters for RA messages

About RA message parameters

You can set the M and O flags in RA advertisements to determine whether hosts use stateful autoconfiguration or not.

The O flag in RA advertisements determines whether receiving hosts use stateful autoconfiguration to obtain configuration information other than IPv6 addresses.

· If the O flag is set to 1 in RA advertisements, receiving hosts use stateful autoconfiguration (for example, from a DHCPv6 server) to obtain configuration information other than IPv6 addresses.

· If the O flag is set to 0 in RA advertisements, receiving hosts use stateless autoconfiguration to obtain configuration information other than IPv6 addresses.

The M flag in RA advertisements determines whether receiving hosts use stateful autoconfiguration to obtain IPv6 addresses.

· If the M flag is set to 1 in RA advertisements, receiving hosts use stateful autoconfiguration (for example, from a DHCPv6 server) to obtain IPv6 addresses.

· If the M flag is set to 0 in RA advertisements, receiving hosts use stateless autoconfiguration. Stateless autoconfiguration generates IPv6 addresses according to link-layer addresses and the prefix information in the RA advertisements.

Restrcitions and guidelines

The RA message settings configured in an ISP domain only apply to PPP users.

For PPP users, you can execute the ipv6 nd autoconfig managed-address-flag or ipv6 nd autoconfig other-flag command in ISP domain view or in interface view. If you have executed one of the commands in either of the views, the device will set the corresponding flag to 1 in RA advertisements to be sent.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Set the M flag to 1 in RA advertisements to be sent.

ipv6 nd autoconfig managed-address-flag

By default, the M flag is set to 0 in RA advertisements. Hosts receiving the advertisements will obtain IPv6 addresses through stateless autoconfiguration.

4. Set the O flag to 0 in RA advertisements to be sent.

ipv6 nd autoconfig other-flag

By default, the O flag is set to 0 in RA advertisements. Hosts receiving the advertisements will acquire other information through stateless autoconfiguration.

Specifying the service type for users in an ISP domain

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Specify the service type for users in the ISP domain.

service-type { hsi | stb | voip }

By default, the service type is hsi.

Applying an ITA policy to users in an ISP domain

About this task

An ITA policy allows the device to perform accounting at different charge rates for user data based on destination addresses.

Restrictions and guidelines

The ITA policy assigned by an AAA server takes precedence over the ITA policy applied to an ISP domain.

If the RADIUS server assigns EDSG policies but no ITA policy to the user, the ITA policy applied to the ISP domain does not take effect on the user.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Apply an ITA policy to users in the ISP domain.

ita-policy policy-name

By default, no ITA policy is applied.

Setting the rate limit mode for EDSG services in an ISP domain

About this task

Perform this task to control the available bandwidth for EDSG services. The following are rate limit modes for EDSG services:

· merge—In-band mode. In this mode, the device limits the overall rates of both EDSG traffic and non-EDSG traffic for a user within the available basic bandwidth of the user. The bandwidth for the EDSG traffic is preferentially guaranteed.

· separate—Out-band mode. In this mode, the device limits the rate of EDSG traffic within an independent bandwidth. The bandwidth for the non-EDSG traffic is not affected.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Set the rate limit mode for EDSG services.

service rate-limit mode { merge | separate }

By default, the out-band mode is used for EDSG services.

Configuring the Web server in an ISP domain

About this task

If you specify an IPv4 or IPv6 Web server URL in an IPoE preauthentication domain, the device redirects the following HTTP and HTTPS requests from unauthenticated IPoE users to that URL for authentication:

· IPv4 or IPv6 HTTP requests with destination port 80.

· HTTPS requests with destination port 443.

For more information about the Web authentication process for IPoE users, see BRAS Services Configuration Guide.

For high availability, you can configure the following settings:

· Specify a primary Web server and a secondary Web server.

· Specify the primary and secondary URLs of each Web server.

· Associate a track entry with each URL to detect the URL reachability.

Restrictions and guidelines

To add SSID information in the Web server URL, you also need to set the SSID on the user access interface by using the aaa ssid command.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Specify a Web server by its URL.

web-server { url ipv4-url-string | ipv6-url ipv6-url-string } [ secondary ] [ track track-entry-number ]

By default, no Web server URL is specified.

4. (Optional.) Specify the IP address of a Web server.

Primary Web server:

web-server { ip ipv4-address | ipv6 ipv6-address } [ secondary ]

Secondary Web server:

secondary-web-server [ secondary ] { ip ipv4-address | ipv6 ipv6-address }

By default, no IP address of a Web server is specified.

If the URL of a Web request carries the specified IP address, the Web request is directly forwarded to the Web server without redirection.

If two Web servers are available, use the commands in this step to specify the IP addresses of the Web servers. If a Web server has two IP addresses, use the secondary keyword to specify one of the IP addresses as a backup IP address.

5. (Optional.) Add a parameter to the Web server URL.

web-server url-parameter param-name { nas-id | nas-port-id | original-url | remote-id | source-address | source-mac [ encryption { aes | des } key { cipher | simple } string ] [ section { 1 | { 3 | 6 } [ separator separator-character ] } { lowercase | uppercase } ] | ssid | user-location | value expression }

By default, no parameters are added to the Web server URL.

You can repeat this command to add multiple parameters to the Web server URL.

Setting the active period of the redirect URL for PPP and IPoE users

About this task

If the server assigns a redirect URL to a PPP or IPoE user after it passes authentication, the device redirects the user to the redirect URL when the user accesses the network for the first time. The redirect URL might provide important information for the user (for example, advertisements, notices, and charge overdue notifications).

Some applications (for example, input software) initiate background Web visit requests to visit the network before the user actively accesses the network. As a result, the device might not redirect the active Web visit requests of the user to the redirect URL because the number of times that the device redirects the background requests has reached the maximum number of redirect times. In this case, the user does not obtain the information provided by the redirect URL.

To resolve this issue, use this feature to set the redirect URL active period. In this period, all Web visit requests of a user are redirected to the redirect URL. The period starts for a user when the server or the device assigns a redirect URL to the user because the user comes online or the server performs a COA authorization.

Restrictions and guidelines

This feature takes effect on a user in either of the following conditions:

· The server assigns the user a redirect URL and the attribute that sets the number of redirect times.

· The server does not assign the user a redirect URL. However, an authorization redirect URL has been configured for the ISP domain and the number of times that the device redirects the user to the redirect URL is not limited.

This feature has higher priority than the maximum number of redirect times configured by using the authorization-attribute redirect-times command in ISP domain view. If limiting the maximum number of redirect times is required, do not configure this feature.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Set the redirect URL active period during which all Web visit requests of a user are redirected to the redirect URL.

redirect active-time time

By default, the active period of the redirect URL is not set.

Specifying an IP address of the Web redirect server for PPP and IPoE users

About this task

To improve the efficiency and accuracy of Web redirections, use this feature to specify an IP address of the Web server that owns the redirect URL. When the device redirects a Web visit request of a PPP or IPoE user, it first identifies whether the destination IP address of the request is the specified IP address of the Web server. If the IP addresses are the same one, the device allows the request to pass through. If the IP addresses are different, the device pushes the redirect URL assigned by the server to the user.

· If the redirect URL does not contain a redirect server IP address, the device uses the IP address specified by using this feature as the redirect destination IP address. Make sure the specified IP address is the same as the IP address resolved from the URL.

· If the redirect URL contains a redirect server IP address but the IP address is different from the IP address specified by using this feature, the device uses the IP address specified by using this feature as the redirect destination IP address.

· If the redirect URL does not contain a redirect server IP address and no redirect server IP address is specified, redirection might fail due to lack of redirect server IP address.

Restrictions and guidelines

In an ISP domain, you can specify only one IPv4 address and one IPv6 address of the Web redirect server.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Specify an IP address of the Web redirect server.

redirect server { ip ip-address | ipv6 ipv6-address }

By default, no redirect server IP address is specified.

Enabling temporary redirect

About this task

Typically, the device carries the redirect URL coded in JavaScript in HTTP or HTTPS responses sent to users. The users obtain the redirect URL by parsing the JavaScript code. If the endpoint of a user (application, for example) does not support JavaScript, the user will fail to be redirected.

To resolve this issue, enable the temporary redirect feature. This feature enables the device to send HTTP or HTTPS responses with status code 302 to users so that the users can obtain the redirect URL.

Restrictions and guidelines

As a best practice, use this feature only if user endpoints that do not support parsing JavaScript codes in HTTP or HTTPS packets exist on the network.

This feature is applicable only to PPP and IPoE users.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Enable the temporary redirect feature.

redirect move-temporarily enable

By default, the temporary redirect feature is disabled.

Specifying the types of IP addresses that PPPoE and L2TP users rely on to use basic services

About this task

A PPPoE or L2TP user might request multiple services of different IP address types. The device logs off the user if the user does not obtain the IP addresses of all types for the services. Perform this task to allow the user to come online if the user has obtained IP addresses of the specified types for the basic services.

Restrictions and guidelines

The configuration in this section takes effect only when the device acts as a PPPoE server or L2TP LNS.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Specify the types of IP addresses that PPPoE and L2TP users must rely on to use the basic services.

basic-service-ip-type { ipv4 | ipv6 | ipv6-pd } *

By default, PPPoE and L2TP users do not rely on any types of IP addresses to use the basic services.

Setting the IPv6 address wait timer for PPPoE and L2TP users

About this task

The IPv6 address wait timer defines the maximum amount of time that a user can wait before the device determines that the user fails to obtain an IPv6 address or PD prefix.

The device starts an IPv6 address wait timer for a PPPoE or L2TP user after it finishes IPv6CP negotiation with the user. If the user's basic service relies on an IPv6 address or PD prefix but it fails to obtain any IPv6 address or PD prefix when the timer expires, the user cannot come online.

As a best practice, increase the IPv6 address wait timer in the following situations:

· The network connectivity is unstable.

· The device uses DHCPv6 to assign IPv6 addresses to users.

· The ISP domain serves a large number of PPPoE and L2TP users.

Restrictions and guidelines

The IPv6 address wait timer takes effect only when the device acts as a PPPoE server or L2TP LNS.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Set the IPv6 address wait timer for PPPoE and L2TP users.

dhcpv6-follow-ipv6cp timeout delay-time

By default, the IPv6 address wait timer is 60 seconds for PPPoE and L2TP users.

Enabling the forcible use of RADIUS server-authorized L2TP attributes

About the forcible use of RADIUS server-authorized L2TP attributes

Typically, whether the device processes an authenticated PPP user as an L2TP user depends on the local L2TP configuration or the L2TP attributes that the RADIUS server assigns to the user. The server-assigned L2TP attributes take precedence over the L2TP configuration on the device.

The forcible use of RADIUS server-authorized L2TP attributes enables the device to decide whether to process a PPP user as an L2TP user only based on the server-assigned L2TP attributes.

· If the RADIUS server assigns the L2TP tunnel type to a PPP user through attribute 64, the device processes the PPP user as an L2TP user.

· If the RADIUS server does not assign the L2TP tunnel type to a PPP user through attribute 64, the device processes the PPP user as a common PPP user.

Use this feature to implement centralized authorization to L2TP users and unified L2TP tunnel parameter management for L2TP users in multiple ISP domains.

For an authenticated PPP user to be processed as an L2TP user, the device selects one of the following items to initiate tunneling requests for the user in descending order:

1. L2TP tunnel attributes assigned by the RADIUS server. These attributes are selected only if they are sufficient for tunnel establishment.

2. L2TP group assigned by the RADIUS server through the Tunnel-Group-Name attribute (attribute 183).

3. L2TP group specified for the ISP domain to which the user belongs.

The L2TP user cannot come online if none of the above items can be used to initiate tunneling requests. For more information about L2TP users and L2TP tunnel attributes, see L2TP configuration in BRAS Services Configuration Guide.

Restrictions and guidelines

This configuration is applicable only to PPP users.

When this feature is disabled in an ISP domain but the device is enabled with L2TP, the device will process a PPP user as an L2TP user under any of the following situations:

· The RADIUS server assigns an L2TP group to the user.

· An L2TP group is specified for the ISP domain.

· The full username of the user or the name of the ISP domain matches the condition of initiating tunneling requests configured for an L2TP group.

For the PPP user to be processed as an L2TP user, the device selects one of the following items to initiate tunneling requests for the user in descending order:

1. L2TP tunnel attributes assigned by the RADIUS server. These attributes are used only they are sufficient for tunnel establishment.

2. L2TP group assigned by the RADIUS server through the Tunnel-Group-Name attribute (proprietary attribute 183).

3. L2TP group specified for the ISP domain to which the user belongs.

4. L2TP group of which the condition configured for initiating tunneling requests matches the username of the user or the name of the ISP domain.

Prerequisites

Before you configure this feature, complete the following tasks:

1. Enable L2TP.

2. Create the L2TP group to be specified for the ISP domain and configure the parameters required for L2TP tunnel establishment in this group.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Enable the forcible use of RADIUS server-authorized L2TP attributes.

l2tp-user radius-force

By default, the forcible use of RADIUS server-authorized L2TP attributes is disabled.

4. (Optional.) Specify an L2TP group for the ISP domain.

l2tp-group { group-name group-name | group-number group-number }

By default, no L2TP group is specified for an ISP domain.

You can specify only one L2TP group for an ISP domain.

Forcibly assigning interface IDs to PPP users

About this task

Perform this task for centralized management of PPP users' interface IDs. This feature enables the device to ignore the interface IDs carried in Configure-Request packets from PPP users and forcibly assign interface IDs to PPP users during IPv6CP negotiation. The device preferentially uses the interface IDs that the RADIUS server assigns to PPP users through the Framed-Interface-Id attribute. If the server does not assign interface IDs to PPP users, the device generates interface IDs and then assigns the IDs to the users.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Configure the device to forcibly assign interface IDs to PPP users during IPv6CP negotiation.

ipv6cp assign-interface-id

By default, the device accepts the non-zero and non-conflicted interface IDs carried in the Configure-Request packets from PPP users in IPv6CP negotiation.

Configuring load-sharing user groups

About this task

Use load-sharing user groups with service features to implement load sharing for user service traffic.

If you configure a load-sharing user group in an ISP domain, the load sharing feature for users is enabled for the ISP domain. You can configure a maximum of 32 load-sharing user groups in an ISP domain. After a user in the ISP domain comes online, the device assigns the user to the load-sharing user group that has the fewest users.

Restrictions and guidelines

If load-sharing user groups are used in conjunction with NAT, they are applicable only to interface-based NAT.

The user group to be configured as a load-sharing user group must already exist. If you configure a nonexistent user group as a load-sharing user group, this configuration does not take effect.

The user group to which the device finally assigns a user depends on the configuration. The device selects the user group to accommodate a user in an ISP domain in the following order:

1. The user group authorized by the server.

2. The load-sharing user group configured in the ISP domain.

3. The authorization user group specified in the ISP domain.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Configure a load-sharing user group.

load-sharing user-group group-name

By default, no load-sharing user groups are configured and the load sharing feature is disabled in an ISP domain.

Setting the maximum number of concurrent logins for a user account

About this task

Perform this task to limit the number of concurrent logins (or shared-account users) for a user account. The shared-account users for a user account use the same username and belong to the same ISP domain (server-assigned or authentication domain). They share the bandwidth allocated to the user account. In other words, the total traffic of the shared-account users is limited to the authorization traffic policing settings of the user account.

Restrictions and guidelines

This configuration is applicable only to PPPoE, IPoE, and L2TP users.

For shared-account users, the ISP domain assigned by the server has a higher priority than the authentication ISP domain.

The idle-cut feature does not take effect on shared-account users.

The maximum number of shared-account users assigned by the server through the Port-Limit attribute (attribute 62) takes precedence over the value set by using the users-per-account command. If the server-assigned value is greater than 512, the effective value is 512.

As a best practice, set the maximum number of concurrent logins to 16 for a user account.

Procedure

4. Enter system view.

system-view

5. Enter ISP domain view.

domain name isp-name

6. Set the maximum number of concurrent logins for a user account.

users-per-account max-user-number [ case-insensitive ]

By default, users in an ISP domain do not share user accounts. The traffic of each user is limited by the traffic policing parameters authorized to the user.

Enabling strict check for VPN instances bound to users' access interfaces

About this task

Use this feature to allow a static IPoE user to come online only when the VPN instance bound to the access interface of the user is the same as the following VPN instances (if any):

· The VPN instance bound to the static IPoE session of the user.

· The VPN instance assigned by AAA to the user.

When this feature is disabled, the device assigns static IPoE users to different VPN instances when the users come online, depending on their VPN instance configuration and authorization information.

· If no VPN instance is bound to the static IPoE session of a user and AAA does not assign a VPN instance to the user, the user belongs to the VPN instance of its access interface when it comes online. If no VPN instance is bound to the interface, the user belongs to the public network.

· If a VPN instance is bound to the static IPoE session of a user or AAA assigns a VPN instance to the user, the user belongs to this VPN instance when it comes online. Whether a VPN instance is bound to the user access interface does not affect the VPN instance assignment.

· If a VPN instance is bound to the static IPoE session of a user and AAA assigns the same VPN instance to the user, the user belongs to that VPN instance when it comes online. If the VPN instances are different, the user cannot come online.

When this feature is enabled, the device examines whether the VPN instance settings are consistent for a static IPoE user when the user comes online in the ISP domain. Depending on the examination result, the device controls whether to assign the user to a VPN instance or the public network or deny the user from coming online.

· If no VPN instance is bound to the static session of the user or AAA does not assign a VPN instance to the user, the user belongs to the VPN instance bound to its access interface after it comes online. If no VPN instance is bound to the access interface, the user belongs to the public network after it comes online.

· If a VPN instance is bound to the static session of the user or AAA assigns a VPN instance to the user, the VPN instance must be the same as the VPN instance bound to the user's access interface. The user belongs to the VPN instance after it comes online. If the VPN instances are different, the user cannot come online.

· If a VPN instance is bound to the static session of the user and AAA assigns a VPN instance to the user, the VPN instances must be the same as the VPN instance bound to the user's access interface. The user belongs to the VPN instance after it comes online. If the three VPN instances are different, the user cannot come online.

Restrictions and guidelines

This feature takes effect only on static IPoE users, including static individual users and static leased users. For more information about static IPoE users, see IPoE in BRAS Services Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Enable strict check for VPN instances bound to users' access interfaces.

strict-check access-interface vpn-instance

By default, strict check is disabled for VPN instances bound to users' access interfaces.

Enabling automatic user backup

About this task

Typically, DHCPv4, DHCPv6, or IPv6 ND RS users are logged out and the user information gets lost if the access card or interface fails or the device reboots. After the failure recovers or the device restarts up, the clients might not initiate authentication to come online again because they do not sense the failure or reboot. The device also will not allow the users to come online automatically because it does not have the user information. To resolve the issue, enable automatic user backup on the device.

When this feature is enabled, the device will instruct the access module to back up the user information after the users pass authentication. With this feature, the device allows the users to come online automatically after they are logged out because of card or interface failure or device reboot.

For this feature to take effect, you must set the maximum number of users that can be backed up by using the ip subscriber auto-save max-user command.

To avoid the loss of the backup user information caused by device reboot, use the ip subscriber save-file command to save the backup to a non-volatile storage medium. Then, if the users are logged out because of device reboot, the access module can use the backup stored in the non-volatile storage medium to reauthenticate the users.

Restrictions and guidelines

This feature takes effect only on IPoE users. For more information about automatic IPoE user backup, see IPoE configuration in BRAS Services Configuration Guide.

This feature is a memory-intensive feature. As a best practice, enable this feature when the system initially starts up or the service load is light, and disable this feature when the device memory is limited.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Enable automatic user backup.

access-user auto-save enable

By default, automatic user backup is enabled.

Configuring the authentication failure policy for users in an ISP domain

About this task

Perform this task to flexibly process users that fail authentication in an ISP domain according to the network requirements. You can configure the device to take one of the following actions on the users:

· Log out the users.

· Allow the users to stay online, and then assign the users to the reauthentication domain of the ISP domain for reauthentication.

Restrictions and guidelines

The reauthentication domain of an ISP domain does not take effect on any of the following users:

· Device management users that fail authentication in the ISP domain.

· Users that fail authentication in the ISP domain because of authentication timeout, for example, no response from the authentication server or no local user account.

· Users that fail authentication in the ISP domain because the ISP domain is in blocked state or is a denied domain.

· Users that fail authentication in the ISP domain because the maximum number of access users in the ISP domain has been reached.

· Users that have been assigned to the reauthentication domain fails authentication again.

· Users that fail reauthentication in the ISP domain.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Configure the authentication failure policy for users in the ISP domain.

authen-fail { offline | online domain new-isp-name }

By default, the device logs out users in an ISP domain if the users fail authentication.

Configuring AAA methods for an ISP domain

Configuring authentication methods for an ISP domain

About this task

For high availability, you can specify one primary authentication method and multiple backup authentication methods. If the primary method is invalid, the device tries the backup methods in sequence.

For example, the radius-scheme radius-scheme-name local none command specifies RADIUS-based remote authentication as the primary authentication method and specifies local authentication and no authentication as the backup authentication methods. The device performs RADIUS authentication by default and performs local authentication if the RADIUS authentication method is invalid. If both remote and local authentication are invalid, the device does not perform authentication.

NOTE:

A remote authentication method is invalid if the device fails to find the specified authentication scheme, send authentication packets, or receive responses from any authentication servers.

Local authentication is invalid if the device fails to find a local user account for the requesting user when it performs local authentication.

Restrictions and guidelines

When you configure remote authentication, follow these restrictions and guidelines:

· If the authentication method uses a RADIUS scheme and the authorization method does not use a RADIUS scheme, AAA accepts only the authentication result from the RADIUS server. The Access-Accept message from the RADIUS server also includes the authorization information, but the device ignores the information.

· If an HWTACACS scheme is specified, the device uses the entered username for role authentication.

· If a RADIUS scheme is specified, the device uses username $enabn$ on the RADIUS server for role authentication.

¡ To obtain a level-n user role, you must create a user account for the level-n user role in the $enabn$ format on the RADIUS server. The variable n represents the target user role level.

¡ To obtain a non-level-n user role, you must perform the following tasks:

- Create a user account named $enab0$ on the server.

- Configure the cisco-av-pair attribute for the account in the form of allowed-roles="role". The variable role represents the target user role.

For more information about user role authentication, see Fundamentals Configuration Guide.

When the primary authentication method is local, the following rules apply to the authentication of a user:

· The device uses the backup authentication methods in sequence only if local authentication is invalid for one of the following reasons:

¡ An exception occurs in the local authentication process.

¡ The user account is not configured on the device or the user is not allowed to use the access service.

· The device does not turn to the backup authentication methods if local authentication is invalid because of any other reason. Authentication fails for the user.

Prerequisites

Before configuring authentication methods, complete the following tasks:

1. Determine the access type or service type to be configured. With AAA, you can configure an authentication method for each access type and service type.

2. Determine whether to configure the default authentication method for all access types or service types. The default authentication method applies to all access users. However, the method has a lower priority than the authentication method that is specified for an access type or service type.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. (Optional.) Specify default authentication methods for all types of users.

authentication default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | ldap-scheme ldap-scheme-name [ local ] [ none ] | local [ radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] | local [ ldap-scheme ldap-scheme-name ] [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }

By default, the default authentication method is local.

4. Specify authentication methods for a user type or a service.

¡ Specify authentication methods for IPoE users.

authentication ipoe { local [ radius-scheme radius-scheme-name ] [ none ] | none | radius-proxy [ radius-scheme radius-scheme-name | local ] * [ none ] | radius-scheme radius-scheme-name [ local ] [ none ] }

By default, the default authentication methods are used for IPoE users.

¡ Specify authentication methods for LAN users.

authentication lan-access { ldap-scheme ldap-scheme-name [ local ] [ none ] | local [ ldap-scheme ldap-scheme-name | radius-scheme radius-scheme-name ] [ none ] | none | radius-scheme radius-scheme-name [ local ] [ none ] }

By default, the default authentication methods are used for LAN users.

¡ Specify authentication methods for login users.

authentication login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | ldap-scheme ldap-scheme-name [ local ] [ none ] | local [ radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] | local [ ldap-scheme ldap-scheme-name ] [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }

By default, the default authentication methods are used for login users.

¡ Specify authentication methods for PPP users.

authentication ppp { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }

By default, the default authentication methods are used for PPP users.

¡ Specify authentication methods for obtaining a temporary user role.

authentication super { hwtacacs-scheme hwtacacs-scheme-name | radius-scheme radius-scheme-name } *

By default, the default authentication methods are used for obtaining a temporary user role.

Configuring authorization methods for an ISP domain

About this task

For high availability, you can specify one primary authorization method and multiple backup authorization methods. If the primary method is invalid, the device tries the backup methods in sequence.

For example, the radius-scheme radius-scheme-name local none command specifies RADIUS-based remote authorization as the primary authorization method and specifies local authorization and no authorization as the backup authorization methods. The device performs RADIUS authorization by default and performs local authorization if the RADIUS authorization method is invalid. If both remote and local authorization are invalid, the device does not perform authorization.

NOTE:

A remote authorization method is invalid if the device fails to find the specified authorization scheme, send authorization packets, or receive responses from any authorization servers.

Local authorization is invalid if the device fails to find a local user account for the requesting user when it performs local authorization.

Restrictions and guidelines

Only SSL VPN users support LDAP authorization.

To use a RADIUS scheme as the authorization method, specify the name of the RADIUS scheme that is configured as the authentication method for the ISP domain. If an invalid RADIUS scheme is specified as the authorization method, RADIUS authentication and authorization fail.

When the primary authorization method is local, the following rules apply:

· The device uses the backup authorization methods in sequence only if local authorization is invalid for one of the following reasons:

¡ An exception occurs in the local authorization process.

¡ The user account is not configured on the device or the user is not allowed to use the access service.

· The device does not turn to the backup authorization methods if local authorization is invalid because of any other reason. Authorization fails for the user.

Prerequisites

Before configuring authorization methods, complete the following tasks:

1. Determine the access type or service type to be configured. With AAA, you can configure an authorization scheme for each access type and service type.

2. Determine whether to configure the default authorization method for all access types or service types. The default authorization method applies to all access users. However, the method has a lower priority than the authorization method that is specified for an access type or service type.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. (Optional.) Specify default authorization methods for all types of users.

authorization default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }

By default, the authorization method is local.

4. Specify authorization methods for a user type or a service.

¡ Specify command authorization methods.

authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local ] [ none ] | local [ none ] | none }

By default, the default authorization methods are used for command authorization.

¡ Specify authorization methods for IPoE users.

authorization ipoe { local [ radius-scheme radius-scheme-name ] [ none ] | none | radius-proxy [ radius-scheme radius-scheme-name | local ] * [ none ] | radius-scheme radius-scheme-name [ local ] [ none ] }

By default, the default authorization methods are used for IPoE users.

¡ Specify authorization methods for LAN users.

authorization lan-access { local [ radius-scheme radius-scheme-name ] [ none ] | none | radius-scheme radius-scheme-name [ local ] [ none ] }

By default, the default authorization methods are used for LAN users.

¡ Specify authorization methods for login users.

authorization login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }

By default, the default authorization methods are used for login users.

¡ Specify authorization methods for PPP users.

authorization ppp { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }

By default, the default authorization methods are used for PPP users.

Configuring accounting methods for an ISP domain

About this task

For high availability, you can specify one primary accounting method and multiple backup accounting methods. If the primary method is invalid, the device tries the backup methods in sequence.

For example, the radius-scheme radius-scheme-name local none command specifies RADIUS-based remote accounting as the primary accounting method and specifies local accounting and no accounting as the backup accounting methods. The device performs RADIUS accounting by default and performs local accounting if the RADIUS accounting method is invalid. If both remote and local accounting are invalid, the device does not perform accounting.

NOTE:

A remote accounting method is invalid if the device fails to find the specified accounting scheme, send accounting packets, or receive responses from any accounting servers.

Local accounting is invalid if the device fails to find a local user account for the requesting user when it performs local accounting.

Restrictions and guidelines

FTP, SFTP, and SCP users do not support accounting.

Local accounting does not provide statistics for charging. It only counts and controls the number of concurrent users that use the same local user account. The threshold is configured by using the access-limit command.

When the primary accounting method is local, the following rules apply:

· The device uses the backup accounting methods in sequence only if local accounting is invalid for one of the following reasons:

¡ An exception occurs in the local accounting process.

¡ The user account is not configured on the device or the user is not allowed to use the access service.

· The device does not turn to the backup accounting methods if local accounting is invalid because of any other reason. Accounting fails for the user.

· For PPPoEA users, you can configure RADIUS accounting or no accounting. To use the AAA server in the campus to control traffic to ISP networks, configure a RADIUS accounting scheme as a best practice. If no accounting scheme is configured for agency dialup in the authentication domain used by PPPoEA users, the default accounting method in the domain is used. If the default accounting method is not radius-scheme or none, accounting fails.

Prerequisites

Before configuring accounting methods, complete the following tasks:

1. Determine the access type or service type to be configured. With AAA, you can configure an accounting method for each access type and service type.

2. Determine whether to configure the default accounting method for all access types or service types. The default accounting method applies to all access users. However, the method has a lower priority than the accounting method that is specified for an access type or service type.

Procedure

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. (Optional.) Specify default accounting methods for all types of users.

accounting default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }

By default, the accounting method is local.

4. Specify accounting methods for a user type.

¡ Specify the command accounting method.

accounting command hwtacacs-scheme hwtacacs-scheme-name

By default, the default accounting methods are used for command accounting.

¡ Specify accounting methods for IPoE users.

accounting ipoe { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ local ] [ none ] | local [ radius-scheme radius-scheme-name ] [ none ] | none | radius-scheme radius-scheme-name [ local ] [ none ] }

By default, the default accounting methods are used for IPoE users.

¡ Specify accounting methods for LAN users.

accounting lan-access { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ local ] [ none ] | local [ radius-scheme radius-scheme-name ] [ none ] | none | radius-scheme radius-scheme-name [ local ] [ none ] }

By default, the default accounting methods are used for LAN users.

¡ Specify accounting methods for login users.

accounting login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }

By default, the default accounting methods are used for login users.

¡ Specify accounting methods for PPP users.

accounting ppp { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] | hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }

By default, the default accounting methods are used for PPP users.

¡ Specify an accounting method for PPPoEA users.

accounting pppoea { none | radius-scheme radius-scheme-name [ none ] }

By default, the default accounting method is used for PPPoEA users.

5. (Optional.) Configure extended accounting policies.

¡ Configure access control for users that encounter accounting-start failures.

accounting start-fail { offline | online }

By default, the device allows users that encounter accounting-start failures to stay online.

¡ Configure access control for users that have failed all their accounting-update attempts.

accounting update-fail { [ max-times max-times ] offline | online }

By default, the device allows users that have failed all their accounting-update attempts to stay online.

¡ Configure access control for users that have used up their data or time accounting quotas.

accounting quota-out { offline | online | redirect-url url-string [ stop-accounting ] [ user-profile profile-name ] } [ no-accounting-update ]

By default, the device sends accounting-update packets to the server to request new accounting quotas for the users that have used up their accounting quotas. A user is logged off if the device has not received new quota from the server for the user.

¡ Specify the accounting method for dual-stack users.

accounting dual-stack { merge | separate }

By default, the merge method is used.

¡ Set the start-accounting delay (the period of time that the device waits before sending a start-accounting request).

accounting start-delay delay-time

By default, the start-accounting delay is 0 seconds.

Display and maintenance commands for ISP domains

Execute display commands in any view.

Task	Command
Display configuration information about an ISP domain or all ISP domains.	display domain [ name isp-name ]
Display statistics for online access users in ISP domains.	display domain [ name isp-name ] access-user statistics

Configuring AAA fail-permit and recovery

About this task

This feature is used to resolve the issue that users that use a RADIUS scheme cannot come online when all RADIUS servers in the RADIUS scheme are unavailable. The feature contains the following settings in a user authentication domain:

· In the user authentication domain, specify a critical domain (also known as fail-permit domain) to accommodate users that access the authentication domain when all RADIUS servers are unavailable. The users can come online in the critical domain without being authenticated when all RADIUS servers are unavailable.

· In the user authentication domain, specify an action to take on users that have been assigned to the critical domain when a RADIUS server for the authentication domain becomes available.

¡ To perform authentication, authorization, and accounting for the users, log off the users.

¡ To assign the users back to the authentication domain, allow the users to stay online and specify the authentication domain as the recovery domain. The device does not perform authentication, authorization, or accounting for the users after the users are assigned to the recovery domain. The users can obtain the effective authorization attributes in the recovery domain. To specify the effective authorization attributes, use the dynamic-authorization effective-attribute command.

For the device to obtain the status of RADIUS authentication servers in time, it detects the status of the RADIUS authentication servers in each RADIUS scheme at intervals. In addition, the device notifies access modules to remove users that use a RADIUS scheme from the critical domain when that RADIUS scheme has reachable RADIUS servers.

Restrictions and guidelines

This feature takes effect only on IPoE and PPPoE users.

When you specify a critical domain for an ISP domain, follow these restrictions and guidelines:

· If non-none authentication, authorization, or accounting methods are configured in the critical domain for an ISP domain, the non-none authentication or authorization methods cannot take effect on users. However, the non-none accounting methods in the critical domain can take effect on users.

· If an ISP domain has been specified as a critical domain, do not specify a critical domain for that ISP domain. If you do so, the critical domain specified for that ISP domain cannot take effect.

· If a critical domain has been specified for an ISP domain, do not specify that ISP domain as a critical domain. If you do so, that ISP domain cannot act as a critical domain.

When you specify a recovery domain for an ISP domain, follow these restrictions and guidelines:

· If the none method is configured as the backup authentication method in the original authentication domain before the users are assigned to the critical domain, the users still can be assigned to the recovery domain when a RADIUS server becomes available.

· As a best practice to accurately identify whether a RADIUS authentication server is available and the recovery configuration can take effect in time, configure RADIUS server status detection.

When you set the interval at which the device detects the status of RADIUS authentication servers, follow these restrictions and guidelines:

· A too short interval consumes too many system resources for access services. A too long interval cannot detect server status changes in time.

· As a best practice, consider the processing efficiency for access services and the accuracy for fail-permit and recovery when a large number of users come online in a short time.

Procedure

1. Enter system view.

system-view

2. (Optional.) Set the interval at which the device detects the status of RADIUS authentication servers.

radius-server authen-state-check interval interval

By default, the device detects the status of RADIUS authentication servers at intervals of 10 minutes.

3. Enter ISP domain view.

domain name isp-name

4. Specify a critical domain to accommodate users that access the ISP domain when all RADIUS servers are unavailable.

authen-radius-unavailable online domain new-isp-name

By default, no critical domain is specified for an ISP domain to accommodate users that access the ISP domain when all RADIUS servers are unavailable.

5. Specify an action to take on users in the critical domain when a RADIUS server becomes available.

authen-radius-recover { offline | online domain new-isp-name }

By default, no action is specified for users in the critical domain when a RADIUS server becomes available.

Configuring ISP domains on an interface

About ISP domain selection on an interface

To provide flexible AAA services for PPP, IPoE, and LAN users, you can specify ISP domains for the users in access modules, on access interfaces, or in system view.

If the ISP domain selected for a user is a domain permitted by the user access interface, the domain's AAA methods can be used to perform AAA on the user. If the selected ISP domain is a domain denied by the user access interface, the user fails authentication.

A preauthentication domain is the ISP domain to which a user belongs before the user passes authentication. The user must pass authentication in the preauthentication domain to obtain necessary network resources (such as IP address) to come online. The device selects a preauthentication domain for a user in the following order:

1. The preauthentication domain specified in the access module. If the specified domain does not exist, the selection process goes to step 4.

2. The interface-specific default preauthentication domain specified by using the aaa default-domain pre-authentication command.

3. The default system ISP domain specified by using the domain default enable command.

4. The ISP domain specified by using the domain if-unknown command. If the specified domain does not exist, the authentication fails.

The device selects an authentication domain in the order as shown in Figure 12.

Figure 12 Authentication domain selection workflow

Configuring default ISP domains on an interface

About this task

Perform this task to configure default ISP domains on an interface for the users that access this interface.

The following default ISP domains are supported on an interface:

· Default preauthentication domain—Users are assigned to this domain before they pass authentication. Once the users pass authentication in this domain, they can obtain IP addresses. To specify a default preauthentication domain, use the aaa default-domain pre-authentication command.

· Default authentication domain—You can configure one of the following default authentication domains on an interface:

¡ Common default authentication domain—Domain applicable only to users whose usernames do not include a domain name. To specify a common default authentication domain, use the aaa default-domain authentication command.

¡ Force default authentication domain—Users are forcibly assigned to this domain. If the username of a user includes a domain name, the device does not change the original domain name in the username. To specify a force default authentication domain, use the aaa default-domain authentication force command.

¡ Replacement default authentication domain—Users are forcibly assigned to this domain. If the username of a user includes a domain name, the device replaces the original domain name in the username with the replacement default domain name. To specify a replacement default authentication domain, use the aaa default-domain authentication replace command.

Restrictions and guidelines

The configuration in this section is applicable only to PPP, IPoE, and LAN users.

The default preauthentication domain takes effect only on IPoE users.

On an interface, you can configure only one default authentication domain (common default authentication domain, force default authentication domain, or replacement default authentication domain). If you configure the default authentication domain multiple times, the most recent configuration takes effect.

Procedure

1. Enter system view.

system-view

2. Enter Layer 3 interface view.

interface interface-type interface-number

3. Configure default ISP domains on the interface.

aaa default-domain { authentication [ force | replace ] isp-name | pre-authentication isp-name } *

By default, no default ISP domains are configured on an interface.

Specifying a roaming domain on an interface

About this task

The device uses the roaming domain to authenticate a user if the user is assigned to the ISP domain carried in the username but the assigned domain does not exist.

Restrictions and guidelines

The configuration in this section is applicable only to PPP, IPoE, and LAN users.

Procedure

1. Enter system view.

system-view

2. Enter Layer 3 interface view.

interface interface-type interface-number

3. Specify a roaming domain on the interface.

aaa roam-domain isp-name

By default, no roaming domain is specified on an interface.

Specifying permitted domains on an interface

About this task

Perform this task to allow only users in specific domains to access an interface.

Restrictions and guidelines

The configuration in this section is applicable only to IPoE users.

You can specify a maximum of 16 permitted domains on an interface.

Permitted domain configuration is mutually exclusive with denied domain configuration on an interface.

Procedure

1. Enter system view.

system-view

2. Enter Layer 3 interface view.

interface interface-type interface-number

3. Specify a permitted domain on the interface.

aaa permit-domain isp-name

By default, no permitted domains are specified on an interface. All ISP domains are permitted.

Specifying denied domains on an interface

About this task

Perform this task to prevent users in specific domains from accessing an interface.

Restrictions and guidelines

The configuration in this section is applicable only to PPP, IPoE, and LAN users.

You can specify a maximum of 16 denied domains on an interface.

Denied domain configuration is mutually exclusive with permitted domain configuration on an interface.

Procedure

1. Enter system view.

system-view

2. Enter Layer 3 interface view.

interface interface-type interface-number

3. Specify a denied domain on the interface.

aaa deny-domain isp-name

By default, no denied domains are specified on an interface.

Setting the maximum number of concurrent login users

About this task

Perform this task to set the maximum number of concurrent users that can log on to the device through a specific protocol, regardless of their authentication methods. The authentication methods include no authentication, local authentication, and remote authentication.

Restrictions and guidelines

You can set the maximum number of concurrent login users for all SSH users in total and for SSH users of a specific type (NETCONF over SSH, SCP, SFTP, or Stelnet). When an SSH user comes online, the system operates as follows:

1. Examines if the number of total online SSH users has reached the upper limit.

2. Examines if the number of online SSH users of the specific type has reached its upper limit.

The user can come online when neither limit is reached.

Procedure

1. Enter system view.

system-view

2. Set the maximum number of concurrent login users.

aaa session-limit { ftp | http | https | ssh [ service-type { netconf | scp | sftp | stelnet } ] | telnet } max-sessions

By default, the maximum number of concurrent login users is 32 for each user type.

Processing shared-account users as non-family users

About this task

By default, shared-account users (concurrent users that share a user account) are processed as family users. The device collectively limits the traffic rate of each shared-account user according to the traffic policing parameters assigned to the shared-account.

Perform this task to process shared-account users as non-family users. In this way, the device will separately limit the traffic rate for each shared-account user according to the traffic policing parameters assigned to the shared account.

Restrictions and guidelines

This configuration is applicable only to PPPoE, IPoE, and L2TP users. It takes effect only on users that come online after the command execution.

For this configuration to take effect on users, make sure one of the following conditions exists:

· The server assigns the Port-Limit attribute (attribute 62) to users.

· The maximum number of concurrent logins per user account has been configured by using the users-per-account command for the ISP domain to which the users belong.

Procedure

3. Enter system view.

system-view

4. Configure the device to process shared-account users as non-family users.

aaa shared-account-user no-family

By default, shared-account users (concurrent users that share a user account) are processed as family users.

Configuring NetStream sampling for users

About this task

The device supports NetStream sampling on authenticated online users' traffic in specified directions. This feature helps the network administrators collect statistics of online users and analyze online users' traffic on a per user basis in real time.

After the device assigns a NetStream sampler to an online user, it immediately starts NetStream sampling on the user's traffic by using the sampler. NetStream sampling stops for a user only if the user goes offline, a new sampler is assigned to the user, or the authorization sampler configuration for the user is cancelled.

Restrictions and guidelines

This feature is applicable only to PPP and IPoE users.

The authorization NetStream samplers can take effect without requiring you to configure other NetStream settings. For a user, this NetStream sampling configuration takes precedence over the NetStream sampling configuration (if any) on the access interface. Interface-specific NetStream sampling configuration applies only to the traffic that does not belong to that user.

Procedure

To assign an authorization NetStream sampler to a user and enable NetStream sampling for the user traffic, execute the following command in user view:

aaa authorize user-name user-name netstream-sampler sampler-name [ inbound | outbound ]

To remove the authorization NetStream sampler assigned to a user, execute the following command in user view:

aaa de-authorize user-name user-name netstream-sampler [ inbound | outbound ]

Configuring the local bill cache feature

About local bill cache

The local bill cache stores accounting bills locally for users that encounter accounting-stop failures (for example, failures caused by unreachable servers). The accounting bills include the following information:

· Start and stop timestamps for accounting sessions.

· User access information.

· Accounting traffic statistics.

Local accounting bills can be exported to a storage directory by using FTP or TFTP. When an accounting server becomes available, it can download the accounting bills from the directory. The following mechanisms are available for exporting accounting bills:

· Automatic mechanism—The system automatically exports the accounting bills at regular intervals or when the number of bills reaches a system-defined threshold. The local bill cache is cleared each time the system finishes an automatic bill export process.

· Manual mechanism—The system exports the accounting bills when the local-bill export command is used. If the clear-cache keyword is specified, the system clears the local bill cache. Use manual mechanism to meet the demands of auditing and analysis when automatic mechanism is unavailable.

Automatic bill export supports SNMP notification. When an automatic bill export fails, the system sends notification messages to the information center.

The local bill cache feature is applicable to LAN, PPP, and IPoE users.

Enabling the local bill cache feature

1. Enter system view.

system-view

2. Enable the local bill cache feature.

local-bill enable

By default, this feature is disabled.

3. Specify the destination URL for exporting accounting bills.

local-bill export-url url

By default, no URL is specified.

4. (Optional.) Set an interval at which accounting bills are exported automatically.

local-bill export-interval interval

By default, the interval is 1440 minutes.

5. (Optional.) Enable SNMP notification for automatic bill export.

snmp-agent trap enable local-bill

By default, SNMP notification is enabled for automatic bill export.

Exporting the accounting bills manually to the specified URL

Restrictions and guidelines

You can perform a manual bill export only on one user line each time. It takes the system a period of time to upload the accounting bills. During this period, the automatic bill export is suspended, and you cannot execute any command on the user line or perform a manual bill export on another user line.

Procedure

1. Enter system view.

system-view

2. Enable the local bill cache feature.

local-bill enable

By default, this feature is disabled.

3. Export the accounting bills manually to the specified URL.

local-bill export [ url ] [ clear-cache ]

Display and maintenance commands for local bill cache

Execute display commands in any view.

Task	Command
Display detailed information about a series of consecutive accounting bills.	display local-bill verbose start-number count count
Display usage statistics of the local bill cache.	display local-bill cache-usage

Configuring a NAS-ID

About NAS-IDs

During RADIUS authentication, the device uses a NAS-ID to set the NAS-Identifier attribute of RADIUS packets so that the RADIUS server can identify the access location of users. You can configure NAS-IDs in different views. The device selects the NAS-ID for the NAS-Identifier attribute in the following order:

1. NAS-ID bound with VLANs for a NAS-ID profile in NAS-ID profile view.

2. NAS-ID configured on an interface in interface view.

3. NAS-ID configured for an ISP domain in ISP domain view.

If no NAS-ID is configured, the device uses the device name (set by using the sysname command) as the NAS-ID.

Configuring a NAS-ID profile

About this task

Configure a NAS-ID profile to maintain NAS-ID and VLAN bindings on the device so that the device can send different NAS-Identifier attribute strings in RADIUS requests from different VLANs.

Restrictions and guidelines

The NAS-ID and VLAN bindings in a NAS-ID profile are applicable only to PPP and IPoE users.

You can directly configure a NAS-ID profile on interfaces by using the aaa nas-id-profile command.

You can configure multiple NAS-ID and VLAN bindings in a NAS-ID profile.

A NAS-ID can be bound with more than one VLAN, but a VLAN can be bound with only one NAS-ID. If you configure multiple bindings for the same VLAN, the most recent configuration takes effect.

The device selects a NAS-ID and VLAN binding for double-tagged packets in the following order:

1. NAS-ID with both matching outer VLAN ID and inner VLAN ID.

2. NAS-ID with a matching outer VLAN ID.

3. NAS-ID with a matching inner VLAN ID.

Procedure

1. Enter system view.

system-view

2. Create a NAS-ID profile and enter NAS-ID profile view.

aaa nas-id profile profile-name

3. Configure a NAS-ID and VLAN binding in the profile.

nas-id nas-identifier bind { { c-vid vlan-id | s-vid vlan-id } * | vlan vlan-id }

In a QinQ network, specify an inner VLAN ID, outer VLAN ID, or both in a binding as a best practice. In a non-QinQ network, you can only specify a VLAN ID in a binding by specifying the vlan vlan-id option.

Setting the NAS-ID on an interface

Restrictions and guidelines

The NAS-ID on an interface is applicable only to PPP and IPoE users that access the network through the interface.

If you set a NAS-ID on an interface and specify a NAS-ID profile for the interface, the NAS and VLAN binding in the NAS-ID profile has higher priority.

Procedure

1. Enter system view.

system-view

2. Enter Layer 3 interface view.

interface interface-type interface-number

3. Set the NAS-ID on the interface.

aaa nas-id nas-identifier

By default, no NAS-ID is set on an interface.

4. (Optional.) Specify a NAS-ID profile for the interface.

aaa nas-id-profile profile-name

By default, no NAS-ID profile is specified for an interface.

Setting the NAS-ID in an ISP domain

1. Enter system view.

system-view

2. Enter ISP domain view.

domain name isp-name

3. Set the NAS-ID in the ISP domain.

nas-id nas-identifier

By default, no NAS-ID is set in an ISP domain.

Setting the SSID on an interface

About this task

In a wireless network, the SSID on a user access interface identifies the SSID of the wireless network to which users on the interface access. The SSID is used as follows:

· Carried in the Web server URL to which the device redirects users.

· Populated in the standard attribute 30 (Called-Station-Id attribute) of outgoing RADIUS authentication requests. The format of the SSID information is 00-00-00-00-00-00:ssid-name.

Restrictions and guidelines

To carry a user SSID in the Web server URL, you must specify the ssid keyword when you execute the web-server url-parameter command.

Do not perform this task if no wireless users exist on the interface.

Procedure

1. Enter system view.

system-view

2. Enter Layer 3 interface view.

interface interface-type interface-number

3. Set the SSID on the interface.

aaa ssid ssid-name

By default, no SSID is set on an interface.

Configuring the device ID

About this task

RADIUS uses the value of the Acct-Session-ID attribute as the accounting ID for a user. The device generates an Acct-Session-ID value for each online user based on the system time, random digits, and device ID.

Procedure

1. Enter system view.

system-view

2. Configure the device ID.

aaa device-id device-id

By default, the device ID is 0.

Enabling password change prompt logging

About this task

Use this feature to enhance the protection of passwords for Telnet, SSH, NETCONF over SSH, and NETCONF over SOAP users and improve the system security.

This feature enables the device to generate logs to prompt users to change their weak passwords at an interval of 24 hours and at the users' login.

A password is a weak password if it does not meet the following requirements:

· Password composition restriction configured by using the password-control composition command.

· Minimum password length restriction set by using the password-control length command.

· Password complexity checking policy configured by using the password-control complexity command.

For a NETCONF over SSH or NETCONF over SOAP user, the device also generates a password change prompt log if any of the following conditions exists:

· The current password of the user is the default password.

· The current password of the user has expired.

· The user logs in to the device for the first time or uses a new password to log in after global password control is enabled.

The device will no longer generate password change prompt logs for a user when one of the following conditions exists:

· The password change prompt logging feature is disabled.

· The user has changed the password and the new password meets the password control requirements.

· The enabling status of a related password control feature has changed so the current password of the user meets the password control requirements.

· The password composition policy or the minimum password length has changed.

Restrictions and guidelines

You can use the display password-control command to display password control configuration. For more information about password control commands, see password control commands in Security Command Reference.

Procedure

3. Enter system view.

system-view

4. Enable password change prompt logging.

local-server log change-password-prompt

By default, password change prompt logging is enabled.

Configuring user online and offline recording

About user online and offline recording

This feature enables the device to record user information when the users fail to come online, or the users go offline normally or abnormally. These records help the administrator to quickly identify the causes of user online and offline faults. The feature occupies the system memory. To reduce the memory usage, you can disable this feature.

Restrictions and guidelines for user online and offline recording configuration

This feature is applicable only to PPP, IPoE, login, and LAN users.

The user online and offline recording feature does not take effect on PPP or IPoE users with EDSG services.

Enabling user online failure recording

1. Enter system view.

system-view

2. Enable user online failure recording.

aaa online-fail-record enable

By default, user online failure recording is enabled.

Enabling user offline recording

1. Enter system view.

system-view

2. Enable user offline recording.

aaa offline-record enable

By default, user offline recording is enabled.

User normal offline recording and user abnormal offline recording take effect only when this feature is enabled.

3. Enable user normal offline recording.

aaa normal-offline-record enable

By default, user normal offline recording is enabled.

4. Enable user abnormal offline recording.

aaa abnormal-offline-record enable

By default, user abnormal offline recording is enabled.

Display and maintenance commands for user online and offline recording

Execute display commands in any view and reset commands in user view.

Task	Command
Display user abnormal offline records.	display aaa abnormal-offline-record { access-type { ipoe \| lan-access \| login \| ppp } \| domain domain-name \| interface interface-type interface-number \| { ip ipv4-address \| ipv6 ipv6-address } \| mac-address mac-address \| s-vlan svlan-id [ c-vlan cvlan-id ] \| slot slot-number \| username user-name [ fuzzy-match ] } * [ brief \| count count ] display aaa abnormal-offline-record offline-reason { idle-cut \| quota-out \| realtime-acct-fail \| session-timeout \| user-detect-fail } [ brief ] display aaa abnormal-offline-record time begin-time end-time [ date begin-date end-date ] [ brief ] display aaa abnormal-offline-record
Display user normal offline records.	display aaa normal-offline-record { access-type { ipoe \| lan-access \| login \| ppp } \| domain domain-name \| interface interface-type interface-number \| { ip ipv4-address \| ipv6 ipv6-address } \| mac-address mac-address \| s-vlan svlan-id [ c-vlan cvlan-id ] \| slot slot-number \| username user-name [ fuzzy-match ] } * [ brief \| count count ] display aaa normal-offline-record time begin-time end-time [ date begin-date end-date ] [ brief ] display aaa normal-offline-record
Display user offline records.	display aaa offline-record { access-type { ipoe \| lan-access \| login \| ppp } \| domain domain-name \| interface interface-type interface-number \| { ip ipv4-address \| ipv6 ipv6-address } \| mac-address mac-address \| s-vlan svlan-id [ c-vlan cvlan-id ] \| slot slot-number \| username user-name [ fuzzy-match ] } * [ brief \| count count ] display aaa offline-record time begin-time end-time [ date begin-date end-date ] [ brief ] display aaa offline-record
Display user online failure records.	display aaa online-fail-record { access-type { ipoe \| lan-access \| login \| ppp } \| domain domain-name \| interface interface-type interface-number \| { ip ipv4-address \| ipv6 ipv6-address } \| mac-address mac-address \| s-vlan svlan-id [ c-vlan cvlan-id ] \| slot slot-number \| username user-name [ fuzzy-match ] } * [ brief \| count count ] display aaa online-fail-record time begin-time end-time [ date begin-date end-date ] [ brief ] display aaa online-fail-record
Display descriptions of online-offline reason codes.	display aaa online-offline-reason [ code code-id ]
Clear user abnormal offline records.	reset aaa abnormal-offline-record
Clear user normal offline records.	reset aaa normal-offline-record reset aaa offline-record [ slot slot-number \| up-id up-id ]
Clear user offline records.	reset aaa offline-record
Clear user online failure records.	reset aaa online-fail-record

Configuring the AAA test feature

About this task

This feature enables the device to send authentication or accounting requests to the specified AAA servers to simulate an authentication or accounting process of a user. Use this feature to identify the reasons for the failure of the interaction between the device and the AAA servers. This feature is applicable only to RADIUS.

When performing an AAA test, the device ignores the status of the specified AAA servers and the RADIUS server load sharing feature. The process of an AAA test is as follows:

1. The device sends authentication requests that carry the specified username and password to the specified authentication server or to the authentication servers in the specified RADIUS scheme. The device tries to communicate with the authentication servers in the specified scheme in sequence.

The process goes to the next step in the following situations:

¡ The device receives an authentication response (no matter the authentication succeeds or fails).

¡ The device does not receive any authentication response after making all authentication request attempts.

This step is skipped if no correct authentication server is specified for the AAA test or no authentication servers are configured in the specified RADIUS scheme.

2. The device sends start-accounting requests to the specified accounting server or to the accounting servers in the specified RADIUS scheme. The device tries to communicate with the accounting servers in the specified scheme in sequence.

The process goes to the next step in the following situations:

¡ The device receives a start-accounting response (no matter the accounting succeeds or fails).

¡ The device does not receive any start-accounting response after making all start-accounting request attempts.

This step and the next step are skipped if no correct accounting server is specified for the AAA test or no accounting servers are configured in the specified RADIUS scheme.

3. The device sends stop-accounting requests to the accounting servers to which it has sent a start-accounting request.

The process finishes in the following situations:

¡ The device receives a stop-accounting response.

¡ The device does not receive any stop-accounting response after making all stop-accounting request attempts.

To identify attributes that cause authentication or accounting failures, you can configure the device to carry specific attributes in RADIUS requests or define values for specific attributes in the requests. Table 4 shows the attributes that RADIUS requests carry by default.

Table 4 Attributes that RADIUS requests carry by default

Packet type	Attributes that the type of packets carry by default
RADIUS authentication request	User-Name CHAP-Password (or User-Password) CHAP-Challenge NAS-IP-Address (or NAS-IPv6-Address) Service-Type Framed-Protocol NAS-Identifier NAS-Port-Type Acct-Session-Id
RADIUS accounting request	User-Name Acct-Status-Type NAS-IP-Address (or NAS-IPv6-Address) NAS-Identifier Acct-Session-Id Acct-Delay-Time Acct-Terminate-Cause

Packet type

Attributes that the type of packets carry by default

RADIUS authentication request

User-Name

CHAP-Password (or User-Password)

CHAP-Challenge

NAS-IP-Address (or NAS-IPv6-Address)

Service-Type

Framed-Protocol

NAS-Identifier

NAS-Port-Type

Acct-Session-Id

RADIUS accounting request

User-Name

Acct-Status-Type

NAS-IP-Address (or NAS-IPv6-Address)

NAS-Identifier

Acct-Session-Id

Acct-Delay-Time

Acct-Terminate-Cause

Restrictions and guidelines

When you perform an AAA test, follow these restrictions and guidelines:

· The device might communicate with the AAA servers incorrectly during an AAA test. Make sure no users come online or go offline during an AAA text.

· If the configuration of the specified RADIUS scheme changes, the new configuration does not affect the current AAA test. The modification will take effect in the next test.

· The system can have only one AAA test at a time. Another AAA test can be performed only after the current test finishes.

When you configure attributes to be included in or excluded from RADIUS requests, follow these restrictions and guidelines:

· Before you include an attribute that is already configured to be excluded from RADIUS requests, you must cancel the exclusion configuration by using the undo exclude command.

· Before you exclude an attribute that is already configured to be included in RADIUS requests, you must cancel the inclusion configuration by using the undo include command.

Prerequisites

Before you perform an AAA test, you must configure a RADIUS scheme that contains the RADIUS servers to be tested.

Plan the RADIUS attributes to be included in RADIUS requests. Besides the attributes carried by default, the device adds the specified attributes to RADIUS packets in the order that they are specified by using the include command. Additional attributes cannot be added to a RADIUS request if the length of the RADIUS request will reach or exceed 4096 bytes.

Procedure

1. (Optional.) Configure a RADIUS attribute test group:

a. Enter system view.

system-view

b. Create a RADIUS attribute test group and enter its view.

radius attribute-test-group attr-test-group-name

You can create multiple RADIUS attribute test groups.

c. Include an attribute in RADIUS requests.

include { accounting | authentication } { name attribute-name | [ vendor vendor-id ] code attribute-code } type { binary | date | integer | interface-id | ip | ipv6 | ipv6-prefix | octets | string } value attribute-value

For an attribute that RADIUS requests carry by default, use this command to change its attribute value.

d. Exclude an attribute from RADIUS requests.

exclude { accounting | authentication } name attribute-name

e. Return to system view.

quit

f. Return to user view.

quit

2. Perform an AAA test in user view.

test-aaa user user-name password password radius-scheme radius-scheme-name [ radius-server { ipv4-address | ipv6 ipv6-address } port-number [ vpn-instance vpn-instance-name ] ] [ chap | pap ] [ attribute-test-group attr-test-group-name ] [ trace ]

Recommended actions on failed test results

If you receive an error message after you execute the test-aaa command, use the following information to remove the issue:

Message	Possible causes	Recommended action
Authentication or accounting request expired	The device cannot reach the RADIUS server.	Check for communication issues between the device and the server.
	The device and the RADIUS server are inconsistent in the following settings: · UDP port number for RADIUS authentication or accounting service. · Shared key for authentication or accounting.	1. Examine the RADIUS scheme used in the authentication domain. 2. Make sure the scheme contains the same service port numbers and shared keys as the RADIUS authentication, authorization, and accounting servers.
	The IP address of the device is not added to the RADIUS server. Incorrect IP address is added to the RADIUS server for the device.	Add the node IP address of the device to the RADIUS server. IMPORTANT: This IP address must be the source IP address used by the device to send RADIUS packets to the RADIUS server.
	The RADIUS authentication or accounting service port number has been used by another program on the server.	1. Search the server for conflicting service numbers. 2. Close the program that uses the same port number as the RADIUS authentication or accounting service.
Authentication request rejected by the RADIUS server	This issue might result from various errors, for example, user information not found in the database of the RADIUS server or incorrect user password.	1. Review the authentication log on the RADIUS server. 2. Take action depending on the cause of rejection and the failure cause provided in the log.
The RADIUS scheme does not contain RADIUS authentication or accounting servers or does not contain the specified server	The RADIUS scheme specified for the test-aaa command has one of the following issues: · The scheme does not contain RADIUS authentication or accounting servers. · The RADIUS server parameters specified in the scheme are inconsistent with the actual settings for the target servers.	1. Examine the RADIUS scheme and make sure: ¡ The scheme contains a minimum of one RADIUS authentication server and a minimum of one RADIUS accounting server. ¡ The RADIUS server parameters specified in the scheme are consistent with the actual settings for the target servers. 2. Re-execute the test-aaa command with the correct RADIUS scheme.

Enabling SNMP notifications for ISP domains

About this task

After you enable SNMP notifications for ISP domains, the device generates a notification if a specific event occurs in an ISP domain. For ISP domain event notifications to be sent correctly, you must also configure SNMP on the device. For more information about SNMP configuration, see Network Management and Monitoring Configuration Guide.

The device supports SNMP notifications for the following events:

· Changes in the reachability to the IPv4 and IPv6 Web server URLs an ISP domain. The device generates a notification in the following situations:

¡ A Web server URL changes from unreachable to reachable.

¡ A Web server URL changes from reachable to unreachable.

¡ The Web server URL in use is changed to another URL.

· Events about authorization IPv4 address usage and authorization IPv6 address or prefix usage in an ISP domain. Based on the usage periodically provided by the DHCP and DHCPv6 modules, the device generates notifications as shown in Table 5. In addition, the device generates logs about authorization IPv4 address usage and authorization IPv6 address or prefix usage. For more information about the logs, see the system log message reference.

Authorization IPv4 address usage refers to the usage of IPv4 addresses in the authorization IPv4 address pool or pool group. The IPv4 addresses are allocated by DHCP.

Authorization IPv6 address or prefix usage refers to the usage of IPv6 addresses or prefixes in the authorization IPv6 address pool or pool group or in the authorization ND prefix pool or pool group.

Table 5 Alarm notifications and alarm-removed notifications

Notification	Triggering condition	Remarks
Low alarm notification	Authorization IPv4 address usage or authorization IPv6 address or prefix usage reaches or drops below the low alarm threshold for the first time.	The default low alarm threshold is 0. After generating and sending a low alarm notification, the system typically does not generate or send any additional low alarm notifications until the first low alarm is removed.
Low alarm-removed notification	Authorization IPv4 address usage or authorization IPv6 address or prefix usage reaches or exceeds the value calculated by using the following formula: Low alarm threshold + (high alarm threshold – low alarm threshold)*10%.	If you cancel the low alarm threshold setting when the system is still in low alarm state, the system will automatically generate and send a notification to remove the low alarm.
High alarm notification	Authorization IPv4 address usage or authorization IPv6 address or prefix usage reaches or exceeds the high alarm threshold for the first time.	The default high alarm threshold is 100. After generating and sending a high alarm notification, the system typically does not generate or send any additional high alarm notifications until the first high alarm is removed.
High alarm-removed notification	Authorization IPv4 address usage or authorization IPv6 address or prefix usage drops below or reaches the value calculated by using the following formula: High alarm threshold – (high alarm threshold – low alarm threshold)*10%.	If you cancel the high alarm threshold setting when the system is still in high alarm state, the system will automatically generate and send a notification to remove the high alarm.

The system uses value 0 for the low alarm threshold and 100 for the high alarm threshold when no low or high alarm threshold is set.

If you change one of the following settings, the system determines whether to generate one notification only based on the new settings regardless of whether another notification of the same type has been generated:

¡ An alarm threshold setting for authorization IPv4 address usage or authorization IPv6 address or prefix usage in the ISP domain.

¡ The authorization IPv4 address pool, IPv4 address pool group, IPv6 address pool, ND prefix pool, IPv6 address pool group, or ND prefix pool group specified for the ISP domain.

¡ The configuration in the authorization IPv4 address pool, IPv4 address pool group, IPv6 address pool, ND prefix pool, IPv6 address pool group, or ND prefix pool group of the ISP domain.

Restrictions and guidelines

For this feature to take effect when the device acts as a DHCP or DHCPv6 relay agent, you must execute the network command in the relay address pool on the DHCP relay agent. Make sure the subnet specified in the network command is the same as the subnet specified for the IP pool of the DHCP server.

As a best practice to make better use of SNMP notifications for reachability status changes of Web server URLs, associate the URLs with track entries when you specify the URLs. In addition, associate each of the track entries with an HTTP NQA operation. The URL-Track-NQA collaboration will detect the reachability and performance of the Web servers in time.

Procedure

1. Enter system view.

system-view

2. Enable SNMP notifications for ISP domains.

snmp-agent trap enable domain { ip-usage-warning | ipv6-usage-warning | web-server-ipv6-url-warning | web-server-url-warning } *

By default, SNMP notifications are disabled for ISP domains.

3. Enter ISP domain view.

domain name isp-name

4. Set the alarm thresholds for authorization IPv4 address usage.

ip-usage-warning { high-threshold high-value | low-threshold low-value }

By default, no alarm thresholds are set for authorization IPv4 address usage. The system does not generate alarm notifications about authorization IPv4 address usage.

5. Set the alarm thresholds for authorization IPv6 address or prefix usage.

ipv6-usage-warning { high-threshold high-value | low-threshold low-value }

By default, no alarm thresholds are set for authorization IPv6 address or prefix usage. The system does not generate alarm notifications about authorization IPv6 address or prefix usage.

Configuring SNMP notification for AAA

About this task

With SNMP notification for user login failure configured, the system generates a user login failure alarm for a device management user when either of the following cases exist:

· The number of user login failures reaches the triggering threshold for the first time within an alarm period.

· The number of user login failures increases from a value below the clearing threshold to the triggering threshold within an alarm period.

When the number of user login failures drops from the triggering threshold or higher to the clearing threshold or lower within an alarm period, the systems generates an alarm removal message.

Procedure

1. Enter system view.

system-view

2. Enable SNMP notification for AAA.

snmp-agent trap enable aaa [ login-failed-threshold ]

By default, SNMP notification for AAA is enabled.

3. Configure SNMP notification parameters for user login failures.

aaa login-failed alarm-threshold trigger-threshold trigger-threshold clear-threshold clear-threshold period period

By default, the triggering threshold, clearing threshold, and alarm period is 30, 20, and 5 minutes, respectively.

Configuring the RADIUS proxy feature

About the RADIUS proxy feature

Figure 13 shows a typical RADIUS proxy network diagram. The BRAS is enabled with IPoE authentication to provide access authentication service for users. The AC is bypassingly deployed at the BRAS side to perform 802.1X authentication on wireless clients. In this situation, the authentication information of wired and wireless users is stored on different devices. To simplify user information management and unify user access strategies, enable the RADIUS proxy feature on the BRAS and specify the AC as a RADIUS client.

With the RADIUS proxy feature, the BRAS listens for authentication request packets from the AC (a RADIUS client) on the specified port and forwards the packets to the RADIUS server. In addition, the BRAS listens for RADIUS response packets from the RADIUS server and forwards the packets to the AC. Finally, the BRAS participates in both IPoE authentication and wireless 802.1X authentication.

For the AC to cooperate with the BRAS to implement RADIUS proxy, you must specify the BRAS as the RADIUS authentication and accounting server for wireless clients on the AC.

Figure 13 RADIUS proxy network diagram

As shown in Figure 13, the RADIUS proxy workflow is as follows when a wireless client accesses the network:

1. The AC that acts as a RADIUS client forwards the authentication request packets of the wireless client to the RADIUS server (the BRAS).

2. Upon receiving an authentication request packet, the RADIUS proxy (the BRAS) matches the source IP address and VPN instance of the packet with local RADIUS client settings.

¡ If no matching RADIUS client is found or no RADIUS client has been specified on the BRAS, the BRAS discards the packet.

¡ If a matching RADIUS client is found, the BRAS uses the shared key of the matching RADIUS client to validate the packet. If the packet fails the validation, the BRAS discards the packet. If the packet passes the validation, the BRAS forwards the packet to the RADIUS server.

3. Upon receiving the Access-Accept response for the user from the RADIUS server if the user passes authentication, the RADIUS proxy creates a local proxy user entry for that user. The entry records the user's MAC address, username, IP address, endpoint information, and authorization attributes. At the same time, the RADIUS proxy creates an aging timer for the user entry at the first authentication. Then, the RADIUS proxy reorganizes the RADIUS response packet and forwards the packet to the RADIUS client.

4. After receiving the RADIUS response packet, if the authentication result is pass, the RADIUS client sends start-accounting request packets to the RADIUS server (the BRAS).

5. Upon receiving the start-accounting request packets, the RADIUS proxy directly processes the packets instead of forwarding the packets to the RADIUS server. It matches the source IP address and VPN instance of the packets with local RADIUS client settings and validates the packets. The validation method is the same as that of an authentication request packet. The RADIUS proxy responds to the RADIUS client with accounting success or failure depending on whether the start-accounting request packets pass the validation.

The process of subsequent real-time accounting packets is the same as the process of start-accounting packets.

6. The wireless client sends a DHCP request packet to the BRAS to obtain an IP address or directly sends data traffic to the BRAS, which triggers IPoE authentication on the BRAS. Then, the RADIUS proxy searches authorization information in local proxy user entries based on the user MAC address of the wireless client.

¡ If authorization information of the user account exists, the RADIUS proxy assigns the authorization information (including IP address information) to the IPoE wireless client. At the same time, the RADIUS proxy saves the user session ID in the local proxy user entry and stops the aging timer for the local proxy user entry. Then, the BRAS sends a start-accounting request packet to the RADIUS server for the IPoE user.

¡ If RADIUS proxy is disabled or no matching local proxy user entry exists, the BRAS turns to a backup authentication method. If authentication fails again by using the backup method, the IPoE user cannot come online.

Transparent to the wireless client, the RADIUS proxy process does not require the client to repeatedly enter the username and password.

7. If the RADIUS server (acts as a DAC) sends a DAE request to the RADIUS proxy, the RADIUS proxy processes the request and forwards it to the RADIUS client (DAS). Then, the RADIUS proxy listens for DAE responses from the DAS and forwards the responses to the DAC.

8. When the accounting for the wireless client needs to stop (for example, if proactive disassociation or roaming occurs), the RADIUS client sends a stop-accounting request packet to the RADIUS proxy. The RADIUS proxy directly responds to the request and performs the corresponding action:

¡ Clears the local proxy user entry but does not inform IPoE to delete the IPoE session.

¡ Ignores the stop-accounting request and does not clear the local proxy user entry. In this case, the local proxy user entry and the related IPoE session still exist.

9. When the IPoE user goes offline (for example, if the IP address is released), BRAS sends a stop-accounting request to the RADIUS server and deletes the corresponding IPoE session. The RADIUS proxy restarts the aging timer based on the current configuration for the local proxy user entry.

Restrictions and guidelines for RADIUS proxy configuration

Restrictions and guidelines for RADIUS scheme configuration

As a best practice to avoid user authentication failure or residual user information on the RADIUS proxy caused by RADIUS server switchover, follow these restrictions:

· Configure the RADIUS proxy device as the only RADIUS server in the RADIUS scheme used by a RADIUS client to perform AAA on wireless clients.

· Make sure the following product on the RADIUS client is larger than the following product on the RADIUS proxy:

¡ The product of the maximum number of attempts to transmit a RADIUS request and the RADIUS server response timeout timer in the RADIUS scheme on the RADIUS client.

The maximum number of attempts to transmit a RADIUS request is set by using the retry command, and the RADIUS server response timeout timer is set by using the timer response-timeout command.

¡ The product of the maximum number of attempts to transmit a RADIUS request, the RADIUS server response timeout timer, and the number of RADIUS servers on the RADIUS proxy.

The RADIUS proxy processes accounting packets sent by a RADIUS client in a special manner. Follow these restrictions and guidelines when you configure the RADIUS proxy feature:

· The RADIUS proxy indeed does not process accounting packets sent by the RADIUS client. As a best practice to ensure that all accounting packets of access users are processed correctly, do not enable the RADIUS proxy feature on the BRAS in a non-IPoE plus wireless 802.1X network.

· On the RADIUS client, you must specify the same RADIUS scheme for wireless client authentication, authorization, and accounting. The configuration ensures that the RADIUS proxy can listen for the stop-accounting request packets of the wireless clients and clear the corresponding local proxy user entries in time to release memory space. In addition, execute the stop-accounting-packet send-force command on the RADIUS client. This command forces the RADIUS client to send a stop-accounting request packet to the RADIUS proxy. As a result, the residual user information is cleared in time on the RADIUS proxy.

· On the RADIUS proxy, the accounting server for wireless client IPoE access must be the same as the authentication server in the RADIUS scheme specified in RADIUS proxy view for the wireless clients. A violation might cause accounting exceptions.

To ensure that a wireless client that uses CHAP authentication to come online, configure the RADIUS proxy and the RADIUS client to use the same authentication shared key. If the authentication shared keys are different, the RADIUS proxy still generates a local proxy user entry for the wireless client. In this case, you need to check the configuration for errors and clear the invalid user entry.

Restrictions and guidelines for the usernames used by the RADIUS proxy during IPoE accounting

When the RADIUS proxy performs IPoE accounting on a wireless client, it does not use the IPoE username configured on the RADIUS proxy. Instead, the RADIUS proxy selects a username for the wireless client based on the authorization information.

· If the authentication server does not assign a username to the wireless client, the RADIUS proxy uses the username used in 802.1X authentication on the RADIUS client. In this situation, the wireless client has the same username on the RADIUS proxy and the RADIUS client.

· If the authentication server assigns a username to the wireless client, the RADIUS proxy uses the assigned username. Because 802.1X authentication does not support username authorization, the wireless client has different usernames on the RADIUS proxy and the RADIUS client.

If the authentication server assigns a username to the wireless client, the RADIUS client cannot respond to the DAE requests sent by the RADIUS server (a DAC) to the RADIUS proxy. The RADIUS client cannot find user information corresponding to the assigned username.

Restrictions and guidelines for configuring the RADIUS proxy feature together with the RADIUS session-control feature

The RADIUS proxy cannot forward session-control packets to RADIUS clients.

By default, the RADIUS proxy and RADIUS session-control features both use UDP port 1812 to listen for packets. If you use both of the features, make sure the two features use different listening ports.

Prerequisites for RADIUS proxy configuration

On each RADIUS client, configure authentication, authorization, and accounting methods for 802.1X wireless clients. Make sure the authentication, authorization, and accounting servers are all the RADIUS proxy device.

Enable IPoE and configure the Layer 2 access mode for IPv4 users on the RADIUS proxy device. Configure RADIUS proxy authentication and authorization for IPoE users. Configure the accounting methods if required.

Procedure

1. Enter system view.

system-view

2. Enable the RADIUS proxy feature and enter RADIUS proxy view.

radius-proxy

3. Specify a RADIUS client.

client { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] radius-scheme radius-scheme-name [ key { cipher | simple } string ] [ authentication-port authentication-port-num ] [ accounting-port accounting-port-num ] [ dae-server-port dae-server-port-num ]

By default, no RADIUS clients are specified.

4. (Optional.) Set the aging time of local proxy user entries.

timer aging aging-time

By default, the aging time for local proxy user entries is 720 minutes.

5. (Optional.) Enable the RADIUS proxy to ignore stop-accounting requests.

stop-accounting ignore

By default, the RADIUS proxy does not ignore stop-accounting requests and clears the corresponding local proxy user entry upon receiving a stop-accounting request.

For a device enabled with RADIUS proxy to support reassociation of IPoE users after unexpected association, enable this feature as a best practice.

Display and maintenance commands for RADIUS proxy

Execute display commands in any view and reset commands in user view.

Task	Command
Display RADIUS proxy packet statistics for a RADIUS client.	display radius-proxy statistics client { ip ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ]
Display RADIUS proxy user information for RADIUS clients.	display radius-proxy user [ client { ip ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ] [ count ]
Clear RADIUS proxy packet statistics for RADIUS clients.	reset radius-proxy statistics [ client { ip ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ]
Clear RADIUS proxy user information.	reset radius-proxy user [ mac mac-address [ client { ip ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ] \| client { ip ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ]

‌

AAA configuration examples

Example: Configuring authentication and authorization for SSH users by a RADIUS server

Network configuration

As shown in Figure 14, configure the router to meet the following requirements:

· Use the RADIUS server for SSH user authentication and authorization.

· Include domain names in the usernames sent to the RADIUS server.

· Assign the network-admin user role to SSH users after they pass authentication.

The RADIUS server runs IMC PLAT 7.3 (E0605) and IMC UAM 7.3 (E0512). Add an account with username hello@bbb on the RADIUS server.

The RADIUS server and the router use expert as the shared key for secure RADIUS communication. The ports for authentication and accounting are 1812 and 1813, respectively.

Figure 14 Network diagram

‌

Prerequisites

# Configure IP addresses for interfaces, and make sure the network connections are available.

Configuring the RADIUS server

1. Add the router to the IMC Platform as an access device:

a. Log in to IMC.

b. Click the User tab.

c. From the navigation tree, select User Access Policy > Access Device Management > Access Device.

d. Click Add.

The Add Access Device page opens.

e. In the Access Configuration area, configure the following parameters, as shown in Figure 15:

- Set the authentication port and accounting port to 1812 and 1813, respectively.

- Select Device Management Service from the Service Type list.

- Select H3C (General) from the Access Device Type list.

- Set the shared key for secure RADIUS communication to expert.

- Use the default values for other parameters.

f. In the Device List area, click Select or Add Manually to add the device at 10.1.1.2 as an access device.

IMPORTANT:

You must specify the source IP address of outgoing RADIUS packets on the router as the IP address of the access device on the server.

On the router, the source IP address configured by using the source-ip command has higher priority than the source IP address configured by using the radius source-ip command. If no IP address is specified as the source IP address, the IP address of the packet outbound interface is used as the source IP address.

In this example, no source IP address is specified on the router. The IP address of the packet outbound interface on the router is specified as the IP address of the access device on the server, which is 10.1.1.2.

g. Click OK.

Figure 15 Adding the router as an access device

2. Add an account for device management:

a. Click the User tab.

b. From the navigation tree, select Device User > Device User.

c. Click Add.

d. On the Add Device User page, configure the following parameters, as shown in Figure 16:

- Enter account name hello@bbb and specify the password.

- Select SSH from the Login Type list.

- Enter network-admin in the Role Name field.

- In the IP Address List of Managed Devices area, click Add to specify an IP segment (from 10.1.1.0 to 10.1.1.255) for management.

IMPORTANT:

The managed IP segment must contain the NAS IP address of the router.

On the router, the priority of the NAS IP addresses configured by using the aaa nas-ip, nas-ip, and radius nas-ip commands are in descending order. If no IP address is specified as the NAS IP address, the IP address of the packet outbound interface is used as the NAS IP address.

In this example, no NAS IP address is specified on the router. The IP address (10.1.1.2) of the packet outbound interface on the router must be contained in the managed IP segment.

e. Click OK.

Figure 16 Adding an account for device management

Configuring the router

# Configure the IP addresses for interfaces. (Details not shown.)

# Create local RSA and DSA key pairs.

<Router> system-view

[Router] public-key local create rsa

[Router] public-key local create dsa

# Enable the Stelnet server.

[Router] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.

[Router] line vty 0 63

[Router-line-vty0-63] authentication-mode scheme

[Router-line-vty0-63] quit

# Create a RADIUS scheme.

[Router] radius scheme rad

# Specify the primary authentication server.

[Router-radius-rad] primary authentication 10.1.1.1 1812

# Set the shared key to expert in plaintext form for secure communication with the server.

[Router-radius-rad] key authentication simple expert

# Include domain names in the usernames sent to the RADIUS server.

[Router-radius-rad] user-name-format with-domain

[Router-radius-rad] quit

# Create an ISP domain named bbb and configure authentication, authorization, and accounting methods for login users. Because RADIUS user authorization information is piggybacked in authentication responses, the authentication and authorization methods must use the same RADIUS scheme.

[Router] domain name bbb

[Router-isp-bbb] authentication login radius-scheme rad

[Router-isp-bbb] authorization login radius-scheme rad

[Router-isp-bbb] accounting login none

[Router-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the router, and enter username hello@bbb and the correct password. The user logs in to the router. (Details not shown.)

# Verify that the user can use the commands permitted by the network-admin user role. (Details not shown.)

Example: Configuring local authentication and authorization for SSH users

Network configuration

As shown in Figure 17, configure the router to meet the following requirements:

· Perform local authentication and authorization for SSH users.

· Assign the network-admin user role to SSH users after they pass authentication.

Figure 17 Network diagram

‌

Prerequisites

# Configure IP addresses for interfaces, and make sure the network connections are available.

Procedure

# Create local RSA and DSA key pairs.

<Router> system-view

[Router] public-key local create rsa

[Router] public-key local create dsa

# Enable the Stelnet server.

[Router] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.

[Router] line vty 0 63

[Router-line-vty0-63] authentication-mode scheme

[Router-line-vty0-63] quit

# Create a device management user.

[Router] local-user ssh class manage

# Assign the SSH service to the local user.

[Router-luser-manage-ssh] service-type ssh

# Set the password to 123456TESTplat&! in plaintext form for the local user.

[Router-luser-manage-ssh] password simple 123456TESTplat&!

# Specify the user role for the user as network-admin.

[Router-luser-manage-ssh] authorization-attribute user-role network-admin

[Router-luser-manage-ssh] quit

# Create an ISP domain named bbb and configure the domain to use local authentication and authorization for login users.

[Router] domain name bbb

[Router-isp-bbb] authentication login local

[Router-isp-bbb] authorization login local

[Router-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the router, and enter username ssh@bbb and the correct password. The user logs in to the router. (Details not shown.)

# Verify that the user can use the commands permitted by the network-admin user role. (Details not shown.)

Example: Configuring AAA for SSH users by an HWTACACS server

Network configuration

As shown in Figure 18, configure the router to meet the following requirements:

· Use the HWTACACS server for SSH user authentication, authorization, and accounting.

· Assign the default user role network-operator to SSH users after they pass authentication.

· Exclude domain names from the usernames sent to the HWTACACS server.

· Use expert as the shared keys for secure HWTACACS communication.

Figure 18 Network diagram

‌

Prerequisites

# Configure IP addresses for interfaces, and make sure the network connections are available.

Configuring the HWTACACS server

# Set the shared keys to expert for secure communication with the router, add an account for the SSH user, and specify the password. (Details not shown.)

Configuring the router

# Create an HWTACACS scheme.

<Router> system-view

[Router] hwtacacs scheme hwtac

# Specify the primary authentication server.

[Router-hwtacacs-hwtac] primary authentication 10.1.1.1 49

# Specify the primary authorization server.

[Router-hwtacacs-hwtac] primary authorization 10.1.1.1 49

# Specify the primary accounting server.

[Router-hwtacacs-hwtac] primary accounting 10.1.1.1 49

# Set the shared keys to expert in plaintext form for secure HWTACACS communication.

[Router-hwtacacs-hwtac] key authentication simple expert

[Router-hwtacacs-hwtac] key authorization simple expert

[Router-hwtacacs-hwtac] key accounting simple expert

# Exclude domain names from the usernames sent to the HWTACACS server.

[Router-hwtacacs-hwtac] user-name-format without-domain

[Router-hwtacacs-hwtac] quit

# Create an ISP domain and configure the domain to use the HWTACACS scheme for authentication, authorization, and accounting of login users.

[Router] domain name bbb

[Router-isp-bbb] authentication login hwtacacs-scheme hwtac

[Router-isp-bbb] authorization login hwtacacs-scheme hwtac

[Router-isp-bbb] accounting login hwtacacs-scheme hwtac

[Router-isp-bbb] quit

# Create local RSA and DSA key pairs.

[Router] public-key local create rsa

[Router] public-key local create dsa

# Enable the Stelnet server.

[Router] ssh server enable

# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.

[Router] role default-role enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.

[Router] line vty 0 63

[Router-line-vty0-63] authentication-mode scheme

[Router-line-vty0-63] quit

Verifying the configuration

# Initiate an SSH connection to the router, and enter the correct username and password. The user logs in to the router. (Details not shown.)

# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)

Example: Configuring authentication for SSH users by an LDAP server

Network configuration

As shown in Figure 19, the LDAP server uses domain ldap.com and runs Microsoft Windows 2003 Server Active Directory.

Configure the router to meet the following requirements:

· Use the LDAP server to authenticate SSH users.

· Assign the level-0 user role to SSH users after they pass authentication.

On the LDAP server, set the administrator password to admin!123456, add a user named aaa, and set the user's password to ldap!123456.

Figure 19 Network diagram

‌

Prerequisites

# Configure IP addresses for interfaces, and make sure the network connections are available.

Configuring the LDAP server

1. Add a user named aaa and set the password to ldap!123456:

a. On the LDAP server, select Start > Control Panel > Administrative Tools.

b. Double-click Active Directory Users and Computers.

The Active Directory Users and Computers window is displayed.

c. From the navigation tree, click Users under the ldap.com node.

d. Select Action > New > User from the menu to display the dialog box for adding a user.

e. Enter logon name aaa and click Next.

Figure 20 Adding user aaa

f. In the dialog box, enter password ldap!123456, select options as needed, and click Next.

Figure 21 Setting the user's password

g. Click OK.

2. Add user aaa to group Users:

a. From the navigation tree, click Users under the ldap.com node.

b. In the right pane, right-click user aaa and select Properties.

c. In the dialog box, click the Member Of tab and click Add.

Figure 22 Modifying user properties

d. In the Select Groups dialog box, enter Users in the Enter the object names to select field, and click OK.

User aaa is added to group Users.

Figure 23 Adding user aaa to group Users

3. Set the administrator password to admin!123456:

a. In the right pane, right-click user Administrator and select Set Password.

b. In the dialog box, enter the administrator password. (Details not shown.)

Configuring the router

# Create the local DSA key pair and RSA key pairs.

<Router> system-view

[Router] public-key local create dsa

[Router] public-key local create rsa

# Enable the Stelnet server.

[Router] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.

[Router] line vty 0 63

[Router-line-vty0-63] authentication-mode scheme

[Router-line-vty0-63] quit

# Configure an LDAP server.

[Router] ldap server ldap1

# Specify the IP address of the LDAP authentication server.

[Router-ldap-server-ldap1] ip 10.1.1.1

# Specify the administrator DN.

[Router-ldap-server-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com

# Specify the administrator password.

[Router-ldap-server-ldap1] login-password simple admin!123456

# Configure the base DN for user search.

[Router-ldap-server-ldap1] search-base-dn dc=ldap,dc=com

[Router-ldap-server-ldap1] quit

# Create an LDAP scheme.

[Router] ldap scheme ldap1-shml

# Specify the LDAP authentication server.

[Router-ldap-ldap-shml] authentication-server ldap1

[Router-ldap-ldap1-shml] quit

# Create an ISP domain named bbb and configure the authentication, authorization, and accounting methods for login users.

[Router] domain name bbb

[Router-isp-bbb] authentication login ldap-scheme ldap1-shml

[Router-isp-bbb] authorization login none

[Router-isp-bbb] accounting login none

[Router-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the router, and enter username aaa@bbb and password ldap!123456. The user logs in to the router. (Details not shown.)

# Verify that the user can use the commands permitted by the level-0 user role. (Details not shown.)

Example: Configuring AAA for PPP users by an HWTACACS server

Network configuration

As shown in Figure 24:

· Router A uses the HWTACACS server to perform PAP authentication for users from Router B.

· The HWTACACS server is also the authorization server and accounting server of Router B.

· Router B does not provide authentication, authorization, or accounting for users from Router A.

Figure 24 Network diagram

‌

Prerequisites

# Configure IP addresses for interfaces, and make sure the network connections are available.

Configuring the HWTACACS server

# Set the shared keys for secure communication with Router A to expert, and add a user account with username userb and password passb for PPP users from Router B. (Details not shown.)

Configuring Router A

# Create an HWTACACS scheme.

<RouterA> system-view

[RouterA] hwtacacs scheme hwtac

# Configure the primary HWTACACS server at 10.1.1.1. Set the authentication, authorization, and accounting ports to 49. Configure the router to establish only one TCP connection with the server.

[RouterA-hwtacacs-hwtac] primary authentication 10.1.1.1 49 single-connection

[RouterA-hwtacacs-hwtac] primary authorization 10.1.1.1 49 single-connection

[RouterA-hwtacacs-hwtac] primary accounting 10.1.1.1 49 single-connection

# Set the shared keys to expert in plaintext form for authentication, authorization, and accounting.

[RouterA-hwtacacs-hwtac] key authentication simple expert

[RouterA-hwtacacs-hwtac] key authorization simple expert

[RouterA-hwtacacs-hwtac] key accounting simple expert

# Exclude domain names from the usernames sent to the HWTACACS server.

[RouterA-hwtacacs-hwtac] user-name-format without-domain

[RouterA-hwtacacs-hwtac] quit

# Create an ISP domain named bbb and configure the domain to use the HWTACACS scheme for authentication, authorization, and accounting for PPP users.

[RouterA] domain name bbb

[RouterA-isp-bbb] authentication ppp hwtacacs-scheme hwtac

[RouterA-isp-bbb] authorization ppp hwtacacs-scheme hwtac

[RouterA-isp-bbb] accounting ppp hwtacacs-scheme hwtac

[RouterA-isp-bbb] quit

# Enable PPP encapsulation on GigabitEthernet 3/0/2.

[RouterA] interface gigabitethernet 3/0/2

[RouterA-GigabitEthernet3/0/2] link-protocol ppp

# Configure GigabitEthernet 3/0/2 to authenticate the peer by using PAP in authentication domain bbb.

[RouterA-GigabitEthernet3/0/2] ppp authentication-mode pap domain bbb

Configuring Router B

# Enable PPP encapsulation on GigabitEthernet 3/0/2.

<RouterB> system-view

[RouterB] interface gigabitethernet 3/0/2

[RouterB-GigabitEthernet3/0/2] link-protocol ppp

# Configure the local username and password for PAP authentication to userb and plaintext passb, respectively.

[RouterB-GigabitEthernet3/0/2] ppp pap local-user userb password simple passb

Verifying the configuration

# Use the display interface serial command to display information for GigabitEthernet 3/0/2. The PPP link is established if the output contains the following information:

· Both the physical layer and link layer are up.

· LCP and IPCP have entered the Opened state.

Router A and Router B can ping each other.

Example: Configuring the RADIUS proxy

Network configuration

As shown in Figure 25, IPoE authentication is enabled on the device for user access and the AC is bypassingly deployed at the device side to perform 802.1X authentication on wireless clients.

· The RADIUS server is a Free RADIUS server that provides authentication, authorization, and accounting services for users.

· The device acts as a RADIUS proxy to participate in the authentication, authorization, and accounting process of wireless 802.1X users.

· The device and the RADIUS server use a shared key of 123456 for secure RADIUS communication. The authentication and accounting ports are 1812 and 1813, respectively.

· The AC and the RADIUS proxy use a shared key of abcdef for secure RADIUS communication. The authentication and accounting ports are 2016 and 2017, respectively.

Figure 25 Network diagram

‌

Prerequisites

# Configure IP addresses for interfaces, and make sure the network connections are available.

Configuring the RADIUS server

# Add the following RADIUS client information to the client.conf file on the RADIUS server.

client 6.6.6.2/24 {

secret = 123456

}

# Add the following information to the user.conf file on the RADIUS server.

user1 Cleartext-Password := abcdef

The information indicates that the password of user user1 for access authentication is abcdef.

Configuring the device (RADIUS proxy)

1. Configure the RADIUS proxy feature:

# Enable the RADIUS proxy feature and enter RADIUS proxy view.

<Device> system

[Device] radius-proxy

# Specify the RADIUS client at 5.5.5.1 for the RADIUS proxy and set the shared key to abcdef in plaintext form for secure RADIUS communication with the RADIUS client. Set the authentication port to 2016 and the accounting port to 2017 for communication with the RADIUS client. Configure the RADIUS proxy to use the RADIUS servers in RADIUS scheme rs1 for the users from the RADIUS client.

[Device-radius-proxy] client ip 5.5.5.1 radius-scheme rs1 key simple abcdef authentication-port 2016 accounting-port 2017

[Device-radius-proxy] quit

2. Configure a RADIUS scheme:

# Create RADIUS scheme rs1 and enter its view.

[Device] radius scheme rs1

# Specify the RADIUS server as the primary authentication server and primary accounting server.

[Device-radius-rs1] primary authentication 6.6.6.1

[Device-radius-rs1] primary accounting 6.6.6.1

# Set the authentication and accounting shared keys to 123456 in plaintext form.

[Device-radius-rs1] key authentication simple 123456

[Device-radius-rs1] key accounting simple 123456

# Exclude domain names from usernames sent to the RADIUS server.

[Device-radius-rs1] user-name-format without-domain

[Device-radius-rs1] quit

3. Configure IPoE:

# Enter the view of Ten-GigabitEthernet 3/0/2.

[Device] interface ten-gigabitethernet 3/0/2

# Enable IPoE and configure the Layer 2 access mode for users on Ten-GigabitEthernet 3/0/2.

[Device–Ten-GigabitEthernet3/0/2] ip subscriber l2-connected enable

# Specify ISP domain dom1 for DHCPv4 users on Ten-GigabitEthernet 3/0/2.

[Device-Ten-GigabitEthernet3/0/2] ip subscriber dhcp domain dom1

[Device-Ten-GigabitEthernet3/0/2] quit

4. Configure an authentication domain:

# Create ISP domain dom1 and enter its view.

[Device] domain name dom1

# Configure IP address pool p1 as the authorization IP pool.

[Device-isp-dom1] authorization-attribute ip-pool p1

# Configure the ISP domain to use RADIUS proxy for IPoE user authentication and authorization.

[Device-isp-dom1] authentication ipoe radius-proxy

[Device-isp-dom1] authorization ipoe radius-proxy

# Configure the ISP domain to use RADIUS scheme rs1 for IPoE user accounting.

[Device-isp-dom1] accounting ipoe radius-scheme rs1

[Device-isp-dom1] quit

5. Configure the authorization IP pool:

# Enable DHCP.

[Device] dhcp enable

# Enable the DHCP server to return a DHCP-NAK message if the client notions of their IP addresses are incorrect.

[Device] dhcp server request-ip-address check

# Create IP address pool p1 and assign IP addresses to clients from subnet 30.0.0.0/24.

[Device] ip pool p1

[Device–ip-pool-p1] gateway-list 30.0.0.1 export-route

[Device–ip-pool-p1] network 30.0.0.0 mask 255.255.255.0

[Device–ip-pool-p1] forbidden ip 30.0.0.1

[Device–ip-pool-p1] quit

Configuring the AC

1. Configure WLAN access and wireless 802.1X authentication. (Details not shown.)

2. Configure a RADIUS scheme:

# Create RADIUS scheme rs1 and enter its view.

<AC> system-view

[AC] radius scheme rs1

# Specify the device as the primary authentication server and primary accounting server and set the authentication and accounting ports for secure RADIUS communication.

[AC-radius-rs1] primary authentication 5.5.5.2 2016

[AC-radius-rs1] primary accounting 5.5.5.2 2017

# Set the authentication and accounting shared keys to abcdef in plaintext form.

[AC-radius-rs1] key authentication simple abcdef

[AC-radius-rs1] key accounting simple abcdef

# Exclude domain names from usernames sent to the RADIUS server.

[AC-radius-rs1] user-name-format without-domain

[AC-radius-rs1] quit

3. Configure an authentication domain:

# Create ISP domain dom1 and enter its view.

[AC] domain name dom1

# Configure the ISP domain to use RADIUS scheme rs1 for LAN user authentication, authorization, and accounting.

[AC-isp-dom1] authentication lan-access radius-scheme rs1

[AC-isp-dom1] authorization lan-access radius-scheme rs1

[AC-isp-dom1] accounting lan-access radius-scheme rs1

[AC-isp-dom1] quit

Verifying the configuration

# Use a wireless client to initiate 802.1X authentication. (Details not shown.)

# On the device, display RADIUS proxy user information for the RADIUS client.

[Device] display radius-proxy user

Username MAC address IP address Client IP Client VPN

user1 0800-2700-240e - 5.5.5.1 -

# On the device, display IPoE online user information.

[Device] display access-user auth-type bind

UserID Interface IP address MAC address S-/C-VLAN

Username Access type

IPv6 address

0x1348 XGE3/0/2 30.0.0.2 0800-2700-240e -/-

user1 L2 IPoE dynamic

Troubleshooting RADIUS

RADIUS authentication failure

Symptom

User authentication always fails.

Analysis

Possible reasons include:

· A communication failure exists between the NAS and the RADIUS server.

· The username is not in the userid@isp-name format, or the ISP domain is not correctly configured on the NAS.

· The user is not configured on the RADIUS server.

· The password entered by the user is incorrect.

· The RADIUS server and the NAS are configured with different shared keys.

Solution

To resolve the problem:

1. Verify the following items:

¡ The NAS and the RADIUS server can ping each other.

¡ The username is in the userid@isp-name format and the ISP domain is correctly configured on the NAS.

¡ The user is configured on the RADIUS server.

¡ The correct password is entered.

¡ The same shared key is configured on both the RADIUS server and the NAS.

2. If the problem persists, contact H3C Support.

RADIUS packet delivery failure

Symptom

RADIUS packets cannot reach the RADIUS server.

Analysis

Possible reasons include:

· A communication failure exists between the NAS and the RADIUS server.

· The NAS is not configured with the IP address of the RADIUS server.

· The authentication and accounting UDP ports configured on the NAS are incorrect.

· The RADIUS server's authentication and accounting port numbers are being used by other applications.

Solution

To resolve the problem:

1. Verify the following items:

¡ The link between the NAS and the RADIUS server works well at both the physical and data link layers.

¡ The IP address of the RADIUS server is correctly configured on the NAS.

¡ The authentication and accounting UDP port numbers configured on the NAS are the same as those of the RADIUS server.

¡ The RADIUS server's authentication and accounting port numbers are available.

2. If the problem persists, contact H3C Support.

RADIUS accounting error

Symptom

A user is authenticated and authorized, but accounting for the user is not normal.

Analysis

The accounting server configuration on the NAS is not correct. Possible reasons include:

· The accounting port number configured on the NAS is incorrect.

· The accounting server IP address configured on the NAS is incorrect. For example, the NAS is configured to use a single server to provide authentication, authorization, and accounting services, but in fact the services are provided by different servers.

Solution

To resolve the problem:

1. Verify the following items:

¡ The accounting port number is correctly configured.

¡ The accounting server IP address is correctly configured on the NAS.

2. If the problem persists, contact H3C Support.

Troubleshooting HWTACACS

Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS."

LDAP authentication failure

Symptom

User authentication fails.

Analysis

Possible reasons include:

· A communication failure exists between the NAS and the LDAP server.

· The LDAP server IP address or port number configured on the NAS is not correct.

· The username is not in the userid@isp-name format, or the ISP domain is not correctly configured on the NAS.

· The user is not configured on the LDAP server.

· The password entered by the user is incorrect.

· The administrator DN or password is not configured.

· Some user attributes (for example, the username attribute) configured on the NAS are not consistent with those configured on the server.

· No user search base DN is specified for the LDAP scheme.

Solution

To resolve the problem:

1. Verify the following items:

¡ The NAS and the LDAP server can ping each other.

¡ The IP address and port number of the LDAP server configured on the NAS match those of the server.

¡ The username is in the correct format and the ISP domain for the user authentication is correctly configured on the NAS.

¡ The user is configured on the LDAP server.

¡ The correct password is entered.

¡ The administrator DN and the administrator password are correctly configured.

¡ The user attributes (for example, the username attribute) configured on the NAS are consistent with those configured on the LDAP server.

¡ The user search base DN for authentication is specified.

2. If the problem persists, contact H3C Support.

Appendixes

Appendix A Commonly used RADIUS attributes

Commonly used RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868.

Table 6 Commonly used RADIUS attributes

No.	Attribute	No.	Attribute
1	User-Name	45	Acct-Authentic
2	User-Password	46	Acct-Session-Time
3	CHAP-Password	47	Acct-Input-Packets
4	NAS-IP-Address	48	Acct-Output-Packets
5	NAS-Port	49	Acct-Terminate-Cause
6	Service-Type	50	Acct-Multi-Session-Id
7	Framed-Protocol	51	Acct-Link-Count
8	Framed-IP-Address	52	Acct-Input-Gigawords
9	Framed-IP-Netmask	53	Acct-Output-Gigawords
10	Framed-Routing	54	(unassigned)
11	Filter-ID	55	Event-Timestamp
12	Framed-MTU	56-59	(unassigned)
13	Framed-Compression	60	CHAP-Challenge
14	Login-IP-Host	61	NAS-Port-Type
15	Login-Service	62	Port-Limit
16	Login-TCP-Port	63	Login-LAT-Port
17	(unassigned)	64	Tunnel-Type
18	Reply-Message	65	Tunnel-Medium-Type
19	Callback-Number	66	Tunnel-Client-Endpoint
20	Callback-ID	67	Tunnel-Server-Endpoint
21	(unassigned)	68	Acct-Tunnel-Connection
22	Framed-Route	69	Tunnel-Password
23	Framed-IPX-Network	70	ARAP-Password
24	State	71	ARAP-Features
25	Class	72	ARAP-Zone-Access
26	Vendor-Specific	73	ARAP-Security
27	Session-Timeout	74	ARAP-Security-Data
28	Idle-Timeout	75	Password-Retry
29	Termination-Action	76	Prompt
30	Called-Station-Id	77	Connect-Info
31	Calling-Station-Id	78	Configuration-Token
32	NAS-Identifier	79	EAP-Message
33	Proxy-State	80	Message-Authenticator
34	Login-LAT-Service	81	Tunnel-Private-Group-ID
35	Login-LAT-Node	82	Tunnel-Assignment-id
36	Login-LAT-Group	83	Tunnel-Preference
37	Framed-AppleTalk-Link	84	ARAP-Challenge-Response
38	Framed-AppleTalk-Network	85	Acct-Interim-Interval
39	Framed-AppleTalk-Zone	86	Acct-Tunnel-Packets-Lost
40	Acct-Status-Type	87	NAS-Port-Id
41	Acct-Delay-Time	88	Framed-Pool
42	Acct-Input-Octets	89	(unassigned)
43	Acct-Output-Octets	90	Tunnel-Client-Auth-id
44	Acct-Session-Id	91	Tunnel-Server-Auth-id

Appendix B Descriptions for commonly used standard RADIUS attributes

No.	Attribute	Description
1	User-Name	Name of the user to be authenticated.
2	User-Password	User password for PAP authentication, only present in Access-Request packets when PAP authentication is used.
3	CHAP-Password	Digest of the user password for CHAP authentication, only present in Access-Request packets when CHAP authentication is used.
4	NAS-IP-Address	IP address for the server to use to identify the client. Typically, a client is identified by the IP address of its access interface.
5	NAS-Port	Physical port of the NAS that the user accesses.
6	Service-Type	Type of service that the user has requested or type of service to be provided.
7	Framed-Protocol	Encapsulation protocol for framed access.
8	Framed-IP-Address	IP address assigned to the user.
11	Filter-ID	Name of the filter list. This attribute is parsed as follows: · If the name is a string of all digits, it indicates an ACL number. · If the name is not a string of all digits, it indicates a user profile name. If the name is __PAIPPXY__, it indicates the PPPoE agency dialup scenario.
12	Framed-MTU	MTU for the data link between the user and NAS.
14	Login-IP-Host	IP address of the NAS interface that the user accesses.
15	Login-Service	Type of service that the user uses for login.
18	Reply-Message	Text to be displayed to the user, which can be used by the server to communicate information, for example, the cause of the authentication failure.
26	Vendor-Specific	Vendor-specific proprietary attribute. A packet can contain one or more proprietary attributes, each of which can contain one or more subattributes.
27	Session-Timeout	Maximum service duration for the user before termination of the session. Value 0 indicates that the device will log out the user. Value 4294967295 indicates that no limit is placed on the online duration of the user.
28	Idle-Timeout	Maximum idle time permitted for the user before termination of the session.
31	Calling-Station-Id	User identification that the NAS sends to the server. For the LAN access service provided by an H3C device, this attribute includes the MAC address of the user in the format HHHH-HHHH-HHHH.
32	NAS-Identifier	Identification that the NAS uses to identify itself to the RADIUS server.
40	Acct-Status-Type	Type of the Accounting-Request packet. Possible values include: · 1—Start. · 2—Stop. · 3—Interim-Update. · 4—Reset-Charge. · 7—Accounting-On. (Defined in the 3rd Generation Partnership Project.) · 8—Accounting-Off. (Defined in the 3rd Generation Partnership Project.) · 9 to 14—Reserved for tunnel accounting. · 15—Reserved for failed.
45	Acct-Authentic	Authentication method used by the user. Possible values include: · 1—RADIUS. · 2—Local. · 3—Remote.
60	CHAP-Challenge	CHAP challenge generated by the NAS for MD5 calculation during CHAP authentication.
61	NAS-Port-Type	Type of the physical port of the NAS that is authenticating the user. Possible values include: · 15—Ethernet. · 16—Any type of ADSL. · 17—Cable. (With cable for cable TV.) · 19—WLAN-IEEE 802.11. · 201—VLAN. · 202—ATM. If the port is an Ethernet one and VLANs are implemented on it, the value of this attribute is 201.
64	Tunnel-Type	Tunneling protocols used. The value 13 represents VLAN. If the value is 13, the device interprets the Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Private-Group-ID attributes as attributes to assign VLANs.
65	Tunnel-Medium-Type	Transport medium type to use for creating a tunnel. For VLAN assignment, the value must be 6 to indicate the 802 media plus Ethernet.
67	Tunnel-Server-Endpoint	IP address of the LNS.
69	Tunnel-Password	Password to authenticate a remote server during tunnel establishment.
77	Connect-Info	ISP account username in PPPoE agency dialup.
79	EAP-Message	Used to encapsulate EAP packets to allow RADIUS to support EAP authentication. In PPPoE agency dialup, this attribute specifies the ISP account password.
80	Message-Authenticator	Used for authentication and verification of authentication packets to prevent spoofing Access-Requests. This attribute is present when EAP authentication is used.
81	Tunnel-Private-Group-ID	Group ID for a tunnel session. To assign VLANs, the NAS conveys VLAN IDs by using this attribute.
82	Tunnel-Assignment-id	ID of the tunnel that carries the session.
83	Tunnel-Preference	Preference of the tunnel. The smaller the value, the higher the preference. Value 0 indicates the highest preference.
85	Acct-Interim-Interval	Real-time accounting interval, in seconds.
87	NAS-Port-Id	String for describing the port of the NAS that is authenticating the user.
88	Framed-Pool	Name of the IPv4 address pool assigned by the server to a user. In PPPoE agency dialup, the attribute specifies the agency dialup group name.
90	Tunnel-Client-Auth-id	Name used by the LAC during tunnel establishment.
91	Tunnel-Server-Auth-id	Named used by the LNS during tunnel establishment.
95	NAS-IPv6-Address	IPv6 address of the NAS.

‌

Appendix C RADIUS subattributes (vendor ID 25506)

Table 7 lists all RADIUS subattributes with a vendor ID of 25506. Support for these subattributes depends on the device model.

Table 7 RADIUS subattributes (vendor ID 25506)

No.	Subattribute	Description
1	Input-Peak-Rate	Peak rate in the direction from the user to the NAS. The default unit of the rate is bps. If the server assigns the unit of CAR parameters through the Av-Pair attribute, the server-assigned unit applies.
2	Input-Average-Rate	Average rate in the direction from the user to the NAS. The default unit of the rate is bps. If the server assigns the unit of CAR parameters through the Av-Pair attribute, the server-assigned unit applies.
3	Input-Basic-Rate	Basic rate in the direction from the user to the NAS. The default unit of the rate is bps. If the server assigns the unit of CAR parameters through the Av-Pair attribute, the server-assigned unit applies.
4	Output-Peak-Rate	Peak rate in the direction from the NAS to the user. The default unit of the rate is bps. If the server assigns the unit of CAR parameters through the Av-Pair attribute, the server-assigned unit applies.
5	Output-Average-Rate	Average rate in the direction from the NAS to the user. The default unit of the rate is bps. If the server assigns the unit of CAR parameters through the Av-Pair attribute, the server-assigned unit applies.
6	Output-Basic-Rate	Basic rate in the direction from the NAS to the user. The default unit of the rate is bps. If the server assigns the unit of CAR parameters through the Av-Pair attribute, the server-assigned unit applies.
15	Remanent_Volume	Total amount of data available for the connection, in different units for different server types.
17	ISP-ID	ISP domain where the user obtains authorization information.
20	Command	Operation for the session, used for session control. Possible values include: · 1—Trigger-Request. · 2—Terminate-Request. · 3—SetPolicy. · 4—Result. · 5—PortalClear.
25	Result_Code	Result of the Trigger-Request or SetPolicy operation, zero for success and any other value for failure.
26	Connect_ID	Index of the user connection.
27	PortalURL	PADM redirect URL assigned to PPPoE users.
28	Ftp_Directory	FTP, SFTP, or SCP user working directory. When the RADIUS client acts as the FTP, SFTP, or SCP server, this attribute is used to set the working directory for an FTP, SFTP, or SCP user on the RADIUS client.
29	Exec_Privilege	EXEC user priority.
32	NAT-IP-Address	Public IP address assigned to the user when the source IP address and port are translated.
33	NAT-Start-Port	Start port number of the port range assigned to the user when the source IP address and port are translated.
34	NAT-End-Port	End port number of the port range assigned to the user when the source IP address and port are translated.
59	NAS_Startup_Timestamp	Startup time of the NAS in seconds, which is represented by the time elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
60	Ip_Host_Addr	User IP address and MAC address included in authentication and accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space is required between the IP address and the MAC address.
61	User_Notify	Information that must be sent from the server to the client transparently.
98	Multicast_Receive_Group	IP address of the multicast group that the user's host joins as a receiver. This subattribute can appear multiple times in a multicast packet to indicate that the user belongs to multiple multicast groups.
100	IP6_Multicast_Receive_Group	IPv6 address of the multicast group that the user's host joins as a receiver. This subattribute can appear multiple times in a multicast packet to indicate that the user belongs to multiple multicast groups.
101	MLD-Access-Limit	Maximum number of MLD multicast groups that the user can join concurrently.
102	local-name	L2TP local tunnel name.
103	IGMP-Access-Limit	Maximum number of IGMP multicast groups that the user can join concurrently.
104	VPN-Instance	MPLS L3VPN instance to which a user belongs.
105	ANCP-Profile	ANCP profile name.
106	Up-Priority	User priority of incoming packets, in the range of 0 to 7 and 15. The value of 15 indicates cancelling the authorization of the user priority.
107	Down-Priority	User priority of outgoing packets, in the range of 0 to 7 and 15. The value of 15 indicates cancelling the authorization of the user priority.
135	Client-Primary-DNS	IP address of the primary DNS server.
136	Client-Secondary-DNS	IP address of the secondary DNS server.
140	User_Group	User groups assigned after the user passes authentication. Typically, a user can belong to only one user group.
144	Acct_IPv6_Input_Octets	Bytes of IPv6 packets in the inbound direction. The measurement unit depends on the configuration on the device.
145	Acct_IPv6_Output_Octets	Bytes of IPv6 packets in the outbound direction. The measurement unit depends on the configuration on the device.
146	Acct_IPv6_Input_Packets	Number of IPv6 packets in the inbound direction. The measurement unit depends on the configuration on the device.
147	Acct_IPv6_Output_Packets	Number of IPv6 packets in the outbound direction. The measurement unit depends on the configuration on the device.
148	Acct_IPv6_Input_Gigawords	Bytes of IPv6 packets in the inbound direction. The measurement unit is 4G bytes.
149	Acct_IPv6_Output_Gigawords	Bytes of IPv6 packets in the outbound direction. The measurement unit is 4G bytes.
155	User-Roles	List of space-separated user roles.
158	Framed-IPv6-Address	IPv6 address of the user.
180	Auth-Type	Authentication type: · 1—PPP. · 2—IPoE. · 3—Portal. · 6—Web. · 7—Login.
181	Acct-Terminate-Subcause	Subcause code for user going offline.
183	Tunnel-Group-Name	L2TP group for the user.
210	Av-Pair	User-defined attribute pair. Available attribute pairs include: · Server-assigned dynamic WEP key in the format of leap:session-key=xxx. · Server-assigned voice VLAN in the format of device-traffic-class=voice. · Server-assigned user role in the format of shell:role=xxx. · Server-assigned EDSG service policy list, in the format of edsg-policy:activelist=policyname1;policyname2;…;policynameN. · Server-assigned list of EDSG service policies to be deactivated, in the format of edsg-policy:deactivelist=policyname1;policyname2;…;policynameN. · Server-assigned EDSG service policy that carries a username, in the format of edsg-policy:username=[policyname]username. · Server-assigned EDSG service policy that carries a password, in the format of edsg-policy:password=[policyname]password. · Server-assigned unit of CAR parameters, in the format of car:car-unit="xxx". · CAR attribute change in the format of car:car-change=x. It is used to notify the server the speed change of PPP users. The value of x can be: ¡ 1—Downlink speed decrease. ¡ 2—Uplink speed decrease. ¡ 3—Uplink and downlink speed decrease. ¡ 4—Uplink speed increase. ¡ 5—Uplink speed increase. ¡ 6—Uplink and downlink speed increase.
215	Accounting-Level	ITA traffic level in the range of 1 to 8.
216	Ita-Policy	ITA policy name.
217	Nat-Port-Range-Update	NAT port range change for the user: · 1—Delete a port range. · 2—Add a port range.
220	H3C-HTTP-User-Agent	HTTP user agent information for the user endpoint.
230	Nas-Port	Interface through which the user is connected to the NAS.
246	Auth_Detail_Result	Accounting details. The server sends Access-Accept packets with subattributes 246 and 250 in the following situations: · 1—The subscriber charge is overdue. The subscriber is allowed to access network resources in the whitelist. If the subscriber accesses other network resources, the device redirects it to the URL specified by subattribute 250. · 2—The broadband lease of the subscriber expires. The device redirects the subscriber to the URL specified by subattribute 250 when the subscriber requests to access webpages for the first time.
247	Input-Committed-Burst-Size	Committed burst size from the user to the NAS, in bits. The total length cannot exceed 4 bytes for this field. This subattribute must be assigned together with the Input-Average-Rate attribute.
248	Output-Committed-Burst-Size	Committed burst size from the NAS to the user, in bits. The total length cannot exceed 4 bytes for this field. This subattribute must be assigned together with the Output-Average-Rate attribute.
249	authentication-type	Authentication type. The value can be: · 1—Intranet access authentication. · 2—Internet access authentication. If the packet does not contain this subattribute, common authentication applies.
250	WEB-URL	Redirect URL for users.
251	Subscriber-ID	Family plan ID.
252	Subscriber-Profile	QoS policy name for the family plan of the subscriber.
255	Product_ID	Product name.

‌

Appendix D HWTACACS attributes

HWTACACS authorization and accounting packets include the HWTACACS attributes assigned by the server to a user and the HWTACACS attributes uploaded by a user to the server. Table 8 shows the HWTACACS attributes supported by the device. The device ignores an HWTACACS attribute if it does not support that attribute.

Table 8 Supported HWTACACS attributes

Attribute name	Description
acl	Number of the ACL assigned to the user.
idletime	Idle timeout period, in seconds.
priv-lvl	User privilege level in the range of level 0 to level 15.
ftp-directory	Initial working directory of the FTP user.
addr	IP address assigned to the user.
addr-pool	IP address pool assigned to the user.
tunnel-type	Type of the tunnel to be established. Only L2TP is supported.
ip-addresses	LNS IP addresses.
tunnel-id	Group ID of the L2TP tunnel.
gw-password	Authentication password of the L2TP tunnel.
roles	User roles assigned to the user.
allowed-roles	Roles for which the user is allowed to obtain temporary authorization.

‌

15-BRAS Services Configuration Guide

Client/server model

Information exchange security mechanism

User authentication methods

RADIUS packet format

Extended RADIUS attributes

HWTACACS

LDAP directory service

LDAP authentication and authorization

Basic LDAP authorization process

User management based on ISP domains and user access types

Authentication methods

Authorization methods

Accounting methods

Authorization attribute configuration methods

AAA for VPNs

Application scenarios

Operating mechanism

AAA tasks at a glance

Configuring local users

Configuring attributes for device management users

Restrictions and guidelines

Procedure

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

Creating a RADIUS scheme

Restrictions and guidelines

Procedure

Specifying RADIUS authentication servers

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines for source IP address configuration

Specifying a source IP address for outgoing RADIUS packets in system view

Specifying a source IP address for outgoing RADIUS packets in RADIUS scheme view

Setting the username format and traffic statistics units

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines for NAS IP address configuration

Specifying a NAS IP address for RADIUS packets in interface view

Specifying a NAS IP address for RADIUS packets in system view

Specifying a NAS IP address for RADIUS packets in RADIUS scheme view

About the format of the RADIUS NAS-Port attribute

Restrictions and guidelines