Authentication, Authorization, and Accounting (AAA) provides a uniform framework for configuring these three security functions to implement the network security management.

The network security mentioned here refers to access control and includes these problems:

l Which users can access the network servers?

l Which services can the authorized users enjoy?

l How to keep accounts for users using the network resources?

Accordingly, AAA provides the following services:

I. Authentication

AAA supports the following authentication methods:

l None authentication: All users are trusted and no authentication is performed. Generally, this method is not recommended.

l Local authentication: User information (including username, password, and attributes) is configured on the device. Local authentication features high speed and low cost, but the amount of information that can be stored is limited by the hardware.

l Remote authentication: Both RADIUS and HWTACACS protocols are supported. In this approach, the device acts as the client to communicate with the RADIUS or HWTACACS server. With respect to RADIUS, you can use the standard RADIUS protocol or extended RADIUS protocol to complete authentication in collaboration with systems like iTELLIN/CAMS.

II. Authorization

AAA supports the following authorization methods:

l Direct authorization: All users are trusted and authorized. A user gets the default rights of the system.

l Local authorization: Users are authorized according to the attributes configured for them on the device.

l RADIUS authorization: RADIUS authorization is bound with RADIUS authentication. RADIUS authorization can work only after RADIUS authentication is successful. The authorization information is carried in the RADIUS authentication response.

l HWTACACS authorization: Users are authorized using a HWTACACS server.

III. Accounting

AAA supports the following accounting methods:

l None accounting: The system does not keep accounts on the users.

l Local accounting: Local accounting is for controlling the number of local user connections and collecting statistics on number of users; it does not provide statistics on the charges of users. Note that the controlling of the local user connections does not affect the local authentication and authorization.

l Remote accounting: Accounting is implemented by a RADIUS server or HWTACACS server remotely.

AAA usually uses a client/server model, where the client runs on the device that controls user access and the server stores user information. The framework of AAA thus allows for excellent scalability and centralized user information management. Being a management framework, AAA can be implemented through multiple protocols. Currently, AAA is implemented based on RADIUS or HWTACACS.

1.1.2 Introduction to ISP Domain

An Internet service provider (ISP) domain is a group of users that belong to the same ISP. For a username in the userid@isp-name format, the isp-name following the @ sign is the ISP domain name. The access device considers the userid part the username for authentication and the isp-name part the domain name.

In a networking scenario with multiple ISPs, an access device may connect users of different ISPs. Because users of different ISPs may have different user attributes (such as username and password structure, service type, and rights), it is required to configure ISP domains for them and to configure different attribute sets including the AAA policies (such as the RADIUS schemes) for the ISP domains.

1.1.3 Introduction to RADIUS

As described previously, AAA is a management framework and can be implemented through multiple protocols. However, RADIUS is usually used in practice.

I. What is RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol in the client/server model. RADIUS can prevent the network from interruption of unauthorized access and is often used in network environments where both high security and remote user access are required. For example, it is often used for managing a large number of geographically dispersed dial-in users that use Modems.

The RADIUS service involves three components:

l Protocol: Based on the UDP, RFC 2865 and RFC 2866 define the RADIUS frame format and the message transfer mechanism, and use 1812 as the authentication port and 1813 as the accounting port.

l Server: The RADIUS server runs on the computer or workstation at the center, and maintains information for user authentication and network service access.

l Client: The RADIUS client runs on the network access servers (NASs) located throughout the network.

In the client/server model of RADIUS, the client passes user information to the designated RADIUS server and acts on the response of the server (such as connecting/disconnecting users). The RADIUS server receives user connection requests, authenticates users, and returns the required information to the client.

In general, the RADIUS server maintains three databases, namely, Users, Clients, and Dictionary, as shown in Figure 1-1:

l Users: Stores user information such as the username, password, applied protocols, and IP address.

l Clients: Stores information about RADIUS clients such as the shared key.

l Dictionary: Stores the information for interpreting RADIUS protocol attributes and their values.

Figure 1-1 Components of the RADIUS server

In addition, a RADIUS server can act as the client of another AAA server to provide the proxy authentication or accounting service. A RADIUS server supports multiple user authentication methods, such as PPP-based PAP and CHAP.

II. Basic message exchange process of RADIUS

Information exchanged between the RADIUS client and the RADIUS server is authenticated through a shared key for security. The RADIUS protocol combines the authentication and authorization processes by sending authorization information in the authentication response message. For the interaction among the host, the RADIUS client, and the RADIUS server, see Figure 1-2.

Figure 1-2 Basic message exchange process of RADIUS

The following is how RADIUS operates:

1) The user enters the username and password.

2) Having received the username and password, the RADIUS client sends an authentication request (Access-Request) to the RADIUS server.

3) The RADIUS server compares the received user information with that in the Users database. If the authentication succeeds, it sends back an Access-Accept message containing the information of user’s right. If the authentication fails, it returns an Access-Reject message.

4) The RADIUS client accepts or denies the user according to the returned authentication result. If it accepts the user, it sends an accounting start request (Accounting-Request) to the RADIUS server, with the value of Status-Type being “start”.

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

6) The subscriber accesses the network resources.

7) The RADIUS client sends a stop-accounting request (Accounting-Request) to the RADIUS server, with the value of Status-Type being “stop”.

8) The RADIUS server returns a stop-accounting response (Accounting-Response).

9) The subscriber stops network resource accessing.

III. RADIUS packet structure

RADIUS uses UDP to transmit messages. It ensures the smooth message exchange between the RADIUS server and the client through a series of mechanisms, including the timer management mechanism, retransmission mechanism, and slave server mechanism. Figure 1-3 shows the RADIUS packet structure.

Figure 1-3 RADIUS packet structure

Descriptions of fields are as follows:

1) The Code field (1-byte long) is for indicating the type of the RADIUS packet. Table 1-1 gives the possible values and their meanings.

Table 1-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, that is, the authentication succeeds, 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 server rejects the user and 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 accounting on the user. It contains the Acct-Status-Type attribute, which indicates whether the server is requested to start the accounting or to end the accounting.
5	Accounting-Response	From the server to the client. The server sends to the client a packet of this type to notify that it has received the Accounting-Request and has correctly recorded the accounting information.

2) The Identifier field (1-byte long) is for matching request packets and response packets. It varies with the Attribute field and the received valid response packets, but keeps unchanged during retransmission.

3) The Length field (2-byte long) indicates the length of the entire packet, including the Code, Identifier, Length, Authenticator, and Attribute fields. Bytes beyond the length are considered the padding and are neglected at receipt. If the length of a received packet is less than that indicated by the Length field, the packet is dropped.

4) The Authenticator field (16-byte long) is used to authenticate the reply from the RADIUS server, and is also used in the password hiding algorithm. There are two kinds of authenticators: Request and Response.

5) The Attribute field carries information about the configuration details of a request or response. This field is represented in triplets of Type, Length, and Value.

l Type: One byte, in the range 1 to 255. It is for indicating the type of the attribute. Commonly used attributes for RADIUS authentication and authorization are listed in Table 1-2.

l Length: One byte for indicating the length of the attribute in bytes, including the Type, Length, and Value fields.

l Value: Value of the attribute, up to 253 bytes. Its format and content depend on the Type and Length fields.

Table 1-2 RADIUS attributes

Type	Attribute type	Type	Attribute type
1	User-Name	23	Framed-IPX-Network
2	User-Password	24	State
3	CHAP-Password	25	Class
4	NAS-IP-Address	26	Vendor-Specific
5	NAS-Port	27	Session-Timeout
6	Service-Type	28	Idle-Timeout
7	Framed-Protocol	29	Termination-Action
8	Framed-IP-Address	30	Called-Station-Id
9	Framed-IP-Netmask	31	Calling-Station-Id
10	Framed-Routing	32	NAS-Identifier
11	Filter-ID	33	Proxy-State
12	Framed-MTU	34	Login-LAT-Service
13	Framed-Compression	35	Login-LAT-Node
14	Login-IP-Host	36	Login-LAT-Group
15	Login-Service	37	Framed-AppleTalk-Link
16	Login-TCP-Port	38	Framed-AppleTalk-Network
17	(unassigned)	39	Framed-AppleTalk-Zone
18	Reply_Message	40-59	(reserved for accounting)
19	Callback-Number	60	CHAP-Challenge
20	Callback-ID	61	NAS-Port-Type
21	(unassigned)	62	Port-Limit
22	Framed-Route	63	Login-LAT-Port

The RADIUS protocol features excellent extensibility. Attribute 26 (Vender-Specific) allows a vender to define extended attributes to implement functions that the standard RADIUS protocol does not provide. Figure 1-4 illustrates a segment of a RADIUS packet containing an extended attribute.

Figure 1-4 Segment of a RADIUS packet containing an extended attribute

1.1.4 Introduction to HWTACACS

I. What is HWTACACS

Huawei Terminal Access Controller Access Control System (HWTACACS) is an enhanced security protocol based on TACACS (RFC 1492). Similar to RADIUS, it uses the server/client model to implement AAA for the accessing of different types of terminal users.

Compared with RADIUS, HWTACACS provides more reliable transmission and encryption, and therefore is more suitable for security control. Table 1-3 lists the primary differences between HWTACACS and RADIUS.

Table 1-3 Primary differences between HWTACACS and RADIUS

HWTACACS	RADIUS
Uses TCP, providing more reliable network transmission	Uses UDP
Encrypts the entire packet except for the HWTACACS header	Encrypts only the password field in an authentication packet
Separates authentication from authorization. Authentication and authorization can be deployed on different HWTACACS servers.	Performs authentication and authorization in combination
Suitable for security control	Suitable for accounting
Supports authorized use of configuration commands	Does not support authorized use of configuration commands

In a typical HWTACACS application, a terminal user needs to log onto the device for operations. Working as the HWTACACS client, the device sends the username and password to the HWTACACS server for authentication. After passing authentication and being authorized, the user can log onto the device to perform operations, as shown in Figure 1-5.

Figure 1-5 Network diagram for a typical HWTACACS application

II. Basic message exchange process of HWTACACS

The following takes Telnet user as an example to describe how HWTACACS performs user authentication, authorization, and accounting. Figure 1-6 illustrates the basic message exchange process of HWTACACS.

Figure 1-6 Basic message exchange process of HWTACACS for a Telnet user

1) A user requests to access the NAS. Upon receiving the request, the HWTACACS client sends a start-authentication packet to the HWTACACS server.

2) The HWTACACS server sends back an authentication response requesting for the username. Upon receiving the request, the HWTACACS client asks the user for the username.

3) After receiving the username from the user, the HWTACACS client sends to the server an authentication continuance packet carrying the username.

4) The HWTACACS server sends back an authentication response, requesting for the login password. Upon receipt of the response, the HWTACACS client requests the user for the login password.

5) After receiving the login password, the HWTACACS client sends to the HWTACACS server an authentication continuance packet carrying the login password.

6) The HWTACACS server sends back an authentication response indicating that the user has passed authentication.

7) The HWTACACS client sends the user authorization packet to the HWTACACS server.

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

9) Knowing that the user is now authorized, the HWTACACS client pushes the configuration interface of the router or switch to the user.

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

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

12) When the user logs off, the HWTACACS client sends a stop-accounting request to the HWTACACS server.

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

1.2 AAA/RADIUS/HWTACACS Configuration Task List

I. AAA configuration task list

Task	Remarks
Creating an ISP Domain	Required
Configuring ISP Domain Attributes	Optional
Configuring an AAA Authentication Scheme for an ISP Domain	Required For local authentication, refer to Configuring Local User Attributes. For RADIUS authentication, refer to Configuring RADIUS. For HWTACACS authentication, refer to Configuring HWTACACS.
Configuring an AAA Authorization Scheme for an ISP Domain	Optional
Configuring an AAA Accounting Scheme for an ISP Domain	Optional
Configuring Local User Attributes	Optional
Tearing down User Connections Forcibly	Optional

II. RADIUS configuration task list

Task	Remarks
Creating a RADIUS Scheme	Required
Specifying the RADIUS Authentication/Authorization Servers	Required
Configuring the RADIUS Accounting Servers and Relevant Parameters	Optional
Setting the Shared Key for RADIUS Packets	Required
Setting the Maximum Number of RADIUS Request Retransmission Attempts	Optional
Setting the Supported RADIUS Server Type	Optional
Setting the Status of RADIUS Servers	Optional
Configuring Attributes Related to the Data Sent to the RADIUS Server	Optional
Setting Timers Regarding RADIUS Servers	Optional
Configuring RADIUS Accounting-on	Optional
Configuring an IP Address for the Security Policy Server	Optional
Enabling the Listening Port of the RADIUS Client	Optional

III. HWTACACS configuration task list

Task	Remarks
Creating a HWTACACS scheme	Required
Specifying the HWTACACS Authentication Servers	Required
Specifying the HWTACACS Authorization Servers	Optional
Specifying the HWTACACS Accounting Servers	Optional
Setting the Shared Key for HWTACACS Packets	Required
Configuring Attributes Related to the Data Sent to the TACACS Server	Optional
Setting Timers Regarding HWTACACS Servers	Optional

1.3 Configuring AAA

By configuring AAA, you can provide network access service for legal users, protect the networking devices, and avoid unauthorized access and bilking. In addition, you can configure ISP domains to perform AAA on accessing users.

In AAA, users are divided into lan-access users, login users, and command line users. Except for command line users, you can configure separate authentication/authorization/accounting policies for all the other type of users. Command line users can be configured with authorization policy independently.

1.3.1 Configuration Prerequisites

For remote authentication, authorization, or accounting, you must create the RADIUS or HWTACACS scheme first.

l RADIUS scheme: Reference a configured RADIUS scheme to implement authentication/authorization and accounting. For RADIUS scheme configuration, refer to Configuring RADIUS.

l HWTACACS scheme: Reference a configured HWTACACS scheme to implement authentication/authorization and accounting. For HWTACACS scheme configuration, refer to Configuring HWTACACS.

1.3.2 Creating an ISP Domain

For the NAS, each accessing user belongs to an ISP domain. Up to 16 ISP domains can be configured on a NAS. If a user does not provide the ISP domain name, the system considers that 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 { disable \| enable isp-name }	Optional The system-default ISP domain named system by default

& Note:

l You cannot delete the default ISP domain unless you change it to a non-default ISP domain (with the domain default disable command) first.

l If a user enters a username without an ISP domain name, the device uses the authentication scheme for the default ISP domain to authenticate the user.

1.3.3 Configuring ISP Domain Attributes

Follow these steps to configure ISP domain attributes:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create an ISP domain and enter ISP domain view	domain isp-name	Required
Place the ISP domain to the state of active or blocked	state { active \| block }	Optional When created, an ISP is in the state of active by default, and users in the domain can request network services.
Specify the maximum number of users in the ISP domain	access-limit { disable \| enable max-user-number }	Optional No limit by default
Configure the idle cut function	idle-cut { disable \| enable minute }	Optional Disabled by default
Enable the self-service server localization function and specify the URL of the self-service server for changing user password	self-service-url { disable \| enable url-string }	Optional Disabled by default

& Note:

A self-service RADIUS server, for example, CAMS, is required for the self-service server localization function. With the self-service function, a user can manage and control his or her accounting information or card number. A server with self-service software is a self-service server.

1.3.4 Configuring an AAA Authentication Scheme for an ISP Domain

In AAA, authentication, authorization, and accounting are three separate processes. Authentication refers to the interactive authentication process of username/password/user information during access or service request. The authentication process neither sends authorization information to a supplicant nor triggers any accounting. You can configure AAA to use only authentication. If you do not perform any authentication configuration, the system-default ISP domain uses the local authentication scheme.

Before configuring an authentication scheme, complete these three tasks:

l For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme to be referenced first. The local and none authentication modes do not require any scheme.

l Determine the access mode or service type to be configured. With AAA, you can configure an authentication scheme specifically for each access mode and service type, limiting the authentication protocols that can be used for access.

l Determine whether to configure an authentication scheme for all access modes or service types.

Follow these steps to configure an AAA authentication scheme for 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
Specify the default authentication scheme 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 scheme for LAN access users	authentication lan-access { local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional The default authentication scheme is used by default.
Specify the authentication scheme for login users	authentication login { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional The default authentication scheme is used by default.

& Note:

l The authentication scheme specified with the authentication default command is for all types of users and has a priority lower than that for a specific access mode.

l With a RADIUS authentication scheme configured, AAA accepts only the authentication result from the RADIUS server. The response from the RADIUS server does include the authorization information when the authentication is successful, but the authentication process ignores the information.

l With the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name local keyword and argument combination configured, the local scheme is the backup scheme and is used only when the RADIUS server or TACACS server is not available.

l If the primary authentication scheme is local or none, the system performs local authentication or does not perform any authentication, rather than uses the RADIUS or HWTACACS scheme.

1.3.5 Configuring an AAA Authorization Scheme 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 server and to send authorization information to users authorized. Authorization scheme configuration is optional in AAA configuration.

If you do not perform any authorization configuration, the system-default domain uses the local authorization scheme. With the authorization scheme of none, the users are not required to be authorized, in which case an authenticated user has the default right. The default right is visiting (the lowest one) for EXEC users, that is, command line users, such as those using Telnet or SSH. The default right for FTP users is to use the root directory of the device.

Before configuring an authorization scheme, complete these three tasks:

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

2) Determine the access mode or service type to be configured. With AAA, you can configure an authorization scheme specifically for each access mode and service type, limiting the authorization protocols that can be used for access.

3) Determine whether to configure an authorization scheme for all access modes or service types.

Follow these steps to configure an AAA authorization scheme for 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
Specify the default authorization scheme 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 authorization scheme for command line users	authorization command hwtacacs-scheme hwtacacs-scheme-name	Optional The default authorization scheme is used by default.
Specify the authorization scheme for LAN access users	authorization lan-access { local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional The default authorization scheme is used by default.
Specify the authorization scheme for login users	authorization login { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional The default authorization scheme is used by default.

& Note:

l The authorization scheme specified with the authorization default command is for all types of users and has a priority lower than that for a specific access mode.

l RADIUS authorization is special in that it takes effect only when the RADIUS authorization scheme is the same as the RADIUS authentication scheme. In addition, if a RADIUS authorization fails, the error message returned to the NAS says that the server is not responding.

l If the primary authentication scheme is local or none, the system performs local authorization or does not perform any authorization, rather than uses the RADIUS or HWTACACS scheme.

l Authorization information of the RADIUS server is sent to the RADIUS client along with the authorization response message; therefore, you cannot specify a separate RADIUS server. If you use RADIUS for authorization and authentication, you must use the same scheme setting for authorization and authentication; otherwise, the system will prompt you with an error message.

1.3.6 Configuring an AAA Accounting Scheme for an ISP Domain

In AAA, accounting is a separate process at the same level as authentication and authorization. Its responsibility is to send accounting start/update/end requests to the specified accounting server. Accounting is not required, and therefore accounting scheme configuration is optional. If you do not perform any accounting configuration, the system-default domain uses the local accounting scheme.

Before configuring an authorization scheme, complete these three tasks:

1) For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be referenced first. The local and none authentication modes do not require any scheme.

2) Determine the access mode or service type to be configured. With AAA, you can configure an accounting scheme specifically for each access mode and service type, limiting the accounting protocols that can be used for access.

3) Determine whether to configure an accounting scheme for all access modes or service types.

Follow these steps to configure an AAA accounting scheme for 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
Enable the accounting optional feature	accounting optional	Optional Disabled by default
Specify the default accounting scheme 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 accounting scheme for LAN access users	accounting lan-access { local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional The default accounting scheme is used by default.
Specify the accounting scheme for login users	accounting login { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional The default accounting scheme is used by default.

& Note:

l With the accounting optional command configured, a user that will be disconnected otherwise can use the network resources even when there is no available accounting server or the communication with the current accounting server fails.

l The accounting scheme specified with the accounting default command is for all types of users and has a priority lower than that for a specific access mode.

l If the primary accounting scheme is local or none, the system performs local accounting or does not perform any accounting, rather than uses the RADIUS or HWTACACS scheme.

l With the access mode of login, accounting is not supported for FTP services.

1.3.7 Configuring Local User Attributes

For local authentication, you must create a local user and configure the attributes.

A local user represents a set of users configured on a device, which are uniquely identified by the username. For a user requesting network service to pass local authentication, you must add an entry as required in the local user database of the device.

Follow these steps to configure the attributes for a local user:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Set the password display mode for all local users		local-user password-display-mode { auto \| cipher-force }	Optional auto by default
Add a local user and enter local user view		local-user user-name	Required No local user is configured by default
Configure a password for the local user		password { cipher \| simple } password	Required
Place the local user to the state of active or blocked		state { active \| block }	Optional When created, a local user is in the state of active by default, and the user can request network services.
Specify the service types for the user	Specify the service types for the user	service-type { lan-access \| { ssh \| telnet \| terminal } * [ level level ] }	Required No service is authorized to a user by default
Specify the service types for the user	Authorize the user to use the FTP service and specify a directory for the user to access	service-type ftp [ ftp-directory directory]	Optional By default, no service is authorized to a user and anonymous access to FTP service is not allowed. If you authorize a user to use the FTP service but do not specify a directory that the user can access, the user can access the root directory of the device by default.
Set the directory accessible to FTP/SFTP users		work-directory directory-name	Optional By default, FTP/SFTP users can access the root directory.
Set the priority level of the user		level level	Optional 0 by default
Set attributes for a LAN access user		attribute { access-limit max-user-number \| idle-cut minute \| ip ip-address \| location { port slot-number subslot-number port-number } \| mac mac-address \| vlan vlan-id } *	Optional If the user is bound to a remote port, the nas-ip parameter must be specified. If the user is bound to a local port, the nas-ip parameter does not need to be specified. The default value of nas-ip is 127.0.0.1, meaning the current host.

& Note:

l With the local-user password-display-mode cipher-force command configured, a local user password is always displayed in cipher text, regardless of the configuration of the password command. In this case, if you use the save command to save the configuration, all existing local user passwords will still be displayed in cipher text after the device restarts, even if you restore the display mode to auto.

l Local authentication checks the service types of a local user. If the service types are not available, the user cannot pass authentication. During authorization, a user with no service type configured is authorized with no service by default.

l If you specify an authentication method that requires the username and password, including local authentication, RADIUS authentication and HWTACACS authentication, the level of the commands that a user can use after logging in depends on the priority of the user, or the priority of user interface level as with other authentication methods. For an SSH user using RSA public key authentication, the commands that can be used depend on the level configured on the user interface. For details regarding authentication method and command level, refer to Login Configuration and System Maintaining and Debugging Configuration respectively.

l Both the service-type and level commands can be used to specify user priority. The one used later has the final effect.

l The attribute ip command only applies to authentications that support IP address passing, such as 802.1x. If you configure the command to authentications that do not support IP address passing, such as MAC address authentication, the local authentication will fail.

l The attribute port command binds a port by its number only, regardless of the port type.

l The idle-cut command configured under user interface view applies to lan-access users only.

1.3.8 Tearing down User Connections Forcibly

Follow these steps to tear down user connections forcibly:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Tear down AAA user connections forcibly	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 Applies to only LAN access user connections at present.

To do…

Use the command…

Remarks

Enter system view

system-view

—

Tear down AAA user connections forcibly

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

Applies to only LAN access user connections at present.

1.4 Configuring RADIUS

The RADIUS protocol is configured scheme by scheme. After creating a RADIUS scheme, you need to configure the IP addresses and UDP ports of the RADIUS servers for the scheme. The servers include authentication/authorization servers and accounting servers, or from another point of view, primary servers and secondary servers. In another words, the attributes of a RADIUS scheme mainly include IP addresses of primary and secondary servers, shared key, and RADIUS server type.

Actually, the RADIUS protocol configurations only set the parameters necessary for the information interaction between a NAS and a RADIUS server. For these settings to take effect, you must reference the RADIUS scheme containing those settings in ISP domain view. For information about the commands for referencing a scheme, refer to Configuring AAA.

1.4.1 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	Optional Not defined 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

Optional

Not defined by default

& Note:

A RADIUS scheme can be referenced by more than one ISP domain at the same time.

1.4.2 Specifying the RADIUS Authentication/Authorization Servers

Follow these steps to specify the RADIUS authentication/authorization servers:

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 Not defined by default
Configure the IP address and UDP port of the primary RADIUS authentication/authorization server	primary authentication ip-address [ port-number ]	Required The defaults are as follows: 0.0.0.0 for the IP address, and 1812 for the port.
Configure the IP address and UDP port of the secondary RADIUS authentication/authorization server	secondary authentication ip-address [ port-number ]	Optional The defaults are as follows: 0.0.0.0 for the IP address, and 1812 for the port.

& Note:

l In practice, you may specify two RADIUS servers as the primary and secondary authentication/authorization servers respectively. At a moment, a server can be the primary authentication/authorization server for a scheme and the secondary authentication/authorization servers for another scheme.

l The IP addresses of the primary and secondary authentication/authorization servers for a scheme cannot be the same. Otherwise, the configuration fails.

1.4.3 Configuring the RADIUS Accounting Servers and Relevant Parameters

Follow these steps to specify the RADIUS accounting servers and perform related configurations:

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 Not defined by default
Configure the IP address and UDP port of the primary RADIUS accounting server	primary accounting ip-address [ port-number ]	Required The defaults are as follows: 0.0.0.0 for the IP address, and 1813 for the port.
Configure the IP address and UDP port of the secondary RADIUS accounting server	secondary accounting ip-address [ port-number ]	Optional The defaults are as follows: 0.0.0.0 for the IP address, and 1813 for the port.
Enable the device to buffer stop-accounting requests getting no responses	stop-accounting-buffer enable	Optional Enabled by default
Set the maximum number of stop-accounting request transmission attempts	retry stop-accounting retry-times	Optional 500 by default
Set the maximum number of accounting request transmission attempts	retry realtime-accounting retry-times	Optional 5 by default

& Note:

l In practice, you can specify two RADIUS servers as the primary and secondary accounting servers respectively; or specify one server to function as both. Besides, because RADIUS uses different UDP ports to receive authentication/authorization and accounting packets, the port for authentication/authorization must be different from that for accounting.

l You can set the maximum number of stop-accounting request transmission buffer, allowing the device to buffer and resend a stop-accounting request until it receives a response or the number of transmission retries reaches the configured limit. In the latter case, the device discards the packet.

l You can set the maximum number of accounting request transmission attempts on the device, allowing the device to disconnect a user when the number of accounting request transmission attempts for the user reaches the limit but it still receives no response to the accounting request.

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

l Currently, RADIUS does not support keeping accounts on FTP users.

1.4.4 Setting the Shared Key for RADIUS Packets

The RADIUS client and RADIUS server use the MD5 algorithm to encrypt packets exchanged between them and a shared key to verify the packets. Only when the same key is used can they properly receive the packets and make responses.

Follow these steps to set the shared key for RADIUS packets:

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 Not defined by default
Set the shared key for RADIUS authentication/authorization or accounting packets	key { accounting \| authentication } string	Required No key by default

& Note:

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

1.4.5 Setting the Maximum Number of RADIUS Request Retransmission Attempts

Because RADIUS uses UDP packets to carry data, the communication process is not reliable. If a NAS receives no response from the RADIUS server before the response timeout timer expires, it is required to retransmit the RADIUS request. If the number of transmission attempts exceeds the specified limit but it still receives no response, it considers the authentication a failure.

Follow these steps to set the maximum number of RADIUS request retransmission attempts:

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 Not defined by default
Set the number of retransmission attempts of RADIUS packets	retry retry-times	Optional 3 by default

& Note:

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

l Refer to the timer response-timeout command in the command manual for configuring RADIUS server response timeout period.

1.4.6 Setting the Supported RADIUS Server Type

Follow these steps to set the supported RADIUS server type:

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 Not defined by default
Specify the RADIUS server type supported by the device	server-type { extended \| standard }	Optional By default, the RADIUS server type is standard.

& Note:

l If you change the type of RADIUS server, the data stream destined to the original RADIUS server will be restored to the default unit.

l When a third-party RADIUS is used, you can configure the RADIUS server to standard or extended. When CAMS server is used, you must RADIUS server to extended.

1.4.7 Setting the Status of RADIUS Servers

When a primary server, authentication/authorization server or accounting server, fails, the device automatically turns to the secondary server.

When both the primary and secondary servers are available, the device sends request packets to the primary server.

Once the primary server fails, the primary server turns into the state of block, and the device turns to the secondary server. In this case:

l If the secondary server is available, the device triggers the primary server quiet timer. After the quiet timer times out, the status of the primary server is active again and the status of the secondary server remains the same.

l If the secondary server fails, the device restores the status of the primary server to active immediately.

If the primary server has resumed, the device turns to use the primary server and stops communicating with the secondary server. After accounting starts, the communication between the client and the secondary server remains unchanged.

Follow these steps to set the status of RADIUS servers:

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 Not defined by default
Set the status of the primary RADIUS authentication/authorization server	state primary authentication { active \| block }	Optional active for every server configured with IP address in the RADIUS scheme
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 { active \| block }
Set the status of the secondary RADIUS accounting server	state secondary accounting { active \| block }

& Note:

l If both the primary server and the secondary server are in the blocked state, it is necessary to manually turn the secondary server to the active state so that the secondary server can perform authentication. If the secondary server is still in the blocked state, the primary/secondary switchover cannot take place.

l If one server is in the active state while the other is blocked, the primary/secondary switchover will not take place even if the active server is not reachable.

1.4.8 Configuring Attributes Related to the Data Sent to the RADIUS Server

Follow these steps to configure the attributes related to the data sent to the RADIUS server:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enable the RADIUS trap function		radius trap { accounting-server-down \| authentication-server-down }	Optional Disabled by default
Create a RADIUS scheme and enter RADIUS scheme view		radius scheme radius-scheme-name	Required Not defined by default
Specify the format of the username to be sent to a RADIUS server		user-name-format { with-domain \| without-domain }	Optional By default, the ISP domain name is included in the username.
Specify the unit for data flows or packets to be sent to a RADIUS server		data-flow-format { data { byte \| giga-byte \| kilo-byte \| mega-byte } \| packet { giga-packet \| kilo-packet \| mega-packet \| one-packet } }*	Optional The defaults are as follows: byte for data flows, and one-packet for data packets.
Set the source IP address of the device to send RADIUS packets	In RADIUS scheme view	nas-ip ip-address	Use either command By default, the outbound port serves as the source IP address to send RADIUS packets
	In system view	quit
	In system view	radius nas-ip ip-address

& Note:

l Some earlier RADIUS servers cannot recognize usernames that contain an ISP domain name, therefore before sending a username including a domain name to such a RADIUS server, the device must remove the domain name. This command is thus provided for you to decide whether to include a domain name in a username to be sent to a RADIUS server.

l 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, thus avoiding the confused situation where the RADIUS server regards two users in different ISP domains but with the same userid as one.

l The nas-ip command in RADIUS scheme view is only for the current RADIUS scheme, while the radius nas-ip command in system view is for all RADIUS schemes. However, the nas-ip command in RADIUS scheme view overwrites the configuration of the radius nas-ip command.

1.4.9 Setting Timers Regarding RADIUS Servers

There are three timers regarding RADIUS servers:

l RADIUS server response timeout (response-timeout): If a NAS receives no response from the RADIUS server in a period of time after sending a RADIUS request (authentication/authorization or accounting request), it has to resend the request so that the user has more opportunity to obtain the RADIUS service. The NAS uses the RADIUS server response timeout timer to control the transmission interval.

l Primary server quiet timer (timer quiet): If the primary server is not reachable, its state changes to blocked, and the device will communicate with the secondary server with an IP address configured. If the secondary server is reachable, the primary server will resume active after the period specified by this timer, and the secondary server’s state does not change.

l Real-time accounting interval (realtime-accounting): This timer defines the interval for performing real-time accounting of users. After this timer is set, the switch will send accounting information of online users to the RADIUS server at the specified interval.

Follow these steps to set timers regarding RADIUS servers:

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 Not defined by default
Set the RADIUS server response timeout timer	timer response-timeout seconds	Optional 3 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:

l The product of the maximum number of retransmission attempts of RADIUS packets and the RADIUS server response timeout period cannot be greater than 75. This product is also the upper limit of the timeout time of different access modules.

l For an access module, the product of the RADIUS server response timeout period and the maximum number of retransmission attempts must be smaller than the timeout time.

l To configure the maximum number of retransmission attempts of RADIUS packets, refer to the command retry in the command manual.

1.4.10 Configuring RADIUS Accounting-on

With the accounting-on function enabled, a device sends, whenever it reboots, accounting-on packets to the RADIUS server, requesting the server to force its users offline.

Once configured, the accounting-on function is executed as soon as the device restarts and completes its configuration. In case that the majority of the RADIUS servers (a device can be configured with 16 schemes at most) fail to respond to the accounting-on packets, the number of accounting-on packet retransmission attempts is too big, or the accounting-on packet retransmission interval is too long, the device will not handle AAA services until all these packets are retransmitted and all RADIUS servers have responded to accounting-on packets.

Follow these steps to configure accounting-on function of a RADIUS server:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required Not defined by default
Enable accounting-on	accounting-on enable	Required Disabled by default
Set the number of accounting-on packet retransmission attempts	accounting-on enable send send-times	Optional 5 times by default
Set the retransmission interval of accounting-on packets	accounting-on enable interval seconds	Optional 3 seconds by default

& Note:

If the system has no authentication scheme enabled with the accounting-on function when you execute the accounting-on enable command, you need to save the configuration and restart the device so that the command takes effect. Otherwise, the command takes effect immediately.

1.4.11 Configuring an IP Address for the Security Policy Server

Follow these steps to configure an IP address for the security policy server:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required Not defined by default
Configure an IP address for the security policy server	security-policy-server ip-address	Optional Not configured by default

Caution:

l If the RADIUS server and the security policy server reside on the same physical device, you do not need to configure the IP address of the security policy server.

l The specified security policy server must be a security policy server or RADIUS server that is correctly configured and working normally. Otherwise, the device will regard it as an illegal server.

1.4.12 Enabling the Listening Port of the RADIUS Client

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

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

To do…

Use the command…

Remarks

Enter system view

system-view

—

Enable the listening port of the RADIUS client

radius client enable

Optional

Enabled by default

1.5 Configuring HWTACACS

1.5.1 Creating a HWTACACS scheme

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

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a 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 a HWTACACS scheme and enter HWTACACS scheme view

hwtacacs scheme hwtacacs-scheme-name

Required

Not defined by default

& Note:

l Up to 16 HWTACACS schemes can be configured.

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

1.5.2 Specifying the HWTACACS Authentication Servers

Follow these steps to specify the HWTACACS authentication servers:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a HWTACACS scheme and enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	Required Not defined by default
Configure the IP address and port of the primary HWTACACS authentication server	primary authentication ip-address [ port-number ]	Required The defaults are as follows: 0.0.0.0 for the IP address, and 49 for the TCP port.
Configure the IP address and port of the secondary HWTACACS authentication server	secondary authentication ip-address [ port-number ]	Required The defaults are as follows: 0.0.0.0 for the IP address, and 49 for the TCP port.

& Note:

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

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

1.5.3 Specifying the HWTACACS Authorization Servers

Follow these steps to specify the HWTACACS authorization servers:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a HWTACACS scheme and enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	Required Not defined by default
Configure the IP address and port of the primary HWTACACS authorization server	primary authorization ip-address [ port-number ]	Required The defaults are as follows: 0.0.0.0 for the IP address, and 49 for the TCP port.
Configure the IP address and port of the secondary HWTACACS authorization server	secondary authorization ip-address [ port-number ]	Required The defaults are as follows: 0.0.0.0 for the IP address, and 49 for the TCP port.

& Note:

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

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

1.5.4 Specifying the HWTACACS Accounting Servers

Follow these steps to specify the HWTACACS accounting servers and perform related configurations:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a HWTACACS scheme and enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	Required Not defined by default
Configure the IP address and port of the primary HWTACACS accounting server	primary accounting ip-address [ port-number ]	Required The defaults are as follows: 0.0.0.0 for the IP address, and 49 for the TCP port.
Configure the IP address and port of the secondary HWTACACS accounting server	secondary accounting ip-address [ port-number ]	Required The defaults are as follows: 0.0.0.0 for the IP address, and 49 for the TCP port.
Enable the device to buffer stop-accounting requests getting no responses	stop-accounting-buffer enable	Optional Enabled by default
Set the maximum number of stop-accounting request transmission attempts	retry stop-accounting retry-times	Optional 100 by default

& Note:

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

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

l Currently, HWTACACS does not support keeping accounts on FTP users.

1.5.5 Setting the Shared Key for HWTACACS Packets

When using a HWTACACS server as an AAA server, you can set a key to secure the communications between the device and the HWTACACS server.

The HWTACACS client and HWTACACS server use the MD5 algorithm to encrypt packets exchanged between them and a shared key to verify the packets. Only when the same key is used can they properly receive the packets and make responses.

Follow these steps to set the shared key for HWTACACS packets:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a HWTACACS scheme and enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	Required Not defined by default
Set the shared keys for HWTACACS authentication, authorization, and accounting packets	key { accounting \| authentication \| authorization } string	Required No shared key exists by default.

1.5.6 Configuring Attributes Related to the Data Sent to the TACACS Server

Follow these steps to configure the attributes related to the data sent to the HWTACACS server:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Create a HWTACACS scheme and enter HWTACACS scheme view		hwtacacs scheme hwtacacs-scheme-name	Required Not defined by default
Specify the format of the username to be sent to a HWTACACS server		user-name-format { with-domain \| without-domain }	Optional By default, the ISP domain name is included in the username.
Specify the unit for data flows or packets to be sent to a HWTACACS server		data-flow-format { data { byte \| giga-byte \| kilo-byte \| mega-byte } \| packet { giga-packet \| kilo-packet \| mega-packet \| one-packet } }*	Optional The defaults are as follows: byte for data flows, and one-packet for data packets.
Set the source IP address of the device to send HWTACACS packets	In HWTACACS scheme view	nas-ip ip-address	Use either command By default, the outbound port serves as the source IP address to send HWTACACS packets
	In system view	quit
	In system view	hwtacacs nas-ip ip-address

& Note:

l If a HWTACACS server does not support a username with the domain name, you can configure the device to remove the domain name before sending the username to the server.

l The nas-ip command in HWTACACS scheme view is only for the current HWTACACS scheme, while the hwtacacs nas-ip command in system view is for all HWTACACS schemes. However, the nas-ip command in HWTACACS scheme view overwrites the configuration of the hwtacacs nas-ip command.

1.5.7 Setting Timers Regarding HWTACACS Servers

Follow these steps to set timers regarding TACACS servers:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a HWTACACS scheme and enter HWTACACS scheme view	hwtacacs scheme hwtacacs-scheme-name	Required Not defined by default
Set the TACACS 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:

l For real-time accounting, a NAS must transmit the accounting information of online users to the HWTACACS accounting server periodically. Note that if the device does not receive any response to the information, it does not disconnect the online users forcibly

l The real-time accounting interval must be a multiple of 3.

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

1.6 Displaying and Maintaining AAA/RADIUS/HWTACACS

1.6.1 Displaying and Maintaining AAA

To do…	Use the command…	Remarks
Display the configuration information of a specified ISP domain or all ISP domains	display domain [ isp-name ]	Available in any view
Display information about specified or all user connections	display connection [ access-type { dot1x \| mac-authentication \| portal } \| domain isp-name \| interface interface-type interface-number \| ip ip-address \| mac mac-address \| ucibindex ucib-index \| user-name user-name \| vlan vlan-id ]	Available in any view
Display information about specified or all local users	display local-user [ domain isp-name \| idle-cut { disable \| enable } \| service-type { ftp \| lan-access \| ssh \| telnet \| terminal } \| state { active \| block } \| user-name user-name \| vlan vlan-id ]	Available in any view

1.6.2 Displaying and Maintaining RADIUS

To do…	Use the command…	Remarks
Display the configuration information of a specified RADIUS scheme or all RADIUS schemes	display radius scheme [ radius-scheme-name ]	Available in any view
Display statistics about RADIUS packets	display radius statistics	Available in any view
Display information about buffered stop-accounting requests that get no responses	display stop-accounting-buffer { radius-scheme radius-server-name \| session-id session-id \| time-range start-time stop-time \| user-name user-name }	Available in any view
Clear RADIUS statistics	reset radius statistics	Available in user view
Clear buffered stop-accounting requests that get no responses	reset stop-accounting-buffer { radius-scheme radius-server-name \| session-id session-id \| time-range start-time stop-time \| user-name user-name }	Available in user view
Clear the statistics on the local server	reset local-server statistics	Available in user view

1.6.3 Displaying and Maintaining HWTACACS

To do…	Use the command…	Remarks
Display configuration information or statistics of the specified or all HWTACACS schemes	display hwtacacs [ hwtacacs-server-name [ statistics ] ]	Available in any view
Display information about buffered stop-accounting requests that get no responses	display stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name	Available in any view
Clear HWTACACS statistics	reset hwtacacs statistics { accounting \| all \| authentication \| authorization }	Available in user view
Clear buffered stop-accounting requests that get no responses	reset stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name	Available in user view

1.7 AAA/RADIUS/HWTACACS Configuration Examples

1.7.1 AAA for Telnet Users by a HWTACACS Server

I. Network requirements

As shown in Figure 1-7, configure the switch to use the HWTACACS server to provide authentication, authorization, and accounting services to login users.

The HWTACACS server is used for authentication, authentication, and accounting. Its IP address is 10.1.1.1.

On the switch, set the shared keys for authentication, authorization, and accounting packets to expert. Configure the switch to remove the domain name from a user name before sending the user name to the HWTACACS server.

On the HWTACACS server, set the shared keys for packets exchanged with the switch to expert.

II. Network diagram

Figure 1-7 Configure AAA for Telnet users by a HWTACACS server

III. Configuration procedure

# Configure the IP addresses of various 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 authentication 10.1.1.1 49

[Switch-hwtacacs-hwtac] primary authorization 10.1.1.1 49

[Switch-hwtacacs-hwtac] primary accounting 10.1.1.1 49

[Switch-hwtacacs-hwtac] key authentication expert

[Switch-hwtacacs-hwtac] key authorization expert

[Switch-hwtacacs-hwtac] key accounting expert

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

[Switch-hwtacacs-hwtac] quit

# Apply the AAA schemes to the domain.

[Switch] domain 1

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

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

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

[Switch-isp-1] quit

# You can achieve the same purpose by setting AAA schemes for all types of users.

[Switch] domain 1

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

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

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

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

1.7.2 AAA for Telnet Users by Separate Servers

I. Network requirements

As shown in Figure 1-8, configure the switch to provide local authentication, HWTACACS authorization, and RADIUS accounting services to Telnet users. The user name and the password for Telnet users are both telnet.

The HWTACACS server is used for authorization. Its IP address is 10.1.1.2. On the switch, set the shared keys for packets exchanged with the TACACS server to expert. Configure the switch to remove the domain name from a user name before sending the user name to the HWTACACS server.

The RADIUS server is used for accounting. Its IP address is 10.1.1.1. On the switch, set the shared keys for packets exchanged with the RADIUS server to expert. Configure the switch to remove the domain name from a user name before sending the user name to the HWTACACS server.

& Note:

Configuration of separate AAA for other types of users is similar to that given in this example. The only difference lies in the access type.

II. Network diagram

Figure 1-8 Configure AAA by separate servers for Telnet users

III. Configuration procedure

# Configure the IP addresses of various 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 local user named telnet.

[Switch] local-user telnet

[Switch-luser-telnet] service-type telnet

[Switch-luser-telnet] password simple telnet

# Configure the AAA schemes of the ISP domain.

[Switch] domain 1

[Switch-isp-1] authentication login local

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

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

[Switch-isp-1] quit

# Configure the default AAA schemes for all types of users.

[Switch] domain 1

[Switch-isp-1] authentication default local

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

[Switch-isp-1] accounting default radius-scheme cams

1.8 Troubleshooting AAA/RADIUS/HWTACACS

1.8.1 Troubleshooting RADIUS

Symptom1: 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 no default ISP domain is specified for the NAS.

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

4) The password of 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 a default ISP domain is specified on the NAS.

3) The user is configured on the RADIUS server.

4) The password entered by the user is correct.

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

Symptom2: RADIUS packets cannot reach the RADIUS server.

Analysis:

1) The communication link between the NAS and the RADIUS server is down (at the physical layer and data link layer).

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.

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.

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

1.8.2 Troubleshooting HWTACACS

Refer to Troubleshooting RADIUS if you encounter a HWTACACS fault.

H3C S3610[S5510] Series Ethernet Switches Operation Manual-Release 5303(V1.01)

Chapter 1 AAA/RADIUS/HWTACACS Configuration

1.1.1 Introduction to AAA

I. Authentication

II. Authorization

III. Accounting

1.1.2 Introduction to ISP Domain

1.1.3 Introduction to RADIUS

I. What is RADIUS

II. Basic message exchange process of RADIUS

III. RADIUS packet structure

1.1.4 Introduction to HWTACACS

I. What is HWTACACS

II. Basic message exchange process of HWTACACS

1.2 AAA/RADIUS/HWTACACS Configuration Task List

I. AAA configuration task list

II. RADIUS configuration task list

III. HWTACACS configuration task list

1.3 Configuring AAA

1.3.2 Creating an ISP Domain

1.3.3 Configuring ISP Domain Attributes

1.3.4 Configuring an AAA Authentication Scheme for an ISP Domain

1.3.5 Configuring an AAA Authorization Scheme for an ISP Domain

1.3.6 Configuring an AAA Accounting Scheme for an ISP Domain

1.3.7 Configuring Local User Attributes

1.3.8 Tearing down User Connections Forcibly

1.4 Configuring RADIUS

1.4.1 Creating a RADIUS Scheme

1.4.2 Specifying the RADIUS Authentication/Authorization Servers

1.4.3 Configuring the RADIUS Accounting Servers and Relevant Parameters

1.4.4 Setting the Shared Key for RADIUS Packets

1.4.5 Setting the Maximum Number of RADIUS Request Retransmission Attempts

1.4.6 Setting the Supported RADIUS Server Type

1.4.7 Setting the Status of RADIUS Servers

1.4.8 Configuring Attributes Related to the Data Sent to the RADIUS Server

1.4.9 Setting Timers Regarding RADIUS Servers

1.4.10 Configuring RADIUS Accounting-on

1.5.1 Creating a HWTACACS scheme

1.5.2 Specifying the HWTACACS Authentication Servers

1.5.3 Specifying the HWTACACS Authorization Servers

1.5.4 Specifying the HWTACACS Accounting Servers

1.5.5 Setting the Shared Key for HWTACACS Packets

1.5.6 Configuring Attributes Related to the Data Sent to the TACACS Server

1.5.7 Setting Timers Regarding HWTACACS Servers

1.6 Displaying and Maintaining AAA/RADIUS/HWTACACS

1.7 AAA/RADIUS/HWTACACS Configuration Examples

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

1.8 Troubleshooting AAA/RADIUS/HWTACACS

1.8.1 Troubleshooting RADIUS

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us