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

· Authentication—Identifies users and verifies their validity.

· Authorization—Grants different users different rights and controls their access to resources and services. For example, you can use this function to grant a user who has successfully logged in to the device read and print permissions to the files on the device, and prevent a guest from reading or printing the files.

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

A user who wants to access networks or resources beyond the NAS sends its identity information to the NAS, which transparently passes the user information to the servers. The servers perform user authentication, authorization, and accounting and return the result to the NAS. Based on the result, the NAS determines whether to permit or deny the access request.

AAA has various implementations, including RADIUS and HWTACACS, of which 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 three security functions provided by AAA as needed. For example, if your company only wants employees to be authenticated before they access specific resources, you only need to deploy an authentication server. If network usage information is needed, you must also configure an accounting server.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. It 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. With the addition of new access methods, RADIUS 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. It receives authentication, authorization, and accounting requests from RADIUS clients, performs user authentication, authorization, or accounting, and returns user access control information (for example, rejecting or accepting the user access request) to the clients. In addition, the RADIUS server can act as the client of another RADIUS server to provide authentication proxy services.

The RADIUS server maintains the following databases: Users, Clients, and Dictionary.

Figure 2 RADIUS server 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.

Information exchange security mechanism

The RADIUS client and server exchange information between them with the help of shared keys, which are pre-configured on the client and server. A RADIUS packet has a 16-byte field called Authenticator. This field carries 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 carried in RADIUS packets.

User authentication mechanisms

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 operates in the following manner:

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

2. The RADIUS client encrypts the user password by using the MD5 algorithm, the shared key, and some other information, encapsulates the username and the encrypted password to an authentication request (Access-Request), and sends the request to the RADIUS server.

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 it permits the user, it sends a start-accounting request (Accounting-Request) packet to the RADIUS server.

5. The RADIUS server returns an acknowledgement (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 acknowledgement (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. To ensure smooth packet exchange between the RADIUS server and the client, RADIUS uses a series of mechanisms, including the timer mechanism, the retransmission mechanism, and the backup server mechanism. Figure 4 shows the RADIUS packet format.

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 carries 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 carried 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 carried 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 carries 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 at 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) carries specific authentication, authorization, and accounting information. This field can contain multiple attributes, each with three sub-fields:

¡ Type—Type of the attribute.

¡ Length—Length of the attribute in bytes, including the Type, Length, and Value sub-fields.

¡ Value—Value of the attribute. Its format and content depend on the Type sub-field.

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. Attribute 26 (Vendor-Specific), an attribute defined in RFC 2865, allows a vendor to define extended attributes to implement functions that the standard RADIUS protocol does not provide.

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

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

· Vendor-Type—Type of the sub-attribute.

· Vendor-Length—Length of the sub-attribute.

· Vendor-Data—Contents of the sub-attribute.

For more information about the proprietary RADIUS sub-attributes of H3C, see "H3C proprietary RADIUS sub-attributes."

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). Similar to RADIUS, it 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, some terminal users need to log in to the NAS for operations. Working as the HWTACACS client, the NAS sends users' usernames and passwords to the HWTACACS sever for authentication. After passing authentication and getting 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 their primary differences.

Table 3 Primary differences between HWTACACS and RADIUS

HWTACACS	RADIUS
Uses TCP, providing more reliable network transmission.	Uses UDP, providing higher 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. Commands a user can use depend 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. Commands a user can use solely depend on the user's roles. For more information about user roles, see the chapter on RBAC in 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 in the following manner:

1. A Telnet user sends an access request to the HWTACACS client.

2. Upon receiving the request, the HWTACACS client sends a start-authentication packet to the HWTACACS server.

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 carries the username.

7. The HWTACACS server sends back an authentication response, requesting the login password.

8. Upon receipt of the response, the HWTACACS client asks 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 carries 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 their ISP domains and access types.

On a NAS, each user belongs to one ISP domain. Normally, a NAS determines the ISP domain a user belongs to by the username entered by the user at login.

Figure 7 Determining the ISP domain for a user by the username

AAA manages users in the same ISP domain based on their access types. The device supports login users, including SSH, Telnet, FTP, and terminal users who log in to the device through a console or AUX port.

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, and 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 used for users for whom no specific AAA methods are configured.

The device supports the following authentication methods:

· No authentication—All users are trusted and no authentication is performed. Generally, 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 cooperates with a RADIUS or HWTACACS server to authenticate users. Remote authentication provides centralized information management, high capacity, high reliability, and support for centralized authentication service 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. After passing authentication, non-login users can access the network, FTP users can access the root directory of the NAS, and other login users obtain only the default user role.

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

· Remote authorization—The NAS cooperates 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 carried in the Access-Accept packet. HWTACACS authorization is separate from HWTACACS authentication, and the authorization information is carried in the authorization response after successful authentication. You can configure backup methods to be used when the remote server is not available.

The device supports the following accounting methods:

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

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

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

In addition, the device provides the following services for login users to enhance device security:

· Command authorization—Enables the NAS to defer to the authorization server to determine whether a command entered by a login user is permitted, and allows login users to execute only authorized commands. 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 switching authentication—Authenticates each user who wants to switch to another user role without logging out or getting disconnected. For more information about user role switching, see Fundamentals Configuration Guide.

AAA for MPLS L3VPNs

In an MPLS L3VPN scenario where clients in different VPNs are centrally authenticated, you can deploy AAA across VPNs to enable forwarding of RADIUS and HWTACACS packets across MPLS VPNs. For example, in the network shown in Figure 8, you can deploy the AAA across VPNs feature, so that the PE at the left side of the MPLS backbone serves as a NAS and transparently delivers the AAA packets of private users in VPN 1 and VPN 2 to the AAA servers in VPN 3 for centralized authentication. Authentication packets of private users in different VPNs do not affect each other.

Figure 8 Network diagram

Protocols and standards

The following protocols and standards are related to AAA, RADIUS, and HWTACACS:

· 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 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. Usually, 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 the 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 indicate, for example, the reason of the authentication failure.
26	Vendor-Specific	Vendor specific attribute. A packet can contain one or more such proprietary attributes, each of which can contain one or more sub-attributes.
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.
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.
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.
87	NAS-Port-Id	String for describing the port of the NAS that is authenticating the user.

H3C proprietary RADIUS sub-attributes

No.	Sub-attribute	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 remaining available traffic for the connection, in different units for different server types.
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.
24	Control_Identifier	Identification for retransmitted packets. For retransmitted packets of the same session, this attribute must take the same value. For retransmitted packets of different sessions, this attribute can take the same value. The client response of a retransmitted packet must also carry this attribute and the value of this attribute must be the same. For Accounting-Request packets of the start, stop, and interim update types, the Control-Identifier attribute does not take effect.
25	Result_Code	Result of the Trigger-Request or SetPolicy operation, zero for success and any other value for failure.
26	Connect_ID	Index of the user connection.
28	Ftp_Directory	FTP user working directory. When the RADIUS client acts as the FTP server, this attribute is used to set the FTP directory for an FTP user on the RADIUS client.
29	Exec_Privilege	EXEC user priority.
59	NAS_Startup_Timestamp	Startup time of the NAS in seconds, which is represented by the time elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
60	Ip_Host_Addr	User IP address and MAC address carried 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.
201	Input-Interval-Octets	Number of bytes input within a real-time accounting interval.
202	Output-Interval-Octets	Number of bytes output within a real-time accounting interval.
203	Input-Interval-Packets	Number of packets input within an accounting interval, in the unit set on the NAS.
204	Output-Interval-Packets	Number of packets output within an accounting interval, in the unit set on the NAS.
205	Input-Interval-Gigawords	Amount of bytes input within an accounting interval, in units of 4G bytes.
206	Output-Interval-Gigawords	Amount of bytes output within an accounting interval, in units of 4G bytes.
207	Backup-NAS-IP	Backup source IP address for sending RADIUS packets.
255	Product_ID	Product name.

AAA configuration considerations and task list

To configure AAA, complete these 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 reference the configured RADIUS and HWTACACS schemes.

Figure 9 AAA configuration procedure

To configure AAA, perform the following tasks:

Tasks at a glance

(Required.) Perform at least 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 at least 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.) Enabling the session-control feature

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. Local users are classified into the following types:

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

· Network access user—User who accesses network resources through the device.

The switch supports only the device management users.

Configurable local user attributes are:

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

· User group.

Each local user belongs to a local user group and bears all attributes of the group, such as 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 rights that a user has after passing local authentication. Authorization attributes include the ACL, idle cut function, user role, VLAN, and FTP/SFTP work directory. For support information about authorization attributes, see "Configuring local user attributes."

Every configurable authorization attribute has its definite application environments and purposes. When you configure authorization attributes for a local user, consider which attributes are needed and which are not.

You can configure an authorization attribute in user group view or local user view to make the attribute effective for all local users in the group or for only the local user. The setting of an authorization attribute in local user view takes precedence over that in user group view.

· Password control attributes.

Password control attributes help you control password security for device management users. Password control attributes include password aging time, minimum password length, and password composition policy.

You can configure a password control attribute in system view, user group view, or local user view, making the attribute effective for all local users, local users in a group, or only the local user. 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
(Optional.) Displaying and maintaining local users and local user groups

Configuring local user attributes

Follow these guidelines when you configure local user attributes:

· When the password control feature is globally enabled by using the password-control enable command, local user passwords are not displayed.

· The authentication mode of user interfaces is set by the authentication-mode command, and affects the commands available for login users. In AAA (scheme) mode, the authorized user role determines the commands available for each login user. In password (password) or no authentication (none) mode, the user role of respective user interfaces determines the commands available for the login users. The user role of respective user interfaces also determines the commands available for the public key authenticated SSH users. For more information about the authentication mode and user roles for user interfaces, see Fundamentals Configuration Guide.

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

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 \| network } ]	By default, no local user exists. The network keyword does not take effect.
3. (Optional.) Configure a password for the local user.	password [ { hash \| simple } password ]	Device management user passwords are encrypted with the hash algorithm and saved in cipher text. A local user with no password configured directly passes authentication after providing the valid local username and attributes. To enhance security, configure a password for each local user.
4. Assign services for the local user.	service-type { dvpn \| ftp \| lan-access \| { pad \| ssh \| telnet \| terminal } * \| portal \| ppp }	By default, no service is authorized to a local user. The keywords dvpn, lan-access, pad, portal, and ppp do not take effect.
5. (Optional.) Place the local user to the active or blocked state.	state { active \| block }	By default, a created local user is in active state and can request network services.
6. (Optional.) Configure authorization attributes for the local user.	authorization-attribute { acl acl-number \| callback-number callback-number \| idle-cut minute \| user-profile profile-name \| user-role role-name \| vlan vlan-id \| work-directory directory-name } *	By default, no authorization attribute is configured for a local user. For Telnet and terminal users, only the setting for user-role takes effect. For SSH and FTP users, only the settings for user-role and work-directory take effect. For other types of local users, no authorization attribute takes effect. The acl, call-number, and user-profile keywords do not take effect.
7. (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 ]	Optional. By default, the local user uses password control attributes of the user group to which the local user belongs.
8. (Optional.) Assign the local user to a user group.	group group-name	By default, a local user belongs to the default user group system.

Configuring user group attributes

User groups simplify local user configuration and management. A user group comprises 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 newly added local user belongs to the default user group system and bears all attributes of the group. To assign a local user to a different user group, use the user-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 its view.	user-group group-name	By default, there is a system predefined user group named system, which is the default user group.
3. Configure authorization attributes for the user group.	authorization-attribute { acl acl-number \| callback-number callback-number \| idle-cut minute \| user-profile profile-name \| vlan vlan-id \| work-directory directory-name } *	By default, no authorization attribute is configured for a user group. The call-number and user-profile keywords do not take effect.
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 ]	Optional. By default, the user group uses global settings, including a 90-day password aging time, a minimum password length of 10 characters, and at least one password composition type and at least one character required for each password composition type. For more information about password control commands, see Security Command Reference.

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 \| network } \| idle-cut { disable \| enable } \| service-type { dvpn \| ftp \| lan-access \| pad \| portal \| ppp \| ssh \| telnet \| terminal } \| state { active \| block } \| user-name user-name \| vlan vlan-id ]
Display the user group configuration.	display user-group [ group-name ]

Configuring RADIUS schemes

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

Configuration task list

Tasks at a glance

(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 a VPN for the scheme

(Optional.) Setting the username format

(Optional.) Setting the maximum number of RADIUS request transmission attempts

(Optional.) Setting the status of RADIUS servers

(Optional.) Specifying the source IP address for outgoing RADIUS packets

(Optional.) Setting RADIUS timers

(Optional.) Configuring the accounting-on feature

(Optional.) Displaying and maintaining RADIUS

Creating a RADIUS scheme

Create a RADIUS scheme before performing any other RADIUS configurations. You can configure up to 16 RADIUS schemes. A RADIUS scheme can be referenced 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 its view.	radius scheme radius-scheme-name	By default, no RADIUS scheme is defined.

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 up to 16 secondary authentication servers for a RADIUS scheme. When the primary server is not available, the device tries to communicate with the secondary servers in the order they are configured, and communicates with the first secondary server in active state. If redundancy is not needed, 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.

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 \| vpn-instance vpn-instance-name ] * · Specify a secondary RADIUS authentication server: secondary authentication { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| vpn-instance vpn-instance-name ] *	Configure at least one command. By default, no authentication server is specified. Two authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN.

Specifying the RADIUS accounting servers and the relevant parameters

You can specify one primary accounting server and up to 16 secondary accounting servers for a RADIUS scheme. When the primary server is not available, the device tries to communicate with the secondary servers in the order they are configured, and communicates with the first secondary server in active state. When 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.

When the device receives a connection teardown request from a host or a connection teardown command from an administrator, it sends a stop-accounting request to the accounting server. When the maximum number of real-time accounting attempts is reached, the device disconnects users who have no accounting responses.

RADIUS does not support accounting for FTP 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 ] * · Specify a secondary RADIUS accounting server: secondary accounting { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| vpn-instance vpn-instance-name ] *	Configure at least one command. By default, no accounting server is specified. Two accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN.
4. (Optional.) Set the maximum number of real-time accounting attempts.	retry realtime-accounting retry-times	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. They 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, and 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. The shared key configured on the device must be the same as that configured on the RADIUS server.

Specifying a VPN for the scheme

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

To specify a VPN 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 for the RADIUS scheme.	vpn-instance vpn-instance-name	By default, a RADIUS scheme belongs to the public network.

Setting the username format

A username is usually in the format userid@isp-name, where isp-name represents the user's ISP domain name. By default, the ISP domain name is included in a username. However, some earlier RADIUS servers do 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 you want two or more ISP domains to reference the same RADIUS scheme, configure that RADIUS scheme to keep the ISP domain name in usernames for domain identification.

To set the username format 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.

Setting the maximum number of RADIUS request transmission attempts

RADIUS uses UDP packets to transfer data. UDP communication is not reliable. To improve reliability, RADIUS uses a retransmission mechanism. If a NAS sends a RADIUS request to a RADIUS server but receives no response before the response timeout timer (defined by the timer response-timeout command) expires, it retransmits the request. If the number of transmission attempts exceeds the specified limit but it still receives no response, it tries to communicate with other RADIUS servers in active state. If no other servers are in active state at the time, it considers the authentication or accounting attempt a failure. For more information about the RADIUS server response timeout timer, see "Setting RADIUS timers."

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 retry-times	The default setting is 3.

Setting the status of RADIUS servers

By setting the status of RADIUS servers to blocked or active, you can control the RADIUS servers with which the device communicates when the current servers are no longer available. In practice, you can specify one primary RADIUS server and multiple secondary RADIUS servers, with the secondary servers functioning as the backup of the primary servers. Typically, the device chooses servers based on these rules:

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

If the primary server fails, the device changes the server's status to blocked, starts a quiet timer for the server, and tries to communicate with a secondary server in active state (a secondary server configured earlier has a higher priority).

If the secondary server is unreachable, the device changes the server's status to blocked, starts a quiet timer for the server, and continues to check the next secondary server in active state. This search process continues until the device finds an available secondary server or has checked all secondary servers in active state.

If the quiet timer of a server expires or an authentication or accounting response is received from the server, the status of the server changes back to active automatically, but the device does not check the server again during the authentication or accounting process.

If no server is found reachable during one search process, the device considers the authentication or accounting attempt a failure.

· If you remove an authentication or accounting server in use, the communication of the device with the server soon times out, and the device looks for a server in active state by first checking the primary server and then secondary servers in the order they are configured.

· When the primary server and secondary servers are all in blocked state, the device does not communicate with any server.

· If one server is in active state and all the others are in blocked state, the device only tries to communicate with the server in active state, even if the server is unavailable.

· After receiving an authentication/accounting response from a server, the device changes the status of the server identified by the source IP address of the response to active if the current status of the server is blocked.

By default, the device sets the status of all RADIUS servers to active. In some cases, however, 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.

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 [ ip-address [ port-number \| vpn-instance vpn-instance-name ] * ] { active \| block } · Set the status of a secondary RADIUS accounting server: state secondary accounting [ ip-address [ port-number \| vpn-instance vpn-instance-name ] * ] { active \| block }	Configure at least one command. By default, every server specified in a RADIUS scheme 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.

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 yes, the server processes the packet. If not, 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. In some cases, however, you must change the source IP address. For example, if the NAS is configured with VRRP for stateful failover, the source IP address of outgoing RADIUS packets can be the virtual IP address of the uplink VRRP group.

You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view for a specific RADIUS scheme, or in system view for all RADIUS schemes whose 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 IP address of the RADIUS packet outbound interface is used as the source IP address.

To specify a source IP address for a specific 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 the system view is used. If no source IP address is specified, the IP address of the RADIUS packet outbound interface is used.

Setting RADIUS timers

The device uses the following types of timers to control the 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 receives no 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's 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. To implement real-time accounting, the device must periodically send real-time accounting packets to the accounting server for online users. If the device receives no response from the server, it tears down the user connection forcibly.

When you set RADIUS timers, follow these guidelines:

· When you configure the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout timer, consider the number of secondary servers. If the retransmission process takes too much time, the client connection in the access module such as the Telnet module might time out while the device is trying to find an available server.

· When a number of secondary servers are configured, the client connections of access modules that have a short client connection timeout period might still be timed out during initial authentication or accounting, even if the packet transmission attempt limit and server response timeout period are configured with small values. In this case, the next authentication or accounting attempt can succeed because the device has set the status of the unreachable servers to blocked so time for finding a reachable server is shortened.

· Set the server quiet timer properly. Too short a quiet timer can result in frequent authentication or accounting failures because the device keeps trying to communicate with an unreachable server that is in active state.

· Different real-time accounting intervals impose different performance requirements on the NAS and the RADIUS server. A shorter interval helps achieve higher accounting precision but requires higher performance. Use a longer interval when there are a large number of users (1000 or more).

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 minutes	The default setting is 12 minutes.

Configuring the accounting-on feature

The accounting-on feature enables the device to send an accounting-on packet to the RADIUS server after it reboots so the server can log out users who logged in through the device before the reboot. Without this feature, users who were online before the reboot could not re-log in after the reboot, because the RADIUS server would consider them already online.

If the device receives no response to the accounting-on packet, it resends the packet to the RADIUS server at a particular interval for a specified number of times.

The accounting-on feature requires the cooperation of the H3C IMC network management system.

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 seconds \| send send-times ] *	By default, the accounting-on feature is disabled.

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 a VPN for the scheme

(Optional.) Setting the username format

(Optional.) Specifying the source IP address for outgoing HWTACACS packets

(Optional.) Setting HWTACACS timers

(Optional.) Displaying and maintaining HWTACACS

Creating an HWTACACS scheme

Create an HWTACACS scheme before performing any other HWTACACS configurations. You can configure up to 16 HWTACACS schemes. A HWTACACS scheme can be referenced 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 its view.	hwtacacs scheme hwtacacs-scheme-name	By default, no HWTACACS scheme is defined.

Specifying the HWTACACS authentication servers

You can specify one primary authentication server and up to 16 secondary authentication servers for an HWTACACS scheme. When the primary server is not available, the device tries to communicate with the secondary servers in the order they are configured, and communicates with the first secondary server in active state. If no redundancy is needed, 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 \| vpn-instance vpn-instance-name ] * · Specify a secondary HWTACACS authentication server: secondary authentication { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| vpn-instance vpn-instance-name ] *	Configure at least one command. By default, no authentication server is specified. Two HWTACACS authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN.

Specifying the HWTACACS authorization servers

You can specify one primary authorization server and up to 16 secondary authorization servers for an HWTACACS scheme. When the primary server is not available, the device tries to communicate with the secondary servers in the order they are configured, and communicates with the first secondary server in active state. If no redundancy is needed, 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 \| vpn-instance vpn-instance-name ] * · Specify a secondary HWTACACS authorization server: secondary authorization { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| vpn-instance vpn-instance-name ] *	Configure at least one command. By default, no authorization server is specified. Two HWTACACS authorization servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN.

Specifying the HWTACACS accounting servers

You can specify one primary accounting server and up to 16 secondary accounting servers for an HWTACACS scheme. When the primary server is not available, the device tries to communicate with the secondary servers in the order they are configured, and communicates with the first secondary server in active state. If no redundancy is needed, 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 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 \| vpn-instance vpn-instance-name ] * · Specify a secondary HWTACACS accounting server: secondary accounting { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| vpn-instance vpn-instance-name ] *	Configure at least one command. By default, no accounting server is specified. Two HWTACACS accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN.

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. They must use the same key for each type of communication

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. The shared key configured on the device must be the same as that configured on the HWTACACS server.

Specifying a VPN for the scheme

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

To specify a VPN 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 for the HWTACACS scheme.	vpn-instance vpn-instance-name	By default, an HWTACACS scheme belongs to the public network.

Setting the username format

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

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

To set the username format:

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.

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. Upon receiving an HWTACACS packet, an HWTACACS server checks whether the source IP address of the packet is the IP address of a managed NAS. If yes, the server processes the packet. If not, the server drops the packet.

The source address of outgoing HWTACACS packets is typically the IP address of an egress interface on the NAS to communicate with the HWTACACS server. In some cases, however, you must change the source IP address. For example, if the NAS is configured with the VRRP for stateful failover, the source IP address of outgoing HWTACACS packets can be the virtual IP address of the uplink VRRP group.

You can specify the source IP address for outgoing HWTACACS packets in HWTACACS scheme view for a specific HWTACACS scheme, or in system view for all HWTACACS schemes whose 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 IP address of the HWTACACS packet outbound interface is used as the source IP address.

To specify a source IP address for a specific HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Specify a source IP address for outgoing HWTACACS packets.	nas-ip { ipv4-address \| ipv6 ipv6-address }	By default, the IP address of the HWTACACS packet outbound interface is used as the source IP address.

Setting HWTACACS timers

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

· Server response timeout timer (response-timeout)—Defines the HWTACACS request retransmission interval. The timer starts immediately after an HWTACACS authentication, authorization, or accounting request is sent. If the device receives no response from the 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 a server is not reachable, the device changes the server's 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 updates to the HWTACACS accounting server for online users. To implement real-time accounting, the device must periodically send real-time accounting packets to the accounting server for online users.

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. This command is not supported in the current software version and is reserved for future support.
4. Set the server quiet timer.	timer quiet minutes	By default, the server quiet timer is 5 minutes.
5. Set the real-time accounting interval.	timer realtime-accounting minutes	By default, the real-time accounting interval is 12 minutes. Consider the performance of the NAS and the HWTACACS server when you set the real-time accounting interval. A shorter interval requires higher performance.

Displaying and maintaining HWTACACS

Execute the display command in any view and the reset command in user view.

Purpose	Command
Display the configuration or server statistics of HWTACACS schemes.	display hwtacacs scheme [ hwtacacs-server-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 referencing configured AAA schemes in ISP domain view. Each ISP domain has a set of system predefined 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 predefined AAA methods for users in the domain.

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 and HWTACACS schemes as described in "Configuring RADIUS schemes," "Configuring HWTACACS schemes."

Creating an ISP domain

In a networking scenario with multiple ISPs, the device can connect to users of different ISPs, and 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 ISP domains, and configure AAA methods and domain attributes for each ISP domain as needed.

The device can accommodate up to 16 ISP domains, including the system predefined 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 provides no ISP domain name at login, the device considers the user belongs to the default ISP domain.

To delete the ISP domain functioning as the default ISP domain, change it to a non-default ISP domain by using the undo domain default enable command.

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	N/A
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 predefined ISP domain system.

Configuring ISP domain attributes

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

· Domain status:

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

· Maximum number of online users:

The device controls the number of online users in a domain to ensure the system performance and service reliability.

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. (Optional.) Place the ISP domain to the 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. (Optional.) Specify the maximum number of online users in the ISP domain.	access-limit enable max-user-number	By default, there is no limit to the maximum number of online users.

Configuring authentication methods for an ISP domain

Configuration prerequisites

Before configuring authentication methods, complete the following tasks:

1. For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme to be referenced first. The local and none authentication methods do not require a scheme.

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

3. Determine whether to configure the default authentication method for all access types or service types. The default authentication method applies to all access users, but has a lower priority than the specific authentication method configured for an access type or service type.

Configuration guidelines

When configuring authentication methods, follow these guidelines:

· If you configure an authentication method that references a RADIUS scheme and an authorization method that does not reference a RADIUS scheme, AAA accepts only the authentication result from the RADIUS server. The Access-Accept message from the RADIUS server also carries the authorization information, but the device ignores the information.

· To specify a scheme for user role switching authentication, make sure the user role is in the format of level-n. If an HWTACACS scheme is specified, the device uses the entered username for role switching authentication. If a RADIUS scheme is specified, the device uses the username $enabn$ on the RADIUS server for role switching authentication, where n is the same as that in the target user role level-n.

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 the default authentication method for all types of users.	authentication default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| ldap-scheme ldap-scheme-name [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default authentication method is local. The ladp-scheme keyword does not take effect.
4. Specify the authentication method for login users.	authentication login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] ldap-scheme ldap-scheme-name [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default authentication method is used for login users. The ladp-scheme keyword does not take effect.
5. Specify the user role switching authentication method.	authentication super { hwtacacs-scheme hwtacacs-scheme-name \| radius-scheme radius-scheme-name } *	By default, the default authentication method is used for user role switching authentication.

Configuring authorization methods for an ISP domain

Configuration prerequisites

Before configuring authorization methods, complete the following tasks:

1. For HWTACACS authorization, configure the HWTACACS scheme to be referenced.

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

3. Determine whether to configure the default authorization method for all access types or service types. The default authorization method applies to all access users, but has a lower priority than the specific authorization method configured for an access type or service type.

Configuration guidelines

When configuring authorization methods, follow these guidelines:

· The device supports HWTACACS authorization.

· To configure RADIUS authorization, also configure RADIUS authentication, and reference the same RADIUS scheme for RADIUS authentication and authorization. If the RADIUS authorization configuration is invalid or RADIUS authorization fails, the RADIUS authentication also fails. If RADIUS authorization fails, the server sends an error message to the NAS, indicating that the server itself is not responding.

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 the default authorization method 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.
4. Specify the command authorization method.	authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local [ none ] \| local [ none ] \| none }	By default, the default authorization method is used for command authorization.
5. Specify the authorization method 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 method is used for login users.

Configuring accounting methods for an ISP domain

Configuration prerequisites

Before configuring accounting methods, complete the following tasks:

1. For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be referenced first. The local and none accounting methods do not require a scheme.

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

3. Determine whether to configure the default accounting method for all access types or service types. The default accounting method applies to all access users, but has a lower priority than the specific accounting method configured for an access type or service type.

Configuration guidelines

When configuring accounting methods, follow these guidelines:

· Login users who use FTP services do not support accounting.

· Local accounting does not provide statistics for charging. It only counts and controls the number of concurrent users who use the same local user account. The threshold is configured by using the access-limit enable 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 the default accounting method 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.
4. Specify the command accounting method.	accounting command hwtacacs-scheme hwtacacs-scheme-name	By default, the default accounting method is used for command accounting.
5. Specify the accounting method 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 method is used for login users.

Enabling the session-control feature

A RADIUS server running on IMC can send a dynamic authorization change request or a disconnect request by using a session-control packet. This task enables the device to receive RADIUS session-control packets on UDP port 1812.

To enable the session-control feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the session-control feature.	radius session-control enable	By default, the session-control feature is disabled.

Displaying and maintaining AAA

Execute the display command in any view.

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

AAA for SSH users by an HWTACACS server

By default, Ethernet interfaces, VLAN interfaces, and aggregate interfaces are in DOWN state. To configure such an interface, use the undo shutdown command to bring it up first.

Network requirements

As shown in Figure 10, configure the switch to use the HWTACACS server for SSH user authentication, authorization, and accounting, and to assign the default user role network-operator to SSH users after they pass authentication.

Set the shared keys for secure HWTACACS communication to expert. Configure the switch to send usernames without domain names to the HWTACACS server.

Figure 10 Network diagram

Configuration procedure

1. Configure the HWTACACS server:

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

2. Configure the switch:

# Assign IP addresses to 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 for secure HWTACACS communication to expert in plain text.

[Switch-hwtacacs-hwtac] key authentication simple expert

[Switch-hwtacacs-hwtac] key authorization simple expert

[Switch-hwtacacs-hwtac] key accounting simple expert

# Remove domain names from the usernames sent to an HWTACACS server.

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

[Switch-hwtacacs-hwtac] quit

# Create an ISP domain and configure AAA methods for 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 key pairs.

[Switch] public-key local create rsa

The range of public key size 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...

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

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

..++++++++

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

# Enable the SSH service.

[Switch] ssh server enable

# Enable the default-user-role authorization function, so that an SSH user gets the default user role network-operator after passing authentication.

[Switch] role default-role enable

3. Verify the configuration:

When the user initiates an SSH connection to the switch and enter the correct username and password, the user successfully logs in and can use the commands for the network-operator user role.

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

By default, Ethernet interfaces, VLAN interfaces, and aggregate interfaces are in DOWN state. To configure such an interface, use the undo shutdown command to bring it up first.

Network requirements

As shown in Figure 11, configure the switch to perform local authentication for SSH servers, use the HWTACACS server and RADIUS server for SSH user authorization and accounting respectively, and to 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 for secure communication with the HWTACACS server and RADIUS server to expert. Configure the switch to remove domain names from usernames sent to the servers.

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:

# Assign IP addresses to interfaces. (Details not shown.)

# Create local RSA key pairs.

<Switch> system-view

[Switch] public-key local create rsa

The range of public key size 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...

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

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

..++++++++

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

# Enable the SSH service.

[Switch] ssh server enable

# 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 for the local user.

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

# Set a password for the local user to hello in plain text.

[Switch-luser-manage-hello] password simple hello

[Switch-luser-manage-hello] quit

# Create ISP domain bbb and configure AAA methods for login users.

[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 authorization function, so that an SSH user gets the default user role network-operator after passing authentication.

[Switch] role default-role enable

4. Verify the configuration:

When the user initiates an SSH connection to the switch and enter the username hello@bbb and the correct password, the user successfully logs in and can use the commands for the network-operator user role.

Authentication and authorization for SSH users by a RADIUS server

By default, Ethernet interfaces, VLAN interfaces, and aggregate interfaces are in DOWN state. To configure such an interface, use the undo shutdown command to bring it up first.

Network requirements

As shown in Figure 12, the RADIUS authentication and authorization server runs on IMC.

Configure the switch to use the RADIUS server for SSH user authentication and authorization and add an account with the username hello@bbb on the RADIUS server, so that the SSH user can log in to the switch and is authorized with the network-operator user role after login.

Set the shared keys for secure RADIUS communication to expert, and set the ports for authentication and accounting to 1812 and 1813, respectively. Configure the switch to include the domain name in the username sent to the RADIUS server.

Figure 12 Network diagram

Configuration procedure

1. Configure the RADIUS server on IMC 5.0:

NOTE:

This example assumes that 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, which is chosen in this 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:

# Assign an IP address to VLAN-interface 2, the SSH user access interface.

<Switch> system-view

[Switch] interface vlan-interface 2

[Switch-Vlan-interface2] ip address 192.168.1.70 255.255.255.0

[Switch-Vlan-interface2] quit

# Assign an IP address to VLAN-interface 3, through which the switch communicates with the server.

[Switch] interface vlan-interface 3

[Switch-Vlan-interface3] ip address 10.1.1.2 255.255.255.0

[Switch-Vlan-interface3] quit

# Create local RSA and DSA key pairs, and enable the SSH service.

[Switch] public-key local create rsa

The range of public key size 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...

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

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

..++++++++

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

[Switch] public-key local create dsa

The range of public key size 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...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

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

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

[Switch] ssh server enable

# Enable the default-user-role authorization function, so that an SSH user gets the default user role network-operator after passing authentication.

[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 for secure communication with the server to expert in plain text.

[Switch-radius-rad] key authentication simple expert

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

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

[Switch-radius-rad] quit

# Create ISP domain bbb and configure authentication and authorization 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] quit

3. Verify the configuration:

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 format userid@isp-name, 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

Check that:

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

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

Check that:

· The link between the NAS and the RADIUS server work 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.

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

Check that:

· The accounting port number is correctly configured.

· The accounting server IP address is correctly configured on the NAS.

Troubleshooting HWTACACS

Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS."

10-Security Configuration Guide

Client/server model

Information exchange security mechanism

User authentication mechanisms

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

Creating an HWTACACS scheme

Specifying the shared keys for secure HWTACACS communication

Specifying a VPN for the scheme

Creating an ISP domain

Configuration prerequisites

Configuration guidelines

Configuration procedure

Configuration prerequisites

Configuration guidelines

Configuration procedure

Configuration prerequisites

Configuration procedure

AAA for SSH users by an HWTACACS server

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Troubleshooting RADIUS

RADIUS authentication failure

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us