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 and HWTACACS. 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 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 sends an access request to the HWTACACS client.

2. The HWTACACS client sends a start-authentication packet to the HWTACACS server when it receives the request.

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

4. Upon receiving the response, the HWTACACS client asks the user for the username.

5. The user enters the username.

6. After receiving the username from the user, the HWTACACS client sends the server a continue-authentication packet that includes the username.

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

8. Upon receipt of the response, the HWTACACS client prompts the user for the login password.

9. The user enters the password.

10. After receiving the login password, the HWTACACS client sends the HWTACACS server a continue-authentication packet that includes the login password.

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

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

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

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

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

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

17. The user logs off.

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

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

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

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

· HTTP or HTTPS—Users log in to the device through HTTP or HTTPS.

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 which no AAA methods are configured.

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 or HWTACACS server to authenticate users. The server manages user information in a centralized manner. Remote authentication provides high capacity, reliable, and centralized authentication services for multiple NASs. You can configure backup methods to be used when the remote server is not available.

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:

? 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 or HWTACACS 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 that use the same local user account, but does not provide statistics for charging.

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

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 that wants to obtain another user role without logging out or getting disconnected. For more information about user role authentication, see Fundamentals Configuration Guide.

AAA for MPLS L3VPNs

You can deploy AAA across VPNs in an MPLS L3VPN scenario where clients in different VPNs are centrally authenticated. The deployment enables forwarding of RADIUS and HWTACACS packets across MPLS VPNs. For example, as shown in Figure 8, you can deploy AAA across the VPNs. The left PE connects the user private networks to the MPLS backbone and 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. The servers process authentication packets separately for private users from different VPNs.

Figure 8 Network diagram

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

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.
12	Framed-MTU	MTU for the data link between the user and NAS.
14	Login-IP-Host	IP address of the NAS interface that the user accesses.
15	Login-Service	Type of service that the user uses for login.
18	Reply-Message	Text to be displayed to the user, which can be used by the server to communicate information, for example, the 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 RADIUS subattributes with a vendor ID of 25506. Support for these subattributes depends on the device model.

Table 4 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.
27	PortalURL	PADM redirect URL assigned to PPPoE users.
28	Ftp_Directory	FTP, SFTP, or SCP user working directory. When the RADIUS client acts as the FTP, SFTP, or SCP server, this attribute is used to set the working directory for an FTP, SFTP, or SCP user on the RADIUS client.
29	Exec_Privilege	EXEC user priority.
32	NAT-IP-Address	Public IP address assigned to the user when the source IP address and port are translated.
33	NAT-Start-Port	Start port number of the port range assigned to the user when the source IP address and port are translated.
34	NAT-End-Port	End port number of the port range assigned to the user when the source IP address and port are translated.
59	NAS_Startup_Timestamp	Startup time of the NAS in seconds, which is represented by the time elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
60	Ip_Host_Addr	User IP address and MAC address included in authentication and accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space is required between the IP address and the MAC address.
61	User_Notify	Information that must be sent from the server to the client transparently.
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.
102	local-name	L2TP local tunnel name.
103	IGMP-Access-Limit	Maximum number of IGMP multicast groups that the user can join concurrently.
104	VPN-Instance	MPLS L3VPN instance to which a user belongs.
105	ANCP-Profile	ANCP profile name.
135	Client-Primary-DNS	IP address of the primary DNS server.
136	Client-Secondary-DNS	IP address of the secondary DNS server.
140	User_Group	User groups assigned after the SSL VPN user passes authentication. A user can belong to multiple user groups that are separated by semicolons. This attribute is used to work with the SSL VPN device.
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.
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 Web redirect URL in the format of url-redirect=xxx.
215	Accounting-Level	ITA traffic level in the range of 1 to 8.
216	Ita-Policy	ITA policy name.
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.

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 and HWTACACS schemes.

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

Figure 9 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
(Required.) Configure AAA methods for ISP domains: 1. (Required.) Creating an ISP domain 2. (Optional.) Configuring ISP domain attributes 3. (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.) Setting the maximum number of concurrent login users
(Optional.) Configuring a NAS-ID profile
(Optional.) Configuring the device ID

Configuring AAA schemes

This section includes information on configuring local users, RADIUS schemes, and HWTACACS schemes.

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.

The following shows the configurable local user attributes:

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

Service types include FTP, HTTP, HTTPS, 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 that can concurrently access the device by using the same user name. When the number reaches the upper limit, no more local users can access the device by using the user name.

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

· Authorization attributes—Authorization attributes indicate the user's rights after it passes local authentication. For support information about authorization attributes, see "Configuring 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 device management users. Password control attributes include password aging time, minimum password length, password composition checking, password complexity checking, and login attempt limit.

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

Local user configuration task list

Tasks at a glance
(Required.) Configuring local user attributes
(Optional.) Configuring user group attributes

Configuring local user attributes

When you configure local user attributes, follow these guidelines:

· When you use the password-control enable command to globally enable the password control feature, local user passwords are not displayed.

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

To configure 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 ]	By default, no local users exist.
3. (Optional.) Configure a password for the local 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.
4. Assign services to the local 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.
5. (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.
6. (Optional.) Set the upper limit of concurrent logins using the local user name.	access-limit max-user-number	By default, the number of concurrent logins is not limited for the local user. This command takes effect only when local accounting is configured for the local user. It does not apply to FTP, SFTP, or SCP users. These users do not support accounting.
7. (Optional.) Configure authorization attributes for the local user.	authorization-attribute { idle-cut minutes \| user-role role-name \| work-directory directory-name } *	The following default settings apply: · The working directory for FTP, SFTP, and SCP users is the root directory of the NAS. However, the users do not have permission to access the root directory. · The network-operator user role is assigned to local users that are created by a network-admin or level-15 user.
8. (Optional.) Configure password control attributes for the local user.	· 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.
9. (Optional.) Assign the local user to a user group.	group group-name	By default, a local user belongs to the user group system.

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 { idle-cut minutes \| 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."

Displaying and maintaining local users and local user groups

Execute display commands in any view.

Task	Command
Display the local user configuration and online user statistics.	display local-user [ class manage \| idle-cut { disable \| enable } \| service-type { ftp \| http \| https \| ssh \| telnet \| terminal } \| state { active \| block } \| user-name user-name class manage \| vlan vlan-id ]
Display the user group configuration.	display user-group { all \| name group-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 IP addresses, UDP port numbers, shared keys, and server types.

Configuration task list

Tasks at a glance
(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 the RADIUS server load sharing feature
(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 Login-Service attribute check method for SSH, FTP, and terminal users
(Optional.) Configuring the MAC address format for RADIUS attribute 31
(Optional.) Setting the data measurement unit for the Remanent_Volume attribute
(Optional.) Enabling SNMP notifications for RADIUS

Configuring a test profile for RADIUS server status detection

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

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

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

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

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

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

· The RADIUS server is removed from the RADIUS scheme.

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

· The test profile is deleted.

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

· The RADIUS scheme is deleted.

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 [ interval interval ]	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 [ interval interval ]

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

The device sends a stop-accounting request to the accounting server in the following situations:

· The device receives a connection teardown request from a host.

· The device receives a connection teardown command from an administrator.

When the maximum number of real-time accounting attempts is reached, the device disconnects users that have no accounting responses.

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

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

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 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 [ { ipv4-address \| ipv6 ipv6-address } [ port-number \| vpn-instance vpn-instance-name ] * ] { active \| block } · Set the status of a secondary RADIUS accounting server: state secondary accounting [ { ipv4-address \| ipv6 ipv6-address } [ port-number \| vpn-instance vpn-instance-name ] * ] { active \| block }	By default, a RADIUS server is in active state. 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 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.

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 the source IP address for outgoing RADIUS packets

The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon receiving a RADIUS packet, a RADIUS server checks whether the source IP address of the packet is the IP address of a managed NAS.

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

The source 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 address.

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 in which the RADIUS servers are in a VPN or the public network.

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

To specify a 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 IP address for outgoing RADIUS packets.	radius nas-ip { ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ]	By default, the primary IP address of the RADIUS packet outbound interface is used as the source IP address.

To specify a 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 IP address for outgoing RADIUS packets.	nas-ip { ipv4-address \| ipv6 ipv6-address }	By default, the source IP address specified by the radius nas-ip command in system view is used. If the source IP address is not specified, the primary IP address of the outbound interface is used.

Setting RADIUS timers

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.

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.

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.

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 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 RADIUS attribute 31

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

To configure the MAC address format for RADIUS attribute 31:

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 RADIUS attribute 31.	attribute 31 mac-format section { six \| three } separator separator-character { lowercase \| uppercase }	By default, a MAC address is in the format of HH-HH-HH-HH-HH-HH. The MAC address is separated by hyphen (-) into six sections with letters in upper case.

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.

Enabling SNMP notifications for RADIUS

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.

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.

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 RADIUS packet statistics.	display radius statistics
Clear RADIUS statistics.	reset radius statistics

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

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

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 { 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 { 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 IP address, port number, and VPN instance.

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

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

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

To communicate with the HWTACACS server, the source address of outgoing HWTACACS packets is typically the IP address of an egress interface on the NAS. 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 address.

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 to one HWTACACS scheme.

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

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

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

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

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

To specify a 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 IP address for outgoing HWTACACS packets.	hwtacacs nas-ip { ipv4-address \| ipv6 ipv6-address } [ vpn-instance vpn-instance-name ]	By default, the primary IP address of the HWTACACS packet outbound interface is used as the source IP address.

To specify a 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 the source IP address of outgoing HWTACACS packets.	nas-ip { ipv4-address \| ipv6 ipv6-address }	By default, the source IP address specified by the hwtacacs nas-ip command in system view is used. If the source IP address is not specified, the primary IP address of the outbound interface is used.

Setting HWTACACS timers

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

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

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

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

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

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

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

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.

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 ] ]
Clear HWTACACS statistics.	reset hwtacacs statistics { accounting \| all \| authentication \| authorization }

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

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

Creating an ISP domain

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 assigned to nonexistent domains. If no such ISP domain is configured, user authentication fails.

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 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 that are assigned to nonexistent domains.	domain if-unknown isp-name	By default, no ISP domain is specified to accommodate users that are assigned to nonexistent domains.

Configuring ISP domain attributes

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 user group—The device assigns the authorization user group in the ISP domain to the authenticated users that do not receive the authorization attribute from the server. The authenticated users obtain all attributes of the user group.

· User online duration including idle timeout period—If a user goes offline due to connection failure or malfunction, the user's online duration sent to the server includes the idle timeout period. The online duration that is generated on the server is longer than the actual online duration of the user.

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

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 user-group user-group-name	By default, no 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 does not include the idle timeout period.

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.

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 ] \| local [ none ] \| 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 login users.	authentication login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default authentication methods are used for login users. The none keyword is not supported in FIPS mode.
5. Specify authentication methods for obtaining a temporary user role.	authentication super { hwtacacs-scheme hwtacacs-scheme-name \| radius-scheme radius-scheme-name } *	By default, the default authentication methods are used for obtaining a temporary user role.

Configuring authorization methods for an ISP domain

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.

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

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 [ 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 methods are used for command authorization. The none keyword is not supported in FIPS mode.
5. Specify authorization methods for login users.	authorization login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default authorization methods are used for login users. 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 that use the same local user account. The threshold is configured by using the access-limit command.

Configuration procedure

To configure accounting 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 accounting methods for all types of users.	accounting default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| local [ 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 methods are used for command accounting.
5. Specify accounting methods for login users.	accounting login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default accounting methods are used for login users. The none keyword is not supported in FIPS mode.
6. Configure access control for users that encounter accounting-start failures.	accounting start-fail { offline \| online }	By default, the device allows users that encounter accounting-start failures to stay online.
7. Configure access control for users that have failed all their accounting-update attempts.	accounting update-fail { [ max-times max-times ] offline \| online }	By default, the device allows users that have failed all their accounting-update attempts to stay online.
8. Configure access control for users that have used up their data quotas.	accounting quota-out { offline \| online }	By default, the device logs off users that have used up their data quotas.
9. Specify the accounting method for dual-stack users.	accounting dual-stack { merge \| separate }	By default, the merge method is used.

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 with matching IP and VPN instance settings. 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 RADIUS session-control feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the RADIUS session-control feature.	radius session-control enable	By default, the RADIUS session-control feature is disabled.
3. Specify a RADIUS 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 RADIUS 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 perform the following operations:

· Log off online users.

· Change online user authorization information.

· Shut down or reboot the online users' access ports.

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 that match the criteria in the requests, changes their authorization information, or shuts down or reboots their access ports.

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 or shut down or reboot the users' access ports.

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

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

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.

Setting the maximum number of concurrent login users

Perform this task to set the maximum number of concurrent users that can log on to the device through a specific protocol, regardless of their authentication methods. The authentication methods include no authentication, local authentication, and remote authentication.

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.

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.

Displaying and maintaining AAA

Execute display commands in any view.

Task	Command
Display the configuration of ISP domains.	display domain [ isp-name ]

AAA configuration examples

AAA for SSH users by an HWTACACS server

Network requirements

As shown in Figure 10, 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 10 Network diagram

Configuration procedure

1. Configure the HWTACACS server:

# Set the shared keys to expert for secure communication with the switch. (Details not shown.)

# Add an account for the SSH user and specify the password. (Details not shown.)

2. Configure 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 11, 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 with the username hello for the SSH user. Configure the shared keys to expert for secure communication with the HWTACACS server and RADIUS server.

Figure 11 Network diagram

Configuration procedure

1. Configure the HWTACACS server. (Details not shown.)

2. Configure the RADIUS server. (Details not shown.)

3. Configure 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 the 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 12, 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 default user role network-operator to SSH users after they pass authentication.

The RADIUS server runs on IMC. Add an account with the username 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 12 Network diagram

Configuration procedure

1. Configure the RADIUS server on IMC 5.0:

NOTE:

In this example, the RADIUS server runs on IMC PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101).

# Add the switch to the IMC Platform as an access device.

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

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

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

c. Select the service type Device Management Service.

d. Select the access device type H3C.

e. Select the access device from the device list or manually add the access device (with the IP address 10.1.1.2).

f. Leave the default settings for other parameters and 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 the nas-ip command.

? IP address specified by the radius nas-ip command.

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

Figure 13 Adding the switch as an access device

# Add an account for device management.

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

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

b. Select the service type SSH.

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

d. Click OK.

NOTE:

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

Figure 14 Adding an account for device management

2. Configure the switch:

# Configure the 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

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

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

Configuring password control

Overview

Password control allows you to implement the following features:

· Manage login and super password setup, expirations, and updates for device management users.

· Control user login status based on predefined policies.

Local users are divided into two types: device management users and network access users. This feature applies only to device management users. For more information about local users, see "Configuring AAA."

Password setting

Minimum password length

You can define the minimum length of user passwords. If a user enters a password that is shorter than the minimum length, the system rejects the password.

Password composition policy

A password can be a combination of characters from the following types:

· Uppercase letters A to Z.

· Lowercase letters a to z.

· Digits 0 to 9.

· Special characters in Table 5.

Table 5 Special Characters

Character name	Symbol	Character name	Symbol
Ampersand sign	&	Apostrophe	'
Asterisk	*	At sign	@
Back quote	`	Back slash	\
Blank space	N/A	Caret	^
Colon	:	Comma	,
Dollar sign	$	Dot	.
Equal sign	=	Exclamation point	!
Left angle bracket	<	Left brace	{
Left bracket	[	Left parenthesis	(
Minus sign	-	Percent sign	%
Plus sign	+	Pound sign	#
Quotation marks	"	Right angle bracket	>
Right brace	}	Right bracket	]
Right parenthesis	)	Semi-colon	;
Slash	/	Tilde	~
Underscore	_	Vertical bar	\|

Depending on the system's security requirements, you can set the minimum number of character types a password must contain and the minimum number of characters for each type, as shown in Table 6.

Table 6 Password composition policy

Password combination level	Minimum number of character types	Minimum number of characters for each type
Level 1	One	One
Level 2	Two	One
Level 3	Three	One
Level 4	Four	One

In non-FIPS mode, all the combination levels are available for a password. In FIPS mode, only the level 4 combination is available for a password.

When a user sets or changes a password, the system checks if the password meets the combination requirement. If not, the operation fails.

Password complexity checking policy

A less complicated password such as a password containing the username or repeated characters is more likely to be cracked. For higher security, you can configure a password complexity checking policy to ensure that all user passwords are relatively complicated. With such a policy configured, when a user configures a password, the system checks the complexity of the password. If the password is complexity-incompliant, the configuration will fail.

You can apply the following password complexity requirements:

· A password cannot contain the username or the reverse of the username. For example, if the username is abc, a password such as abc982 or 2cba is not complex enough.

· A character or number cannot be included three or more times consecutively. For example, password a111 is not complex enough.

Password updating and expiration

Password updating

This feature allows you to set the minimum interval at which users can change their passwords. If a user logs in to change the password but the time passed since the last change is less than this interval, the system denies the request. For example, if you set this interval to 48 hours, a user cannot change the password twice within 48 hours.

The set minimum interval is not effective when a user is prompted to change the password at the first login or after its password aging time expires.

Password expiration

Password expiration imposes a lifecycle on a user password. After the password expires, the user needs to change the password.

If a user enters an expired password when logging in, the system displays an error message. The user is prompted to provide a new password and to confirm it by entering it again. The new password must be valid, and the user must enter exactly the same password when confirming it.

Telnet users, SSH users, and console users can change their own passwords. The administrator must change passwords for FTP users.

Early notice on pending password expiration

When a user logs in, the system checks whether the password will expire in a time equal to or less than the specified notification period. If so, the system notifies the user when the password will expire and provides a choice for the user to change the password. If the user sets a new password that is complexity-compliant, the system records the new password and the setup time. If the user chooses not to change the password or the user fails to change it, the system allows the user to log in using the current password.

Telnet users, SSH users, and console users can change their own passwords. The administrator must change passwords for FTP users.

Login with an expired password

You can allow a user to log in a certain number of times within a period of time after the password expires. For example, if you set the maximum number of logins with an expired password to 3 and the time period to 15 days, a user can log in three times within 15 days after the password expires.

Password history

With this feature enabled, the system stores passwords that a user has used. When a user changes the password, the system compares the new password with the current password and those stored in the password history records. The new password must be different from the current one and those stored in the history records by a minimum of four characters. The four characters must be different from one another. Otherwise, the system will display an error message, and the password will not be changed.

You can set the maximum number of history password records for the system to maintain for each user. When the number of history password records exceeds your setting, the most recent record overwrites the earliest one.

Current login passwords of device management users are not stored in the password history, because a device management user password is saved in cipher text and cannot be recovered to a plaintext password.

User login control

First login

If the global password control feature is enabled, users must change the password at first login before they can access the system. In this situation, password changes are not subject to the minimum password update interval.

Login attempt limit

Limiting the number of consecutive login failures can effectively prevent password guessing.

· Nonexistent users (users not configured on the device).

· Users logging in to the device through console ports.

If a user fails to log in, the system adds the user account and the user's IP address to the password control blacklist. After making the maximum number of consecutive attempts, login attempt limit limits the user and user account in any of the following ways:

· Disables the user account until the account is manually removed from the password control blacklist.

· Allows the user to continue using the user account. The user's IP address and user account are removed from the password control blacklist when the user uses this account to successfully log in to the device.

· Disables the user account for a period of time.

The user can use the account to log in when either of the following conditions exists:

? The locking timer expires.

? The account is manually removed from the password control blacklist before the locking timer expires.

NOTE:

This account is locked only for this user. Other users can still use this account, and the blacklisted user can use other user accounts.

Maximum account idle time

You can set the maximum account idle time for user accounts. When an account is idle for this period of time since the last successful login, the account becomes invalid.

Password not displayed in any form

For security purposes, nothing is displayed when a user enters a password.

Logging

The system logs all successful password changing events and user adding events to the password control blacklist.

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.

Password control configuration task list

The password control features can be configured in several different views, and different views support different features. The settings configured in different views or for different objects have the following application ranges:

· Settings for super passwords apply only to super passwords.

· Settings in local user view apply only to the password of the local user.

· Settings in user group view apply to the passwords of the local users in the user group if you do not configure password policies for these users in local user view.

· Global settings in system view apply to the passwords of the local users in all user groups if you do not configure password policies for these users in both local user view and user group view.

For local user passwords, the settings with a smaller application scope have higher priority.

To configure password control, perform the following tasks:

Tasks at a glance
(Required.) Enabling password control
(Optional.) Setting global password control parameters
(Optional.) Setting user group password control parameters
(Optional.) Setting local user password control parameters
(Optional.) Setting super password control parameters

Enabling password control

To successfully enable the global password control feature and allow device management users to log in to the device, the device must have sufficient storage space.

Enabling the global password control feature is the prerequisite for all password control configurations to take effect. Then, for a specific password control feature to take effect, enable this password control feature.

After the global password control feature is enabled, you cannot display the password and super password configurations for device management users by using the corresponding display commands. However, the configuration for network access user passwords can be displayed. The first password configured for device management users must contain a minimum of four different characters.

To ensure correct function of password control, configure the device to use NTP to obtain the UTC time. After global password control is enabled, password control will record the UTC time when the password is set. The recorded UTC time might not be consistent with the actual UTC time due to power failure or device reboot. The inconsistency will cause the password expiration feature to malfunction. For information about NTP, see Network Management and Monitoring Configuration Guide.

To enable password control:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the global password control feature.	password-control enable	· In non-FIPS mode, the global password control feature is disabled by default. · In FIPS mode, the global password control feature is enabled, and cannot be disabled by default.
3. (Optional.) Enable a specific password control feature.	password-control { aging \| composition \| history \| length } enable	By default, all four password control features are enabled.

Setting global password control parameters

The password expiration time, minimum password length, and password composition policy can be configured in system view, user group view, or local user view. The password settings with a smaller application scope have higher priority. Global settings in system view apply to the passwords of the local users in all user groups if you do not configure password policies for these users in both local user view and user group view.

The password-control login-attempt command takes effect immediately and can affect the users already in the password control blacklist. Other password control configurations do not take effect on users that have been logged in or passwords that have been configured.

To set global password control parameters:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the password expiration time.	password-control aging aging-time	The default setting is 90 days.
3. Set the minimum password update interval.	password-control update interval interval	The default setting is 24 hours.
4. Set the minimum password length.	password-control length length	· In non-FIPS mode, the default setting is 10 characters. · In FIPS mode, the default length is 15 characters.
5. Configure the password composition policy.	password-control composition type-number type-number [ type-length type-length ]	The following default settings apply: · In non-FIPS mode, a password must contain a minimum of one character type and a minimum of one character for each type. · In FIPS mode, a password must contain a minimum of four character types and a minimum of one character for each type.
6. Configure the password complexity checking policy.	password-control complexity { same-character \| user-name } check	By default, the system does not perform password complexity checking.
7. Set the maximum number of history password records for each user.	password-control history max-record-number	The default setting is 4.
8. Configure the login attempt limit.	password-control login-attempt login-times [ exceed { lock \| lock-time time \| unlock } ]	By default, the maximum number of login attempts is 3 and a user failing to log in after the specified number of attempts must wait for 1 minute before trying again.
9. Set the number of days during which a user is notified of the pending password expiration.	password-control alert-before-expire alert-time	The default setting is 7 days.
10. Set the maximum number of days and maximum number of times that a user can log in after the password expires.	password-control expired-user-login delay delay times times	By default, a user can log in three times within 30 days after the password expires.
11. Set the maximum account idle time.	password-control login idle-time idle-time	The default setting is 90 days.

Setting user group password control parameters

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a user group and enter its view.	user-group group-name	By default, no user groups exist. For information about how to configure a user group, see "Configuring AAA."
3. Configure the password expiration time for the user group.	password-control aging aging-time	By default, the password expiration time of the user group equals the global password expiration time.
4. Configure the minimum password length for the user group.	password-control length length	By default, the minimum password length of the user group equals the global minimum password length.
5. Configure the password composition policy for the user group.	password-control composition type-number type-number [ type-length type-length ]	By default, the password composition policy of the user group equals the global password composition policy.
6. Configure the password complexity checking policy for the user group.	password-control complexity { same-character \| user-name } check	By default, the password complexity checking policy of the user group equals the global password complexity checking policy.
7. Configure the login attempt limit.	password-control login-attempt login-times [ exceed { lock \| lock-time time \| unlock } ]	By default, the login-attempt policy of the user group equals the global login-attempt policy.

Setting local user password control parameters

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a device management user and enter its view.	local-user user-name class manage	By default, no local users exist. Local user password control applies to device management users instead of network access users. For information about how to configure a local user, see "Configuring AAA."
3. Configure the password expiration time for the local user.	password-control aging aging-time	By default, the setting equals that for the user group to which the local user belongs. If no expiration time is configured for the user group, the global setting applies to the local user.
4. Configure the minimum password length for the local user.	password-control length length	By default, the setting equals that for the user group to which the local user belongs. If no minimum password length is configured for the user group, the global setting applies to the local user.
5. Configure the password composition policy for the local user.	password-control composition type-number type-number [ type-length type-length ]	By default, the settings equal those for the user group to which the local user belongs. If no password composition policy is configured for the user group, the global settings apply to the local user.
6. Configure the password complexity checking policy for the local user.	password-control complexity { same-character \| user-name } check	By default, the settings equal those for the user group to which the local user belongs. If no password complexity checking policy is configured for the user group, the global settings apply to the local user.
7. Configure the login attempt limit.	password-control login-attempt login-times [ exceed { lock \| lock-time time \| unlock } ]	By default, the settings equal those for the user group to which the local user belongs. If no login-attempt policy is configured for the user group, the global settings apply to the local user.

Setting super password control parameters

The super password allows you to obtain a temporary user role without reconnecting to the device. For more information, see Fundamentals Configuration Guide.

To set super password control parameters:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the password expiration time for super passwords.	password-control super aging aging-time	The default setting is 90 days.
3. Configure the minimum length for super passwords.	password-control super length length	· In non-FIPS mode, the default setting is 10 characters. · In FIPS mode, the default setting is 15 characters.
4. Configure the password composition policy for super passwords.	password-control super composition type-number type-number [ type-length type-length ]	The following default settings apply: · In non-FIPS mode, a super password must contain a minimum of one character type and a minimum of one character for each type. · In FIPS mode, a super password must contain a minimum of four character types and a minimum of one character for each type.

Displaying and maintaining password control

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

Task	Command
Display password control configuration.	display password-control [ super ]
Display information about users in the password control blacklist.	display password-control blacklist [ user-name user-name \| ip ipv4-address \| ipv6 ipv6-address ]
Delete users from the password control blacklist.	reset password-control blacklist [ user-name user-name ]
Clear history password records.	reset password-control history-record [ user-name user-name \| super [ role role name ] ]

NOTE:

The reset password-control history-record command can delete the history password records of one or all users even when the password history feature is disabled.

Password control configuration example

Network requirements

Configure a global password control policy to meet the following requirements:

· A password must contain a minimum of 16 characters.

· A password must contain a minimum of four character types and a minimum of four characters for each type.

· An FTP or VTY user failing to provide the correct password in two successive login attempts is permanently prohibited from logging in.

· A user can log in five times within 60 days after the password expires.

· A password expires after 30 days.

· The minimum password update interval is 36 hours.

· The maximum account idle time is 30 days.

· A password cannot contain the username or the reverse of the username.

· No character appears consecutively three or more times in a password.

Configure a super password control policy for user role network-operator to meet the following requirements:

· A super password must contain a minimum of 24 characters.

· A super password must contain a minimum of four character types and a minimum of five characters for each type.

Configure a password control policy for local Telnet user test to meet the following requirements:

· The password must contain a minimum of 24 characters.

· The password must contain a minimum of four character types and a minimum of five characters for each type.

· The password for the local user expires after 20 days.

Configuration procedure

# Enable the password control feature globally.

<Sysname> system-view

[Sysname] password-control enable

# Disable a user account permanently if a user fails two consecutive login attempts on the user account.

[Sysname] password-control login-attempt 2 exceed lock

# Set all passwords to expire after 30 days.

[Sysname] password-control aging 30

# Globally set the minimum password length to 16 characters.

[Sysname] password-control length 16

# Set the minimum password update interval to 36 hours.

[Sysname] password-control update-interval 36

# Specify that a user can log in five times within 60 days after the password expires.

[Sysname] password-control expired-user-login delay 60 times 5

# Set the maximum account idle time to 30 days.

[Sysname] password-control login idle-time 30

# Refuse any password that contains the username or the reverse of the username.

[Sysname] password-control complexity user-name check

# Specify that no character can be included three or more times consecutively in a password.

[Sysname] password-control complexity same-character check

# Globally specify that all passwords must each contain a minimum of four character types and a minimum of four characters for each type.

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

# Set the minimum super password length to 24 characters.

[Sysname] password-control super length 24

# Specify that a super password must contain a minimum of four character types and a minimum of five characters for each type.

[Sysname] password-control super composition type-number 4 type-length 5

# Configure a super password used for switching to user role network-operator as 123456789ABGFTweuix@#$%! in plain text.

[Sysname] super password role network-operator simple 123456789ABGFTweuix@#$%!

# Create a device management user named test.

[Sysname] local-user test class manage

# Set the service type of the user to Telnet.

[Sysname-luser-manage-test] service-type telnet

# Set the minimum password length to 24 for the local user.

[Sysname-luser-manage-test] password-control length 24

# Specify that the password of the local user must contain a minimum of four character types and a minimum of five characters for each type.

[Sysname-luser-manage-test] password-control composition type-number 4 type-length 5

# Set the password for the local user to expire after 20 days.

[Sysname-luser-manage-test] password-control aging 20

# Configure the password of the local user in interactive mode.

[Sysname-luser-manage-test] password

Password:

Confirm :

Updating user information. Please wait ... ...

[Sysname-luser-manage-test] quit

Verifying the configuration

# Display the global password control configuration.

<Sysname> display password-control

Global password control configurations:

Password control: Enabled

Password aging: Enabled (30 days)

Password length: Enabled (16 characters)

Password composition: Enabled (4 types, 4 characters per type)

Password history: Enabled (max history record:4)

Early notice on password expiration: 7 days

Maximum login attempts: 2

Action for exceeding login attempts: Lock

Minimum interval between two updates: 36 hours

User account idle time: 30 days

Logins with aged password: 5 times in 60 days

Password complexity: Enabled (username checking)

Enabled (repeated characters checking)

# Display the password control configuration for super passwords.

<Sysname> display password-control super

Super password control configurations:

Password aging: Enabled (90 days)

Password length: Enabled (24 characters)

Password composition: Enabled (4 types, 5 characters per type)

# Display the password control configuration for local user test.

<Sysname> display local-user user-name test class manage

Total 1 local users matched.

Device management user test:

State: Active

Service type: Telnet

User group: system

Bind attributes:

Authorization attributes:

Work directory: flash:

User role list: network-operator

Password control configurations:

Password aging: 20 days

Password length: 24 characters

Password composition: 4 types, 5 characters per type

Configuring keychains

Overview

A keychain, a sequence of keys, provides dynamic authentication to ensure secure communication by periodically changing the key and authentication algorithm without service interruption.

Each key in a keychain has a key string, authentication algorithm, sending lifetime, and receiving lifetime. These settings can be different for the keys. When the system time is within the lifetime of a key in a keychain, an application uses the key to authenticate incoming and outgoing packets. The keys in the keychain take effect one by one according to the sequence of the configured lifetimes. In this way, the authentication algorithms and keys are dynamically changed to implement dynamic authentication.

A keychain operates in absolute time mode. In this mode, each time point during a key's lifetime is the UTC time and is not affected by the system's time zone or daylight saving time.

Configuration procedure

Follow these guidelines when you configure a keychain:

· To make sure only one key in a keychain is used at a time to authenticate packets to a peer, set non-overlapping sending lifetimes for the keys in the keychain.

· The keys used by the local device and the peer device must have the same authentication algorithm and key string.

To configure a keychain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a keychain and enter keychain view.	keychain keychain-name [ mode absolute ]	By default, no keychains exist.
3. (Optional.) Set the kind value in the TCP Enhanced Authentication Option.	tcp-kind kind-value	By default, the kind value is 254. When the local device uses TCP to communicate with a peer device from another vendor, make sure both devices have the same kind value setting. If they do not have the same value, use this command to modify the kind value on the local device.
4. (Optional.) Set an algorithm ID for a TCP authentication algorithm.	tcp-algorithm-id { hmac-md5 \| md5 } algorithm-id	By default, the algorithm ID is 3 for the MD5 authentication algorithm, and is 5 for the HMAC-MD5 authentication algorithm. When the local device uses TCP to communicate with a peer device from another vendor, make sure both devices have the same algorithm ID setting. If they do not have the same algorithm ID, use this command to modify the algorithm ID on the local device.
5. (Optional.) Set a tolerance time for accept keys in the keychain.	accept-tolerance { value \| infinite }	By default, no tolerance time is configured for accept keys in a keychain.
6. Create a key and enter key view.	key key-id	By default, no keys exist.
7. Specify an authentication algorithm for the key.	authentication-algorithm { hmac-md5 \| hmac-sha-256 \| md5 }	By default, no authentication algorithm is specified for a key.
8. Configure a key string for the key.	key-string { cipher \| plain } string	By default, no key string is configured.
9. Set the sending lifetime in UTC mode for the key.	send-lifetime utc start-time start-date { duration { duration-value \| infinite } \| to end-time end-date }	By default, the sending lifetime is not configured for a key.
10. Set the receiving lifetime in UTC mode for the key.	accept-lifetime utc start-time start-date { duration { duration-value \| infinite } \| to end-time end-date }	By default, the receiving lifetime is not configured for a key.
11. (Optional.) Specify the key as the default send key.	default-send-key	By default, no key in a keychain is specified as the default send key.

Displaying and maintaining keychain

Execute display commands in any view.

Task	Command
Display keychain information.	display keychain [ name keychain-name [ key key-id ] ]

Keychain configuration example

Network requirements

As shown in Figure 15, establish an OSPF neighbor relationship between Switch A and Switch B, and use a keychain to authenticate packets between the switches. Configure key 1 and key 2 for the keychain and make sure key 2 is used immediately when key 1 expires.

Figure 15 Network diagram

Configuration procedure

Configuring Switch A

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

# Configure OSPF.

<SwitchA> system-view

[SwitchA] ospf 1 router-id 1.1.1.1

[SwitchA-ospf-1] area 0

[SwitchA-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255

[SwitchA-ospf-1-area-0.0.0.0] quit

[SwitchA-ospf-1] quit

# Create a keychain named abc, and specify the absolute time mode for it.

[SwitchA] keychain abc mode absolute

# Create key 1 for keychain abc, specify an authentication algorithm, and configure a key string and the sending and receiving lifetimes for the key.

[SwitchA-keychain-abc] key 1

[SwitchA-keychain-abc-key-1] authentication-algorithm md5

[SwitchA-keychain-abc-key-1] key-string plain 123456

[SwitchA-keychain-abc-key-1] send-lifetime utc 10:00:00 2015/02/06 to 11:00:00 2015/02/06

[SwitchA-keychain-abc-key-1] accept-lifetime utc 10:00:00 2015/02/06 to 11:00:00 2015/02/06

[SwitchA-keychain-abc-key-1] quit

# Create key 2 for keychain abc, specify an authentication algorithm, and configure a key string and the sending and receiving lifetimes for the key.

[SwitchA-keychain-abc] key 2

[SwitchA-keychain-abc-key-2] authentication-algorithm hmac-md5

[SwitchA-keychain-abc-key-2] key-string plain pwd123

[SwitchA-keychain-abc-key-2] send-lifetime utc 11:00:00 2015/02/06 to 12:00:00 2015/02/06

[SwitchA-keychain-abc-key-2] accept-lifetime utc 11:00:00 2015/02/06 to 12:00:00 2015/02/06

[SwitchA-keychain-abc-key-2] quit

[SwitchA-keychain-abc] quit

# Configure VLAN-interface 100 to use keychain abc for authentication.

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] ospf authentication-mode keychain abc

[SwitchA-Vlan-interface100] quit

Configuring Switch B

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

# Configure OSPF.

[SwitchB] ospf 1 router-id 2.2.2.2

[SwitchB-ospf-1] area 0

[SwitchB-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] quit

[SwitchB-ospf-1] quit

# Create a keychain named abc, and specify the absolute time mode for it.

[SwitchB] keychain abc mode absolute

# Create key 1 for keychain abc, specify an authentication algorithm, and configure a key string and the sending and receiving lifetimes for the key.

[SwitchB-keychain-abc] key 1

[SwitchB-keychain-abc-key-1] authentication-algorithm md5

[SwitchB-keychain-abc-key-1] key-string plain 123456

[SwitchB-keychain-abc-key-1] send-lifetime utc 10:00:00 2015/02/06 to 11:00:00 2015/02/06

[SwitchB-keychain-abc-key-1] accept-lifetime utc 10:00:00 2015/02/06 to 11:00:00 2015/02/06

[SwitchB-keychain-abc-key-1] quit

# Create key 2 for keychain abc, specify an authentication algorithm, and configure a key string and the sending and receiving lifetimes for the key.

[SwitchB-keychain-abc] key 2

[SwitchB-keychain-abc-key-2] authentication-algorithm hmac-md5

[SwitchB-keychain-abc-key-2] key-string plain pwd123

[SwitchB-keychain-abc-key-2] send-lifetime utc 11:00:00 2015/02/06 to 12:00:00 2015/02/06

[SwitchB-keychain-abc-key-2] accept-lifetime utc 11:00:00 2015/02/06 to 12:00:00 2015/02/06

[SwitchB-keychain-abc-key-2] quit

[SwitchB-keychain-abc] quit

# Configure VLAN-interface 100 to use keychain abc for authentication.

[SwitchB] interface vlan-interface 100

[SwitchB-Vlan-interface100] ospf authentication-mode keychain abc

[SwitchB-Vlan-interface100] quit

Verifying the configuration

1. When the system time is within the lifetime from 10:00:00 to 11:00:00 on the day 2015/02/06, verify the status of the keys in keychain abc.

# Display keychain information on Switch A. The output shows that key 1 is the valid key.

[SwitchA] display keychain

Keychain name : abc

Mode : absolute

Accept tolerance : 0

TCP kind value : 254

TCP algorithm value

HMAC-MD5 : 5

MD5 : 3

Default send key ID : None

Active send key ID : 1

Active accept key IDs: 1

Key ID : 1

Key string : $c$3$dYTC8QeOKJkwFwP2k/rWL+1p6uMTw3MqNg==

Algorithm : md5

Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06

Send status : Active

Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06

Accept status : Active

Key ID : 2

Key string : $c$3$7TSPbUxoP1ytOqkdcJ3K3x0BnXEWl4mOEw==

Algorithm : hmac-md5

Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06

Send status : Inactive

Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06

Accept status : Inactive

# Display keychain information on Switch B. The output shows that key 1 is the valid key.

[SwitchB]display keychain

Keychain name : abc

Mode : absolute

Accept tolerance : 0

TCP kind value : 254

TCP algorithm value

HMAC-MD5 : 5

MD5 : 3

Default send key ID : None

Active send key ID : 1

Active accept key IDs: 1

Key ID : 1

Key string : $c$3$/G/Shnh6heXWprlSQy/XDmftHa2JZJBSgg==

Algorithm : md5

Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06

Send status : Active

Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06

Accept status : Active

Key ID : 2

Key string : $c$3$t4qHAw1hpZYN0JKIEpXPcMFMVT81u0hiOw==

Algorithm : hmac-md5

Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06

Send status : Inactive

Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06

Accept status : Inactive

2. When the system time is within the lifetime from 11:00:00 to 12:00:00 on the day 2015/02/06, verify the status of the keys in keychain abc.

# Display keychain information on Switch A. The output shows that key 2 becomes the valid key.

[SwitchA]display keychain

Keychain name : abc

Mode : absolute

Accept tolerance : 0

TCP kind value : 254

TCP algorithm value

HMAC-MD5 : 5

MD5 : 3

Default send key ID : None

Active send key ID : 2

Active accept key IDs: 2

Key ID : 1

Key string : $c$3$dYTC8QeOKJkwFwP2k/rWL+1p6uMTw3MqNg==

Algorithm : md5

Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06

Send status : Inactive

Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06

Accept status : Inactive

Key ID : 2

Key string : $c$3$7TSPbUxoP1ytOqkdcJ3K3x0BnXEWl4mOEw==

Algorithm : hmac-md5

Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06

Send status : Active

Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06

Accept status : Active

# Display keychain information on Switch B. The output shows that key 2 becomes the valid key.

[SwitchB]display keychain

Keychain name : abc

Mode : absolute

Accept tolerance : 0

TCP kind value : 254

TCP algorithm value

HMAC-MD5 : 5

MD5 : 3

Default send key ID : None

Active send key ID : 1

Active accept key IDs: 1

Key ID : 1

Key string : $c$3$/G/Shnh6heXWprlSQy/XDmftHa2JZJBSgg==

Algorithm : md5

Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06

Send status : Inactive

Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06

Accept status : Inactive

Key ID : 2

Key string : $c$3$t4qHAw1hpZYN0JKIEpXPcMFMVT81u0hiOw==

Algorithm : hmac-md5

Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06

Send status : Active

Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06

Accept status : Active

Managing public keys

Overview

This chapter describes public key management for the following asymmetric key algorithms:

· Revest-Shamir-Adleman Algorithm (RSA).

· Digital Signature Algorithm (DSA).

· Elliptic Curve Digital Signature Algorithm (ECDSA).

Many security applications (for example, SSH) use asymmetric key algorithms to secure communications between two parties, as shown in Figure 16. Asymmetric key algorithms use two separate keys (one public and one private) for encryption and decryption. Symmetric key algorithms use only one key.

Figure 16 Encryption and decryption

A key owner can distribute the public key in plain text on the network but must keep the private key in privacy. It is mathematically infeasible to calculate the private key even if an attacker knows the algorithm and the public key.

The security applications use the asymmetric key algorithms for the following purposes:

· Encryption and decryption—Any public key receiver can use the public key to encrypt information, but only the private key owner can decrypt the information.

· Digital signature—The key owner uses the private key to digitally sign information to be sent. The receiver decrypts the information with the sender's public key to verify information authenticity.

RSA, DSA, and ECDSA can all perform digital signature, but only RSA can perform encryption and decryption.

Asymmetric key algorithms enable secure key distribution on an insecure network. The security strength of an asymmetric key varies by the key modulus length as with any symmetric key algorithm.

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.

Creating a local key pair

When you create a local key pair, follow these guidelines:

· The key algorithm must be the same as required by the security application.

· When you create an RSA or DSA key pair, enter an appropriate key modulus length at the prompt. The longer the key modulus length, the higher the security, and the longer the key generation time.

When you create an ECDSA key pair, choose the appropriate elliptic curve. The elliptic curve determines the ECDSA key length. The longer the key length, the higher the security, and the longer the key generation time.

See Table 7 for more information about key modulus lengths and key lengths.

· If you do not assign the key pair a name, the system assigns the default name to the key pair and marks the key pair as default. You can also assign the default name to another key pair, but the system does not mark the key pair as default. The key pair name must be unique among all manually named key pairs that use the same key algorithm. If a name conflict occurs, the system asks whether you want to overwrite the existing key pair.

· The key pairs are automatically saved and can survive system reboots.

Table 7 A comparison of different types of asymmetric key algorithms

Type	Generated key pairs	Modulus/key length
RSA	· In non-FIPS mode: ? One host key pair, if you specify a key pair name. ? One server key pair and one host key pair, if you do not specify a key pair name. Both key pairs use their default names. · In FIPS mode: One host key pair. NOTE: Only SSH 1.5 uses the RSA server key pair.	· In non-FIPS mode: 512 to 2048 bits, 1024 bits by default. To ensure security, use a minimum of 768 bits. · In FIPS mode: 2048 bits.
DSA	One host key pair.	· In non-FIPS mode: 512 to 2048 bits, 1024 bits. To ensure security, use a minimum of 768 bits. · In FIPS mode: 2048 bits.
ECDSA	One host key pair.	· In non-FIPS mode: 192, 256, 384, or 521 bits. · In FIPS mode: 256, 384, or 521 bits.

To create a local key pair:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Create a local key pair.

· In non-FIPS mode:
public-key local create { dsa | ecdsa [ secp192r1 | secp256r1 | secp384r1 | secp521r1 ] | rsa } [ name key-name ]

· In FIPS mode:
public-key local create { dsa | ecdsa [ secp256r1 | secp384r1 | secp521r1 ] | rsa } [ name key-name ]

By default, no local key pairs exist.

Distributing a local host public key

For applications such as SSH, you must distribute a local host public key to a peer device so the peer device can perform the following operations:

· Use the public key to encrypt information sent to the local device.

· Authenticate the digital signature signed by the local device.

To distribute a local host public key, you must first export or display the key.

· Export a host public key:

? Export a host public key to a file.

? Export a host public key to the monitor screen, and then save it to a file.

After the key is exported to a file, transfer the file to the peer device. On the peer device, import the key from the file.

· Display a host public key.

After the key is displayed, record the key, for example, copy it to an unformatted file. On the peer device, you must literally enter the key.

Exporting a host public key

When you export a host public key, follow these restrictions and guidelines:

· If you specify a file name in the command, the command exports the key to the specified file.

· If you do not specify a file name, the command exports the key to the monitor screen. You must manually save the exported key to a file.

To export a local host public key:

Step

Command

1. Enter system view.

system-view

2. Export a local host public key.

· Export an RSA host public key:

? In non-FIPS mode:
public-key local export rsa [ name key-name ] { openssh | ssh1 | ssh2 } [ filename ]

? In FIPS mode:
public-key local export rsa [ name key-name ] { openssh | ssh2 } [ filename ]

· Export an ECDSA host public key:
public-key local export ecdsa [ name key-name ] { openssh | ssh2 } [ filename ]

· Export a DSA host public key:
public-key local export dsa [ name key-name ] { openssh | ssh2 } [ filename ]

Displaying a host public key

Perform the following tasks in any view:

Task	Command
Display local RSA public keys.	display public-key local rsa public [ name key-name ]
Display local ECDSA public keys.	display public-key local ecdsa public [ name key-name ]
Display local DSA public keys.	display public-key local dsa public [ name key-name ]

NOTE:

Do not distribute the RSA server public key serverkey (default) to a peer device.

Destroying a local key pair

To avoid key compromise, destroy the local key pair and generate a new pair after any of the following conditions occurs:

· An intrusion event has occurred.

· The storage media of the device is replaced.

To destroy a local key pair:

Step	Command
1. Enter system view.	system-view
2. Destroy a local key pair.	public-key local destroy { dsa \| ecdsa \| rsa } [ name key-name ]

Configuring a peer host public key

To encrypt information sent to a peer device or authenticate the digital signature of the peer device, you must configure the peer device's public key on the local device.

You can configure the peer host public key by using the following methods:

· Import the peer host public key from a public key file (recommended).

· Manually enter (type or copy) the peer host public key.

Importing a peer host public key from a public key file

Before you perform this task, make sure you have exported the host public key to a file on the peer device and obtained the file from the peer device. For information about exporting a host public key, see "Exporting a host public key."

After you import the key, the system automatically converts the imported public key to a string in the Public Key Cryptography Standards (PKCS) format.

To import a peer host public key from a public key file:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Import a peer host public key from a public key file.	public-key peer keyname import sshkey filename	By default, no peer host public keys exist.

Entering a peer host public key

Before you perform this task, make sure you have displayed the key on the peer device and recorded the key. For information about displaying a host public key, see "Displaying a host public key."

Use the display public-key local public command to display the public key on the peer device. The format of the public key displayed in any other way might be incorrect. If the key is not in the correct format, the system discards the key and displays an error message. If the key is valid, the system saves the key.

Always import rather than enter the peer host public key if you are not sure whether the device supports the format of the recorded peer host public key.

To enter a peer host public key:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify a name for the peer host public key and enter public key view.	public-key peer keyname	By default, no peer host public keys exist.
3. Type or copy the key.	N/A	You can use spaces and carriage returns, but the system does not save them.
4. Return to system view.	peer-public-key end	When you exit public key view, the system automatically saves the peer host public key.

Displaying and maintaining public keys

Execute display commands in any view.

Task	Command
Display local public keys.	display public-key local { dsa \| ecdsa \| rsa } public [ name key-name ]
Display peer host public keys.	display public-key peer [ brief \| name publickey-name ]

Examples of public key management

Example for entering a peer host public key

Network requirements

As shown in Figure 17, to prevent illegal access, Device B authenticates Device A through a digital signature. Before configuring authentication parameters on Device B, configure the public key of Device A on Device B.

· Configure Device B to use the asymmetric key algorithm of RSA to authenticate Device A.

· Manually specify the host public key of Device A on Device B.

Figure 17 Network diagram

Configuration procedure

1. Configure Device A:

# Create local RSA key pairs with default names on Device A, and use the default modulus length 1024 bits.

<DeviceA> system-view

[DeviceA] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.................++++++

......................................++++++

.....++++++++

..............++++++++

Create the key pair successfully.

# Display all local RSA public keys.

[DeviceA] display public-key local rsa public

=============================================

Key name: hostkey (default)

Key type: RSA

Time when key pair created: 16:48:31 2011/05/12

Key code:

30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B

8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E

45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257

6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788

CB47440AF6BB25ACA50203010001

=============================================

Key name: serverkey (default)

Key type: RSA

Time when key pair created: 16:48:31 2011/05/12

Key code:

307C300D06092A864886F70D0101010500036B003068026100C9451A80F7F0A9BA1A90C7BC

1C02522D194A2B19F19A75D9EF02219068BD7FD90FCC2AF3634EEB9FA060478DD0A1A49ACE

E1362A4371549ECD85BA04DEE4D6BB8BE53B6AED7F1401EE88733CA3C4CED391BAE633028A

AC41C80A15953FB22AA30203010001

2. Configure Device B:

# Enter the host public key of Device A in public key view. The key must be literally the same as displayed on

09-Security Configuration Guide

Client/server model

Information exchange security mechanism

User authentication methods

RADIUS packet format

Extended RADIUS attributes

HWTACACS

AAA implementation on the device

User management based on ISP domains and user access types

AAA methods

AAA for MPLS L3VPNs

Configuring AAA schemes

Local user configuration task list

Configuration task list

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

Setting RADIUS timers

Configuring the RADIUS accounting-on feature

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

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

Creating an ISP domain

Configuration prerequisites

Configuration guidelines

Configuration procedure

Configuration prerequisites

Configuration guidelines

Configuration procedure

Configuration prerequisites

Configuration procedure

Configuring the RADIUS DAS feature

Configuring a NAS-ID profile

AAA configuration examples

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Troubleshooting RADIUS

RADIUS authentication failure

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Overview

Minimum password length

Password composition policy

Password complexity checking policy

Password updating

Password expiration

Early notice on pending password expiration

Login with an expired password

Password history

First login

Login attempt limit

Maximum account idle time

FIPS compliance

Enabling password control

Setting global password control parameters

Setting user group password control parameters

Setting super password control parameters

Displaying and maintaining password control

Password control configuration example

Configuration procedure

Displaying and maintaining keychain

Keychain configuration example