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

· Authentication—Identifies users and determines whether a user is valid.

· Authorization—Grants different users different rights and controls their access to resources and services. For example, a user who has successfully logged in to the device can be granted read and print permissions to the files on the device.

· Accounting—Records all network service usage information of users, including the service type, start time, and traffic. The accounting function not only provides the information required for charging, but also allows for network security surveillance.

AAA usually uses a client/server model. The client runs on the network access server (NAS), which is also referred to as the access device. The server maintains user information centrally. In an AAA network, a NAS is a server for users but a client for the AAA servers. See Figure 1.

Figure 1 Network diagram for AAA

When a user tries to log in to the NAS, use network resources, or access other networks, the NAS authenticates the user. The NAS can transparently pass the user’s authentication, authorization, and accounting information to the servers. The RADIUS and HWTACACS protocols define how a NAS and a remote server exchange user information between them.

In the network shown in Figure 1, there is a RADIUS server and an HWTACACS server. You can choose different servers for different security functions. For example, you can use the HWTACACS server for authentication and authorization, and the RADIUS server for accounting.

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

AAA can be implemented through multiple protocols. The device supports using RADIUS and HWTACACS. RADIUS is often used in practice.

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 where both high security and remote user access are required.

RADIUS uses UDP as the transport protocol. It 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. RADIUS provides access authentication and authorization services, and its accounting function collects and records network resource usage information.

Client/server model

The RADIUS client runs on the NASs located throughout the network. It passes user information to designated RADIUS servers and acts on the responses (for example, rejects or accepts 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 listens to connection requests, authenticates users, and returns user access control information (for example, rejecting or accepting the user access request) to the clients.

In general, the RADIUS server maintains the following databases: Users, Clients, and Dictionary. See Figure 2.

Figure 2 RADIUS server components

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

Security and authentication mechanisms

RADIUS uses a shared key that is never transmitted over the network to authenticate information exchanged between a RADIUS client and the RADIUS server, enhancing the information exchange security. In addition, to prevent user passwords from being intercepted on insecure networks, RADIUS encrypts passwords before transmitting them.

A RADIUS server supports multiple user authentication methods, such as the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP) of the Point-to-Point Protocol (PPP). Moreover, a RADIUS server can act as the client of another AAA server to provide authentication proxy services.

RADIUS basic message exchange process

Figure 3 illustrates the interaction between the host, the RADIUS client, and the RADIUS server.

Figure 3 RADIUS basic message exchange process

RADIUS operates in the following manner:

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

2. Having received the username and password, the RADIUS client sends an authentication request (Access-Request) to the RADIUS server, with the user password encrypted by using the Message-Digest 5 (MD5) algorithm and the shared key.

3. The RADIUS server authenticates the username and password. If the authentication succeeds, the server sends back an Access-Accept message containing the user’s authorization information. If the authentication fails, the server returns an Access-Reject message.

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

5. The RADIUS server returns a start-accounting response (Accounting-Response) and starts accounting.

6. The user accesses the network resources.

7. The host requests the RADIUS client to tear down the connection and the RADIUS client sends a stop-accounting request (Accounting-Request) to the RADIUS server.

8. The RADIUS server returns a stop-accounting response (Accounting-Response) and stops accounting for the user.

9. The user stops access to network resources.

RADIUS packet format

RADIUS uses UDP to transmit messages. To ensure smooth message exchange between the RADIUS server and the client, RADIUS uses a series of mechanisms, including the timer management 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:

1. The Code field (1 byte long) indicates the type of the RADIUS packet. Table 1 gives the possible 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 the 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.

2. The Identifier field (1 byte long) is used to match request packets and response packets and to detect duplicate request packets. Request and response packets of the same type have the same identifier.

3. The Length field (2 bytes long) indicates the length of the entire packet, including the Code, Identifier, Length, Authenticator, and Attribute 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 value of this field is in the range 20 to 4096.

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

5. The Attributes field, variable in length, carries authentication, authorization, and accounting information that defines the configuration details of the request or response. This field may contain multiple attributes, each with three sub-fields: Type, Length, and Value.

· Type (1 byte long)—Indicates the type of the attribute. It is in the range 1 to 255. See Table 2 for commonly used attributes for RADIUS authentication, authorization and accounting.

· Length (1 byte long)—Indicates the length of the attribute in bytes, including the Type, Length, and Value fields.

· Value (up to 253 bytes)—Value of the attribute. Its format and content depend on the Type and Length fields.

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

NOTE:

· The attribute types listed in Table 2 are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868.

· For more information about commonly used standard RADIUS attributes, see “Commonly used standard RADIUS attributes.“

Extended RADIUS attributes

The RADIUS protocol features excellent extensibility. Attribute 26 (Vendor-Specific), an attribute defined by 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 type-length-value (TLV) format in RADIUS packets for extension of applications. As shown in Figure 5, a sub-attribute encapsulated in Attribute 26 consists of the following parts:

· Vendor-ID—Indicates the ID of the vendor. Its most significant byte is 0; the other three bytes contains a code that is compliant to RFC 1700. The vendor ID of H3C is 2011. For more information about the proprietary RADIUS sub-attributes of H3C, see “Proprietary RADIUS sub-attributes of H3C.“

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

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

· Vendor-Data—Indicates the contents of the sub-attribute.

Figure 5 Segment of a RADIUS packet containing an extended attribute

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 Point-to-Point Protocol (PPP) users, Virtual Private Dial-up Network (VPDN) users, 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 the usernames and passwords of the users to the HWTACACS sever for authentication. After passing authentication and being authorized, the users log in to the device and performs operations, and the HWTACACS server records the operations that each user performs.

Differences between HWTACACS and RADIUS

HWTACACS and RADIUS both provide authentication, authorization, and accounting services. They have many features in common, such as using a client/server model, using shared keys for user information security, and providing flexibility and extensibility. Table 3 lists the 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. Which commands a user can use depends on both the user level and the AAA authorization. A user can use only commands that are at, or lower than, the user level and authorized by the HWTACACS server.	Does not support authorization of configuration commands. Which commands a user can use solely depends on the level of the user. A user can use all the commands at, or lower than, the user level.

HWTACACS basic message exchange process

The following takes a Telnet user as an example to describe how HWTACACS performs user authentication, authorization, and accounting.

Figure 6 HWTACACS basic message exchange process for a Telnet user

Here is the process:

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 inputs 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 inputs 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. The HWTACACS server sends back an authentication response to indicate that the user has passed authentication.

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

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

14. Knowing that the user is now authorized, the HWTACACS client pushes its configuration interface to the user.

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.

Domain-based user management

A NAS manages users based on Internet service provider (ISP) domains. On a NAS, each user belongs to one ISP domain. A NAS determines the ISP domain a user belongs to by the username entered by the user at login, as shown in Figure 7.

Figure 7 Determine the ISP domain of a user by the username

The authentication, authorization, and accounting of a user depends on the AAA methods configured for the domain that the user belongs to. If no specific AAA methods are configured for the domain, the default methods are used. By default, a domain uses local authentication, local authorization, and local accounting.

AAA allows you to manage users based on their access types:

· LAN users—Users on a LAN who must pass 802.1X or MAC address authentication to access the network.

· Login users—Users who want to log in to the device, including SSH users, Telnet users, FTP users, and terminal users.

In addition, AAA 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 for the user, ensuring that login users execute only commands they are authorized to execute. For more information about command authorization, see the Fundamentals Configuration Guide.

· Command accounting—Allows the accounting server to record all commands executed on the device or all authorized commands successfully executed. For more information about command accounting, see the Fundamentals Configuration Guide.

· Level switching authentication—Allows the authentication server to authenticate users who perform privilege level switching. As long as passing level switching authentication, users can switch their user privilege levels, without logging out and disconnecting current connections. For more information about user privilege level switching, see the Fundamentals Configuration Guide.

You can configure different authentication, authorization, and accounting methods for different users in a domain. See “Configuring AAA methods for ISP domains.“

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, present only in Access-Request packets in PAP authentication mode.
3	CHAP-Password	Digest of the user password for CHAP authentication, present only in Access-Request packets in CHAP authentication mode.
4	NAS-IP-Address	IP address for the server to identify a client. Usually, a client is identified by the IP address of the access interface of the NAS, namely the NAS IP address. This attribute is present in only 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	Maximum transmission unit (MTU) for the data link between the user and NAS. For example, with 802.1X EAP authentication, NAS uses this attribute to notify the server of the MTU for EAP packets, so as to avoid oversized EAP packets.
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 duration of service to be provided to 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	Identification of the user that the NAS sends to the server. For the LAN access service provided by an H3C device, this attribute carries the MAC address of the user in the format HHHH-HHHH-HHHH.
32	NAS-Identifier	Identification that the NAS uses for indicating itself.
40	Acct-Status-Type	Type of the Accounting-Request packet. Possible values are as follows: · 1—Start · 2—Stop · 3—Interim-Update · 4—Reset-Charge · 7—Accounting-On (Defined in 3GPP, the 3rd Generation Partnership Project) · 8—Accounting-Off (Defined in 3GPP) · 9 to 14—Reserved for tunnel accounting · 15—Reserved for failed
45	Acct-Authentic	Authentication method used by the user. Possible values are as follows: · 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 are as follows: · 15—Ethernet · 16—Any type of ADSL · 17—Cable (with cable for cable TV) · 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 for encapsulating EAP packets to allow the NAS to authenticate dial-in users via EAP without having to understand the EAP protocol.
80	Message-Authenticator	Used for authentication and checking of authentication packets to prevent spoofing Access-Requests. This attribute is used when RADIUS supports EAP authentication.
87	NAS-Port-Id	String for describing the port of the NAS that is authenticating the user.

Proprietary RADIUS sub-attributes of H3C

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	Remaining, available total traffic of the connection, in different units for different server types.
20	Command	Operation for the session, used for session control. It can be: · 1—Trigger-Request · 2—Terminate-Request · 3—SetPolicy · 4—Result
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 may take the same value. The client response of a retransmitted packet must also carry this attribute and the value of the attribute must be the same. For Accounting-Request packets of the start, stop, and interim update types, the Control-Identifier attribute, if present, makes no sense.
25	Result_Code	Result of the Trigger-Request or SetPolicy operation. A value of zero means the operation succeeded; any other value means the operation failed.
26	Connect_ID	Index of the user connection
28	Ftp_Directory	Working directory of the FTP user. For an FTP user, when the RADIUS client acts as the FTP server, this attribute is used to set the FTP directory on the RADIUS client.
29	Exec_Privilege	Priority of the EXEC user
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 needs to be sent from the server to the client transparently
62	User_HeartBeat	Hash value assigned after an 802.1X user passes authentication, which is a 32-byte string. This attribute is stored in the user list on the device and is used for verifying the handshake messages from the 802.1X user. This attribute exists in only Access-Accept and Accounting-Request packets.
201	Input-Interval-Octets	Bytes input within a real-time accounting interval
202	Output-Interval-Octets	Bytes output within a real-time accounting interval
203	Input-Interval-Packets	Packets input within an accounting interval, in the unit set on the device
204	Output-Interval-Packets	Packets output within an accounting interval, in the unit set on the device
205	Input-Interval-Gigawords	Result of bytes input within an accounting interval divided by 4G bytes
206	Output-Interval-Gigawords	Result of bytes output within an accounting interval divided by 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, you must 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 of the users to be authenticated.

· Remote authentication—Configure the required RADIUS and HWTACACS schemes. You must configure user attributes on the servers accordingly.

2. Configure AAA methods for the users’ ISP domains.

· Authentication method—No authentication (none), local authentication (local), or remote authentication (scheme)

· Authorization method—No authorization (none), local authorization (local), or remote authorization (scheme)

· Accounting method—No accounting (none), local accounting (local), or remote accounting (scheme)

Figure 8 illustrates the configuration procedure.

Figure 8 AAA configuration procedure

Table 4 AAA configuration task list

Task		Remarks
Configuring AAA schemes	Configuring local users	Required Complete at least one task.
	Configuring RADIUS schemes
	Configuring HWTACACS schemes
Configuring AAA methods for ISP domains	Creating an ISP domain	Required
	Configuring ISP domain attributes	Optional
	Configuring AAA authentication methods for an ISP domain	Required Complete at least one task.
	Configuring AAA authorization methods for an ISP domain
	Configuring AAA accounting methods for an ISP domain
Tearing down user connections		Optional

NOTE:

To control access of login users by using AAA methods, you must configure the login authentication mode for the user interfaces as scheme. For more information about the configuration command, see the Fundamentals Command Reference.

Configuring AAA schemes

Configuring local users

To implement local user authentication, authorization, and accounting, you must 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 a username. Configurable local user attributes are as follows:

· Service type

The types of the 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, LAN access, SSH, Telnet, and Terminal.

· User state

Indicates whether or not a local user can request network services. There are two user states: active and blocked. A user in the active state can request network services, but a user in the blocked state cannot.

· Maximum number of users using the same local user account

Indicates how many users can use the same local user account for local authentication.

· Validity time and expiration time

Indicates the validity time and expiration time of a local user account. A user must use a valid local user account to pass local authentication. When some users need to access the network temporarily, you can create a guest account and specify a validity time and an expiration time for the account to control the validity of the account.

· User group

Each local user belongs to a local user group and bears all attributes of the group. For more information about local user group, see “Configuring user group attributes.“

· Binding attributes

Binding attributes are used for controlling the scope of users. They are checked during local authentication of a user. If the attributes of a user do not match the binding attributes configured for the local user account, the user cannot pass authentication. Binding attributes include the ISDN calling number, IP address, access port, MAC address, and native VLAN. For more information about binding attributes, see “Configuring local user attributes.“ Be cautious when deciding which binding attributes to configure for a local user.

· Authorization attributes

Authorization attributes indicate the rights that a user has after passing local authentication. Authorization attributes include the ACL, PPP callback number, idle cut function, user level, user role, user profile, VLAN, and FTP/SFTP work directory. For more information about authorization attributes, see “Configuring local user attributes.“

Every configurable authorization attribute has its definite application environments and purposes. When configuring authorization attributes for a local user, consider which attributes are needed and which are not. For example, for PPP users, you do not need to configure the work directory attribute.

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.

Local user configuration task list

Task	Remarks
Configuring local user attributes	Required
Configuring user group attributes	Optional
Displaying and maintaining local users and local user groups	Optional

Configuring local user attributes

Follow these steps to configure attributes for a local user:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Add a local user and enter local user view	local-user user-name	Required No local user exists by default.
Configure a password for the local user	password { cipher \| simple } password	Optional
Specify the service types for the local user	service-type { ftp \| lan-access \| { ssh \| telnet \| terminal } * }	Required By default, no service is authorized to a local user.
Place the local user to the state of active or blocked	state { active \| block }	Optional When created, a local user is in the active state by default, and the user can request network services.
Set the maximum number of concurrent users of the local user account	access-limit max-user-number	Optional By default, there is no limit to the maximum number of concurrent users of a local user account. The limit is effective only for local accounting, and is not effective for FTP users.
Configure the binding attributes for the local user	bind-attribute { call-number call-number [ : subcall-number ] \| ip ip-address \| location port slot-number subslot-number port-number \| mac mac-address \| vlan vlan-id } *	Optional By default, no binding attribute is configured for a local user. Binding attributes are only intended for PPP and LAN users.
Configure the authorization attributes for the local user	authorization-attribute { acl acl-number \| callback-number callback-number \| idle-cut minute \| level level \| user-profile profile-name \| user-role security-audit \| vlan vlan-id \| work-directory directory-name } *	Optional By default, no authorization attribute is configured for a local user. For PPP users, only acl, callback-number, idle-cut, and user-profile are supported. For LAN users, only acl, idle-cut, user-profile, and vlan are supported. For SSH and terminal users, only level is supported. For FTP users, only level and work-directory are supported. For Telnet users, only level and user-role is supported. For other types of local users, no binding attribute is supported.
Set the expiration time of the local user	expiration-date time	Optional Not set by default
Assign the local user to a user group	group group-name	Optional By default, a local user belongs to the default user group system.

NOTE:

· If the user interface authentication mode (set by the authentication-mode command in user interface view) is AAA (scheme), which commands a login user can use after login depends on the privilege level authorized to the user. If the user interface authentication mode is password (password) or no authentication (none), which commands a login user can use after login depends on the level configured for the user interface (set by the user privilege level command in user interface view). For an SSH user using public key authentication, which commands are available depends on the level configured for the user interface. For more information about user interface authentication mode and user interface command level, see the Fundamentals Configuration Guide.

· You can configure the user profile authorization attribute in local user view, user group view, and ISP domain view. The setting in local user view has the highest priority, and that in ISP domain view has the lowest priority. For more information about user profiles, see the chapter “User profile configuration.”

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. Configurable user attributes include authorization attributes.

By default, every newly added local user belongs to the system default user group system and bears all attributes of the group. To change the user group to which a local user belongs, use the user-group command in local user view.

Follow these steps to configure attributes for a user group:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a user group and enter user group view	user-group group-name	Required
Configure the authorization attributes for the user group	authorization-attribute { acl acl-number \| callback-number callback-number \| idle-cut minute \| level level \| user-profile profile-name \| vlan vlan-id \| work-directory directory-name } *	Optional By default, no authorization attribute is configured for a user group.

Displaying and maintaining local users and local user groups

To do…	Use the command…	Remarks
Display local user information (on a distributed device)	display local-user [ idle-cut { disable \| enable } \| service-type { ftp \| lan-access \| ssh \| telnet \| terminal } \| state { active \| block } \| user-name user-name \| vlan vlan-id ] [ slot slot-number ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the user group configuration information	display user-group [ group-name ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view

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. There may be authentication/authorization servers and accounting servers, or primary servers and secondary servers. The parameters include the IP addresses of the servers, the shared keys, and the RADIUS server type.

RADIUS scheme configuration task list

Task	Remarks
Creating a RADIUS scheme	Required
Specifying the RADIUS authentication/authorization servers	Required
Specifying the RADIUS accounting servers and the relevant parameters	Optional
Specifying the shared keys for RADIUS packets	Optional
Setting the maximum number of RADIUS request transmission attempts	Optional
Setting the supported RADIUS server type	Optional
Setting the status of RADIUS servers	Optional
Setting the username format and traffic statistics units	Optional
Specifying the source IP address for outgoing RADIUS packets	Optional
Setting timers for controlling communication with RADIUS servers	Optional
Configuring RADIUS accounting-on	Optional
Configuring the IP address of the security policy server	Optional
Configuring interpretation of RADIUS class attribute as CAR parameters	Optional
Enabling the trap function for RADIUS	Optional
Enabling the RADIUS listening port of the RADIUS client	Optional
Displaying and maintaining RADIUS	Optional

Creating a RADIUS scheme

Before performing other RADIUS configurations, follow these steps to create a RADIUS scheme and enter RADIUS scheme view:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a RADIUS scheme and enter RADIUS scheme view	radius scheme radius-scheme-name	Required No RADIUS scheme by default

To do…

Use the command…

Remarks

Enter system view

system-view

—

Create a RADIUS scheme and enter RADIUS scheme view

radius scheme radius-scheme-name

Required

No RADIUS scheme by default

NOTE:

A RADIUS scheme can be referenced by multiple ISP domains at the same time.

Specifying the RADIUS authentication/authorization servers

You can specify one primary authentication/authorization server and up to 16 secondary authentication/authorization servers for a RADIUS scheme so that the NAS can find a server for user authentication/authorization when using the scheme. When the primary server is not available, a secondary server is used, if any. In a scenario where redundancy is not required, specify only the primary server.

In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS clients. It is neither allowed nor needed to specify a separate RADIUS authorization server.

Follow these steps to specify RADIUS authentication/authorization servers for a RADIUS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Specify the primary RADIUS authentication/authorization server	primary authentication { ip-address [ port-number \| key string ] * \| ipv6 ipv6-address [ port-number \| key string ] * }	Required Configure at least one command. No authentication/authorization server is specified by default.
Specify the secondary RADIUS authentication/authorization server	secondary authentication { ip-address [ port-number \| key string ] * \| ipv6 ipv6-address [ port-number \| key string ] * }

NOTE:

· The IP addresses of the primary and secondary authentication/authorization servers for a scheme must be different from each other. Otherwise, the configuration will fail.

· All servers for authentication/authorization and accountings, primary or secondary, must use IP addresses of the same IP version.

· You can specify a RADIUS authentication/authorization server as the primary authentication/authorization server for one scheme and as the secondary authentication/authorization server for another scheme at the same time.

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, a secondary server is used, if any. When redundancy is not required, specify only the primary server.

By setting the maximum number of real-time accounting attempts for a scheme, you make the device disconnect users for whom no accounting response is received before the number of accounting attempts reaches the limit.

When the device receives a connection teardown request from a host or a connection teardown notification from an administrator, it sends a stop-accounting request to the accounting server. You can enable buffering of non-responded stop-accounting requests to allow the device to buffer and resend a stop-accounting request until it receives a response or the number of stop-accounting attempts reaches the configured limit. In the latter case, the device discards the packet.

Follow these steps to specify RADIUS accounting servers and set relevant parameters for a scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Specify the primary RADIUS accounting server	primary accounting { ip-address [ port-number \| key string ] * \| ipv6 ipv6-address } [ port-number \| key string ] * }	Required Configure at least one command. No accounting server is specified by default.
Specify the secondary RADIUS accounting server	secondary accounting { ip-address [ port-number \| key string ] * \| ipv6 ipv6-address } [ port-number \| key string ] * }
Set the maximum number of real-time accounting attempts	retry realtime-accounting retry-times	Optional 5 by default
Enable buffering of stop-accounting requests to which no responses are received	stop-accounting-buffer enable	Optional Enabled by default
Set the maximum number of stop-accounting attempts	retry stop-accounting retry-times	Optional 500 by default

NOTE:

· The IP addresses of the primary and secondary accounting servers must be different from each other. Otherwise, the configuration fails.

· All servers for authentication/authorization and accountings, primary or secondary, must use IP addresses of the same IP version.

· If you delete an accounting server that is serving users, the device can no longer send real-time accounting requests and stop-accounting requests for the users to that server, or buffer the stop-accounting requests.

· You can specify a RADIUS accounting server as the primary accounting server for one scheme and as the secondary accounting server for another scheme at the same time.

· RADIUS does not support accounting for FTP users.

Specifying the shared keys for RADIUS packets

The RADIUS client and RADIUS server use the MD5 algorithm to encrypt packets exchanged between them and use shared keys to authenticate the packets. They must use the same shared key for the same type of packets.

A shared 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 shared key configured individually for a RADIUS server.

Follow these steps to specify shared keys for authenticating RADIUS packets:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Specify a shared key for authenticating RADIUS authentication/authorization or accounting packets	key { accounting \| authentication } string	Required No shared key by default

NOTE:

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

Setting the maximum number of RADIUS request transmission attempts

Because RADIUS uses UDP packets to transfer data, the communication process is not reliable. RADIUS uses a retransmission mechanism to improve the reliability. If a NAS sends a RADIUS request to a RADIUS server but receives no response after 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 the active state. If no other servers are in the active state at the time, it considers the authentication or accounting attempt a failure. For more information about RADIUS server states, see “Setting the status of RADIUS servers.“

Follow these steps to set the maximum number of RADIUS request transmission attempts for a scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Set the maximum number of RADIUS request transmission attempts	retry retry-times	Optional 3 by default

NOTE:

· The maximum number of transmission attempts of RADIUS packets multiplied by the RADIUS server response timeout period cannot be greater than 75 seconds.

· For more information about the RADIUS server response timeout period, see “Setting timers for controlling communication with RADIUS servers.“

Setting the supported RADIUS server type

The supported RADIUS server type determines the type of the RADIUS protocol that the device uses to communicate with the RADIUS server. It can be standard or extended:

· Standard—Uses the standard RADIUS protocol, compliant to RFC 2865 and RFC 2866 or later.

· Extended—Uses the proprietary RADIUS protocol of H3C.

When the RADIUS server runs iMC, you must set the RADIUS server type to extended. When the RADIUS server runs third-party RADIUS server software, either RADIUS server type applies. For the device to function as a RADIUS server to authenticate login users, you must set the RADIUS server type to standard.

Follow these steps to set the RADIUS server type:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Set the RADIUS server type	server-type { extended \| standard }	Optional standard by default

NOTE:

Changing the RADIUS server type will restore the unit for data flows and that for packets that are sent to the RADIUS server to the defaults.

Setting the status of RADIUS servers

By setting the status of RADIUS servers to blocked or active, you can control which servers the device will communicate with for authentication, authorization, and accounting or turn to when the current servers are not available anymore. 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. Generally, the device chooses servers based on these rules:

· When the primary server is in the active state, the device communicates with the primary server. If the primary server fails, the device changes the server’s status to blocked and starts a quiet timer for the server, and then turns to a secondary server in the 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 the active state. This search process continues until the device finds an available secondary server or has checked all secondary servers in the 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.

· Once the accounting process of a user starts, the device keeps sending the user’s real-time accounting requests and stop-accounting requests to the same accounting server. If you remove the accounting server, real-time accounting requests and stop-accounting requests for the user cannot be delivered to the server anymore.

· If you remove an authentication or accounting server in use, the communication of the device with the server will soon time out, and the device will look for a server in the active state from scratch: it checks the primary server (if any) first and then the secondary servers in the order they are configured.

· When the primary server and secondary servers are all in the blocked state, the device communicates with the primary server. If the primary server is available, its status changes to active; otherwise, its status remains to be blocked.

· If one server is in the active state and all the others are in the blocked state, the device only tries to communicate with the server in the 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 may need to 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 with the server.

Follow these steps to set the status of RADIUS servers in a RADIUS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Set the status of the primary RADIUS authentication/authorization server	state primary authentication { active \| block }	Optional active for every server specified in the RADIUS scheme by default
Set the status of the primary RADIUS accounting server	state primary accounting { active \| block }
Set the status of the secondary RADIUS authentication/authorization server	state secondary authentication [ ip ipv4-address \| ipv6 ipv6-address ] { active \| block }
Set the status of the secondary RADIUS accounting server	state secondary accounting [ ip ipv4-address \| ipv6 ipv6-address ] { active \| block }

NOTE:

· The server status set by the state command cannot be saved to the configuration file. After the device restarts, the status of each server is restored to active.

· To display the states of the servers, use the display radius scheme command.

Setting the username format and traffic statistics units

Follow these steps to set the username format and the traffic statistics units for a RADIUS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Set the format for usernames sent to the RADIUS servers	user-name-format { keep-original \| with-domain \| without-domain }	Optional By default, the ISP domain name is included in a username.
Specify the unit for data flows or packets sent to the RADIUS servers	data-flow-format { data { byte \| giga-byte \| kilo-byte \| mega-byte } \| packet { giga-packet \| kilo-packet \| mega-packet \| one-packet } }*	Optional byte for data flows and one-packet for data packets by default.

NOTE:

· If a RADIUS scheme defines that the username is sent without the ISP domain name, do not apply the RADIUS scheme to more than one ISP domain. Otherwise, users using the same username but in different ISP domains will be considered the same user.

· For level switching authentication, the user-name-format keep-original and user-name-format without-domain commands produce the same results: they ensure that usernames sent to the RADIUS server carry no ISP domain name.

Specifying the source IP address for outgoing RADIUS packets

By specifying a source IP address for outgoing RADIUS packets, you can ensure that the device can receive RADIUS packets from the RADIUS server when the outgoing physical interface fails.

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 any managed NAS. If yes, the server processes the packet. If not, the server drops the packet.

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, a NAS selects a source IP address in this 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.

Follow these steps to specify a source IP address for all RADIUS schemes in a VPN or the public network:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Specify a source IP address for outgoing RADIUS packets	radius nas-ip { ip-address \| ipv6 ipv6-address }	Required By default, the IP address of the outbound interface is used as the source IP address.

To do…

Use the command…

Remarks

Enter system view

system-view

—

Specify a source IP address for outgoing RADIUS packets

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

Required

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

Follow these steps to specify a source IP address for a specific RADIUS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Specify a source IP address for outgoing RADIUS packets	nas-ip { ip-address \| ipv6 ipv6-address }	Required By default, the IP address of the outbound interface is used as the source IP address.

Setting timers for controlling communication with RADIUS servers

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. After sending a RADIUS request (authentication/authorization or accounting request), the device starts this timer. If the device receives no response from the RADIUS server before this timer expires, it resends the request.

· Server quiet timer (quiet)—Defines the duration to keep an unreachable server in the 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 the active state. After this 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.

Follow these steps to set timers for controlling communication with RADIUS servers:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Set the RADIUS server response timeout timer	timer response-timeout seconds	Optional 3 seconds by default
Set the quiet timer for the servers	timer quiet minutes	Optional 5 minutes by default
Set the real-time accounting timer	timer realtime-accounting minutes	Optional 12 minutes by default

NOTE:

· For a type of users, the maximum number of transmission attempts multiplied by the RADIUS server response timeout period must be less than the client connection timeout time and must not exceed 75 seconds. Otherwise, stop-accounting messages cannot be buffered, and the primary/secondary server switchover cannot take place. For example, the product of the two parameters must be less than 10 seconds for voice users, and less than 30 seconds for Telnet users because the client connection timeout period for voice users is 10 seconds and that for Telnet users is 30 seconds.

· When configuring the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout period, be sure to take the number of secondary servers into account. If the retransmission process takes too much time, the client connection in the access module may be timed 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 may 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 may succeed because the device has set the state of the unreachable servers to blocked and the time for finding a reachable server is shortened.

· Be sure to set the server quiet timer properly. Too short a quiet timer may result in frequent authentication or accounting failures because the device has to repeatedly attempt to communicate with an unreachable server that is in the active state.

· For more information about the maximum number of RADIUS packet transmission attempts, see “Setting the maximum number of RADIUS request transmission attempts.“

Configuring RADIUS accounting-on

The accounting-on feature enables a device to send accounting-on packets to the RADIUS server after it reboots, making the server log out users who logged in through the device before the reboot. Without this feature, users who were online before the reboot cannot re-log in after the reboot, because the RADIUS server considers they are already online.

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

Follow these steps to configure the accounting-on feature for a RADIUS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Enable accounting-on and configure parameters	accounting-on enable [ interval seconds \| send send-times ] *	Required Disabled by default. The default interval is 3 seconds and the default number of send-times is 5.

NOTE:

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

Configuring the IP address of the security policy server

The core of the H3C EAD solution is integration and cooperation, and the security policy server is the management and control center. Using a collection of software, the security policy server provides functions such as user management, security policy management, security status assessment, security cooperation control, and security event audit.

The NAS checks the validity of received control packets and accepts only control packets from known servers. To use a security policy server that is independent of the AAA servers, you must configure the IP address of the security policy server on the NAS. To implement all EAD functions, configure both the IP address of the iMC security policy server and that of the iMC configuration platform on the NAS.

Follow these steps to configure the IP address of the security policy server for a scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Specify a security policy server	security-policy-server ip-address	Required No security policy server is specified by default

NOTE:

You can specify up to eight security policy servers for a RADIUS scheme.

Configuring interpretation of RADIUS class attribute as CAR parameters

According to RFC 2865, a RADIUS server assigns the RADIUS class attribute (attribute 25) to a RADIUS client. However, the RFC only requires the RADIUS client to send the attribute to the accounting server on an “as is” basis; it does not require the RADIUS client to interpret the attribute. Some RADIUS servers use the class attribute to deliver the assigned committed access rate (CAR) parameters. In this case, the device must interpret the attribute as the CAR parameters to implement user-based traffic monitoring and controlling.

Follow these steps to configure the device to interpret the RADIUS class attribute as CAR parameters:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Interpret the class attribute as CAR parameters	attribute 25 car	Required By default, RADIUS attribute 25 is not interpreted as CAR parameters.

NOTE:

Whether interpretation of RADIUS class attribute as CAR parameters is supported depends on two factors:

· Whether the device supports CAR parameters assignment.

· Whether the RADIUS server supports assigning CAR parameters through the class attribute.

Enabling the trap function for RADIUS

With the trap function, a NAS sends a trap message when either of the following events occurs:

· The status of a RADIUS server changes. If a NAS receives no response to an accounting or authentication request before the specified maximum number of RADIUS request transmission attempts is exceeded, it considers the server unreachable, sets the status of the server to block and sends a trap message. If the NAS receives a response from a RADIUS server that it considers unreachable, the NAS considers that the RADIUS server is reachable again, sets the status of the server to active, and sends a trap message.

· The ratio of the number of failed transmission attempts to the total number of authentication request transmission attempts reaches the threshold. This threshold ranges from 1% to 100% and defaults to 30%. This threshold can only be configured through the MIB.

The failure ratio is generally small. If a trap message is triggered because the failure ratio is higher than the threshold, troubleshoot the configuration on and the communication between the NAS and the RADIUS server.

Follow these steps to enable the trap function for RADIUS:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enable the trap function for RADIUS	radius trap { accounting-server-down \| authentication-error-threshold \| authentication-server-down }	Required Disabled by default

To do…

Use the command…

Remarks

Enter system view

system-view

—

Enable the trap function for RADIUS

radius trap { accounting-server-down | authentication-error-threshold | authentication-server-down }

Required

Disabled by default

Enabling the RADIUS listening port of the RADIUS client

Only after you enable the RADIUS listening port of a RADIUS client, can the client receive and send RADIUS packets. If RADIUS is not required, disable the RADIUS listening port to avoid attacks that exploit RADIUS packets.

Follow these steps to enable the RADIUS listening port of a RADIUS client:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enable the RADIUS listening port of a RADIUS client	radius client enable	Optional Enabled by default

To do…

Use the command…

Remarks

Enter system view

system-view

—

Enable the RADIUS listening port of a RADIUS client

radius client enable

Optional

Enabled by default

Displaying and maintaining RADIUS

To do…	Use the command…	Remarks
Display the configuration information of RADIUS schemes	display radius scheme [ radius-scheme-name ] [ slot slot-number ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the statistics for RADIUS packets	display radius statistics [ slot slot-number ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about buffered stop-accounting requests for which no responses have been received	display stop-accounting-buffer { radius-scheme radius-server-name \| session-id session-id \| time-range start-time stop-time \| user-name user-name } [ slot slot-number ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Clear RADIUS statistics	reset radius statistics [ slot slot-number ]	Available in user view
Clear the buffered stop-accounting requests for which no responses have been receive	reset stop-accounting-buffer { radius-scheme radius-server-name \| session-id session-id \| time-range start-time stop-time \| user-name user-name } [ slot slot-number ]	Available in user view

Configuring HWTACACS schemes

NOTE:

You cannot remove the HWTACACS schemes in use or change the IP addresses of the HWTACACS servers in use.

HWTACACS configuration task list

Task	Remarks
Creating an HWTACACS scheme	Required
Specifying the HWTACACS authentication servers	Required
Specifying the HWTACACS authorization servers	Optional
Specifying the HWTACACS accounting servers and the relevant parameters	Optional
Specifying the shared keys for HWTACACS packets	Required
Setting the username format and traffic statistics units	Optional
Specifying the source IP address for outgoing HWTACACS packets	Optional
Setting timers for controlling communication with HWTACACS servers	Optional
Displaying and maintaining HWTACACS	Optional

Creating an HWTACACS scheme

The HWTACACS protocol is configured on a per scheme basis. Before performing other HWTACACS configurations, follow these steps to create an HWTACACS scheme and enter HWTACACS scheme view:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create an HWTACACS scheme and enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	Required Not defined by default

To do…

Use the command…

Remarks

Enter system view

system-view

—

Create an HWTACACS scheme and enter HWTACACS scheme view

hwtacacs scheme hwtacacs-scheme-name

Required

Not defined by default

NOTE:

· Up to 16 HWTACACS schemes can be configured.

· A scheme can be deleted only when it is not referenced.

Specifying the HWTACACS authentication servers

You can specify one primary authentication server and up to one secondary authentication server for an HWTACACS scheme so that the NAS can find a server for user authentication when using the scheme. When the primary server is not available, the secondary server is used, if any. In a scenario where redundancy is not required, specify only the primary server.

Follow these steps to specify HWTACACS authentication servers for an HWTACACS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	—
Specify the primary HWTACACS authentication server	primary authentication ip-address [ port-number ] *	Required Configure at least one command. No authentication server is specified by default.
Specify the secondary HWTACACS authentication server	secondary authentication ip-address [ port-number ] *

NOTE:

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

· The IP addresses of the primary and secondary authentication servers cannot be the same. Otherwise, the configuration fails.

· You can remove an authentication server only when no active TCP connection for sending authentication packets is using it.

Specifying the HWTACACS authorization servers

You can specify one primary authorization server and up to one secondary authorization server for an HWTACACS scheme so that the NAS can find a server for user authorization when using the scheme. When the primary server is not available, the secondary server is used, if any. In a scenario where redundancy is not required, specify only the primary server.

Follow these steps to specify HWTACACS authorization servers for an HWTACACS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	—
Specify the primary HWTACACS authorization server	primary authorization ip-address [ port-number ] *	Required Configure at least one command. No authorization server is specified by default.
Specify the secondary HWTACACS authorization server	secondary authorization ip-address [ port-number ] *

NOTE:

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

· The IP addresses of the primary and secondary authorization servers cannot be the same. Otherwise, the configuration fails.

· You can remove an authorization server only when no active TCP connection for sending authorization packets is using it.

Specifying the HWTACACS accounting servers and the relevant parameters

You can specify one primary accounting server and up to one secondary accounting server for an HWTACACS scheme so that the NAS can find a server for user accounting when using the scheme. When the primary server is not available, the secondary server is used, if any. In a scenario where redundancy is not required, specify only the primary server.

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. You can enable buffering of non-responded stop-accounting requests to allow the device to buffer and resend a stop-accounting request until it receives a response or the number of stop-accounting attempts reaches the configured limit. In the latter case, the device discards the packet.

Follow these steps to specify HWTACACS accounting servers and set relevant parameters for an HWTACACS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	—
Specify the primary HWTACACS accounting server	primary accounting ip-address [ port-number ] *	Required Configure at least one command. No accounting server is specified by default.
Specify the secondary HWTACACS accounting server	secondary accounting ip-address [ port-number ] *
Enable buffering of stop-accounting requests to which no responses are received	stop-accounting-buffer enable	Optional Enabled by default
Set the maximum number of stop-accounting attempts	retry stop-accounting retry-times	Optional 100 by default

NOTE:

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

· The IP addresses of the primary and secondary accounting servers cannot be the same. Otherwise, the configuration fails.

· You can remove an accounting server only when no active TCP connection for sending accounting packets is using it.

· HWTACACS does not support accounting for FTP users.

Specifying the shared keys for HWTACACS packets

The HWTACACS client and HWTACACS server use the MD5 algorithm to encrypt packets exchanged between them and use shared keys to authenticate the packets. They must use the same shared key for the same type of packets.

Follow these steps to specify the shared keys for authenticating HWTACACS packets:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	—
Specify the shared keys for authenticating HWTACACS authentication, authorization, and accounting packets	key { accounting \| authentication \| authorization } string	Required No shared key by default

NOTE:

A shared key configured on the device must be the same as that configured on the HWTACACS server.

Setting the username format and traffic statistics units

Follow these steps to set the username format and the traffic statistics units for an HWTACACS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	—
Set the format of usernames sent to the HWTACACS servers	user-name-format { keep-original \| with-domain \| without-domain }	Optional By default, the ISP domain name is included in a username.
Specify the unit for data flows or packets sent to the HWTACACS servers	data-flow-format { data { byte \| giga-byte \| kilo-byte \| mega-byte } \| packet { giga-packet \| kilo-packet \| mega-packet \| one-packet } }*	Optional byte for data flows and one-packet for data packets by default.

NOTE:

· If an HWTACACS server does not support a username that carries the domain name, configure the device to remove the domain name before sending the username to the server.

Specifying the source IP address for outgoing HWTACACS packets

By specifying a source IP address for outgoing HWTACACS packets, you can ensure that the device can receive HWTACACS packets from the HWTACACS server when the outgoing physical interface fails.

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 any managed NAS. If yes, the server processes the packet. If not, the server drops the packet.

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, a NAS selects a source IP address in this order:

· The source IP address specified for the HWTACACS scheme.

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

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

Follow these steps to specify a source IP address for all HWTACACS schemes of a VPN or the public network:

To do…

Use the command…

Remarks

Enter system view

system-view

—

Specify a source IP address for outgoing HWTACACS packets

hwtacacs nas-ip ip-address

Required

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

Follow these steps to specify a source IP address for a specific HWTACACS scheme:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	—
Specify a source IP address for outgoing HWTACACS packets	nas-ip ip-address	Required By default, the IP address of the outbound interface is used as the source IP address.

Setting timers for controlling communication with HWTACACS servers

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. After sending an HWTACACS request (authentication, authorization, or accounting request), the device starts this timer. If the device receives no response from the server before this timer expires, it resends the request.

· 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 send real-time accounting packets to the accounting server for online users periodically.

Follow these steps to set timers for controlling communication with HWTACACS servers:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	—
Set the HWTACACS server response timeout timer	timer response-timeout seconds	Optional 5 seconds by default
Set the quiet timer for the primary server	timer quiet minutes	Optional 5 minutes by default
Set the real-time accounting interval	timer realtime-accounting minutes	Optional 12 minutes by default

NOTE:

The setting of the real-time accounting interval somewhat depends on the performance of the NAS and the HWTACACS server. A shorter interval requires higher performance.

Displaying and maintaining HWTACACS

To do…	Use the command…	Remarks
Display the configuration information or statistics of HWTACACS schemes	display hwtacacs [ hwtacacs-server-name [ statistics ] ] [ slot slot-number ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about buffered stop-accounting requests for which no responses have been received	display stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name [ slot slot-number ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Clear HWTACACS statistics	reset hwtacacs statistics { accounting \| all \| authentication \| authorization } [ slot slot-number ]	Available in user view
Clear buffered stop-accounting requests that get no responses	reset stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name [ slot slot-number ]	Available in user view

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 default AAA methods, which are local authentication, local authorization, and local accounting by default and can be customized. If you do not configure any AAA methods for an ISP domain, the device uses the system default AAA methods for authentication, authorization, and accounting of the users in the domain.

Configuration prerequisites

To use local authentication for users in an ISP domain, configure local user accounts (see “Configuring local user attributes“) on the device.

To use remote authentication, authorization, and accounting, create the required RADIUS and HWTACACS schemes as described in “Configuring RADIUS schemes” and ”Configuring HWTACACS schemes.”

Creating an ISP domain

In a networking scenario with multiple ISPs, the device may connect users of different ISPs, and users of different ISPs may have different user attributes, such as different username and password structures, different service types, and different rights. To distinguish the users of different ISPs, configure ISP domains, and configure different AAA methods and domain attributes for the ISP domains.

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.

Follow these steps to create an ISP domain:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create an ISP domain and enter ISP domain view	domain isp-name	Required
Return to system view	quit	—
Specify the default ISP domain	domain default enable isp-name	Optional By default, the default ISP domain is the system predefined ISP domain system.

NOTE:

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

Configuring ISP domain attributes

Follow these steps to configure ISP domain attributes:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter ISP domain view	domain isp-name	—
Place the ISP domain to the state of active or blocked	state { active \| block }	Optional By default, an ISP domain is in the active state, and users in the domain can request network services.
Specify the maximum number of online users in the ISP domain	access-limit enable max-user-number	Optional No limit by default
Configure the idle cut function	idle-cut enable minute [ flow ]	Optional Disabled by default This command is effective for only LAN users and PPP users.
Enable the self-service server location function and specify the URL of the self-service server	self-service-url enable url-string	Optional Disabled by default
Specify the default authorization user profile	authorization-attribute user-profile profile-name	Optional By default, an ISP domain has no default authorization user profile.

NOTE:

· For more information about user profiles, see the chapter “User profile configuration.”

· A self-service RADIUS server, such as Intelligent Management Center (iMC), is required for the self-service server location function to work.

Configuring AAA authentication methods for an ISP domain

In AAA, authentication, authorization, and accounting are separate processes. Authentication refers to the interactive authentication process of username/password/user information during an access or service request. The authentication process neither sends authorization information to a supplicant nor triggers any accounting.

AAA supports the following authentication methods:

· No authentication (none)—All users are trusted and no authentication is performed. Generally, do not use this method.

· Local authentication (local)—Authentication is performed by the NAS, which is configured with the 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 hardware.

· Remote authentication (scheme)—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 local or no authentication as the backup method, which will be used when the remote server is not available. No authentication can only be configured for LAN users as the backup method of remote authentication.

You can configure AAA authentication to work alone without authorization and accounting. By default, an ISP domain uses the local authentication method.

Before configuring authentication methods, complete the following tasks:

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

· 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, limiting the authentication protocols that can be used for access.

· Determine whether to configure an authentication method for all access types or service types.

Follow these steps to configure AAA authentication methods for an ISP domain:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter ISP domain view	domain isp-name	—
Specify the default authentication method for all types of users	authentication default { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional local by default
Specify the authentication method for LAN users	authentication lan-access { local \| none \| radius-scheme radius-scheme-name [ local \| none ] }	Optional The default authentication method is used by default.
Specify the authentication method for login users	authentication login { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional The default authentication method is used by default.
Specify the authentication method for privilege level switching	authentication super { hwtacacs-scheme hwtacacs-scheme-name \| radius-scheme radius-scheme-name }	Optional The default authentication method is used by default.

NOTE:

· The authentication method specified with the authentication default command is for all types of users and has a priority lower than that for a specific access type.

· With an authentication method that references 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 authentication process ignores the information.

· If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name local keyword and argument combination when configuring an authentication method, local authentication is the backup method and is used only when the remote server is not available.

· If you specify only the local or none keyword in an authentication method configuration command, the device has no backup authentication method and performs only local authentication or does not perform any authentication.

· If the method for level switching authentication references an HWTACACS scheme, the device uses the login username of a user for level switching authentication of the user by default. If the method for level switching authentication references a RADIUS scheme, the system uses the username configured for the corresponding privilege level on the RADIUS server for level switching authentication, rather than the login username. A username configured on the RADIUS server is in the format of $enablevel$, where level specifies the privilege level to which the user wants to switch. For example, if user user1 of domain aaa wants to switch the privilege level to 3, the system uses $enab3@aaa$ for authentication when the domain name is required and uses $enab3$ for authentication when the domain name is not required.

Configuring AAA authorization methods for an ISP domain

In AAA, authorization is a separate process at the same level as authentication and accounting. Its responsibility is to send authorization requests to the specified authorization servers and to send authorization information to users after successful authorization. Authorization method configuration is optional in AAA configuration.

AAA supports the following authorization methods:

· No authorization (none)—All users are trusted and no authentication is performed. Generally, this method is not recommended.

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

· Remote authorization (scheme)—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 message. HWTACACS authorization is separate from HWTACACS authentication, and the authorization information is carried in the authorization response after successful authentication. You can configure local authorization or no authorization as the backup method, which will be used when the remote server is not available.

Before configuring authorization methods, complete the following tasks:

1. For HWTACACS authorization, configure the HWTACACS scheme to be referenced first. For RADIUS authorization, the RADIUS authorization scheme must be the same as the RADIUS authentication scheme; otherwise, it does not take effect.

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, limiting the authorization protocols that can be used for access.

3. Determine whether to configure an authorization method for all access types or service types.

Follow these steps to configure AAA authorization methods for an ISP domain:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter ISP domain view	domain isp-name	—
Specify the default authorization method for all types of users	authorization default { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional local by default
Specify the command authorization method	authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local \| none ] \| local \| none }	Optional The default authorization method is used by default.
Specify the authorization method for LAN users	authorization lan-access { local \| none \| radius-scheme radius-scheme-name [ local \| none ] }	Optional The default authorization method is used by default.
Specify the authorization method for login users	authorization login { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local\| none \| radius-scheme radius-scheme-name [ local ] }	Optional The default authorization method is used by default.

NOTE:

· The authorization method specified with the authorization default command is for all types of users and has a priority lower than that for a specific access type.

· If you configure an authentication method and an authorization method that use RADIUS schemes for an ISP domain, the RADIUS scheme for authorization must be the same as that for authentication. If the RADIUS authorization configuration is invalid or RADIUS authorization fails, the RADIUS authentication also fails. Whenever RADIUS authorization fails, an error message is sent to the NAS, indicating that the server is not responding.

· If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name [ local | none ] keyword and argument combination when configuring an authorization method, local authorization or no authorization is the backup method and is used only when the remote server is not available.

· If you specify only the local or none keyword in an authorization method configuration command, the device has no backup authorization method and performs only local authorization or does not perform any authorization.

Configuring AAA accounting methods for an ISP domain

In AAA, accounting is a separate process at the same level as authentication and authorization. This process sends accounting start/update/end requests to the specified accounting server. Accounting is optional.

AAA supports the following accounting methods:

· No accounting (none)—The system does not perform accounting for the users.

· Local accounting (local)—Local accounting is implemented on the NAS. It counts and controls the number of concurrent users who use the same local user account; it does not provide statistics for charging. The maximum number of concurrent users using the same local user account is set by the access-limit command in local user view.

· Remote accounting (scheme)—The NAS works with a RADIUS server or HWTACACS server for accounting. You can configure local or no accounting as the backup method, which will be used when the remote server is not available.

By default, an ISP domain uses the local accounting method.

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, limiting the accounting protocols that can be used for access.

3. Determine whether to configure an accounting method for all access types or service types.

Follow these steps to configure AAA accounting methods for an ISP domain:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter ISP domain view	domain isp-name	—
Enable the accounting optional feature	accounting optional	Optional Disabled by default
Specify the default accounting method for all types of users	accounting default { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional local by default
Specify the command accounting method	accounting command hwtacacs-scheme hwtacacs-scheme-name	Optional The default accounting method is used by default.
Specify the accounting method for LAN users	accounting lan-access { local \| none \| radius-scheme radius-scheme-name [ local \| none ] }	Optional The default accounting method is used by default.
Specify the accounting method for login users	accounting login { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional The default accounting method is used by default.

NOTE:

· If you configure the accounting optional command, the limit on the number of local user connections is not effective.

· The accounting method specified with the accounting default command is for all types of users and has a priority lower than that for a specific access type.

· If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name local keyword and argument combination when configuring an accounting method, local accounting is the backup method and is used only when the remote server is not available.

· If you specify only the local or none keyword in an accounting method configuration command, the device has no backup accounting method and performs only local accounting or does not perform any accounting.

· Accounting is not supported for FTP services.

Tearing down user connections

Follow these steps to tear down user connections:

To do…

Use the command…

Remarks

Enter system view

system-view

—

Tear down AAA user connections (on a distributed device)

cut connection { access-type { dot1x | mac-authentication } | all | domain isp-name | interface interface-type interface-number | ip ip-address | mac mac-address | ucibindex ucib-index | user-name user-name | vlan vlan-id } [ slot slot-number ]

Required

Applicable to only LAN and PPP user connections.

Displaying and maintaining AAA

To do…	Use the command…	Remarks
Display the configuration information of ISP domains	display domain [ isp-name ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about user connections	display connection [ access-type { dot1x \| mac-authentication } \| domain isp-name \| interface interface-type interface-number \| ip ip-address \| mac mac-address \| ucibindex ucib-index \| user-name user-name \| vlan vlan-id ] [ slot slot-number ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view

AAA configuration examples

AAA for Telnet users by an HWTACACS server

Network requirements

As shown in Figure 9, configure the switch to use the HWTACACS server to provide authentication, authorization, and accounting services for Telnet users.

Set the shared keys for authenticating authentication, authorization, and accounting exchanges with the HWTACACS server to expert. Configure the switch to remove the domain name from a username before sending the username to the HWTACACS server.

Figure 9 Configure AAA for Telnet users by an HWTACACS server

Configuration procedure

1. Configure the switch

# Assign IP addresses to the interfaces (omitted).

# Enable the Telnet server on the switch.

<Switch> system-view

[Switch] telnet server enable

# Configure the switch to use AAA for Telnet users.

[Switch] user-interface vty 0 4

[Switch-ui-vty0-4] authentication-mode scheme

[Switch-ui-vty0-4] quit

# Create HWTACACS scheme hwtac.

[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 key for authentication, authorization, and accounting packets to expert.

[Switch-hwtacacs-hwtac] key authentication expert

[Switch-hwtacacs-hwtac] key authorization expert

[Switch-hwtacacs-hwtac] key accounting expert

# Specify the scheme to exclude the domain names from usernames to be sent to the HWTACACS server.

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

[Switch-hwtacacs-hwtac] quit

# Configure the AAA methods for the domain.

[Switch] domain bbb

[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

# You can also configure a set of default methods to achieve the same effect.

[Switch] domain bbb

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

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

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

2. Verify the configuration

Telnet to the switch as a user and enter the correct username and password. You pass authentication and log in to the switch. Issuing the display connection command on the switch, you can see information about the user connection.

AAA for Telnet users by separate servers

Network requirements

As shown in Figure 10, configure the switch to provide local authentication, HWTACACS authorization, and RADIUS accounting services for Telnet users. Set the shared keys for packet exchange with the HWTACACS server and the RADIUS server to expert. Configure the switch to remove the domain name from a username before sending the username to the HWTACACS server. The username and password of the Telnet user are both hello.

Figure 10 Configure AAA by separate servers for Telnet users

NOTE:

Configuration required for another AAA application like this one is similar. The only difference lies in the access mode.

Configuration procedure

1. Configure the switch

# Assign IP addresses to interfaces. (Omitted)

# Enable the Telnet server on the switch.

<Switch> system-view

[Switch] telnet server enable

# Configure the switch to use AAA for Telnet users.

[Switch] user-interface vty 0 4

[Switch-ui-vty0-4] authentication-mode scheme

[Switch-ui-vty0-4] quit

# Configure the HWTACACS scheme.

[Switch] hwtacacs scheme hwtac

[Switch-hwtacacs-hwtac] primary authorization 10.1.1.2 49

[Switch-hwtacacs-hwtac] key authorization expert

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

[Switch-hwtacacs-hwtac] quit

# Configure the RADIUS scheme.

[Switch] radius scheme rd

[Switch-radius-rd] primary accounting 10.1.1.1 1813

[Switch-radius-rd] key accounting expert

[Switch-radius-rd] server-type extended

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

[Switch-radius-rd] quit

# Create a local user named hello.

[Switch] local-user hello

[Switch-luser-hello] service-type telnet

[Switch-luser-hello] password simple hello

[Switch-luser-hello] quit

# Configure the AAA methods for the ISP domain.

[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

# You can also configure a set of default methods to achieve the same effect.

[Switch] domain bbb

[Switch-isp-bbb] authentication default local

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

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

2. Verify the configuration

Telnet to the switch as a user and enter the username hello@bbb and the correct password. You pass authentication and log in to the switch. Issuing the display connection command on the switch, you can see information about the user connection.

Authentication/authorization for SSH/Telnet users by a RADIUS server

NOTE:

The configuration of authentication and authorization for SSH users is similar to that for Telnet users. The following takes SSH users as an example.

Network requirements

See Figure 11. Complete the following tasks:

· Configure a iMC server to act as the RADIUS server.

· Configure the switch to use the RADIUS server for SSH user authentication and authorization.

· Set the shared keys for packet exchange with the RADIUS server to expert; and specify that a username sent to the RADIUS server carries the domain name. The RADIUS server provides different user services according to the domain names.

· Add an account on the RADIUS server, with the username being hello@bbb. The SSH user uses the username and the configured password to log in to the switch and is authorized with the privilege level of 3 after login.

Figure 11 Configure authentication/authorization for SSH users by a RADIUS server

Configuration procedure

1. Configure the RADIUS server(when the server runs iMC PLAT 3.20)

NOTE:

This example assumes that the RADIUS server runs iMC PLAT 3.20-R2606 and iMC UAM 3.60-E6206.

# Add an access device.

Log in to the iMC management platform, click the Service tab, and select Access Service > Service Configuration from the navigation tree. Then, click Add to configure an access device as follows:

· Set the shared key for authentication and accounting to expert

· Set the ports for authentication and accounting to 1812 and 1813 respectively

· Select Device Management Service as the service type

· Select H3C as the access device type

· Select the access device from the device list or manually add the device with the IP address 10.1.1.2

· Click OK to finish the configuration

NOTE:

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 device, which is chosen in this order:

· The IP address specified with the nas-ip command on the device

· The IP address specified with the radius nas-ip command on the device

· The IP address of the outbound interface (the default)

Figure 12 Add an access device

增加接入设备－telnet－en

# Add a user for device management

From the navigation tree, click the User tab, select Access User View > All Access Users. Then, click Add to configure a device management user as follows:

· Add a user named hello@bbb and specify the password.

· Select SSH as the service type.

· Set the EXEC privilege level to 3. This value identifies the privilege level of the SSH user after login, which is 0 by default.

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

· Click OK to finish the configuration.

Figure 13 Add an account for device management

2. Configure the RADIUS server (when the server runs iMC PLAT 5.0)

NOTE:

This section assumes that the RADIUS server runs iMC PLAT 5.0 (E0101H03) and iMC UAM 5.0 SP1 (E0101P03).

# Add an access device.

Log in to the iMC management platform, 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:

· Set the shared key for authentication and accounting to expert

· Set the ports for authentication and accounting to 1812 and 1813 respectively

· Select Device Management Service as the service type

· Select H3C(General) as the access device type

· Select the access device from the device list or manually add the device with the IP address 10.1.1.2

· Click OK to finish the configuration

NOTE:

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 device, which is chosen in this order:

· The IP address specified with the nas-ip command on the device

· The IP address specified with the radius nas-ip command on the device

· The IP address of the outbound interface (the default)

Figure 14 Add an access device

# Add a user for device management.

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

· Add a user named hello@bbb and specify the password.

· Select SSH as the service type.

· Set the EXEC privilege level to 3. This value identifies the privilege level of the SSH user after login, which is 0 by default.

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

· Click OK to finish the configuration.

Figure 15 Add an account for device management

3. Configure the switch

# Configure the IP address of VLAN interface 2, through which the SSH user accesses the switch.

<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

# Configure the IP address of VLAN-interface 3, through which the switch access the server.

[Switch] interface vlan-interface 3

[Switch-Vlan-interface3] ip address 10.1.1.2 255.255.255.0

[Switch-Vlan-interface3] quit

# Generate RSA and DSA key pairs and enable the SSH server.

[Switch] public-key local create rsa

[Switch] public-key local create dsa

[Switch] ssh server enable

# Configure the switch to use AAA for SSH users.

[Switch] user-interface vty 0 4

[Switch-ui-vty0-4] authentication-mode scheme

# Configure the user interfaces to support SSH.

[Switch-ui-vty0-4] protocol inbound ssh

[Switch-ui-vty0-4] quit

# Create RADIUS scheme rad.

[Switch] radius scheme rad

# Specify the primary authentication server.

[Switch-radius-rad] primary authentication 10.1.1.1 1812

# Set the shared key for authentication packets to expert.

[Switch-radius-rad] key authentication expert

# Specify the scheme to include the domain names in usernames to be sent to the RADIUS server.

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

# Specify the service type for the RADIUS server, which must be extended when the RADIUS server runs iMC.

[Switch-radius-rad] server-type extended

[Switch-radius-rad] quit

# Configure the AAA methods for the domain.

[Switch] domain bbb

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

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

[Switch-isp-bbb] quit

4. Verify the configuration

After you complete the configuration, the SSH user should be able to use the configured account to access the user interface of the switch and can access the demands of level 0 through level 3. .

# Use the display connection command to view the connection information on the switch.

[Switch] display connection

Index=1 ,Username=hello@bbb

IP=192.168.1.58

IPv6=N/A

Total 1 connection(s) matched.

AAA for 802.1X users by a RADIUS server

Network requirements

As shown in Figure 16, configure the switch to use the RADIUS server to perform authentication, authorization, and accounting for 802.1X users.

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

· Set the shared keys for authentication and authorization to expert.

· Set the ports for authentication/authorization and accounting to 1812 and 1813 respectively.

· Specify that a username sent to the RADIUS server carries the domain name. The username of the user is dot1x@bbb.

· After the host passes authentication, the authentication server assigns the host to VLAN 4.

· The host registers a monthly service charging 120 dollars for up to 120 hours per month.

Figure 16 Configure AAA for 802.1X users by a RADIUS server

Configuration procedure

NOTE:

Configure the interfaces and VLANs as shown in Figure 16. Make sure that the host can get a new IP address manually or automatically and can access resources in the authorized VLAN after passing authentication.

1. Configure the RADIUS server(when the server runs iMC PLAT 3.20)

NOTE:

This section assumes that the RADIUS server runs iMC PLAT 3.20-R2606 and iMC UAM 3.60-E6206.

# Add an access device.

Log in to the iMC management platform, click the Service tab, and select Access Service > Access Device from the navigation tree . Then, click Add to configure an access device as follows:

· Set the shared key for authentication and accounting to expert

· Set the ports for authentication and accounting to 1812 and 1813 respectively

· Select LAN Access Service as the service type

· Select H3C as the access device type

· Select the access device from the device list or manually add the device with the IP address 10.1.1.2

· Leave the default settings for other parameters and click OK to finish the configuration.

NOTE:

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 device, which is chosen in this order:

· The IP address specified with the nas-ip command on the device

· The IP address specified with the radius nas-ip command on the device

· The IP address of the outbound interface (the default)

Figure 17 Add an access device

# Add a charging plan.

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

· Add a plan named UserAcct

· Select Flat rate as the charging template

· Select time for Charge Based on, select Monthly for Billing Term, and type 120 in the Fixed Fee field

· Type 120 in the Usage Threshold field and select hours for the in field to allow the user to access the Internet for up to 120 hours per month

· Leave the default settings for other parameters and click OK to finish the configuration.

Figure 18 Add a charging plan

# Add a service.

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

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

· Select UserAcct as the charging plan.

· Select Deploy VLAN and set the ID of the VLAN to 4.

· Configure other parameters according as required.

· Click OK to finish the configuration.

Figure 19 Add a service

# Add a user.

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

· Select the user or add a user named test

· Specify the account name as dot1x and configure the password

· Select the access service Dot1x auth

· Configure other parameters as required and click OK to finish the configuration

Figure 20 Add an access user account

2. Configure the RADIUS server (when the server runs iMC PLAT 5.0)

NOTE:

This section assumes that the RADIUS server runs iMC PLAT 5.0 (E0101) and iMC UAM 5.0 (E0101).

# Add an access device.

· Set the shared key for authentication and accounting to expert

· Set the ports for authentication and accounting to 1812 and 1813 respectively

· Select LAN Access Service as the service type

· Select H3C(General) as the access device type

· Select the access device from the device list or manually add the device with the IP address 10.1.1.2

· Leave the default settings for other parameters and click OK to finish the configuration.

NOTE:

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 device, which is chosen in this order:

· The IP address specified with the nas-ip command on the device

· The IP address specified with the radius nas-ip command on the device

· The IP address of the outbound interface (the default)

Figure 21 Add an access device

# Add a charging plan.

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

· Add a plan named UserAcct

· Select Flat rate as the charging template

· Select time for Charge Based on, select Monthly for Billing Term, and type 120 in the Fixed Fee field

· Type 120 in the Usage Threshold field and select hr for the in field to allow the user to access the Internet for up to 120 hours per month

· Leave the default settings for other parameters and click OK to finish the configuration.

Figure 22 Add a charging plan

# Add a service.

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

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

· Select UserAcct as the charging plan.

· Select Deploy VLAN and set the ID of the VLAN to be assigned to 4.

· Configure other parameters as required.

· Click OK to finish the configuration.

Figure 23 Add a service

# Add a user.

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

· Select the user or add a user named hello

· Specify the account name as dot1x and configure the password

· Select the access service Dot1x auth

· Configure other parameters as required and click OK to finish the configuration

Figure 24 Add an access user account

3. Configure the switch

· Configure a RADIUS scheme

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

<Switch> system-view

[Switch] radius scheme rad

# Set the server type for the RADIUS scheme. When using the iMC server, set the server type to extended.

[Switch-radius-rad] server-type extended

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

[Switch-radius-rad] primary authentication 10.1.1.1

[Switch-radius-rad] primary accounting 10.1.1.1

[Switch-radius-rad] key authentication expert

[Switch-radius-rad] key accounting expert

# Specify the scheme to include the domain names in usernames to be sent to the RADIUS server.

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

[Switch-radius-rad] quit

· Configure an authentication domain

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

[Switch] domain bbb

# Configure the ISP domain to use RADIUS scheme rad.

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

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

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

[Switch-isp-bbb] quit

# Configure bbb as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at login, the authentication and accounting methods of the default domain will be used for the user.

[Switch] domain default enable bbb

· Configure 802.1X authentication

# Enable 802.1X globally.

[Switch] dot1x

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

[Switch] interface gigabitethernet 1/0/1

[Switch-GigabitEthernet1/0/1] dot1x

[Switch-GigabitEthernet1/0/1] quit

# Configure the access control method. (Optional. The default setting meets the requirement.)

[Switch] dot1x port-method macbased interface gigabitethernet 1/0/1

4. Verify the configuration

NOTE:

· If the 802.1X client of Windows XP is used, the properties of the 802.1X connection should be specifically configured in the Authentication tab on the Properties page, where you must select the Enable IEEE 802.1X authentication for this network option and specify the EAP type as MD5-Challenge.

· If the H3C iNode client is used, no advanced authentication options need to be enabled.

When using the H3C iNode client, the user can pass authentication after entering username dot1x@bbb and the correct password in the client property page. When using the Windows XP 802.1X client, the user can pass authentication after entering the correct username and password in the pop-up authentication page. After the user passes authentication, the server assigns the port connecting the client to VLAN 4.

Use the display connect command to view the connection information on the switch.

[Switch] display connection

Slot: 1

Index=22 , Username=dot1x@bbb

IP=192.168.1.58

IPv6=N/A

MAC=0015-e9a6-7cfe

Total 1 connection(s) matched on slot 1.

Total 1 connection(s) matched.

# View the information of the specified connection on the switch.

[Switch] display connection ucibindex 22

Slot: 1

Index=22 , Username=dot1x@bbb

MAC=0015-e9a6-7cfe

IP=192.168.1.58

IPv6=N/A

Access=8021X ,AuthMethod=CHAP

Port Type=Ethernet,Port Name=GigabitEthernet1/0/1

Initial VLAN=2, Authorized VLAN=4

ACL Group=Disable

User Profile=N/A

CAR=Disable

Priority=Disable

Start=2009-04-26 19:41:12 ,Current=2009-04-26 19:41:25 ,Online=00h00m14s

Total 1 connection matched.

As the Authorized VLAN field in the output shows, VLAN 4 has been assigned to the user.

Level switching authentication for Telnet users by an HWTACACS server

Network requirements

As shown in Figure 25,

· Connect the Telnet user to the switch and the switch to the HWTACACS server.

· Configure the switch to use local authentication for the Telnet user and assign the privilege level of 0 for the user to enjoy after login.

· Configure the switch to use the HWTACACS server and, if HWTACACS authentication is not available, use local authentication instead for level switching authentication of the Telnet user.

Figure 25 Configure level switching authentication for Telnet users by an HWTACACS server

Configuration considerations

1. Configure the switch to use AAA, particularly, local authentication for Telnet users.

· Create ISP domain bbb and configure it to use local authentication for Telnet users.

· Create a local user account, configure the password, and assign the privilege level for the user to enjoy after login.

2. On the switch, configure the authentication method for user privilege level switching.

· Specify to use HWTACACS authentication and, if HWTACACS authentication is not available, use local authentication for user level switching authentication.

· Configure HWTACACS scheme hwtac and assign an IP address to the HWTACACS server. Set the shared keys for message exchange and specify that usernames sent to the HWTACACS server carry no domain name. Configure the domain to use the HWTACACS scheme hwtac for user privilege level switching authentication.

· Configure the password for local privilege level switching authentication.

3. On the HWTACACS server, add the username and password for user privilege level switching authentication.

Configuration procedure

1. Configure the switch

# Configure the IP address of VLAN-interface 2, through which the Telnet user accesses the switch.

<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

# Configure the IP address of 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

# Enable the switch to provide Telnet service.

[Switch] telnet server enable

# Configure the switch to use AAA for Telnet users.

[Switch] user-interface vty 0 4

[Switch-ui-vty0-4] authentication-mode scheme

[Switch-ui-vty0-4] quit

# Use HWTACACS authentication for user level switching authentication and, if HWTACACS authentication is not available, use local authentication.

[Switch] super authentication-mode scheme local

# Create an HWTACACS scheme named hwtac.

[Switch] hwtacacs scheme hwtac

# Specify the IP address for the primary authentication server as 10.1.1.1 and the port for authentication as 49.

[Switch-hwtacacs-hwtac] primary authentication 10.1.1.1 49

# Set the shared key for authentication packets to expert.

[Switch-hwtacacs-hwtac] key authentication expert

# Specify the scheme to exclude the domain names from usernames to be sent to the HWTACACS server.

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

[Switch-hwtacacs-hwtac] quit

# Create ISP domain bbb.

[Switch] domain bbb

# Configure the ISP domain to use local authentication for Telnet users.

[Switch-isp-bbb] authentication login local

# Configure to use HWTACACS scheme hwtac for privilege level switching authentication.

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

[Switch-isp-bbb] quit

# Create a local Telnet user named test.

[Switch] local-user test

[Switch-luser-test] service-type telnet

[Switch-luser-test] password simple aabbcc

# Configure the user level of the Telnet user to 0 after user login.

[Switch-luser-test] authorization-attribute level 0

[Switch-luser-test] quit

# Configure the password for local privilege level switching authentication to 654321.

[Switch] super password simple 654321

[Switch] quit

2. Configure the HWTACACS server

NOTE:

The HWTACACS server in this example runs ACSv4.0.

Add a user named test on the HWTACACS server and configure advanced attributes for the user as shown in Figure 26:

· Select Max Privilege for any AAA Client and set the privilege level to level 3. After these configurations, the user needs to use the password enabpass when switching to level 1, level 2, or level 3.

· Select Use separate password and specify the password as enabpass.

Figure 26 Configure advanced attributes for the Telnet user

NOTE:

For new user test, you only need to configure the correct Enable password as shown in the figure.

3. Verify the configuration

After you complete the configuration, the Telnet user should be able to telnet to the switch and use username test@bbb and password aabbcc to enter the user interface of the switch, and access all level 0 commands.

<Switch> telnet 192.168.1.70

Trying 192.168.1.70 ...

Press CTRL+K to abort

Connected to 192.168.1.70 ...

******************************************************************************

* Without the owner's prior written consent, *

* no decompiling or reverse-engineering shall be allowed. *

******************************************************************************

Username:test@bbb

Password:

<Switch> ?

User view commands:

cluster Run cluster command

display Display current system information

ping Ping function

quit Exit from current command view

ssh2 Establish a secure shell client connection

super Set the current user priority level

telnet Establish one TELNET connection

tracert Trace route function

When switching to user privilege level 3, the Telnet user only needs to enter password enabpass as prompted.

<Switch> super 3

Password:

User privilege level is 3, and only those commands can be used

whose level is equal or less than this.

Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE

If the HWTACACS server is not available, the Telnet user needs to enter password 654321 as prompted for local authentication.

<Switch> super 3

Password: ß Enter the password for HWTACACS privilege level switch authentication

Error: Invalid configuration or no response from the authentication server.

Info: Change authentication mode to local.

Password: ß Enter the password for local privilege level switch authentication

User privilege level is 3, and only those commands can be used

whose level is equal or less than this.

Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE

Troubleshooting AAA

Troubleshooting RADIUS

Symptom 1

User authentication/authorization always fails.

Analysis

1. A communication failure exists between the NAS and the RADIUS server.

2. The username is not in the format of userid@isp-name or the ISP domain for the user authentication is not correctly configured on the NAS.

3. The user is not configured on the RADIUS server.

4. The password entered by the user is incorrect.

5. The RADIUS server and the NAS are configured with different shared key.

Solution

Check that:

1. The NAS and the RADIUS server can ping each other.

2. The username is in the userid@isp-name format and the ISP domain for the user authentication is correctly configured on the NAS.

3. The user is configured on the RADIUS server.

4. The correct password is entered.

5. The same shared key is configured on both the RADIUS server and the NAS.

Symptom 2

RADIUS packets cannot reach the RADIUS server.

Analysis

1. The NAS and the RADIUS server cannot communicate with each other.

2. The NAS is not configured with the IP address of the RADIUS server.

3. The UDP ports for authentication/authorization and accounting are not correct.

4. The port numbers of the RADIUS server for authentication, authorization and accounting are being used by other applications.

Solution

Check that:

1. The communication links between the NAS and the RADIUS server work well at both physical and link layers.

2. The IP address of the RADIUS server is correctly configured on the NAS.

3. UDP ports for authentication/authorization/accounting configured on the NAS are the same as those configured on the RADIUS server.

4. The port numbers of the RADIUS server for authentication, authorization and accounting are available.

Symptom 3

A user is authenticated and authorized, but accounting for the user is not normal.

Analysis

1. The accounting port number is not correct.

2. Configuration of the authentication/authorization server and the accounting server are not correct on the NAS. For example, one server is configured on the NAS to provide all the services of authentication/authorization and accounting, but in fact the services are provided by different servers.

Solution

Check that:

1. The accounting port number is correctly set.

2. The authentication/authorization server and the accounting server are correctly configured on the NAS.

Troubleshooting HWTACACS

Similar to RADIUS troubleshooting. See ”Troubleshooting RADIUS.”

06-Security Configuration Guide

AAA overview

RADIUS

Client/server model

Security and authentication mechanisms

RADIUS packet format

Extended RADIUS attributes

HWTACACS

Commonly used standard RADIUS attributes

Proprietary RADIUS sub-attributes of H3C

Configuring AAA schemes

Local user configuration task list

Creating a RADIUS scheme

Specifying the RADIUS accounting servers and the relevant parameters

Specifying the shared keys for RADIUS packets

Setting the maximum number of RADIUS request transmission attempts

Setting timers for controlling communication with RADIUS servers

Configuring RADIUS accounting-on

Enabling the trap function for RADIUS

HWTACACS configuration task list

Creating an HWTACACS scheme

Specifying the HWTACACS accounting servers and the relevant parameters

Configuring ISP domain attributes

Configuring AAA authentication methods for an ISP domain

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration considerations

Configuration procedure

Troubleshooting AAA

Troubleshooting RADIUS

Symptom 1

Analysis

Solution

Symptom 2

Analysis

Solution

Symptom 3

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

Company Information

News & Events

Contact Us