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 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, HWTACACS, and LDAP. RADIUS is most often used.

The network in Figure 1 has one RADIUS server and one HWTACACS server. You can use different servers to implement different security functions. For example, you can use the HWTACACS server for authentication and authorization, and use the 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.

Commonly used RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868. For more information, see "Commonly used standard RADIUS attributes."

Table 2 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

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 "Proprietary 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 PPP, VPDN, and terminal users. In a typical HWTACACS scenario, terminal users 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 logs in to the device and performs 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 3 lists the primary differences between HWTACACS and RADIUS.

Table 3 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.

AAA implementation on the device

This section describes AAA user management and methods.

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. The NAS determines the ISP domain to which a user belongs based on the username entered by the user at login.

Figure 9 Determining the ISP domain for a user by username

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

· LAN—LAN users, such as 802.1X authentication users and MAC authentication users.

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

· Portal—Portal users must pass portal authentication to access the network.

· ONU—ONU users must pass ONU authentication to access the network.

The device also provides authentication modules (such as 802.1X) 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

The device provides the following types of ISP domains for you to control access of wired 802.1X, Web authentication, and MAC authentication users to network resources at different phases of authentication:

· Preauthentication domain—The domain to which users belong before authentication starts for them. For example, users are placed in the preauthentication domain in the following situations:

¡ Before they authenticate to the network for the first time.

¡ When they fail authentication in an ISP domain that does not have an auth-fail domain.

¡ When no authentication servers are available, they are assigned to the specified critical domain. However, the specified critical domain does not exist.

The preauthentication domain is applicable only to 802.1X and Web authentication users.

· Authentication domain—The ISP domain in which users are authenticated and come online.

· Auth-fail domain—The ISP domain specified to accommodate users that have failed authentication in an authentication domain.

· Critical domain—The ISP domain specified to accommodate users that access an authentication domain when all RADIUS servers in that authentication domain are unavailable.

· Recovery domain—The ISP domain to which users in the critical domain are moved after a RADIUS authentication server in their authentication domain becomes available.

IMPORTANT:

In the current version, you must specify the authentication domain as the recovery domain.

Figure 10 Movement of users between different types of ISP domains

AAA 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.

Figure 11 AAA configuration structure for an ISP domain

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, HWTACACS, or LDAP 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.

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 RADIUS, HWTACACS, or LDAP 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.

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 who 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.

In addition, 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 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 Fundamentals Configuration Guide.

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

You can configure multiple authorization attributes for an ISP domain. Typically, server-assigned authorization attributes have higher priority than the attributes configured for a domain. Attributes configured for a domain can take effect only if they do not conflict with server-assigned attributes. If an attribute configured for an ISP domain conflicts with a server-assigned attribute, the server-assigned attribute takes effect.

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 12, 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 12 Network diagram

This feature can also help an MCE to implement portal authentication for VPNs. For more information about MCE, see MPLS Configuration Guide. For more information about portal authentication, see "Configuring portal authentication."

RADIUS server feature of the device

Enable the RADIUS server feature of the device to work with RADIUS clients for user authentication and authorization. The device can act as a dedicated RADIUS server or as both a RADIUS server and a RADIUS client at the same time.

The RADIUS server feature provides for flexible networks with less cost. As shown in Figure 13, Device A provides RADIUS server functions at the distribution layer; Device B and Device C are configured with RADIUS schemes to implement user authentication and authorization at the access layer.

Figure 13 Network diagram

The RADIUS server feature supports the following operations:

· Manages RADIUS user data, which is generated from local user information and includes user name, password, description, authorization ACL, authorization VLAN, and expiration time.

· Allows you to add, modify, and delete RADIUS clients. A RADIUS client is identified by the IP address and includes attribute information such as the shared key. The RADIUS server feature processes authentication requests only from the recorded RADIUS clients and ignores requests from unknown clients.

· Authenticates and authorizes users of the network access type. The server does not provide accounting.

When the RADIUS server receives a RADIUS packet, it performs the following actions:

1. Verifies that the packet is sent from a recorded RADIUS client.

2. Verifies the packet with the shared key.

3. Verifies that the user account exists, the password is correct, and other attributes meet the requirements (for example, the account is in the validity period).

4. Determines the authentication result and authorizes specific privileges to the authenticated user.

The RADIUS server feature of the device has the following restrictions:

· The authentication port is fixed at UDP 1812 and cannot be modified.

· The feature is supported on IPv4 networks, but not on IPv6 networks.

· The server provides only PAP and CHAP authentication methods.

· User names sent to the RADIUS server cannot include a domain name.

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 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)

RADIUS attributes

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. This attribute is only present in Access-Request packets.
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. If the name starts with a digit, it indicates an ACL number. If the name does not start with a digit, it indicates a user profile name.
12	Framed-MTU	MTU for the data link between the user and NAS. For example, this attribute can be used to define the maximum size of EAP packets allowed to be processed in 802.1X EAP authentication.
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 authentication failure reason.
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.
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.
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 ATM or 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.
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.
79	EAP-Message	Used to encapsulate EAP packets to allow RADIUS to support EAP authentication.
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.
87	NAS-Port-Id	String for describing the port of the NAS that is authenticating the user.

Proprietary RADIUS subattributes (vendor ID 25506)

Table 4 lists all proprietary RADIUS subattributes with a vendor ID of 25506. Support for these subattributes depends on the device model.

Table 4 Proprietary RADIUS subattributes (vendor ID 25506)

No.	Subattribute	Description
1	Input-Peak-Rate	Peak rate in the direction from the user to the NAS, in bps.
2	Input-Average-Rate	Average rate in the direction from the user to the NAS, in bps.
3	Input-Basic-Rate	Basic rate in the direction from the user to the NAS, in bps.
4	Output-Peak-Rate	Peak rate in the direction from the NAS to the user, in bps.
5	Output-Average-Rate	Average rate in the direction from the NAS to the user, in bps.
6	Output-Basic-Rate	Basic rate in the direction from the NAS to the user, in bps.
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.
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.
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.
62	User_HeartBeat	Hash value assigned after an 802.1X user passes authentication, which is a 32-byte string. This attribute is stored in the user list on the NAS and verifies the handshake packets from the 802.1X user. This attribute only exists in Access-Accept and Accounting-Request packets.
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.
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.
135	Client-Primary-DNS	IP address of the primary DNS server.
136	Client-Secondary-DNS	IP address of the secondary DNS server.
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.
182	Microsegment-ID	Microsegment ID.
210	Av-Pair	Vendor-specific attribute pair. Available attribute pairs include: · Dynamically assigned 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 ACL in the format of url-redirect-acl=xxx. · Server-assigned IPv4 Web redirect URL in the format of url-redirect=xxx. · Server-assigned IPv6 Web redirect URL in the format of urlipv6-redirect=xxx. · Server-deployed command to reboot a port, in the format of subscriber:command=bounce-host-port. · Server-assigned port shutdown duration in the format of bounce:seconds=xxx. · Server-deployed command to shut down a port, in the format of subscriber:command=disable-host-port. · Server-assigned VSI in the format of vxlan:vsi-name=xxx. · VSI-based ACL resource assignment capability in the format of ACL:match-by-vsiindex=x. Value 1 of x indicates that this feature is supported, and the other values of x are reserved. · Server-assigned blackhole MAC address attribute in the format of mac:block-mac=xxx. · Server-assigned MAC authentication offline detect timer (in seconds) in the format of mac-authentication: offline-detect-time=xxx. Value 0 of xxx indicates that MAC authentication offline detection is disabled. · Server-assigned MAC authentication offline detection flag in the format of mac-authentication: offline-detect-check=x. x has the following values: ¡ 0—The device does not search for the ARP snooping entry or ND snooping entry of the MAC address. ¡ 1—The device searches for the ARP snooping entry or ND snooping entry of the MAC address. · Server-assigned dynamic ACL. For more information about the format of this attribute, see "Format of dynamic authorization ACLs." Support for this attribute in 802.1X authentication and MAC authentication depends on the device model. If the server assigns a user both this attribute and the Filter-ID attribute, the device will ignore this attribute. The device does not support using CoA messages to change the content assigned by this attribute or assign another ACL to the user.
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.

Format of dynamic authorization ACLs (vendor ID 25506)

The server might assign a dynamic authorization ACL that contains multiple rules to a user in different ways:

· Assign only one Av-Pair subattribute to the user. In this subattribute, the dynamic ACL contains multiple rules separated by question marks (?).

· Assign multiple Av-Pair subattributes to the user. All the subattributes contain the same dynamic ACL and a different rule. Support for this method depends on the server model.

The format of a dynamic ACL rule is as follows:

aclrule?same?acl-name?acl-type?ver-type?rule-id?protocol=protocol-type?counting?dst-ip=ip-addr?src-ip=ip-addr?dst-port=port-value?src-port=port-value?action=action-type

The fields in the rule are described in Table 5. The following is an example of a dynamic ACL rule:

aclrule?same?test?1?1?1?protocol=3?counting?dst-ip=1.1.1.1/1.1.1.1?src-ip=1.1.1.1/0?dst-port=1.2000?src-port=5.2000-3000?action=1

Table 5 Fields in a dynamic ACL rule

Field	Description	Remarks
aclrule	Indicates that the following part is information about a dynamic ACL rule.	Required
same	Indicates that the current user will inherit the dynamic ACL rules that have been successfully assigned to another authenticated user. If the server assigns one user the same dynamic ACL as another user but the rules are different for the two users, the device applies the dynamic ACL rules of the user that comes online first to the other user.	Required
acl-name	ACL name, a case-insensitive string of 1 to 63 characters. The ACL name must begin with a letter and it cannot be all or the same as an existing static ACL on the device.	Required
acl-type	ACL type. 1 indicates an advanced ACL. In the current software version, only advanced ACLs are supported.	Required
ver-type	IP protocol type: · 1—IPv4. · 2—IPv6.	Required
rule-id	ACL rule number, in the range of 0 to 65534.	Required
protocol-type	Protocol type: · 1—IP. · 2—ICMP. · 3—TCP. · 4—UDP. · 5—ICMPv6. · 6—IPv6.	Optional
counting	Indicates that rule match statistics is enabled. If a rule does not include this field, rule match statistics is disabled for the rule.	Optional
ip-addr	IP address information. For example, 1.1.1.1/1.1.1.1, 1.1.1.1/0, or 3::3/128. If the value is any, the rule matches any IP address.	Optional
port-value	TCP or UDP port information, in the X.YYY format. · X—Operator. ¡ 1—Equal to. ¡ 2—Greater than. ¡ 3—Smaller than. ¡ 4—Not equal to. ¡ 5—In the range of. · YYY—Port number information. For example, 1.3000 and 5.2000-3000.	Optional
action-type	Action type: · 1—Deny. · 2—Permit.	Optional

The following restrictions apply to dynamic authorization ACLs:

· For the former six fields (aclrule?same?acl-name?acl-type?ver-type?rule-id) of a dynamic ACL rule, their positions are fixed. The device cannot interpret a dynamic ACL rule if the positions of the six fields are changed. For the other fields, position changes are allowed.

· The settings for all the fields in the rules must meet the configuration logic of ACL rules on the device so the device can correctly interpret the rules.

· All dynamic ACL rules in one authorization must belong to the same ACL name.

· A dynamic ACL must have rules and the format of the rules must be valid.

Format of dynamic authorization ACLs (vendor ID 9)

The server might assign a dynamic ACL to a user by using the CISCO-AV-Pair subattribute (vendor ID 9). The formats of the subattribute are as follows:

· CiscoSecure-Defined-ACL=#ACSACL#-IP-name-number

The name argument represents the ACL name and the number argument represents the version number.

For example: CiscoSecure-Defined-ACL=#ACSACL#-IP-UACL-0.

· ip:inacl#number=rule

The number argument represents the ACL rule number and the rule argument represents the rule content.

For example: ip:inacl#1=permit udp any any eq 21862.

Currently, only some device models support the CISCO-AV-Pair subattribute for 802.1X and MAC authentication. If the RADIUS server assigns dynamic ACLs to a user by using both the CISCO-AV-Pair (vendor ID 9) and Av-Pair (vendor ID 25506) subattributes, the device ignores the CISCO-AV-Pair subattribute.

The server assigns a dynamic ACL to a user as follows:

1. The server assigns a dynamic ACL name to a user by using the CISCO-AV-Pair subattribute in the format of CiscoSecure-Defined-ACL=#ACSACL#-IP-name-number after the user passes authentication.

2. The device uses the dynamic ACL name as the username of the user to initiate authentication again.

3. The server assigns one or multiple ACL rules to the user by using the CISCO-AV-Pair subattribute in the format of ip:inacl#number=rule after the user passes authentication.

4. The device parses the ACL rules received from the server, creates the ACL and its rules, and deploys the ACL and its rules to the user.

In the current software version, the device can parse only the dynamic ACL rules in the following formats:

{ deny | permit } protocol [ destination { dest-address dest-wildcard | any } | destination-port operator port1 [ port2 ] | source { source-address source-wildcard | any } | source-port operator port1 [ port2 ] ]

The value for the operator argument can be lt (lower than), gt (greater than), eq (equal to), or neq (not equal to).

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 6 shows the HWTACACS attributes supported by the device. The device ignores an HWTACACS attribute if it does not support that attribute.

Table 6 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.
roles	User roles assigned to the user.
allowed-roles	Roles for which the user is allowed to obtain temporary authorization.

FIPS compliance

The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.

AAA configuration considerations and task list

To configure AAA, complete the following tasks on the NAS:

1. Configure the required AAA schemes:

¡ Local authentication—Configure local users and the related attributes, including the usernames and passwords, for the users to be authenticated.

¡ Remote authentication—Configure the required RADIUS, HWTACACS, and LDAP schemes.

2. Configure AAA methods for the users' ISP domains. Remote AAA methods need to use the configured RADIUS, HWTACACS, and LDAP schemes.

Figure 14 AAA configuration procedure

To configure AAA, perform the following tasks:

Tasks at a glance
(Required.) Perform a minimum one of the following tasks to configure local users or AAA schemes: · Configuring local users · Configuring RADIUS schemes · Configuring HWTACACS schemes · Configuring LDAP schemes
(Required.) Configure AAA methods for ISP domains: 1. (Required.) Creating an ISP domain 2. (Optional.) Configuring ISP domain attributes 3. (Optional.) Configuring an authorization profile 4. (Optional.) Configuring the authentication failure policy for users in an ISP domain 5. (Required.) Perform a minimum one of the following tasks to configure AAA authentication, authorization, and accounting methods for the ISP domain: ¡ Configuring authentication methods for an ISP domain ¡ Configuring authorization methods for an ISP domain ¡ Configuring accounting methods for an ISP domain
(Optional.) Configuring the RADIUS session-control feature
(Optional.) Configuring the RADIUS DAS feature
(Optional.) Changing the DSCP priority for RADIUS packets
(Optional.) Configuring the RADIUS attribute translation feature
(Optional.) Configuring a critical profile
(Optional.) Configuring AAA fail-permit and recovery
(Optional.) Setting the maximum number of concurrent login users
(Optional.) Configuring a NAS-ID profile
(Optional.) Configuring the device ID
(Optional.) Enabling password change prompt logging
(Optional.) Configuring the RADIUS server feature
(Optional.) Configuring the connection recording policy
(Optional.) Displaying user MAC and UUID binding entries
(Optional.) Configuring the AAA test feature

Configuring 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 who logs in to the device for device management.

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

The following shows the configurable local user attributes:

· Description—Descriptive information of the user.

· 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.

Service types include FTP, HTTP, HTTPS, LAN access, ONU, portal, SSH, Telnet, and terminal.

· 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 who 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. Binding attributes include the IP address, access port, MAC address, and native VLAN. For support and usage information about binding attributes, see "Configuring non-guest local user attributes."

· Authorization attributes—Authorization attributes indicate the user's rights after it passes local authentication. For support information about authorization attributes, see "Configuring non-guest local user attributes."

Configure the authorization attributes based on the service type of local users.

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 local 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."

· Validity period—Time period in which a network access user is considered valid for authentication.

Local user configuration task list

Tasks at a glance
(Required.) Configure local user attributes based on the user type: · Configuring non-guest local user attributes · Configuring local guest attributes
(Optional.) Configuring user group attributes
(Optional.) Managing local guests
(Optional.) Configuring the auto-delete feature of local users

Configuring non-guest local user attributes

Non-guest local user attributes apply to all local users except guests. When you configure non-guest local user attributes, follow these guidelines:

· If password control is enabled globally by using the password-control enable command, the device does not display local user passwords 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.

· Configure the location binding attribute based on the service types of users.

¡ For 802.1X users, specify the 802.1X-enabled Layer 2 Ethernet interfaces or Layer 2 aggregate interfaces through which the users access the device.

¡ For MAC authentication users, specify the MAC authentication-enabled Layer 2 Ethernet interfaces or Layer 2 aggregate interfaces through which the users access the device.

¡ For Web authentication users, specify Web authentication-enabled Layer 2 Ethernet interfaces through which the users access the device.

¡ For portal users, specify the portal-enabled interfaces through which the users access the device. Specify the Layer 2 Ethernet interfaces if portal is enabled on VLAN interfaces and the portal roaming enable command is not configured.

To configure non-guest local user attributes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Add a local user and enter local user view.	local-user user-name [ class { manage \| network } ]	By default, no local users exist.
3. (Optional.) Configure a password for the local user.	· For a network access user: password { cipher \| simple } string · For a device management user: ¡ In non-FIPS mode: password [ { hash \| simple } string ] ¡ In FIPS mode: password	The default settings are as follows: · In non-FIPS mode, no password is configured for a local user. A local user can pass authentication after entering the correct username and passing attribute checks. · In FIPS mode, no password is configured for a local user. A local user cannot pass authentication. As a best practice to enhance security, configure a password for each local user.
4. (Optional.) Configure a description for the local user.	description text	By default, no description is configured for a local user. You can configure descriptions only for network access users.
5. Assign services to the local user.	· For a network access user: service-type { lan-access \| onu \| portal } · For a device management user: ¡ In non-FIPS mode: service-type { ftp \| { http \| https \| ssh \| telnet \| terminal } * } ¡ In FIPS mode: service-type { https \| ssh \| terminal } *	By default, no services are authorized to a local user.
6. (Optional.) Place the local user to the active or blocked state.	state { active \| block }	By default, a local user is in active state and can request network services.
7. (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. It does not apply to FTP, SFTP, or SCP users, who do not support accounting.
8. (Optional.) Configure binding attributes for the local user.	bind-attribute { ip ip-address \| location interface interface-type interface-number \| mac mac-address \| vlan vlan-id } *	By default, no binding attributes are configured for a local user.
9. (Optional.) Configure authorization attributes for the local user.	authorization-attribute { acl acl-number \| idle-cut minutes \| ip-pool ipv4-pool-name \| ipv6-pool ipv6-pool-name \| session-timeout minutes \| user-role role-name \| user-profile profile-name \| vlan vlan-id \| 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 on the default MDC. · The mdc-operator user role is assigned to local users that are created by an mdc-admin or level-15 user on a non-default MDC.
10. (Optional.) Configure password control attributes for the local user.	· 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, the local user uses password control attributes of the user group to which the local user belongs.
11. (Optional.) Assign the local user to a user group.	group group-name	By default, a local user belongs to the user group system.
12. (Optional.) Configure 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, a local user does not expire. You can configure validity periods only for network access users.

Configuring local guest attributes

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.

To configure local guest attributes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a local guest and enter local guest view.	local-user user-name class network guest	By default, no local guests exist.
3. Configure a password for the local guest.	password { cipher \| simple } string	By default, no password is configured for a local guest.
4. Configure a description for the local guest.	description text	By default, no description is configured for a local guest.
5. Specify the name of the local guest.	full-name name-string	By default, no name is specified for a local guest.
6. Specify the company of the local guest.	company company-name	By default, no company is specified for a local guest.
7. Specify the phone number of the local guest.	phone phone-number	By default, no phone number is specified for a local guest.
8. Specify the email address of the local guest.	email email-string	By default, no email address is specified for a local guest. The device sends email notifications to this address to inform the guest of the account information.
9. Specify the sponsor name for the local guest.	sponsor-full-name name-string	By default, no sponsor name is specified for a local guest.
10. Specify the sponsor department for the local guest.	sponsor-department department-string	By default, no sponsor department is specified for a local guest.
11. 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. The device sends email notifications to this address to inform the sponsor of the guest information.
12. Configure the validity period for the local guest.	validity-datetime from start-date start-time to expiration-date expiration-time	By default, a local guest does not expire. Expired guests cannot pass local authentication.
13. Assign the local guest to a user group.	group group-name	By default, a local guest belongs to the system-defined user group system.
14. 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

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.

By default, every new local user belongs to the default user group system and has all attributes of the group. To assign a local user to a different user group, use the group command in local user view.

To configure user group attributes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
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 \| idle-cut minutes \| ip-pool ipv4-pool-name \| ipv6-pool ipv6-pool-name \| session-timeout minutes\| user-role role-name \| user-profile profile-name \| vlan vlan-id \| 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.	· 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, the user group uses the global password control settings. For more information, see "Configuring password control."

Managing local guests

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:

· Registration and approval—The device creates local guests after the guest registration information is approved by a guest manager.

The registration and approval processes are as follows:

a. The device pushes the portal user registration page to a user that wants to access the network as a local guest.

b. The user submits account information for registration, including the user name, password, and email address.

c. The device forwards the registration request to the guest manager in an email notification.

d. The guest manager adds supplementary information as needed and approves the registration information.

The guest manager must process the registration request before the waiting-approval timeout timer expires. The device automatically deletes expired registration request information.

e. The device creates a local guest account and sends an email notification to the user and guest sponsor. The email contains local guest account, password, validity period, and other account information.

f. The user can access the network as a local guest.

· 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.

To manage local guests:

Step	Command	Remarks
1. Enter system view	system-view	N/A
2. 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 and body are configured.
3. 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.
4. 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.
5. Configure the guest manager's email address.	local-guest manager-email email-address	By default, the guest manager's email address is not configured.
6. (Optional.) Set the waiting-approval timeout timer for guest registration requests.	local-guest timer waiting-approval time-value	By default, the waiting-approval timeout timer for guest registration requests is 24 hours.
7. (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 ] *	N/A
8. (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.
9. (Optional.) Export local guest account information to a .csv file in the specified path.	local-user-export class network guest url url-string	N/A
10. Return to user view.	quit	N/A
11. (Optional.) Send email notifications to the local guest or the guest sponsor.	local-guest send-email user-name user-name to { guest \| sponsor }	The email contents include the user name, password, and validity period of the guest account.

Configuring the auto-delete feature of local users

This feature enables the device to examine the validity of local users at fixed time periods of 10 minutes and automatically delete expired local users.

To configure the auto-delete feature of local users:

Step	Command	Remarks
1. Enter system view	system-view	N/A
2. Enable the local user auto-delete feature.	local-user auto-delete enable	By default, the feature is disabled.

Displaying and maintaining local users and local user groups

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

Task	Command
Display pending registration requests for local guests.	display local-guest waiting-approval [ user-name user-name ]
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 \| lan-access \| onu \| portal \| ssh \| telnet \| terminal } \| state { active \| block } \| user-name user-name class { manage \| network [ guest ] } \| vlan vlan-id ]
Display the user group configuration information.	display user-group { all \| name group-name }
Clear pending registration requests for local guests.	reset local-guest waiting-approval [ user-name user-name ]

Configuring RADIUS schemes

A RADIUS scheme specifies the RADIUS servers that the device can work with and defines a set of parameters. The device uses the parameters to exchange information with the RADIUS servers, including the server host names, IP addresses, UDP port numbers, shared keys, and server types.

Configuration task list

If the authentication server in a RADIUS scheme is provided by the RADIUS server feature on the device, the RADIUS scheme only includes the following settings:

· RADIUS authentication server.

· Shared key for RADIUS communication.

· Username format for interaction with the RADIUS server.

Tasks for other settings are ignored.

To configure RADIUS schemes, perform the following tasks:

Tasks at a glance
(Optional.) Configuring an EAP profile
(Optional.) Configuring a test profile for RADIUS server status detection
(Required.) Creating a RADIUS scheme
(Required.) Specifying the RADIUS authentication servers
(Optional.) Specifying the RADIUS accounting servers and the relevant parameters
(Optional.) Specifying the shared keys for secure RADIUS communication
(Optional.) Specifying an MPLS L3VPN instance for the scheme
(Optional.) Setting the username format and traffic statistics units
(Optional.) Setting the maximum number of RADIUS request transmission attempts
(Optional.) Setting the status of RADIUS servers
(Optional.) Enabling forcibly sending stop-accounting packets
(Optional.) Associating a microsegment with a VSI
(Optional.) Enabling the RADIUS server load sharing feature
(Optional.) Specifying a RADIUS server selection mode for reauthentication
(Optional.) Specifying the source IP address for outgoing RADIUS packets
(Optional.) Setting RADIUS timers
(Optional.) Configuring the RADIUS accounting-on feature
(Optional.) Interpreting the RADIUS class attribute as CAR parameters
(Optional.) Configuring the format of the RADIUS NAS-Port attribute
(Optional.) Configuring the Login-Service attribute check method for SSH, FTP, and terminal users
(Optional.) Configuring the MAC address format for the RADIUS Called-Station-Id attribute
(Optional.) Configuring the MAC address format for the RADIUS Calling-Station-Id attribute
(Optional.) Configuring the format of RADIUS attribute 87
(Optional.) Setting the data measurement unit for the Remanent_Volume attribute
(Optional.) Including subattribute 218 of vendor 25506 in outgoing RADIUS packets
(Optional.) Configuring the device to preferentially process RADIUS authentication requests
(Optional.) Enabling SNMP notifications for RADIUS
(Optional.) Disabling the RADIUS service

Configuring an EAP profile

An EAP profile is a collection of EAP authentication settings, including the EAP authentication method and the CA certificate file. You can specify an EAP profile in a test profile for RADIUS server status detection. EAP-based RADIUS server status detection provides more reliable server status detection results than simple server status detection.

When you configure an EAP profile, follow these restrictions and guidelines:

· Before you specify a CA certificate file, use FTP or TFTP to transfer the CA certificate file to the root directory of the default storage medium on the device. In an IRF fabric, make sure the CA certificate file already exists in the root directory of the default storage medium on the master device.

· You can specify an EAP profile in multiple test profiles.

· You can configure a maximum of 16 EAP profiles.

To configure an EAP profile:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an EAP profile and enter EAP profile view.	eap-profile eap-profile-name	By default, no EAP profiles exist.
3. Specify the EAP authentication method.	method { md5 \| peap-gtc \| peap-mschapv2 \| ttls-gtc \| ttls-mschapv2 }	By default, the EAP authentication method is MD5-challenge.
4. Specify a CA certificate file for EAP authentication.	ca-file file-name	By default, no CA certificate file is specified for EAP authentication. You must specify a CA certificate file to verify the RADIUS server certificate if the EAP authentication method is PEAP-GTC, PEAP-MSCHAPv2, TTLS-GTC, or TTLS-MSCHAPv2.

Configuring a test profile for RADIUS server status detection

Overview

To detect the reachability or availability of a RADIUS authentication server, specify a test profile for the RADIUS server when you specify the server in a RADIUS scheme. With the test profile, the device refreshes the RADIUS server status at each detection interval according to the detection result. If the server is unreachable or unavailable, the device sets the status of the server to blocked. If the server is reachable or available, the device sets the status of the server to active.

The device supports the following RADIUS server status detection methods:

· Simple detection—For a RADIUS server, the device simulates an authentication request with the username and password specified in the test profile used by the server. The authentication request is sent to the RADIUS server within each detection interval. The device determines that the RADIUS server is reachable if the device receives a response from the server within the interval.

· EAP-based detection—For a RADIUS server, the device simulates an EAP authentication with the username and password specified in the test profile used by the server. The simulated EAP authentication starts at the beginning of each detection interval. If the EAP authentication completes within a detection interval, the device determines that the RADIUS server is available.

Simulating a complete EAP authentication process, EAP-based detection provides more reliable detection results than simple detection. As a best practice, configure EAP-based detection on a network environment where EAP authentication is configured.

Configuration restrictions and guidelines

When you configure test profiles for RADIUS server status detection, follow these restrictions and guidelines:

· You can configure multiple test profiles in the system.

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

· If you specify a nonexistent EAP profile in a test profile, the device performs simple detection for the RADIUS servers that use the test profile. After the EAP profile is configured, the device will start EAP-based detection at the next detection interval.

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

¡ The RADIUS server is removed from the RADIUS scheme.

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

¡ The test profile specified for the RADIUS server is deleted.

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

¡ The RADIUS scheme that contains the RADIUS server is deleted.

Configuration procedure

To configure a test profile for RADIUS server status detection:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure a test profile for detecting the status of RADIUS authentication servers.	radius-server test-profile profile-name username name [ password { cipher \| simple } string ] [ interval interval ] [ eap-profile eap-profile-name ]	By default, no test profiles exist. You can configure multiple test profiles in the system.

Step

Command

Remarks

1. Enter system view.

system-view

N/A

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

radius-server test-profile profile-name username name [ password { cipher | simple } string ] [ interval interval ] [ eap-profile eap-profile-name ]

By default, no test profiles exist.

You can configure multiple test profiles in the system.

Creating a RADIUS scheme

Create a RADIUS scheme before performing any other RADIUS configurations. You can configure a maximum of 16 RADIUS schemes. A RADIUS scheme can be used by multiple ISP domains.

To create a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a RADIUS scheme and enter RADIUS scheme view.	radius scheme radius-scheme-name	By default, no RADIUS schemes exist.

Specifying the RADIUS authentication servers

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 unavailable. The device searches for an active server in the order the secondary servers are configured.

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.

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.

To specify RADIUS authentication servers for a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Specify RADIUS authentication servers.	· Specify the primary RADIUS authentication server: primary authentication { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| test-profile profile-name \| vpn-instance vpn-instance-name \| weight weight-value ] * · Specify a secondary RADIUS authentication server: secondary authentication { host-name \| 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 authentication servers are specified. To support server status detection, specify an existing test profile for the RADIUS authentication server. If the test profile does not exist, the device cannot detect the server status. Two authentication servers in a scheme, primary or secondary, cannot have the same combination of host name, IP address, port number, and VPN instance. The weight keyword takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme.

Specifying the RADIUS accounting servers and the relevant parameters

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.

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.

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

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.

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

To specify RADIUS accounting servers and the relevant parameters for a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Specify RADIUS accounting servers.	· Specify the primary RADIUS accounting server: primary accounting { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| vpn-instance vpn-instance-name \| weight weight-value ] * · Specify a secondary RADIUS accounting server: secondary accounting { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| vpn-instance vpn-instance-name \| weight weight-value ] *	By default, no accounting servers are specified. Two accounting servers in a scheme, primary or secondary, cannot have the same combination of host name, IP address, port number, and VPN instance. The weight keyword takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme.
4. (Optional.) Set the maximum number of real-time accounting attempts.	retry realtime-accounting retries	The default setting is 5.
5. (Optional.) 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.
6. (Optional.) Set the maximum number of transmission attempts for individual RADIUS stop-accounting requests.	retry stop-accounting retries	The default setting is 500.

Specifying the shared keys for secure RADIUS communication

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.

To specify a shared key for secure RADIUS communication:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
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. The shared key configured on the device must be the same as the shared key configured on the RADIUS server.

Specifying an MPLS L3VPN instance for the scheme

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.

To specify a VPN instance for a scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
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 username format and traffic statistics units

A username is in the userid@isp-name format, where the isp-name argument 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.

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.

The device reports online user traffic statistics in accounting packets. The traffic measurement units are configurable, but they must be the same as the traffic measurement units configured on the RADIUS accounting servers.

To set the username format and the traffic statistics units for a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
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. If the device is specified as the RADIUS server in the scheme, the username format must be without-domain.
4. (Optional.) 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

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 RADIUS timers."

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.

To set the maximum number of RADIUS request transmission attempts:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Set the maximum number of RADIUS request transmission attempts.	retry retries	The default setting is 3.

Setting the status of RADIUS servers

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 disabled, the device chooses servers based on the following rules:

· When the primary server is in active state, the device communicates with the primary server.

· If the primary server fails, the device performs the following operations:

¡ Changes the server status to blocked.

¡ Starts a quiet timer for the server.

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

· If the secondary 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.

· 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 or accounting attempt a failure.

· 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.

· 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 all servers are in blocked state, the device only tries to communicate with the primary server.

· 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.

· 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.

The device selects a reachable server for the authentication or accounting of a new user according to the server selection rules in this section if the RADIUS server load sharing feature is disabled. However, these rules are inapplicable to the reauthentication of online users if the RADIUS server selection mode for reauthentication is set to inherit by using the reauthentication server-select inherit command.

To set the status of RADIUS servers:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Set the RADIUS server status.	· 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 [ { host-name \| 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 [ { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| vpn-instance vpn-instance-name ] * ] { active \| block }	By default, a RADIUS server is in active state. 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.

Enabling forcibly sending stop-accounting packets

Typically, if the device does not send a start-accounting packet to the RADIUS server for an authenticated user, it does not send a stop-accounting packet when the user goes offline. If the 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 stop-accounting packets to the RADIUS server when the user goes offline for timely releasing the user entry on the server.

To enable forcibly sending stop-accounting packets:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Enable the device to send stop-accounting packets when users for which no start-accounting packets are sent go offline.	stop-accounting-packet send-force	By default, forcibly sending stop-accounting packets is disabled. The device does not send stop-accounting packets when users for which no start-accounting packets are sent go offline.

Associating a microsegment with a VSI

About this task

Use this feature when microsegment-based access control is deployed on a VXLAN network.

When the RADIUS server assigns the microsegment and VSI attributes to a user, the device directly assigns the microsegment and VSI to the user so the user can access the related VXLAN resources.

When the RADIUS server assigns only the microsegment attribute but no VSI attribute to a user, the device will search for a VSI associated with the microsegment.

· If the device finds an associated VSI, it assigns the microsegment and the VSI to the user.

· If the device does not find an associated VSI, it assigns only the microsegment to the user.

Restrictions and guidelines

In a RADIUS scheme, a microsegment can be associated with only one VSI. Multiple microsegments can be associated with the same VSI. If you repeat the microsegment associate command to associate a microsegment with different VSIs, the most recent configuration takes effect.

Make sure the device can interpret microsegment IDs assigned by the RADIUS server. If the device cannot directly interpret microsegment IDs, use the attribute translation feature so the device can translate the server-assigned microsegment ID attribute to the H3C-Microsegment-Id attribute.

Procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Associate a microsegment with a VSI.	microsegment microsegment-id associate vsi vsi-name	By default, no VSI is associated with a microsegment.

Enabling the RADIUS server load sharing feature

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 unavailable, 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 the active server.

Use the RADIUS server load sharing feature to dynamically distribute the workload over multiple servers regardless of their server roles. The device forwards an AAA request to the most appropriate server of all active servers in the scheme after it compares the weight values and numbers of currently served users. Specify a weight value for each RADIUS server based on the AAA capacity of the server. A larger weight value indicates a higher AAA capacity.

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.

To enable the RADIUS server load sharing feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Enable the RADIUS server load sharing feature.	server-load-sharing enable	By default, this feature is disabled.

Specifying a RADIUS server selection mode for reauthentication

Use this feature to configure the RADIUS server selection mechanism in reauthentication. The following RADIUS server selection modes are available:

· Inherit—The device uses the RADIUS server that performed authentication for a user to reauthenticate that user. This mode reduces the amount of time used in reauthentication. However, if the RADIUS server is unreachable, the reauthentication will fail.

· Reselect—The device searches for a reachable RADIUS server to reauthenticate a user. This mode requires more time than the inherit mode. However, this mode ensures that the device uses the optimal reachable RADIUS server for reauthentication. The following factors affect the RADIUS server selection:

¡ Server configuration in the RADIUS scheme, including the configuration order.

¡ Enabling status of the RADIUS server load sharing feature.

¡ Status of the RADIUS servers in the RADIUS scheme.

To specify a RADIUS server selection mode for reauthentication:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Specify a RADIUS server selection mode for reauthentication.	reauthentication server-select { inherit \| reselect }	By default, the inherit mode is used.

Specifying the source IP address for outgoing RADIUS packets

Overview

A RADIUS server identifies a NAS by its IP address. Upon receiving a RADIUS packet, the RADIUS server checks the source IP address of the packet.

· If it is the IP address of a managed NAS, the server processes the packet.

· If it is not the IP address of a managed NAS, the server drops the packet.

Before sending a RADIUS packet, the NAS selects a source IP address for the packet in the following order:

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

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

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

In an M-LAG system, you must specify the source IP address for outgoing RADIUS packets on both the M-LAG member devices. Each M-LAG member device selects a source IP address in the above order. To make user traffic switchover caused by primary/secondary M-LAG member device switchover transparent to the RADIUS server, ensure that the source IP address for outgoing RADIUS packets remains unchanged. Therefore, you must specify the source IP address according to the load sharing mode for user authentication on M-LAG interfaces:

· In centralized mode, you must specify the same local source IP address on both the M-LAG member devices.

When an M-LAG member device fails, the active M-LAG member device uses the local source IP address of outgoing RADIUS packets for users authenticated on the failed M-LAG member device.

· In distributed mode, you must specify a local and peer source IP address pair on both the M-LAG member devices. Make sure the peer source IP address on an M-LAG member device is the local IP address on the other M-LAG member device.

When an M-LAG member device fails, the active M-LAG member device uses the peer source IP address of outgoing RADIUS packets for users authenticated on the failed M-LAG member device.

Configuration restrictions and guidelines

When you specify the source IP address for outgoing RADIUS packets, follow these restrictions and guidelines:

· You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view or in system view.

¡ The IP address specified in RADIUS scheme view applies only to one RADIUS scheme.

¡ The IP address specified in system view applies to all RADIUS schemes for the specified VPN or the public network.

The setting in RADIUS scheme view takes precedence over the setting in system view.

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

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

· The source IP address of outgoing RADIUS packets is typically the IP address of an egress interface on the NAS to communicate with the RADIUS server. However, in some situations, you must change the source IP address. For example, when VRRP is configured for stateful failover, configure the virtual IP of the uplink VRRP group as the source IP address.

· You can directly specify a source IP address for outgoing RADIUS packets or specify a source interface to provide the source IP address for outgoing RADIUS packets. The source interface configuration and the source IP address configuration overwrite each other.

In an M-LAG system, you must specify a virtual IP address for the M-LAG system as the source IP address specified for outgoing RADIUS packets. For more information about virtual IP addresses for the M-LAG system, see M-LAG configuration in Layer 2—LAN Switching Configuration Guide.

Configuration procedure

To specify a source interface or source IP address for all RADIUS schemes in a VPN or the public network:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify a source interface or source IP address for outgoing RADIUS packets.	radius nas-ip { interface interface-type interface-number \| { ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] }	By default, the source IP address of an outgoing RADIUS packet is the primary IPv4 address or the IPv6 address of the outbound interface.

To specify a source interface or source IP address for a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Specify a source interface or source IP address for outgoing RADIUS packets.	nas-ip [ m-lag { local \| peer } ] { ipv4-address \| interface interface-type interface-number \| ipv6 ipv6-address }	By default, the source IP address of an outgoing RADIUS packet is that specified by using the radius nas-ip command in system view. If this command is not used, the source IP address is the primary IP address of the outbound interface. The m-lag { local \| peer } option specifies the source IP address of outgoing RADIUS packets for users that access the network through M-LAG interfaces on an M-LAG system. This option is required only on an M-LAG system.

Setting RADIUS timers

Overview

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.

Configuration restrictions and guidelines

When you set RADIUS timers, follow these 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.

Configuration procedure

To set RADIUS timers:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Set the RADIUS server response timeout timer.	timer response-timeout seconds	The default setting is 3 seconds.
4. Set the quiet timer for the servers.	timer quiet minutes	The default setting is 5 minutes.
5. Set the real-time accounting timer.	timer realtime-accounting interval [ second ]	The default setting is 12 minutes.

Configuring the RADIUS accounting-on feature

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. For the extended accounting-on feature to take effect, the RADIUS server must run on IMC and the accounting-on feature must be enabled.

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 who 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.

To configure the accounting-on feature for a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
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.

Interpreting the RADIUS class attribute as CAR parameters

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.

To configure the device to interpret the RADIUS class attribute as CAR parameters:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
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 format of the RADIUS NAS-Port attribute

Overview

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

· Default format—Contains the following portions:

¡ 8-bit IRF member ID.

¡ 4-bit slot number.

¡ 8-bit interface index.

¡ 12-bit VLAN ID.

· Port format—Contains the last segment for the interface number of the interface through which a user accesses the device. For example, if a user accesses the device through Twenty-FiveGigE 1/0/2, 2 is used as the value for the RADIUS NAS-Port attribute.

Configuration restrictions and guidelines

RADIUS servers of different types might have different requirements for the format of the NAS-Port attribute. To ensure correct RADIUS packet exchange, make sure the format of the NAS-Port attribute meets the requirements of the RADIUS servers.

Configuration procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Configure the format of the RADIUS NAS-Port attribute as the port format.	attribute 5 format port	By default, the RADIUS NAS-Port attribute uses the default format.

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

The device supports the following check methods for the Login-Service attribute (RADIUS attribute 15) of SSH, FTP, and terminal users:

· Strict—Matches Login-Service attribute values 50, 51, and 52 for SSH, FTP, and terminal services, respectively.

· Loose—Matches the standard Login-Service attribute value 0 for SSH, FTP, and terminal services.

An Access-Accept packet received for a user must contain the matching attribute value. Otherwise, the user cannot log in to the device.

Use the loose check method only when the server does not issue Login-Service attribute values 50, 51, and 52 for SSH, FTP, and terminal users.

To configure the Login-Service attribute check method for SSH, FTP, and terminal users:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Configure the Login-Service attribute check method for SSH, FTP, and terminal users.	attribute 15 check-mode { loose \| strict }	The default check method is strict.

Configuring the MAC address format for the RADIUS Called-Station-Id attribute

Configuration restrictions and guidelines

RADIUS servers of different types might have different requirements for the MAC address format in the RADIUS Called-Station-Id attribute. Configure the MAC address format for this attribute to meet the requirements of the RADIUS servers.

Configuration procedure

To configure the MAC address format for the RADIUS Called-Station-Id attribute:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Configure the MAC address format for the RADIUS Called-Station-Id attribute.	attribute 30 mac-format section { one \| { six \| three } separator separator-character } { lowercase \| uppercase }	By default, the MAC address in the RADIUS Called-Station-Id attribute 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 MAC address format for the RADIUS Calling-Station-Id attribute

RADIUS servers of different types might have different requirements for the MAC address format in the RADIUS Calling-Station-Id attribute (attribute 31). Configure the MAC address format for this attribute to meet the requirements of the RADIUS servers.

To configure the MAC address format for the RADIUS Calling-Station-Id attribute:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Configure the MAC address format for the RADIUS Calling-Station-Id attribute.	attribute 31 mac-format section { one \| { six \| three } separator separator-character } { lowercase \| uppercase }	By default, the MAC address in the RADIUS Calling-Station-Id attribute 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 format of RADIUS attribute 87

Overview

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

· Default format—The default format varies by user access type.

¡ For portal users, the NAS-Port-Id attribute in this format contains the following portions:

- 2-bit slot number.

- 2-bit 0s.

- 3-bit interface index.

- 9-bit VLAN ID.

¡ For 802.1X and MAC authentication users, the NAS-Port-Id attribute is in the format of slot=xx;subslot=xx;port=xx;vlanid=xx.

- slot—IRF member ID.

- subslot—Slot number.

- port—Interface index.

- vlanid—VLAN ID.

¡ For login users, the NAS-Port-Id attribute is not included in RADIUS packets.

· Interface name format—Contains the name of the interface through which a user accesses the device. For example, if a user accesses the device through Twenty-FiveGigE 1/0/1, Twenty-FiveGigE 1/0/1 is used as the value for the RADIUS NAS-Port-Id attribute.

Configuration restrictions and guidelines

RADIUS servers of different types might have different requirements for the format of the NAS-Port-Id attribute. To ensure correct RADIUS packet exchange, configure the format of the NAS-Port-Id attribute to meet the requirements of the RADIUS servers.

Configuration procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Configure the format of RADIUS attribute 87 as the interface name format.	attribute 87 format interface-name	By default, the default format is used for RADIUS attribute 87.

Setting the data measurement unit for the Remanent_Volume attribute

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

Perform this task to set the data measurement unit for the Remanent_Volume attribute. Make sure the configured measurement unit is the same as the user data measurement unit on the RADIUS server.

To set the data measurement unit for the Remanent_Volume attribute:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
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.

Including subattribute 218 of vendor 25506 in outgoing RADIUS packets

Overview

The RADIUS Vendor-Specific attribute (attribute 26) allows vendors to define extended attributes to implement functions that the standard RADIUS protocol does not provide. Vendor 25506 defines subattribute 218 to carry user DHCP option information.

To send user DHCP option information to RADIUS servers, perform this task to include subattribute 218 of vendor 25506 in outgoing RADIUS start-accounting and update-accounting requests.

In the current software version, only DHCP Option 55 and DHCP Option 66 can be carried in the subattribute.

Configuration restrictions and guidelines

You can repeat the include-attribute 218 vendor-id 25506 command to configure the device to encapsulate both DHCP Option 55 and DHCP Option 61 in the subattribute. The length of each option is limited to 246 bytes.

If you repeat this command multiple times with the same DHCP option specified, the most recent configuration takes effect.

Configuration procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Include subattribute 218 of vendor 25506 in outgoing RADIUS packets.	include-attribute 218 vendor-id 25506 dhcp-option { 55 \| 61 } * { format1 \| format2 }	By default, the device uses format 1 to encapsulate DHCP Option 61 in subattribute 218 of vendor 25506 in RADIUS packets.

Configuring the device to preferentially process RADIUS authentication requests

Overview

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.

Configuration 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.

Configuration procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
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.

Enabling SNMP notifications for RADIUS

Overview

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

· 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 the network management and monitoring configuration guide for the device.

Configuration 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.

Configuration procedure

To enable SNMP notifications for RADIUS:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable SNMP notifications for RADIUS.	snmp-agent trap enable radius [ accounting-server-down \| accounting-server-up \| authentication-error-threshold \| authentication-server-down \| authentication-server-up ] *	By default, all SNMP notifications are disabled for RADIUS.
3. (Optional.) 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.

Disabling the RADIUS service

Overview

By default, the RADIUS service is enabled. The device can send and receive RADIUS packets. Attackers might use RADIUS session-control and DAE ports to attack the device. To protect the device when such an attack occurs, disable the RADIUS service temporarily on the device. After the network is secure, re-enable the RADIUS service.

If settings on the RADIUS servers require modification or the RADIUS servers cannot provide services temporarily, you can temporarily disable the RADIUS service on the device.

When the RADIUS service is disabled, the device stops sending and receiving RADIUS packets. If a new user comes online, the device uses the backup authentication, authorization, or accounting method to process that user. If the device has not finished requesting authentication or accounting for a user before the RADIUS service is disabled, it uses the following rules to process that user:

· If the device has sent RADIUS authentication requests for that user to a RADIUS server, the device processes that user depending on whether it receives a response from the RADIUS server.

¡ If the device receives a response from the RADIUS server, it uses the response to determine whether that user has passed authentication. If that user has passed authentication, the device assigns authorization information to that user according to the response.

¡ If the device does not receive any response from the RADIUS server, it attempts to use the backup authentication method to authenticate that user.

· If the device has sent RADIUS start-accounting requests for that user to a RADIUS server, the device processes that user depending on whether it receives a response from the RADIUS server.

¡ If the device receives a response from the RADIUS server, it allows that user to come online. However, the device cannot send out accounting-update or stop-accounting requests to the RADIUS server. It cannot buffer the accounting requests, either. When that user goes offline, the RADIUS server cannot log off that user in time. The accounting result might be inaccurate.

¡ If the device does not receive any response from the RADIUS server, it attempts to use the backup accounting method.

Configuration restrictions and guidelines

Disabling the RADIUS service does not affect the RADIUS server feature of the device.

The authentication, authorization, and accounting processes undertaken by other methods are not switched to RADIUS when you re-enable the RADIUS service.

Configuration procedure

To disable the RADIUS service:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Disable the RADIUS service.	undo radius enable	By default, the RADIUS service is enabled. To re-enable the RADIUS service, use the radius enable command.

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Disable the RADIUS service.

undo radius enable

By default, the RADIUS service is enabled.

To re-enable the RADIUS service, use the radius enable command.

Displaying and maintaining 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 on all RADIUS servers.	display radius server-load statistics
Display RADIUS packet statistics.	display radius statistics
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 from all RADIUS servers.	reset radius server-load statistics
Clear RADIUS statistics.	reset radius statistics
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 schemes

Configuration task list

Tasks at a glance
(Required.) Creating an HWTACACS scheme
(Required.) Specifying the HWTACACS authentication servers
(Optional.) Specifying the HWTACACS authorization servers
(Optional.) Specifying the HWTACACS accounting servers
(Required.) Specifying the shared keys for secure HWTACACS communication
(Optional.) Specifying an MPLS L3VPN instance for the scheme
(Optional.) Setting the username format and traffic statistics units
(Optional.) Specifying the source IP address for outgoing HWTACACS packets
(Optional.) Setting HWTACACS timers
(Optional.) Setting the DSCP priority for HWTACACS packets

Creating an HWTACACS scheme

Create an HWTACACS scheme before performing any other HWTACACS configurations. You can configure a maximum of 16 HWTACACS schemes. An HWTACACS scheme can be used by multiple ISP domains.

To create an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an HWTACACS scheme and enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	By default, no HWTACACS schemes exist.

Specifying the HWTACACS authentication servers

You can specify one primary authentication server and a maximum of 16 secondary authentication 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.

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.

To specify HWTACACS authentication servers for an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Specify HWTACACS authentication servers.	· Specify the primary HWTACACS authentication server: primary authentication { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection \| vpn-instance vpn-instance-name ] * · Specify a secondary HWTACACS authentication server: secondary authentication { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection \| vpn-instance vpn-instance-name ] *	By default, no authentication servers are specified. Two HWTACACS authentication servers in a scheme, primary or secondary, cannot have the same combination of host name, IP address, port number, and VPN instance.

Specifying the HWTACACS authorization servers

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.

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.

To specify HWTACACS authorization servers for an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Specify HWTACACS authorization servers.	· Specify the primary HWTACACS authorization server: primary authorization { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection \| vpn-instance vpn-instance-name ] * · Specify a secondary HWTACACS authorization server: secondary authorization { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection \| vpn-instance vpn-instance-name ] *	By default, no authorization servers are specified. Two HWTACACS authorization servers in a scheme, primary or secondary, cannot have the same combination of host name, IP address, port number, and VPN instance.

Specifying the HWTACACS accounting servers

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.

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.

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.

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

To specify HWTACACS accounting servers for an HWTACACS scheme:

Step		Command		Remarks
1. Enter system view.		system-view		N/A
2. Enter HWTACACS scheme view.		hwtacacs scheme hwtacacs-scheme-name		N/A
3. Specify HWTACACS accounting servers.		· Specify the primary HWTACACS accounting server: primary accounting { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection \| vpn-instance vpn-instance-name ] * · Specify a secondary HWTACACS accounting server: secondary accounting { host-name \| ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection \| vpn-instance vpn-instance-name ] *		By default, no accounting servers are specified. Two HWTACACS accounting servers in a scheme, primary or secondary, cannot have the same combination of host name, IP address, port number, and VPN instance.
4. (Optional.) 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.
5. (Optional.) Set the maximum number of transmission attempts for individual HWTACACS stop-accounting requests.	retry stop-accounting retries		The default setting is 100.

Specifying the shared keys for secure HWTACACS communication

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.

To specify a shared key for secure HWTACACS communication:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
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. The shared key configured on the device must be the same as the shared key configured on the HWTACACS server.

Specifying an MPLS L3VPN instance for the scheme

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.

To specify a VPN instance for an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
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 the username format and traffic statistics units

A username is typically in the userid@isp-name format, where the isp-name argument 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.

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.

To set the username format and traffic statistics units for an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
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. (Optional.) 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.

Specifying the source IP address for outgoing HWTACACS packets

Overview

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 it is the IP address of a managed NAS, the server processes the packet.

· If it is not the IP address of a managed NAS, the server drops the packet.

Before sending an HWTACACS packet, the NAS selects a source IP address for the packet 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.

Configuration restrictions and guidelines

When you specify the source IP address for outgoing HWTACACS packets, follow these restrictions and guidelines:

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

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

¡ The IP address specified in system view applies to all HWTACACS schemes for the specified VPN or the public network.

The setting in HWTACACS scheme view takes precedence over the setting in system view.

· 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, specify a loopback interface address as the source IP address for outgoing HWTACACS packets to avoid HWTACACS packet loss caused by physical port errors.

· The source IP address of outgoing HWTACACS packets is typically the IP address of an egress interface on the NAS to communicate with the HWTACACS server. However, in some situations, you must change the source IP address. For example, when VRRP is configured for stateful failover, configure the virtual IP of the uplink VRRP group as the source IP address.

· You can directly specify a source IP address for outgoing HWTACACS packets or specify a source interface to provide the source IP address for outgoing HWTACACS packets. The source interface configuration and the source IP address configuration overwrite each other.

Configuration procedure

To specify a source interface or source IP address for all HWTACACS schemes of a VPN or the public network:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify a source interface or source IP address for outgoing HWTACACS packets.	hwtacacs nas-ip { interface interface-type interface-number \| { ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] }	By default, the source IP address of an outgoing HWTACACS packet is the primary IPv4 address or the IPv6 address of the outbound interface.

To specify a source interface or source IP address for an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Specify a source interface or source IP address for outgoing HWTACACS packets.	nas-ip { ipv4-address \| interface interface-type interface-number \| ipv6 ipv6-address }	By default, the source IP address of an outgoing HWTACACS packet is that specified by using the hwtacacs nas-ip command in system view. If this command is not used, the source IP address is the primary IP address of the outbound interface.

Setting HWTACACS timers

Overview

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.

Configuration restrictions and guidelines

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.

· If the primary server fails, the device performs the following operations:

¡ Changes the server status to blocked.

¡ Starts a quiet timer for the server.

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

· If the secondary 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, the status of the server changes back to active. The device does not check the server again during the authentication, authorization, or accounting process.

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

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

· 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.

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.

Configuration procedure

To set HWTACACS timers:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Set the HWTACACS server response timeout timer.	timer response-timeout seconds	By default, the HWTACACS server response timeout timer is 5 seconds.
4. Set the real-time accounting interval.	timer realtime-accounting minutes	By default, the real-time accounting interval is 12 minutes. A short interval helps improve accounting precision but requires many system resources. When there are 1000 or more users, set a longer interval.
5. Set the server quiet timer.	timer quiet minutes	By default, the server quiet timer is 5 minutes.

Setting the DSCP priority for HWTACACS packets

Overview

DSCP priority determines the transmission priority of HWTACACS packets. A larger value represents a higher priority.

DSCP priority is contained in the ToS field of the IPv4 header and in the Traffic Class field of the IPv6 header.

Configuration procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the DSCP priority for HWTACACS packets.	hwtacacs [ ipv6 ] dscp dscp-value	By default, the DSCP priority is 0 for HWTACACS packets.

Displaying and maintaining 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 HWTACACS packet statistics.	display hwtacacs 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 schemes

Configuration task list

Tasks at a glance
Configuring an LDAP server: · (Required.) Creating an LDAP server · (Required.) Configuring the IP address of the LDAP server · (Optional.) Specifying the LDAP version · (Optional.) Setting the LDAP server timeout period · (Required.) Configuring administrator attributes · (Required.) Configuring LDAP user attributes
(Optional.) Configuring an LDAP attribute map
(Required.) Creating an LDAP scheme
(Required.) Specifying the LDAP authentication server
(Optional.) Specifying the LDAP authorization server
(Optional.) Specifying an LDAP attribute map for LDAP authorization

Creating an LDAP server

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an LDAP server and enter LDAP server view.	ldap server server-name	By default, no LDAP servers exist.

Configuring the IP address of the LDAP server

Step	Command	Remarks
1. Enter system view.	System-view	N/A
2. Enter LDAP server view.	ldap server server-name	N/A
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. You can configure either an IPv4 address or an IPv6 address for an LDAP server. The most recent configuration takes effect.

Specifying the LDAP version

Specify the LDAP version on the NAS. The device supports LDAPv2 and LDAPv3. The LDAP version specified on the device must be consistent with the version specified on the LDAP server.

To specify the LDAP version:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP server view.	ldap server server-name	N/A
3. Specify the LDAP version.	protocol-version { v2 \| v3 }	By default, LDAPv3 is used. A Microsoft LDAP server supports only LDAPv3.

Setting the LDAP server timeout period

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.

To set the LDAP server timeout period:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP server view.	ldap server server-name	N/A
3. Set the LDAP server timeout period.	server-timeout time-interval	By default, the LDAP server timeout period is 10 seconds.

Configuring administrator attributes

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

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP server view.	ldap server server-name	N/A
3. Specify the administrator DN.	login-dn dn-string	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.	login-password { cipher \| simple } string	By default, no administrator password is specified.

Configuring LDAP user attributes

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.

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.

To configure LDAP user attributes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP server view.	ldap server server-name	N/A
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

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.

To configure an LDAP attribute map:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an LDAP attribute map and enter LDAP attribute map view.	ldap attribute-map map-name	By default, no LDAP attribute maps exist.
3. Configure a mapping entry.	map ldap-attribute ldap-attribute-name [ prefix prefix-value delimiter delimiter-value ] aaa-attribute { user-group \| user-profile }	By default, an LDAP attribute map does not have any mapping entries. Repeat this command to configure multiple mapping entries.

Creating an LDAP scheme

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

To create an LDAP scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an LDAP scheme and enter LDAP scheme view.	ldap scheme ldap-scheme-name	By default, no LDAP schemes exist.

Specifying the LDAP authentication server

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP scheme view.	ldap scheme ldap-scheme-name	N/A
3. Specify the LDAP authentication server.	authentication-server server-name	By default, no LDAP authentication server is specified.

Specifying the LDAP authorization server

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP scheme view.	ldap scheme ldap-scheme-name	N/A
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

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

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

To specify an LDAP attribute map for LDAP authorization:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP scheme view.	ldap scheme ldap-scheme-name	N/A
3. Specify an LDAP attribute map.	attribute-map map-name	By default, no LDAP attribute map is specified.

Displaying and maintaining LDAP

Execute display commands in any view.

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

Configuring AAA methods for ISP domains

You configure AAA methods for an ISP domain by specifying configured AAA schemes in ISP domain view. 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.

AAA is available to login users after you enable scheme authentication for the users. For more information about the login authentication modes, see Fundamentals Configuration Guide.

Configuration prerequisites

To use local authentication for users in an ISP domain, configure local user accounts on the device first. See "Configuring non-guest local user attributes."

To use remote authentication, authorization, and accounting, create the required RADIUS, HWTACACS, or LDAP schemes. For more information about the scheme configuration, see "Configuring RADIUS schemes," "Configuring HWTACACS schemes," and "Configuring LDAP schemes."

Creating an ISP domain

Overview

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 AAA methods and domain attributes for each ISP domain as needed.

The device supports a maximum of 16 ISP domains, including the system-defined ISP domain system. You can specify one of the ISP domains as the default 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 considers the user belongs to the default ISP domain.

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

1. The authentication domain specified for the access module.

2. The ISP domain in the username.

3. The default ISP domain of the device.

If the chosen domain does not exist on the device, the device searches for the ISP domain that accommodates users who are assigned to nonexistent domains. If no such ISP domain is configured, user authentication fails.

NOTE:

Support for the authentication domain configuration depends on the access module.

Configuration restrictions and guidelines

When you configure an ISP domain, follow these restrictions and guidelines:

· An ISP domain cannot be deleted when it is the default 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.

Configuration procedure

To create an ISP domain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an ISP domain and enter ISP domain view.	domain isp-name	By default, a system-defined ISP domain exists. The domain name is system.
3. Return to system view.	quit	N/A
4. (Optional.) Specify the default ISP domain.	domain default enable isp-name	By default, the default ISP domain is the system-defined ISP domain system.
5. (Optional.) Specify the ISP domain to accommodate users who are assigned to nonexistent domains.	domain if-unknown isp-domain-name	By default, no ISP domain is specified to accommodate users who are assigned to nonexistent domains.

Configuring ISP domain attributes

Overview

A user in an ISP domain can use the following authorization attributes:

· Attributes assigned by the server.

· Attributes configured in the authentication domain.

· Attributes defined in the authorization profile applied to the authentication domain.

The priorities of the attributes are in descending order.

In an ISP domain, you can configure the following attributes:

· Domain status—By placing the ISP domain in active or blocked state, you allow or deny network service requests from users in the domain.

· Authorization attributes—The device assigns the authorization attributes in the ISP domain to the authenticated users who do not receive these attributes from the server. However, if the idle cut attribute is configured in the ISP domain, the device assigns the attribute to the authenticated users. If no idle cut attribute is configured in the ISP domain, the device uses the idle cut attribute assigned by the server. The device supports the following authorization attributes:

¡ Authorization ACL—The device restricts authenticated users to access only the network resources permitted by the ACL. For portal users, the authorization ACL can be configured in a preauthentication domain to authorize access to network resources before users pass authentication.

¡ 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.

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

¡ Microsegment—The device authorizes the authenticated users to access the network resources in the specified microsegment.

¡ Redirect URL—The device redirects users in the domain to the URL after they pass authentication.

¡ Authorization user group—Authenticated users in the domain obtain all attributes of the user group.

¡ User profile—The device restricts the user's behavior based on the user profile.

¡ Maximum number of multicast groups—The attribute restricts the maximum number of multicast groups that an authenticated user can join concurrently.

¡ VLAN—The device authorizes the authenticated users to access the network resources in the specified VLAN.

¡ VSI—The device authorizes the authenticated users to access the network resources in the specified VSI.

An ISP domain attribute applies to all users in the domain.

Configuration restrictions and guidelines

To avoid user logoff caused by authorization attribute conflicts, do not assign an authorization VSI and an authorization VLAN at the same time. The conflict occurs in the following cases:

· The server authorizes a VSI through session control or CoA messages to an online user that is authorized with a VLAN at association.

· The server authorizes a VLAN through session control or CoA messages to an online user that is authorized with a VSI at association.

· The server authorizes a VSI through session control or CoA messages to an online user that uses the default authorization VLAN because no VLAN or VSI is authorized at association.

Configuration procedure

To configure ISP domain attributes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter ISP domain view.	domain isp-name	N/A
3. Place the ISP domain in active or blocked state.	state { active \| block }	By default, an ISP domain is in active state, and users in the domain can request network services.
4. Configure authorization attributes for authenticated users in the ISP domain.	authorization-attribute { acl acl-number \| author-profile profile-name \| idle-cut minutes [ flow ] [ traffic { both \| inbound \| outbound } ] \| igmp max-access-number max-access-number \| ip-pool pool-name \| ipv6-pool ipv6-pool-name \| microsegment microsegment-id \| mld max-access-number max-access-number \| url url-string \| user-profile profile-name \| user-group user-group-name \| vlan vlan-id \| vsi vsi-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. · No other authorization attributes exist.
5. 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.
6. Specify the service type for users in the ISP domain.	service-type { hsi \| stb \| voip }	By default, the service type is hsi.

Configuring an authorization profile

Overview

An authorization profile defines a set of authorization attributes and can be used to authorize network resources on a VPN basis, for example, assigning different microsegments to different VPN users. If you apply an authorization profile to an authentication domain, all users in the domain can obtain network resources defined in the profile.

Restrictions and guidelines

Authorization profiles take effect only on 802.1X, MAC, and Web authentication users.

You can configure a maximum of 16 authorization profiles.

Deleting or changing an authorization profile does not affect users that are using the profile. The configuration change takes effect only on new clients that come online afterward.

Configuration procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an authorization profile and enter its view.	aaa author-profile profile-name	N/A
3. Specify a VPN instance and microsegment binding.	if-match vpn-instance vpn-instance-name microsegment microsegment-id [ vsi vsi-name ]	By default, no VPN instance and microsegment binding is specified. You can bind a VPN instance only to one microsegment but a microsegment to multiple VPN instances.
4. Specify the default microsegment.	default microsegment microsegment-id [ vsi vsi-name ]	By default, no default microsegment exists. The system authorizes the default microsegment to non-VPN users and VPN users that do not match any VPN instance specified by the if-match vpn-instance microsegment command.

Configuring the authentication failure policy for users in an ISP domain

Overview

By default, users cannot come online if they fail authentication. To have authentication-failed users in an authentication domain stay online and access a limited set of network resources, specify an auth-fail domain to accommodate them. In the auth-fail domain, you can specify a set of authorization and accounting schemes to assign resources to the authentication-failed users.

Configuration restrictions and guidelines

The authen-fail online feature is applicable only to wired 802.1X, Web authentication, and MAC authentication users.

The authen-fail online feature does not apply to users that fail authentication for one of the following reasons:

· Authentication times out, for example, because no authentication servers respond or no matching local users are found.

· The authentication domain is in blocked state or is a denied domain.

Configuration procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter ISP domain view.	domain isp-name	N/A
3. Configure the authentication failure policy for users in the ISP domain.	authen-fail { offline \| online domain new-isp-name no-authen }	By default, the device logs out users in an ISP domain if the users fail authentication.

Configuring authentication methods for an ISP domain

Configuration 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.

Configuration guidelines

When configuring authentication methods, follow these 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 the username $enabn$ on the RADIUS server for role authentication. The variable n represents a user role level. 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 device connection is terminated or the user account is not configured on the device.

· 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.

Configuration procedure

To configure authentication methods for an ISP domain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter ISP domain view.	domain isp-name	N/A
3. 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 \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default authentication method is local. The none keyword is not supported in FIPS mode.
4. 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 method is used for LAN users. The none keyword is not supported in FIPS mode.
5. 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 method is used for login users. The none keyword is not supported in FIPS mode.
6. Specify authentication methods for portal users.	authentication portal { 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 method is used for portal users. The none keyword is not supported in FIPS mode.
7. 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 method is used for obtaining a temporary user role.
8. Specify authentication methods for ONU users.	authentication onu { local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authentication method is used for ONU users. The none keyword is not supported in FIPS mode.

Configuring authorization methods for an ISP domain

Configuration 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.

Configuration guidelines

When configuring authorization methods, follow these guidelines:

· The device supports HWTACACS authorization but not 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 device connection is terminated or the user account is not configured on the device

· 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.

Configuration procedure

To configure authorization methods for an ISP domain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter ISP domain view.	domain isp-name	N/A
3. 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. The none keyword is not supported in FIPS mode.
4. Specify command authorization methods.	authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local ] [ none ] \| local [ none ] \| none }	By default, the default authorization method is used for command authorization. The none keyword is not supported in FIPS mode.
5. 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 method is used for LAN users. The none keyword is not supported in FIPS mode.
6. 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 method is used for login users. The none keyword is not supported in FIPS mode.
7. Specify authorization methods for portal users.	authorization portal { local [ radius-scheme radius-scheme-name ] [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authorization method is used for portal users. The none keyword is not supported in FIPS mode.

Configuring accounting methods for an ISP domain

Configuration 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.

Configuration guidelines

When configuring accounting methods, follow these 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 who 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 device connection is terminated or the user account is not configured on the device

· 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.

Configuration procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter ISP domain view.	domain isp-name	N/A
3. 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. The none keyword is not supported in FIPS mode.
4. Specify the command accounting method.	accounting command hwtacacs-scheme hwtacacs-scheme-name	By default, the default accounting method is used for command accounting.
5. 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 method is used for LAN users. The none keyword is not supported in FIPS mode.
6. 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 method is used for login users. The none keyword is not supported in FIPS mode.
7. Specify accounting methods for portal users.	accounting portal { 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 method is used for portal users. The none keyword is not supported in FIPS mode.
8. Configure access control for users who encounter accounting-start failures.	accounting start-fail { offline \| online }	By default, the device allows users who encounter accounting-start failures to stay online.
9. Configure access control for users who have failed all their accounting-update attempts.	accounting update-fail { [ max-times max-times ] offline \| online }	By default, the device allows users who have failed all their accounting-update attempts to stay online.
10. Configure access control for users who have used up their data or time accounting quotas.	accounting quota-out { offline \| online }	By default, the device logs off users who have used up their accounting quotas.
11. Specify the accounting method for dual-stack users.	accounting dual-stack { merge \| separate }	By default, the merge method is used.

Displaying and maintaining ISP domains

Execute display commands in any view.

Task	Command
Display configuration information about an ISP domain or all ISP domains.	display domain [ isp-name ]
Display authorization profile information.	display aaa author-profile

Configuring the RADIUS session-control feature

The RADIUS session-control feature can only work with the RADIUS server running on IMC. 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. The IP, VPN instance, and shared key settings of the session-control client must be the same as the corresponding settings of the RADIUS server.

You can specify multiple session-control clients on the device.

The device matches a session-control packet to a session-control client based on IP and VPN instance settings, and then uses the shared key of the matched client to validate the packet.

The device searches the session-control client settings prior to searching all RADIUS settings for finding a server whose IP and VPN instance settings match the session-control packet. This process narrows the search scope for finding the matched RADIUS server.

The session-control client configuration takes effect only when the session-control feature is enabled.

To configure the session-control feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
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. The device searches all RADIUS scheme settings to verify session-control packets.

Configuring the RADIUS DAS feature

Dynamic Authorization Extensions (DAE) to RADIUS, defined in RFC 5176, can log off online users and change online user authorization information.

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).

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. Logs off online users who match the criteria in the requests, changes their authorization information, shuts down or reboots their access ports, or reauthenticates the users.

3. Sends DAE responses to the DAC.

DAE defines the following types of packets:

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

· Change of Authorization Messages (CoA Messages)—The DAC sends CoA requests to the DAS to change the authorization information of specific online users, shut down or reboot the users' access ports, or reauthenticate the users.

To configure the RADIUS DAS feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
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 \| vpn-instance vpn-instance-name ] *	By default, no RADIUS DACs are specified.
4. Specify the RADIUS DAS port.	port port-number	By default, the RADIUS DAS port is 3799.

Changing the DSCP priority for RADIUS packets

DSCP priority determines the transmission priority of RADIUS packets. A larger value represents a higher priority.

DSCP priority is contained in the ToS field of the IPv4 header and in the Traffic Class field of the IPv6 header.

To change the DSCP priority for RADIUS packets:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Change the DSCP priority for RADIUS packets.	radius [ ipv6 ] dscp dscp-value	By default, the DSCP priority is 0 for RADIUS packets.

Configuring the RADIUS attribute translation feature

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.

To configure the RADIUS attribute translation feature for a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
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 }	By default, no user-defined extended RADIUS attributes exist. Repeat this command to define multiple extended RADIUS attributes.
3. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
4. Enable the RADIUS attribute translation feature.	attribute translate	By default, this feature is disabled.
5. 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 exist. Repeat this command to add multiple RADIUS attribute conversion rules.
6. Configure a RADIUS attribute rejection rule.	attribute reject attr-name { { access-accept \| access-request \| accounting } * \| { received \| sent } * }	By default, no RADIUS attribute rejection rules exist. Repeat this command to add multiple RADIUS attribute rejection rules.

To configure the RADIUS attribute translation feature for a RADIUS DAS:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
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 }	By default, no user-defined extended RADIUS attributes exist. Repeat this command to define multiple extended RADIUS attributes.
3. Enter RADIUS DAS view.	radius dynamic-author server	N/A
4. Enable the RADIUS attribute translation feature.	attribute translate	By default, this feature is disabled.
5. 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 exist. Repeat this command to add multiple RADIUS attribute conversion rules.
6. Configure a RADIUS attribute rejection rule.	attribute reject attr-name { { coa-ack \| coa-request } * \| { received \| sent } * }	By default, no RADIUS attribute rejection rules exist. Repeat this command to add multiple RADIUS attribute rejection rules.

Configuring a critical profile

During authentication, if all authentication servers in the authentication scheme are unreachable, the device will not receive authentication responses from any server and users will fail authentication.

To resolve this issue, you can configure a critical profile and apply the profile to a port to accommodate the users when all authentication servers are unreachable. The users in a critical profile can access only network resources in the critical profile, such as the critical microsegment. For users in a VPN instance, the users can access the critical microsegment specified for the VPN instance. If no critical microsegment is specified for the VPN instance, the users can access the default critical microsegment.

When you configure a critical profile, follow these restrictions and guidelines:

· This feature is applicable only to 802.1X and MAC authentication users.

· If you remove a critical profile from a port or edit the configuration in the critical profile, the change does not take effect on users already in the critical profile.

To configure a critical profile:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a critical profile and enter its view.	aaa critical-profile profile-name	N/A
3. Specify the default critical microsegment.	default critical-microsegment microsegment-id [ vsi vsi-name ] [ url-user-logoff ]	The url-user-logoff keyword is applicable only to MAC authentication users.
4. Specify the critical microsegment for a VPN instance.	if-match vpn-instance vpn-instance-name critical-microsegment microsegment-id [ vsi vsi-name ] [ url-user-logoff ]	By default, no critical microsegment is specified for a VPN instance. The url-user-logoff keyword is applicable only to MAC authentication users.

Configuring AAA fail-permit and recovery

Overview

This feature is used to resolve the issue that users cannot come online when all RADIUS servers 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 becomes available.

¡ To perform authentication, authorization, and accounting for the users, log off the users.

¡ To allow the users to stay online without being authenticated, specify a recovery domain. When a RADIUS server becomes available, the users in the critical domain are assigned to the recovery domain.

¡ To reauthenticate users in the original authentication domain without users being aware of the process, specify the reauthentication action.

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.

Configuration restrictions and guidelines

This feature takes effect only on the 802.1X authentication, Web authentication, and MAC authentication for wired 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 are still 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.

· In the current software version, you can specify only an ISP domain as its own recovery domain in the view of the ISP domain.

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.

Configuration procedure

Step	Command	Remarks
1. Enter system view.	system-view	N/A
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 isp-name	N/A
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 \| re-authen }	By default, no action is specified for users in the critical domain when a RADIUS server becomes available.

Setting the maximum number of concurrent login users

Perform this task to set the maximum number of concurrent users who 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.

To set the maximum number of concurrent login users:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Set the maximum number of concurrent login users.

· In non-FIPS mode:
aaa session-limit { ftp | http | https | ssh | telnet } max-sessions

· In FIPS mode:
aaa session-limit { https | ssh } max-sessions

By default, the maximum number of concurrent login users is 32 for each user type.

Configuring a NAS-ID profile

By default, the device sends its device name in the NAS-Identifier attribute of all RADIUS requests.

A NAS-ID profile enables you to send different NAS-Identifier attribute strings in RADIUS requests from different VLANs. The strings can be organization names, service names, or any user categorization criteria, depending on the administrative requirements.

For example, map the NAS-ID companyA to all VLANs of company A. The device will send companyA in the NAS-Identifier attribute for the RADIUS server to identify requests from any Company A users.

You can apply a NAS-ID profile to portal- or port security-enabled interfaces. For more information, see "Configuring portal authentication" and "Configuring port security."

A NAS-ID can be bound with more than one VLAN, but a VLAN can be bound with only one NAS-ID.

To configure a NAS-ID profile:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a NAS-ID profile and enter NAS-ID profile view.	aaa nas-id profile profile-name	By default, no NAS-ID profiles exist.
3. Configure a NAS-ID and VLAN binding in the profile.	nas-id nas-identifier bind vlan vlan-id	By default, no NAS-ID and VLAN bindings exist.

Configuring the device ID

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.

To configure the device ID:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
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, HTTP, HTTPS, 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 or 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

To configure the device ID:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable password change prompt logging.	local-server log change-password-prompt	By default, password change prompt logging is enabled.

Configuring the RADIUS server feature

Configuration restrictions and guidelines

When you configure the RADIUS server feature, follow these restrictions and guidelines:

· To use the RADIUS server feature, you must install the FreeRADIUS feature image that has the same version as the current software images. The feature image is named in the format of S7500X-CMW710-FREERADIUS-version.bin, for example, S7500X-CMW710-FREERADIUS-R7523P01.bin.

For more information about how to install a feature image, see Fundamentals Configuration Guide.

· To ensure correct operation of the RADIUS server feature, disable RADIUS session-control on the device.

Configuration task list

To configure the RADIUS server feature, perform the following tasks:

Tasks at a glance	Remarks
(Required.) Configuring local users	Configure network access users, which are the basis of RADIUS user data. A RADIUS user has the following attributes: user name, password, description, authorization ACL, authorization VLAN, and expiration time.
(Required.) Specifying RADIUS clients	N/A
(Required.) Activating the RADIUS server configuration	N/A

Specifying RADIUS clients

Perform this task to specify RADIUS clients and shared keys for centralized management. The RADIUS server feature does not accept requests from RADIUS clients that are not managed by the system.

When you specify RADIUS clients on the device, follow these restrictions and guidelines:

· The IP address of a RADIUS client must be the same as the source IP address for outgoing RADIUS packets specified on the RADIUS client.

· The shared key of a RADIUS client must be the same as the setting on the RADIUS client.

To specify a RADIUS client:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify a RADIUS client.	radius-server client ip ipv4-address key { cipher \| simple } string	By default, no RADIUS clients are specified.

Activating the RADIUS server configuration

At the device startup, the RADIUS server configuration is automatically activated, including RADIUS users and RADIUS clients. You can immediately activate the most recent RADIUS server configuration if you have added, modified, or deleted RADIUS clients and network access users from which RADIUS user data is generated.

To activate the RADIUS server configuration:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Activate the RADIUS server configuration.	radius-server activate	Executing this command restarts the RADIUS server process and an authentication service interruption will occur during the restart.

Displaying and maintaining RADIUS users and clients

Execute display commands in any view.

Task	Command
Display information about activated RADIUS users.	display radius-server active-user [ user-name ]
Display information about activated RADIUS clients.	display radius-server active-client

Configuring the connection recording policy

Overview

Use this feature on scenarios where the device acts as an FTP, SSH, SFTP, or Telnet login client to establish a connection with a login server. This feature enables the device to provide an accounting server with the connection start and termination information. When the login client establishes a connection with the login server, the system sends a start-accounting request to the accounting server. When the connection is terminated, the system sends a stop-accounting request to the accounting server.

Configuration restrictions and guidelines

The device includes the username entered by a user in the accounting packets to be sent to the AAA server for connection recording. The username format configured by using the user-name-format command in the accounting scheme does not take effect.

Configuration procedure

To configure the connection recording policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a connection recording policy and enter its view.	aaa connection-recording policy	By default, the connection recording policy does not exist.
3. Specify the accounting method for the connection recording policy.	accounting hwtacacs-scheme hwtacacs-scheme-name	By default, no accounting method is specified for the connection recording policy.

Displaying and maintaining the connection recording policy

Execute display commands in any view.

Task	Command
Display the connection recording policy configuration.	display aaa connection-recording policy

Displaying user MAC and UUID binding entries

Overview

To help administrators identify whether a universally unique identifier (UUID) has been assigned to a user and maintain the MAC and UUID binding entries for users, use this feature.

In some scenarios, administrators configure and manage MAC address and UUID binding entries for users on the authentication server, depending on the user access control policies. The binding entries will be assigned to the users after they pass authentication. The device automatically generates the MAC and UUID binding entry of a user when the user comes online and automatically deletes the binding entry when the user goes offline.

When a user's client requests the DHCP server to assign or release an IP address, the DHCP snooping module first searches for the UUID bound to the client MAC address. Then, the device replaces the value of Option 61 (client ID) in the client's DHCP packets with the UUID and forwards the DHCP packets to the DHCP server. The DHCP server will assign or reclaim an IP address based on the UUID in the received DHCP packets. UUID-based IP address assignment flexibly meets the IP address requirements of different scenarios.

Configuration restrictions and guidelines

The device supports user MAC and UUID binding entries only for 802.1X and MAC authentication users that use the iNode client.

Configuration procedure

To display user MAC and UUID binding entries in any view:

Task

Command

Display user MAC and UUID binding entries.

In standalone mode:

display mubm record [ mac mac-address ] [ interface interface-type interface-number | slot slot-number ] [ access-type { dot1x | mac-auth } ]

In IRF mode:

display mubm record [ mac mac-address ] [ chassis chassis-number slot slot-number | interface interface-type interface-number ] [ access-type { dot1x | mac-auth } ]

Configuring the AAA test feature

Overview

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 7 shows the attributes that RADIUS requests carry by default.

Table 7 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

Configuration 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.

Configuration 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 reaches 4096 bytes.

Configuration procedure

To configure the AAA test feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a RADIUS attribute test group and enter its view.	radius attribute-test-group attr-test-group-name	By default, no RADIUS attribute test groups exist. You can create multiple RADIUS attribute test groups.
3. 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	By default, no attributes are configured to be included in RADIUS authentication or accounting requests. Use this command to add attributes that RADIUS requests do not carry by default to the RADIUS requests. For an attribute that RADIUS requests carry by default, you can use this command to change its attribute value.
4. Exclude an attribute from RADIUS requests.	exclude { accounting \| authentication } name attribute-name	By default, no attributes are configured to be excluded from RADIUS requests. Use this command to exclude an attribute that RADIUS requests carry by default from the RADIUS requests sent during an AAA test to help troubleshoot authentication or accounting failures.
5. Return to system view.	quit	N/A
6. Return to user view.	quit	N/A
7. 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 ]	N/A

AAA configuration examples

AAA for SSH users by an HWTACACS server

Network requirements

As shown in Figure 15, configure the switch 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 15 Network diagram

Configuring the HWTACACS server

# Set the shared keys to expert for secure communication with the switch, add an account for the SSH user, and specify the password. (Details not shown.)

Configuring the switch

# Configure IP addresses for the interfaces. (Details not shown.)

# Create an HWTACACS scheme.

<Switch> system-view

[Switch] hwtacacs scheme hwtac

# Specify the primary authentication server.

[Switch-hwtacacs-hwtac] primary authentication 10.1.1.1 49

# Specify the primary authorization server.

[Switch-hwtacacs-hwtac] primary authorization 10.1.1.1 49

# Specify the primary accounting server.

[Switch-hwtacacs-hwtac] primary accounting 10.1.1.1 49

# Set the shared keys to expert in plaintext form for secure HWTACACS communication.

[Switch-hwtacacs-hwtac] key authentication simple expert

[Switch-hwtacacs-hwtac] key authorization simple expert

[Switch-hwtacacs-hwtac] key accounting simple expert

# Exclude domain names from the usernames sent to the HWTACACS server.

[Switch-hwtacacs-hwtac] user-name-format without-domain

[Switch-hwtacacs-hwtac] quit

# Create an ISP domain named bbb and configure the domain to use the HWTACACS scheme for authentication, authorization, and accounting of login users.

[Switch-isp-bbb] authentication login hwtacacs-scheme hwtac

[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac

[Switch-isp-bbb] accounting login hwtacacs-scheme hwtac

[Switch-isp-bbb] quit

# Create local RSA and DSA key pairs.

[Switch] public-key local create rsa

[Switch] public-key local create dsa

# Enable the SSH service.

[Switch] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.

[Switch] line vty 0 63

[Switch-line-vty0-63] authentication-mode scheme

[Switch-line-vty0-63] quit

# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.

[Switch] role default-role enable

Verifying the configuration

# Initiate an SSH connection to the switch, and enter the correct username and password. The user logs in to the switch. (Details not shown.)

# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)

Local authentication, HWTACACS authorization, and RADIUS accounting for SSH users

Network requirements

As shown in Figure 16, configure the switch to meet the following requirements:

· Perform local authentication for SSH servers.

· Use the HWTACACS server and RADIUS server for SSH user authorization and accounting, respectively.

· Exclude domain names from the usernames sent to the servers.

· Assign the default user role network-operator to SSH users after they pass authentication.

Configure an account named hello for the SSH user. Configure the shared keys to expert for secure communication with the HWTACACS server and RADIUS server.

Figure 16 Network diagram

Configuring the HWTACACS server

# Set the shared keys to expert for secure communication with the switch, add an account for the SSH user, and specify the password. (Details not shown.)

Configuring the RADIUS server

# Set the shared keys to expert for secure communication with the switch, add an account for the SSH user, and specify the password. (Details not shown.)

Configuring the switch

# Configure IP addresses for interfaces. (Details not shown.)

# Create local RSA and DSA key pairs.

<Switch> system-view

[Switch] public-key local create rsa

[Switch] public-key local create dsa

# Enable the SSH service.

[Switch] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.

[Switch] line vty 0 63

[Switch-line-vty0-63] authentication-mode scheme

[Switch-line-vty0-63] quit

# Configure an HWTACACS scheme.

[Switch] hwtacacs scheme hwtac

[Switch-hwtacacs-hwtac] primary authorization 10.1.1.2 49

[Switch-hwtacacs-hwtac] key authorization simple expert

[Switch-hwtacacs-hwtac] user-name-format without-domain

[Switch-hwtacacs-hwtac] quit

# Configure a RADIUS scheme.

[Switch] radius scheme rd

[Switch-radius-rd] primary accounting 10.1.1.1 1813

[Switch-radius-rd] key accounting simple expert

[Switch-radius-rd] user-name-format without-domain

[Switch-radius-rd] quit

# Create a device management user.

[Switch] local-user hello class manage

# Assign the SSH service to the local user.

[Switch-luser-manage-hello] service-type ssh

# Set the password to 123456TESTplat&! in plaintext form for the local user. In FIPS mode, you must set the password in interactive mode.

[Switch-luser-manage-hello] password simple 123456TESTplat&!

[Switch-luser-manage-hello] quit

# Create an ISP domain named bbb and configure the login users to use local authentication, HWTACACS authorization, and RADIUS accounting.

[Switch] domain bbb

[Switch-isp-bbb] authentication login local

[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac

[Switch-isp-bbb] accounting login radius-scheme rd

[Switch-isp-bbb] quit

# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.

[Switch] role default-role enable

Verifying the configuration

# Initiate an SSH connection to the switch, and enter username hello@bbb and the correct password. The user logs in to the switch. (Details not shown.)

# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)

Authentication and authorization for SSH users by a RADIUS server

Network requirements

As shown in Figure 17, configure the switch 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.

In this example, the RADIUS server runs IMC PLAT 7.3 (E0605) and IMC UAM 7.3 (E0512). Add an account named hello@bbb on the RADIUS server.

The RADIUS server and the switch use expert as the shared key for secure RADIUS communication. The ports for authentication and accounting are 1812 and 1813, respectively.

Figure 17 Network diagram

Configuring the RADIUS server

1. Add the switch to the IMC Platform as an access device:

Log in to IMC, click the User tab, and select User Access Policy > Access Device Management > Access Device from the navigation tree. Then, click Add to configure an access device as follows:

a. Set the ports for authentication and accounting to 1812 and 1813, respectively.

b. Select Device Management Service from the Service Type list.

c. Select H3C (General) from the Access Device Type list.

d. Set the shared key to expert for secure RADIUS communication.

e. Select an access device from the device list or manually add an access device. In this example, the device IP address is 10.1.1.2.

f. Use the default values for other parameters.

g. Click OK.

The IP address of the access device specified here must be the same as the source IP address of the RADIUS packets sent from the switch. The source IP address is chosen in the following order on the switch:

¡ IP address specified by using the nas-ip command.

¡ IP address specified by using the radius nas-ip command.

¡ IP address of the outbound interface (the default).

Figure 18 Adding the switch as an access device

2. Add an account for device management:

Click the User tab, and select Device User > Device User from the navigation tree. Then, click Add to configure a device management account as follows:

a. Enter account name hello@bbb and specify the password.

b. Select SSH from the Login Type list.

c. Enter user role network-admin.

d. Specify 10.1.1.0 to 10.1.1.255 as the IP address range of the hosts to be managed.

e. Click OK.

NOTE:

The IP address range must contain the IP address of the switch.

Figure 19 Adding an account for device management

Configuring the switch

# Configure IP addresses for interfaces. (Details not shown.)

# Create local RSA and DSA key pairs.

<Switch> system-view

[Switch] public-key local create rsa

[Switch] public-key local create dsa

# Enable the SSH service.

[Switch] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.

[Switch] line vty 0 63

[Switch-line-vty0-63] authentication-mode scheme

[Switch-line-vty0-63] quit

# Create a RADIUS scheme.

[Switch] radius scheme rad

# Specify the primary authentication server.

[Switch-radius-rad] primary authentication 10.1.1.1 1812

# Set the shared key to expert in plaintext form for secure communication with the server.

[Switch-radius-rad] key authentication simple expert

# Include domain names in the usernames sent to the RADIUS server.

[Switch-radius-rad] user-name-format with-domain

[Switch-radius-rad] quit

# Create an ISP domain named bbb and configure authentication, authorization, and accounting methods for login users.

[Switch] domain bbb

[Switch-isp-bbb] authentication login radius-scheme rad

[Switch-isp-bbb] authorization login radius-scheme rad

[Switch-isp-bbb] accounting login none

[Switch-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the switch, and enter username hello@bbb and the correct password. The user logs in to the switch. (Details not shown.)

# Verify that the user can use the commands permitted by the network-admin user role. (Details not shown.)

Authentication for SSH users by an LDAP server

Network requirements

As shown in Figure 20, the LDAP server uses domain ldap.com and runs Microsoft Windows 2003 Server Active Directory.

Configure the switch to meet the following requirements:

· Use the LDAP server to authenticate SSH users.

· Assign the default user role network-operator 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 20 Network diagram

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 21 Adding user aaa

f. In the dialog box, enter password ldap!123456, select options as needed, and click Next.

Figure 22 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 23 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 24 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 switch

# Configure IP addresses for interfaces. (Details not shown.)

# Create local RSA and DSA key pairs.

<Switch> system-view

[Switch] public-key local create rsa

[Switch] public-key local create dsa

# Enable the SSH service.

[Switch] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 63.

[Switch] line vty 0 63

[Switch-line-vty0-63] authentication-mode scheme

[Switch-line-vty0-63] quit

# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.

[Switch] role default-role enable

# Configure an LDAP server.

[Switch] ldap server ldap1

# Specify the IP address of the LDAP authentication server.

[Switch-ldap-server-ldap1] ip 10.1.1.1

# Specify the administrator DN.

[Switch-ldap-server-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com

# Specify the administrator password.

[Switch-ldap-server-ldap1] login-password simple admin!123456

# Configure the base DN for user search.

[Switch-ldap-server-ldap1] search-base-dn dc=ldap,dc=com

[Switch-ldap-server-ldap1] quit

# Create an LDAP scheme.

[Switch] ldap scheme ldap-shm1

# Specify the LDAP authentication server.

[Switch-ldap-ldap-shm1] authentication-server ldap1

[Switch-ldap-ldap-shm1] quit

# Create an ISP domain named bbb and configure authentication, authorization, and accounting methods for login users.

[Switch] domain bbb

[Switch-isp-bbb] authentication login ldap-scheme ldap-shm1

[Switch-isp-bbb] authorization login none

[Switch-isp-bbb] accounting login none

[Switch-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the switch, and enter username aaa@bbb and password ldap!123456. The user logs in to the switch. (Details not shown.)

# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)

AAA for 802.1X users by a RADIUS server

Network requirements

As shown in Figure 25, configure the switch to meet the following requirements:

· Use the RADIUS server for 802.1X user authentication, authorization, and accounting.

· Use MAC-based access control on GigabitEthernet 1/0/1 to authenticate all 802.1X users on the port separately.

· Include domain names in the usernames sent to the RADIUS server.

In this example, the RADIUS server runs IMC PLAT 7.1 (E0303), IMC UAM 7.1 (E0304), and IMC CAMS 7.1 (E0301). On the RADIUS server, perform the following tasks:

· Add a service that charges 120 dollars for up to 120 hours per month and assigns authenticated users to VLAN 4.

· Configure a user account named dot1x@bbb and assign the service to the user.

Set the shared keys to expert for secure RADIUS communication. Set the ports for authentication and accounting to 1812 and 1813, respectively.

Figure 25 Network diagram

‌

Configuring the RADIUS server

1. Add the switch to the IMC Platform as an access device:

Log in to IMC, click the User tab, and select User Access Policy > Access Device Management > Access Device from the navigation tree. Then, click Add to configure an access device as follows:

a. Set the ports for authentication and accounting to 1812 and 1813, respectively.

b. Select LAN Access Service from the Service Type list.

c. Select H3C(General) from the Access Device Type list.

d. Set the shared key to expert for secure authentication and accounting communication.

e. Select an access device from the device list or manually add an access device. In this example, the device IP address is 10.1.1.2.

f. Use the default values for other parameters.

g. Click OK.

¡ IP address specified by using the nas-ip command.

¡ IP address specified by using the radius nas-ip command.

¡ IP address of the outbound interface (the default).

Figure 26 Adding the switch as an access device

2. Add a charging plan:

Click the User tab, and select Accounting Manager > Charging Plans from the navigation tree to enter the charging plan configuration page. Then, click Add to configure a charging plan as follows:

a. Add a plan named UserAcct.

b. Select Flat rate from the Charging Template list.

c. Select time for Charge Based on, select Monthly for Billing Term, and enter 120 in the Fixed Fee field.

d. Enter 120 in the Usage Threshold field and select hr (hours) for the in field. The configuration allows the user to access the Internet for up to 120 hours per month.

e. Click OK.

Figure 27 Adding a charging plan

3. Add an access policy:

Click the User tab, and select User Access Policy > Access Policy from the navigation tree. Then, click Add to configure an access policy as follows:

a. Enter access policy name Dot1x auth.

b. Set the ID of the VLAN to be deployed to 4.

c. Configure other parameters as needed.

d. Click OK.

Figure 28 Adding an access policy

4. Add an access service:

Click the User tab, and select User Access Policy > Access Service from the navigation tree. Then, click Add to configure a service as follows:

a. Add a service named Dot1x Service, and set the service suffix to bbb, the authentication domain for the 802.1X user. With the service suffix configured, you must configure the access device to send usernames that include domain names to the RADIUS server.

b. Select UserAcct from the Charging Plan list.

c. Select Dot1x auth from the Default Access Policy list.

d. Configure other parameters as needed.

e. Click OK.

Figure 29 Adding a service

5. Add an access user:

Click the User tab, and select All Access Users from the navigation tree to enter the All Access Users page. Then, click Add to configure a user as follows:

a. Select user test or manually add a user named test.

b. Enter account name dot1x and set the password.

c. Select Dot1x Service in the Access Service area.

d. Configure other parameters as needed.

e. Click OK.

Figure 30 Adding an access user

Configuring the switch

1. Configure a RADIUS scheme:

# Create a RADIUS scheme named rad and enter RADIUS scheme view.

<Switch> system-view

[Switch] radius scheme rad

# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.

[Switch-radius-rad] primary authentication 10.1.1.1

[Switch-radius-rad] primary accounting 10.1.1.1

[Switch-radius-rad] key authentication simple expert

[Switch-radius-rad] key accounting simple expert

# Include domain names in the usernames sent to the RADIUS server.

[Switch-radius-rad] user-name-format with-domain

[Switch-radius-rad] quit

2. Configure an ISP domain:

# Create an ISP domain named bbb and enter ISP domain view.

[Switch] domain bbb

# Configure the ISP domain to use RADIUS scheme rad for authentication, authorization, and accounting of LAN users.

[Switch-isp-bbb] authentication lan-access radius-scheme rad

[Switch-isp-bbb] authorization lan-access radius-scheme rad

[Switch-isp-bbb] accounting lan-access radius-scheme rad

[Switch-isp-bbb] quit

3. Configure 802.1X authentication:

# Enable 802.1X globally.

[Switch] dot1x

# Enable 802.1X for GigabitEthernet 1/0/1.

[Switch] interface gigabitethernet 1/0/1

[Switch-GigabitEthernet1/0/1] dot1x

# Configure the access control method. By default, an 802.1X-enabled port uses the MAC-based access control.

[Switch-GigabitEthernet1/0/1] dot1x port-method macbased

Verifying the configuration

1. On the host, use account dot1x@bbb to pass 802.1X authentication:

# If the host runs the Windows XP 802.1X client, configure the network connection properties as follows:

a. Click the Authentication tab of the properties window.

b. Select the Enable IEEE 802.1X authentication for this network option.

c. Select MD5 challenge as the EAP type.

d. Click OK.

The user passes authentication after entering the correct username and password on the authentication page.

# If the host runs the iNode client, no advanced authentication options are required. The user can pass authentication after entering username dot1x@bbb and the correct password on the client property page.

IMPORTANT:

Make sure the client can update its IP address to access the resources in the authorized VLAN after passing authentication.

2. On the switch, verify that the server assigns the port connecting the client to VLAN 4 after the user passes authentication. (Details not shown.)

3. Display 802.1X connection information on the switch.

[Switch] display dot1x connection

Local guest configuration and management example

Network requirements

As shown in Figure 31, create an 802.1X local guest named user1 for Jack. Configure local guest attributes and manage the local guest on the switch as follows:

· Specify an SMTP server, email sender address, and guest manager email address for the device to send local guest email notifications.

· Enable the local user auto-delete feature.

· Configure the subject and body of the email notifications to be sent to the guest, guest manager, and guest sponsor.

· Configure attributes for the local guest, including the password, user group, validity period, and sponsor information.

· Send email notifications of the local guest account information to the guest and guest sponsor.

Figure 31 Network diagram

Configuration procedure

1. Configure 802.1X settings. Make sure the guest can pass 802.1X authentication to access the network. (Details not shown.)

2. Manage local guests:

# Enable the local user auto-delete feature for expired local guests.

<Switch> system-view

[Switch] local-user auto-delete enable

# Specify an SMTP server to send local guest email notifications.

[Switch] local-guest email smtp-server smtp://192.168.0.112/smtp

# Specify the email sender address as [email protected] in the email notifications sent by the device for local guests.

[Switch] local-guest email sender [email protected]

# Specify the email address of the guest manager as [email protected].

[Switch] local-guest manager-email [email protected]

# Configure the subject and body of the email notifications to be sent to the local guest.

[Switch] local-guest email format to guest subject Guest account information

[Switch] local-guest email format to guest body A guest account has been created for you. The username, password, and validity period of the account are given below.

# Configure the subject and body of the email notifications to be sent to the guest sponsor.

[Switch] local-guest email format to sponsor subject Guest account information

[Switch] local-guest email format to sponsor body A guest account has been created for you. The username, password, and validity period of the account are given below.

# Configure the subject and body of the email notifications to be sent to the guest manager.

[Switch] local-guest email format to manager subject Guest registration information

[Switch] local-guest email format to manager body A guest account has been registered. The username of the account is given below. Please approve the registration information.

3. Configure the local guest:

# Create a user group named guest1.

[Switch] user-group guest1

[Switch-ugroup-guest1] quit

# Create a local guest named user1 and enter local guest view.

[Switch] local-user user1 class network guest

# Set the guest password to 123456 in plain text.

[Switch-luser-network(guest)-user1] password simple 123456

# Assign the guest to user group guest1.

[Switch-luser-network(guest)-user1] group guest1

# Specify the name of the local guest.

[Switch-luser-network(guest)-user1] full-name Jack

# Specify the company of the local guest.

[Switch-luser-network(guest)-user1] company cc

# Configure the email address of the local guest.

[Switch-luser-network(guest)-user1] email [email protected]

# Configure the phone number of the local guest.

[Switch-luser-network(guest)-user1] phone 131129237

# Configure a description for the local guest.

[Switch-luser-network(guest)-user1] description A guest from company cc

# Configure the validity period of the local guest.

[Switch-luser-network(guest)-user1] validity-datetime from 2015/4/1 08:00:00 to 2015/4/3 18:00:00

# Specify the guest sponsor name as Sam.

[Switch-luser-network(guest)-user1] sponsor-full-name Sam

# Configure the email address of the guest sponsor.

[Switch-luser-network(guest)-user1] sponsor-email [email protected]

# Configure the department of the guest sponsor as security.

[Switch-luser-network(guest)-user1] sponsor-department security

[Switch-luser-network(guest)-user1] quit

[Switch] quit

4. Configure the device to send guest email notifications:

# Send an email notification to the guest sponsor.

<Switch> local-guest send-email user-name user1 to sponsor

# Send an email notification to the guest.

<Switch> local-guest send-email user-name user1 to guest

Verifying the configuration

# Display local guest information.

<Switch> display local-user user-name user1 class network guest

Total 1 local users matched.

Network access guest user1:

State: Active

Service type: LAN-access/Portal

User group: guest1

Full name: Jack

Company: cc

Email: [email protected]

Phone: 131129237

Sponsor full name: Sam

Sponsor department: security

Sponsor email: [email protected]

Description: A guest from company cc

Validity period:

Start date and time: 2015/04/01-08:00:00

Expiration date and time:2015/04/03-18:00:00

# Verify that Jack can use username user1 and password 123456 to pass local authentication and come online during the validity period. (Details not shown.)

Authentication and authorization of 802.1X users by the device as a RADIUS server

Network requirements

As shown in Figure 32, Switch B acts as the RADIUS server for authentication and authorization of 802.1X users connected to the NAS (Switch A).

Configure the switches to meet the following requirements:

· Perform 802.1X authentication on GigabitEthernet 1/0/1 of the NAS.

· The shared key is expert and the authentication port is 1812.

· Exclude domain names from the usernames sent to the RADIUS server.

· The user name for 802.1X authentication is dot1x.

· After the user passes authentication, the RADIUS server authorizes VLAN 4 to the NAS port that the user is connecting to.

Figure 32 Network diagram

Configuration procedure

1. Configure the NAS:

a. Configure a RADIUS scheme:

# Configure a RADIUS scheme named rad and enter RADIUS scheme view.

<SwitchA> system-view

[SwitchA] radius scheme rad

# Specify the primary authentication server with IP address 10.1.1.1 and set the shared key to expert in plaintext form.

[SwitchA-radius-rad] primary authentication 10.1.1.1 key simple expert

# Exclude domain names from the usernames sent to the RADIUS server.

[SwitchA-radius-rad] user-name-format without-domain

[SwitchA-radius-rad] quit

b. Configure an authentication domain:

# Create an ISP domain named bbb and enter ISP domain view.

[SwitchA] domain bbb

# Configure the ISP domain to use RADIUS scheme rad for authentication and authorization of LAN users and not to perform accounting for LAN users.

[SwitchA-isp-bbb] authentication lan-access radius-scheme rad

[SwitchA-isp-bbb] authorization lan-access radius-scheme rad

[SwitchA-isp-bbb] accounting lan-access none

[SwitchA-isp-bbb] quit

c. Configure 802.1X authentication:

# Enable 802.1X for GigabitEthernet 1/0/1.

[SwitchA] interface gigabitethernet 1/0/1

[SwitchA-GigabitEthernet1/0/1] dot1x

# Specify bbb as the mandatory authentication domain for 802.1X users on the interface.

[SwitchA-GigabitEthernet1/0/1] dot1x mandatory-domain bbb

[SwitchA-GigabitEthernet1/0/1] quit

# Enable 802.1X globally.

[SwitchA] dot1x

2. Configure the RADIUS server:

# Create a network access user named dot1x.

<SwitchB> system-view

[SwitchB] local-user dot1x class network

# Configure the password as 123456 in plaintext form.

[SwitchB-luser-network-dot1x] password simple 123456

# Configure VLAN 4 as the authorization VLAN.

[SwitchB-luser-network-dot1x] authorization-attribute vlan 4

[SwitchB-luser-network-dot1x] quit

# Configure the IP address of the RADIUS client as 10.1.1.2 and the shared key as expert in plaintext form.

[SwitchB] radius-server client ip 10.1.1.2 key simple expert

# Activate the RADIUS server configuration.

[SwitchB] radius-server activate

Verifying the configuration

1. On the RADIUS server, display the activated RADIUS clients and users.

[SwitchB] display radius-server active-client

Total 1 RADIUS clients.

Client IP: 10.1.1.2

[SwitchB] display radius-server active-user dot1x

Total 1 RADIUS users matched.

Username: dot1x

Description: Not configured

Authorization attributes:

VLAN ID: 4

ACL number: Not configured

Validity period:

Expiration time: Not configured

2. On the host, use the dot1x user for 802.1X authentication.

If the user host runs the Windows built-in 802.1X client, configure the network connection properties as follows:

a. Click the Authentication tab of the properties window.

b. Select the Enable IEEE 802.1X authentication for this network option.

c. Select MD5 challenge as the EAP type.

d. Click OK.

If the user host runs the iNode client, no advanced authentication options are required.

The user passes authentication after entering the correct user name and password on the authentication page or the iNode client.

IMPORTANT:

Make sure the client can update its IP address to access the resources in the authorized VLAN after passing authentication.

3. On the NAS, verify that the RADIUS server assigns the user access port to VLAN 4 after the user passes authentication. (Details not shown.)

4. On the NAS, display online 802.1X user information.

[SwitchA] display dot1x connection

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."

Troubleshooting LDAP

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.

11-Security Configuration Guides

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

AAA implementation on the device

User management based on ISP domains and user access types

AAA methods

AAA for VPNs

Format of dynamic authorization ACLs (vendor ID 25506)

Format of dynamic authorization ACLs (vendor ID 9)

Configuring local users

Configuration task list

Overview

Configuration restrictions and guidelines

Configuration procedure

Creating a RADIUS scheme

Specifying the RADIUS authentication servers

Specifying the RADIUS accounting servers and the relevant parameters

Setting the username format and traffic statistics units

About this task

Restrictions and guidelines

Procedure

Overview

Configuration restrictions and guidelines

Configuration procedure

Setting RADIUS timers

Overview

Configuration restrictions and guidelines

Configuration procedure

Configuring the RADIUS accounting-on feature

Overview

Configuration restrictions and guidelines

Configuration procedure

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

Configuration restrictions and guidelines

Configuration procedure

Overview

Configuration restrictions and guidelines

Configuration procedure

Overview

Configuration restrictions and guidelines

Configuration procedure

Overview

Configuration restrictions and guidelines

Configuration procedure

Overview

Configuration restrictions and guidelines

Configuration procedure

Overview

Configuration restrictions and guidelines

Configuration procedure

Creating an HWTACACS scheme

Specifying the shared keys for secure HWTACACS communication

Specifying an MPLS L3VPN instance for the scheme

Setting the username format and traffic statistics units

Overview

Configuration restrictions and guidelines

Configuration procedure

Overview

Configuration restrictions and guidelines

Configuration procedure

Overview

Configuration procedure

Creating an LDAP server

Configuring administrator attributes

Creating an ISP domain

Overview

Configuration restrictions and guidelines

Configuration procedure

Overview

Configuration restrictions and guidelines

Configuration procedure

Overview