Table of Contents

Chapter 1 AAA & RADIUS & HWTACACS Configuration. 1-1

1.1 Overview. 1-1

1.1.1 Introduction to AAA. 1-1

1.1.2 Introduction to ISP Domain. 1-2

1.1.3 Introduction to RADIUS. 1-2

1.1.4 Introduction to HWTACACS. 1-8

1.2 Configuration Tasks. 1-12

1.3 AAA Configuration. 1-14

1.3.1 Configuration Prerequisites. 1-14

1.3.2 Creating an ISP Domain. 1-15

1.3.3 Configuring the Attributes of an ISP Domain. 1-15

1.3.4 Configuring AAA Authentication of an ISP Domain. 1-16

1.3.5 Configuring AAA Authorization of an ISP Domain. 1-18

1.3.6 Configuring AAA Accounting of an ISP Domain. 1-19

1.3.7 Configuring the Attributes of a Local User 1-21

1.3.8 Cutting Down User Connections Forcibly. 1-23

1.4 RADIUS Configuration. 1-23

1.4.1 Creating a RADIUS Scheme. 1-24

1.4.2 Configuring RADIUS Authentication/Authorization Servers. 1-24

1.4.3 Configuring RADIUS Accounting Servers. 1-25

1.4.4 Configuring Shared Keys for RADIUS Packets. 1-27

1.4.5 Configuring the Maximum Number of Transmission Attempts of RADIUS Requests. 1-28

1.4.6 Configuring the Supported RADIUS Server Type. 1-29

1.4.7 Configuring the Status of RADIUS Servers. 1-29

1.4.8 Configuring the Attributes for Data to be Sent to RADIUS Servers. 1-30

1.4.9 Configuring a Local RADIUS Authentication Server 1-31

1.4.10 Configuring the Timers of RADIUS Servers. 1-32

1.5 HWTACACS Configuration. 1-33

1.5.1 Creating a HWTACAS Scheme. 1-33

1.5.2 Configuring HWTACACS Authentication Servers. 1-33

1.5.3 Configuring HWTACACS Authorization Servers. 1-34

1.5.4 Configuring HWTACACS Accounting Servers. 1-35

1.5.5 Configuring Shared Keys for RADIUS Packets. 1-36

1.5.6 Configuring the Attributes for Data to be Sent to TACACS Servers. 1-37

1.5.7 Configuring the Timers of TACACS Servers. 1-38

1.6 Displaying and Maintaining AAA & RADIUS & HWTACACS Information. 1-38

1.7 AAA & RADIUS & HWTACACS Configuration Example. 1-41

1.7.1 Remote RADIUS Authentication of Telnet/SSH Users. 1-41

1.7.2 Local Authentication, Authorization and Accounting for FTP/Telnet of Users. 1-43

1.7.3 TACACS Authentication/Authorization and Accounting of Telnet Users. 1-44

1.7.4 Local Authentication, HWTACACS Authorization and RADIUS Accounting of Telnet users  1-46

1.8 Troubleshooting AAA & RADIUS & HWTACACS Configuration. 1-47

1.8.1 Troubleshooting the RADIUS Protocol 1-47

1.8.2 Troubleshooting the HWTACACS Protocol 1-48

 

Chapter 1  AAA & RADIUS & HWTACACS Configuration

1.1  Overview

1.1.1  Introduction to AAA

AAA is shortened from the three security functions: authentication, authorization and accounting. It provides a uniform framework for you to configure the three security functions to implement the network security management.

The network security mentioned here mainly refers to access control. It mainly controls:

l           Which users can access the network,

l           Which services the users can have access to,

l           How to charge the users who are using network resources.

Accordingly, AAA provides the following services:

I. Authentication

AAA supports the following authentication methods:

l           None authentication: Users are trusted and are not authenticated. Generally, this method is not recommended.

l           Local authentication: User information (including user name, password, and attributes) is configured on this device. Local authentication is fast and requires lower operational cost. But the information storage capacity is limited by device hardware.

l           Remote authentication: Users are authenticated remotely through the RADIUS protocol or HWTACACS protocol. This device (for example, a H3C series switch) acts as the client to communicate with the RADIUS server or TACACS server. For RADIUS protocol, both standard and extended RADIUS protocols can be used.

II. Authorization

AAA supports the following authorization methods:

l           Direct authorization: Users are trusted and directly authorized. Users have the default rights now.

l           Local authorization: Users are authorized according to the related attributes configured for their local accounts on the device.

l           RADIUS authorization: Users are authorized after they pass the RADIUS authentication. The authentication and authorization of RADIUS protocol are bound together, and you cannot perform RADIUS authorization alone without RADIUS authentication.

l           HWTACACS authorization: Users are authorized by TACACS server.

III. Accounting

AAA supports the following accounting methods:

l           None accounting: No accounting is performed for users.

l           Remote accounting: User accounting is performed on the remote RADIUS server or TACACS server.

l           Local accounting: This function can count the accessed users, for a purpose of limiting access of local users.

Generally, AAA adopts the client/server structure, where the client acts as the managed resource and the server stores user information. This structure has good scalability and facilitates the centralized management of user information. AAA can be based on multiple protocols, and currently RADIUS or HWTACACS is used.

1.1.2  Introduction to ISP Domain

An Internet service provider (ISP) domain is a group of users who belong to the same ISP. For a user name in the format of userid@isp-name, the isp-name following the @ character is the ISP domain name. The access device uses userid as the user name for authentication, and isp-name as the domain name.

In a multi-ISP environment, the users connected to the same access device may belong to different domains. Since the users of different ISPs may have different attributes (such as different compositions of user name and password, different service types/rights), it is necessary to distinguish the users by setting ISP domains.

You can configure a set of ISP domain attributes (including AAA policy, RADIUS scheme, and so on) for each ISP domain independently in ISP domain view.

1.1.3  Introduction to RADIUS

AAA is a management framework. It can be implemented by not only one protocol. But in practice, the most commonly used protocol for AAA is RADIUS.

I. What is RADIUS

RADIUS (remote authentication dial-in user service) is a distributed information exchange protocol in client/server structure. It can prevent unauthorized access to the network and is commonly used in network environments where both high security and remote user access service are required.

The RADIUS service involves three components:

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

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

l           Client: The RADIUS clients run on the dial-in access server device. They can be deployed anywhere in the network.

RADIUS is based on client/server model. Acting as a RADIUS client, the switch passes user information to a designated RADIUS server, and makes processing (such as connecting/disconnecting users) depending on the responses returned from the server. The RADIUS server receives user's connection requests, authenticates users, and returns all required information to the switch.

Generally, the RADIUS server maintains the following three databases (as shown in Figure 1-1):

l           Users: This database stores information about users (such as user name, password, adopted protocol and IP address).

l           Clients: This database stores the information about RADIUS clients (such as shared keys).

l           Dictionary: This database stores the information used to interpret the attributes and attribute values of the RADIUS protocol.

Figure 1-1 Databases in RADIUS server

In addition, the RADIUS server can act as the client of some other AAA server to provide the authentication or accounting proxy service.

II. Basic message exchange procedure of RADIUS

The messages exchanged between a RADIUS client (a switch, for example) and the RADIUS server are verified by using a shared key. This enhances the security. The RADIUS protocol combines the authentication and authorization processes together by sending authorization information in the authentication response message. Figure 1-2 depicts the message exchange procedure between user, switch and RADIUS server.

Figure 1-2 Basic message exchange procedure of RADIUS

The basic message exchange procedure of RADIUS is as follows:

1)         The user enters the user name and password.

2)         The RADIUS client receives the user name and password, and then 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 to authenticate the user. If the authentication succeeds, the RADIUS server sends back an authentication response (Access-Accept), which contains the information of user’s rights, to the RADIUS client. If the authentication fails, it returns an Access-Reject response.

4)         The RADIUS client accepts or denies the user depending on the received authentication result. If it accepts the user, the RADIUS client sends a start-accounting request (Accounting-Request, with the Status-Type filed set to “start”) to the RADIUS server.

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

6)         The user starts to access the resources.

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

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

9)         The resource access of the user is ended.

III. RADIUS packet structure

RADIUS uses UDP to transmit messages. It ensures the correct message exchange between RADIUS server and client through the following mechanisms: timer management, retransmission, and backup server. Figure 1-3 depicts the structure of the RADIUS packets.

Figure 1-3 RADIUS packet structure

1)         The Code field decides the type of the RADIUS packet, as shown in Table 1-1.

Table 1-1 Description on major values of the Code field

Code	Packet type	Packet description
1	Access-Request	Direction: client->server. The client transmits this packet to the server to determine if the user can access the network. This packet carries user information. It must contain the User-Name attribute and may contain the following attributes: NAS-IP-Address, User-Password and NAS-Port.
2	Access-Accept	Direction: server->client. The server transmits this packet to the client if all the attribute values carried in the Access-Request packet are acceptable (that is, the user passes the authentication).
3	Access-Reject	Direction: server->client. The server transmits this packet to the client if any attribute value carried in the Access-Request packet is unacceptable (that is, the user fails the authentication).
4	Accounting-Request	Direction: client->server. The client transmits this packet to the server to request the server to start or end the accounting (whether to start or to end the accounting is determined by the Acct-Status-Type attribute in the packet). This packet carries almost the same attributes as those carried in the Access-Request packet.
5	Accounting-Response	Direction: server->client. The server transmits this packet to the client to notify the client that it has received the Accounting-Request packet and has correctly recorded the accounting information.

 

2)         The Identifier field (one byte) identifies the request and response packets. It is subject to the Attribute field and varies with the received valid responses, but keeps unchanged during retransmission.

3)         The Length field (two bytes) specifies the total length of the packet (including the Code, Identifier, Length, Authenticator and Attribute fields). The bytes beyond the length will be regarded as padding bytes and are ignored upon receiving the packet. If the received packet is shorter than the value of this field, it will be discarded.

4)         The Authenticator field (16 bytes) is used to verify the packet returned from the RADIUS server; it is also used in the password hiding algorithm. There are two kinds of authenticators: Request and Response.

5)         The Attribute field contains special authentication, authorization, and accounting information to provide the configuration details of a request or response packet. This field is represented by a field triplet (Type, Length and Value):

l           The Type field (one byte) specifies the type of the attribute. Its value ranges from 1 to 255. Table 1-2 lists the attributes that are commonly used in RADIUS authentication and authorization.

l           The Length field (one byte) specifies the total length of the Attribute field in bytes (including the Type, Length and Value fields).

l           The Value field (up to 253 bytes) contains the information about the attribute. Its content and format are determined by the Type and Length fields.

Table 1-2 RADIUS attributes

Value of the Type field	Attribute type	Value of the Type field	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 takes good scalability. Attribute 26 (Vender-Specific) defined in this protocol allows a device vendor to extend RADIUS to implement functions that are not defined in standard RADIUS.

Figure 1-4 depicts the structure of attribute 26. The Vendor-ID field representing the code of the vendor occupies four bytes. The first byte is 0, and the other three bytes are defined in RFC1700. Here, the vendor can encapsulate multiple customized sub-attributes (containing Type, Length and Value) to obtain extended RADIUS implementation.

Figure 1-4 Part of the RADIUS packet containing 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 (RFC1492). Similar to the RADIUS protocol, it implements AAA for different types of users (such as PPP/VPDN login users and terminal users) through communications with TACACS servers in the Client-Server mode. S5500-SI series Ethernet switches support authentication, authorization, and accounting for telnet, FTP, Aux, and SSH 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 protocols.

Table 1-3 Comparison between HWTACACS and RADIUS

HWTACACS	RADIUS
Adopts TCP, providing more reliable network transmission.	Adopts UDP.
Encrypts the entire packet except the HWTACACS header.	Encrypts only the password field in authentication packets.
Separates authentication from authorization. For example, you can provide authentication and authorization on different TACACS servers.	Brings together authentication and authorization.
Suitable for security control.	Suitable for accounting.
Supports to authorize the use of configuration commands.	Not support.

 

In a typical HWTACACS application, a dial-up or terminal user needs to log in to the device for operations. As the client of HWTACACS in this case, the switch sends the username and password to the TACACS server for authentication. After passing authentication and being authorized, the user can log in to the switch to perform operations, as shown in Figure 1-5.

Figure 1-5 Network diagram for a typical HWTACACS application

II. Basic message exchange procedure in HWTACACS

For example, use HWTACACS to implement authentication, authorization, and accounting for a telnet user. Figure 1-6 illustrates the basic message exchange procedure:

Figure 1-6 The AAA implementation procedure for a telnet user

The basic message exchange procedure is as follows:

1)         A user requests access to the switch; the TACACS client sends an authentication start request packet to TACACS server upon receipt of the request.

2)         The TACACS server sends back an authentication response requesting for the username; the TACACS client asks the user for the username upon receipt of the response.

3)         The TACACS client sends an authentication continuance packet carrying the username after receiving the username from the user.

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

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

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

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

8)         The TACACS server sends back the authorization response, indicating that the user has passed the authorization.

9)         Upon receipt of the response indicating an authorization success, the TACACS client pushes the configuration interface of the switch to the user.

10)     The TACACS client sends an accounting start request packet to the TACACS server.

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

12)     The user logs out; the TACACS client sends an accounting stop request to the TACACS server.

13)     The TACACS server sends back an accounting stop packet, indicating that the accounting stop request has been received.

1.2  Configuration Tasks

Table 1-4 Configuration tasks

Operation		Description	Related section
AAA configuration	Create an ISP domain	Required	Section 1.3.2  “Creating an ISP Domain”
	Configure the attributes of the ISP domain	Optional	Section 1.3.3  “Configuring the Attributes of an ISP Domain”
	Configure an AAA authentication scheme for the ISP domain	Required If local authentication is adopted, refer to section 1.3.7  “Configuring the Attributes of a Local User”. If RADIUS authentication is adopted, refer to section 1.4  “RADIUS Configuration”. If HWTACAC authentication is adopted , refer to section “HWTACACS Configuration ”	Section 1.3.4  Configuring AAA Authentication of an ISP Domain”
	Configure an AAA authorization scheme for the ISP domain	Optional	Section 1.3.5  “Configuring AAA Authorization of an ISP Domain”
	Configure an AAA accounting scheme for the ISP domain	Optional	Section 1.3.6  “Configuring AAA Accounting of an ISP Domain”
	Configure the attributes of a local user	Optional	Section 1.3.7  Configuring the Attributes of a Local User”
	Cut down user connections forcibly	Optional	Section 1.3.8  Cutting Down User Connections Forcibly”
RADIUS configuration	Create a RADIUS scheme	Required	Section 1.4.1  “Creating a RADIUS Scheme”
	Configure RADIUS authentication/authorization servers	Required	Section 1.4.2  “Configuring RADIUS Authentication/Authorization Servers”
	Configure RADIUS accounting servers	Required	Section 1.4.3  “Configuring RADIUS Accounting Servers”
	Configure shared keys for RADIUS packets	Required	Section 1.4.4  “Configuring Shared Keys for RADIUS Packets”
	Configure the maximum number of transmission attempts of RADIUS requests	Optional	Section 1.4.5  “Configuring the Maximum Number of Transmission Attempts of RADIUS Requests”
	Configure the supported RADIUS server type	Optional	Section 1.4.6  “Configuring the Supported RADIUS Server Type”
	Configure the status of RADIUS servers	Optional	Section 1.4.7  “Configuring the Status of RADIUS Servers”
	Configure the attributes for data to be sent to RADIUS servers	Optional	Section 1.4.8  “Configuring the Attributes for Data to be Sent to RADIUS Servers”
	Configure a local RADIUS authentication server	Optional	Section 1.4.9  “Configuring a Local RADIUS Authentication Server”
	Configure the timers for RADIUS servers	Optional	Section 1.4.10  “Configuring the Timers of RADIUS Servers”
HWTACACS configuration	Create a HWTACAS scheme	Required	Section 1.5.1  “Creating a HWTACAS Scheme”
	Configure HWTACACS authentication servers	Required	Section 1.5.2  “Configuring HWTACACS Authentication Servers”
	Configure HWTACACS authorization servers	Required	Section 1.5.3  “Configuring HWTACACS Authorization Servers”
	Configure HWTACACS accounting servers	Optional	Section 1.5.4  “Configuring HWTACACS Accounting Servers”
	Configure shared keys for RADIUS packets	Optional	Section 1.5.5  “Configuring Shared Keys for RADIUS Packets”
	Configure the attributes for data to be sent to TACACS servers	Optional	Section 1.5.6  “Configuring the Attributes for Data to be Sent to TACACS Servers”
	Configure the timers of TACACS servers	Optional	Section 1.5.7  “Configuring the Timers of TACACS Servers”

 

1.3  AAA Configuration

The goal of AAA configuration is to protect network devices against unauthorized access and at the same time provide network access services to authorized users. If you need to use ISP domains to implement AAA management on access users, you need to configure the ISP domains.

1.3.1  Configuration Prerequisites

If you want to adopt remote AAA method, you must create a RADIUS or HWTACACS scheme.

l           RADIUS scheme (radius-scheme): You can reference a configured RADIUS scheme to implement AAA services. For the configuration of RADIUS scheme, refer to section 1.4  "RADIUS Configuration".

l           HWTACACS scheme (hwtacacs-scheme): You can reference a configured HWTACACS scheme to implement AAA services. For the configuration of RADIUS scheme, refer to section 1.5  "HWTACACS Configuration".

1.3.2  Creating an ISP Domain

Table 1-5 Create an ISP domain

Operation	Command	Description
Enter system view	system-view	—
Create an ISP domain and enter its view, enter the view of an existing ISP domain,	domain isp-name	Required
Quit to system view	quit	—
configure the default ISP domain	domain default { disable | enable isp-name }	Optional The default ISP domain is "system".

 

 

1.3.3  Configuring the Attributes of an ISP Domain

Table 1-6 Configure the attributes of an ISP domain

Operation	Command	Description
Enter system view	system-view	—
Create an ISP domain or enter the view of an existing ISP domain	domain isp-name	Required
Activate/deactivate the ISP domain	state { active | block }	Optional By default, once an ISP domain is created, it is in the active state and all the users in this domain are allowed to access the network.
Set the maximum number of access users that can be contained in the ISP domain	access-limit { disable | enable max-user-number }	Optional After an ISP domain is created, the number of access users it can contain is unlimited by default.
Set the user idle-cut function	idle-cut { disable | enable minute flow }	Optional By default, user idle-cut function is disabled.
Set the self-service server location function	self-service-url { disable | enable url-string }	Optional By default, the self-service server location function is disabled.

 

 

1.3.4  Configuring AAA Authentication of an ISP Domain

Authentication, authorization and accounting are three independent service procedures in AAA. Authentication fulfills interactive authentication of user name/password/user profile to meet individual access or service requests. It neither delivers authorization message to the users who make service requests nor triggers accounting. In AAA, you can use only authentication rather than authorization or accounting. Without any configuration, by default the authentication of the domain is local. You can configure authentication according to the following three steps:

Step1: To use RADIUS solution for authentication, you first need to configure a RADIUS scheme to cite; to use local or none solution for authentication, you do not need to configure a scheme.

Step 2: Determine the access ways or service types to configure. You can configure authentication based on different access ways and service types, and restrict the authentication protocols available for access through configuration.

Step 3: Determine whether to configure a default authentication for all access ways or service types.

Table 1-7 Configure AAA authentication of an ISP domain

Operation	Command	Remarks
Enter system view	system-view	—
Create an ISP domain or enter the created ISP domain view	domain isp-name	Required
Configure authentication for all users	authentication default { radius-scheme radius-scheme-name [ local ] | hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none }	Optional By default, local authentication is used.
Configure authentication for login user	authentication login { radius-scheme radius-scheme-name [ local ] | hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none }	Optional
Configure authentication for lan-access user	authentication lan-access { radius-scheme radius-scheme-name [ local ] | local | none }	Optional

 

 

1.3.5  Configuring AAA Authorization of an ISP Domain

Authorization is an independent procedure at the same level as authentication and accounting in AAA, which is responsible for sending authorization requests to the configured authorization server and delivering relevant authorization messages to users after authorization. It is optional in the AAA configuration of an ISP domain.

By fault, the authorization scheme for an ISP domain is local. If you configure the authorization scheme as none, no authorization is required. In this case, the authenticated users have only default right. For example, by default ECEC users (for instance, Telnet users) have the lowest visit right. And FTP users are authorized to use the root directory. You can configure authorization according to the following three steps:

Step 1: If you choose HWTACACS authorization scheme, you should first define the HWTACACS scheme to be used. For RADIUS authorization, it takes effect only when the RADIUS scheme of authentication and authorization are configured similarly.

Step 2: Determine the access ways or service types to configure. You can configure authorization based on different access ways and service types, and restrict the authorization protocols available for access through configuration.

Step 3: Determine whether to configure a default authorization for all access ways or service types.

Table 1-8 Configure AAA authorization of an ISP Domain

Operation	Command	Remarks
Enter system view	system-view	—
Create an ISP domain or enter the created ISP domain view	domain isp-name	Required
Configure default authorization for all users	authorization default { radius-scheme radius-scheme-name [ local ] | hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none }	Optional
Configure authorization for login users	authorization login { radius-scheme radius-scheme-name [ local ] | hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none }	Optional
Configure authorization for lan-access users	authorization lan-access { radius-scheme radius-scheme-name [ local ] | local | none }	Optional
Configure authorization for CLI users	authorization command hwtacacs-scheme hwtacacs-scheme-name	Optional

 

 

1.3.6  Configuring AAA Accounting of an ISP Domain

Accounting is an independent procedure at the same level as authentication and authorization in AAA, which sends a request of starting/updating/ending accounting to the configured accounting server. Accounting is not required in the AAA configuration of an ISP domain. Without accounting, users accessing the domain do not need to go the accounting procedure. You can configure accounting according to the following three procedures:

Step 1: To use RADIUS or HWTACACS solution for accounting, you need to first configure the RADIUS scheme or HWTACACS scheme to cite; to use local or none solution for accounting, you do need to configure a scheme.

Step 2: Determine the access ways or service types to configure. You can configure accounting based on different access ways and service types, and restrict the accounting protocols available for access through configuration.

Step 3: Determine whether to configure a default accounting for all access ways or service types.

Table 1-9 Configure AAA accounting of an ISP domain

Operation	Command	Remarks
Enter system view	system-view	—
Create an ISP domain or enter the created ISP domain view	domain isp-name	Required
Open/close the accounting-optional switch	accounting optional	Optional By default, once an ISP domain is created, the accounting-optional switch is closed.
Configure accounting for all users	accounting default { radius-scheme radius-scheme-name [ local ] | hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none }	Optional
Configure accounting for login users	accounting login { radius-scheme radius-scheme-name [ local ] | hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none }	Optional
Configure accounting for lan-access users	accounting lan-access { radius-scheme radius-scheme-name [ local ] | local | none }	Optional

 

 

1.3.7  Configuring the Attributes of a Local User

When local scheme is chosen as the AAA scheme, you should create local users on the switch and configure the relevant attributes.

The local users are users set on the switch, with each user uniquely identified by a user name. To make a user who is requesting network service pass through the local authentication, you should add an entry in the local user database on the switch for the user.

Table 1-10 Configure the attributes of a local user

Operation		Command	Description
Enter system view		system-view	—
Set the password display mode of all local users		local-user password-display-mode { cipher-force | auto }	Optional By default, the password display mode of all access users is auto, indicating the passwords of access users are displayed in the modes set with the password command.
Add a local user and enter local user view		local-user user-name	Required By default, there is no local user in the system.
Set a password for the specified user		password { simple | cipher } password	Optional
Set the state of the specified user		state { active | block }	Optional By default, the local users are in the active state once they are created, that is, they are allowed to request network services.
Authorize the user to access the specified type(s) of service(s)	configure the service type	service-type { lan-access | { telnet | ssh | terminal } * [ level level ] }	Required By default, the system does not authorize the user to access any service.
	configure the FTP service type and accessible directories for users	service-type ftp [ ftp-directory directory]	Optional By default, anonymous users cannot access the switch using FTP or are not authorized with any FTP service; authorized FTP users can only access the root directory.
Set the priority level of the user		level level	Optional By default, the priority level of the user is 0.
Set the attributes of the user whose service type is lan-access		attribute { ip ip-address | mac mac-address | idle-cut minute | access-limit max-user-number | vlan vlan-id | location { nas-ip ip-address port portnum | port portnum } } *	Optional If the user is bound to a remote port, you must specify the nas-ip parameter (the following ip-address is 127.0.0.1 by default, representing this device). If the user is bound to a local port, you do not need to specify the nas-ip parameter.

 

 

1.3.8  Cutting Down User Connections Forcibly

Table 1-11 Cut down user connection forcibly

Operation	Command	Description
Enter system view	system-view	—
Cut down user connections forcibly	cut connection { all | access-type { dot1x | mac-authentication } | domain domain-name | interface interface-type interface-number | ip ip-address | mac mac-address | vlan vlan-id | ucibindex ucib-index | user-name user-name }	Required This command is only available for service-type of lan-access

 

1.4  RADIUS Configuration

The RADIUS protocol configuration is performed on a RADIUS scheme basis. In an actual network environment, you can either use a single RADIUS server or two RADIUS servers (primary and secondary servers with the same configuration but different IP addresses) in a RADIUS scheme. After creating a new RADIUS scheme, you should configure the IP address and UDP port number of each RADIUS server you want to use in this scheme. These RADIUS servers fall into two types: authentication/authorization, and accounting. And for each kind of server, you can configure two servers in a RADIUS scheme: primary server and secondary server. A RADIUS scheme has the following attributes: IP addresses of the primary and secondary servers, shared keys, and types of the RADIUS servers.

Actually, the RADIUS protocol configuration only defines the parameters used for information exchange between the switch and the RADIUS servers. To make these parameters take effect, you must reference the RADIUS scheme configured with these parameters in an ISP domain view. For specific configuration commands, refer to section 1.3  "AAA Configuration".

1.4.1  Creating a RADIUS Scheme

The RADIUS protocol configuration is performed on a RADIUS scheme basis. You should first create a RADIUS scheme and enter its view before performing other RADIUS protocol configurations.

Table 1-12 Create a RADIUS scheme

Operation	Command	Description
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required By default, a RADIUS scheme named "system" has already been created in the system.

 

 

1.4.2  Configuring RADIUS Authentication/Authorization Servers

Table 1-13 Configure RADIUS authentication/authorization server

Operation	Command	Description
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required By default, a RADIUS scheme named "system" has already been created in the system.
Set the IP address and port number of the primary RADIUS authentication/authorization server	primary authentication ip-address [ port-number ]	Required By default, the IP address and UDP port number of the primary server are 0.0.0.0 and 1812 respectively.
Set the IP address and port number of the secondary RADIUS authentication/authorization server	secondary authentication ip-address [ port-number ]	Optional By default, the IP address and UDP port number of the secondary server are 0.0.0.0 and 1812 respectively.

 

 

1.4.3  Configuring RADIUS Accounting Servers

Table 1-14 Configure RADIUS accounting server

Operation	Command	Description
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required By default, a RADIUS scheme named "system" has already been created in the system.
Set the IP address and port number of the primary RADIUS accounting server	primary accounting ip-address [ port-number ]	Required By default, the IP address and UDP port number of the primary accounting server are 0.0.0.0 and 1813.
Set the IP address and port number of the secondary RADIUS accounting server	secondary  accounting ip-address [ port-number ]	Optional By default, the IP address and UDP port number of the secondary accounting server are 0.0.0.0 and 1813.
Enable stop-accounting packet buffering	stop-accounting-buffer enable	Optional By default, stop-accounting packet buffering is enabled.
Enable stop-accounting packet retransmission and set the maximum number of transmission attempts of the buffered stop-accounting packets	retry stop-accounting retry-times	Optional By default, the system tries at most 500 times to transmit a buffered stop-accounting request.
Set the maximum number of real-time accounting request attempts	retry realtime-accounting retry-times	Optional By default, the maximum number of real-time accounting request attempts is 5. After that, the user connection is cut down.

 

 

1.4.4  Configuring Shared Keys for RADIUS Packets

The RADIUS client and server adopt MD5 algorithm to encrypt the RADIUS packets exchanged with each other. The two parties verify the validity of the exchanged packets by using the shared keys that have been set on them, and can accept and respond to the packets sent from each other only if both of them have the same shared keys.

Table 1-15 Configure shared keys for RADIUS packets

Operation	Command	Description
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required By default, a RADIUS scheme named "system" has already been created in the system.
Set a shared key for the RADIUS authentication/authorization packets	key authentication string	Required By default, no key is set for any RADIUS server.
Set a shared key for the RADIUS accounting packets	key accounting string	Required By default, no key is set for any RADIUS server.

 

1.4.5  Configuring the Maximum Number of Transmission Attempts of RADIUS Requests

The communication in RADIUS is unreliable because this protocol adopts UDP packets to carry data. Therefore, it is necessary for the switch to retransmit a RADIUS request if it gets no response from the RADIUS server after the response timeout timer expires. If the maximum number of transmission attempts is reached and the switch still receives no answer, the switch considers that the request fails.

Table 1-16 Configure the maximum transmission attempts of RADIUS request

Operation	Command	Description
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required By default, a RADIUS scheme named "system" has already been created in the system.
Set the maximum number of transmission attempts of RADIUS requests	retry retry-times	Optional By default, the system tries three times to transmit a RADIUS request.

 

 

1.4.6  Configuring the Supported RADIUS Server Type

Table 1-17 Configure the supported RADIUS server type

Operation	Command	Description
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required By default, a RADIUS scheme named "system" has already been created in the system.
Specify the type of RADIUS server supported by the switch	server-type { extended | standard }	Optional By default, the switch supports the standard type of RADIUS server. The type of RADIUS server in the default RADIUS scheme "system" is extended.

 

1.4.7  Configuring the Status of RADIUS Servers

For the primary and secondary servers (authentication/authorization servers, or accounting servers) in a RADIUS scheme:

When the switch fails to communicate with the primary server due to some server trouble, the switch will actively exchange packets with the secondary server.

After the time the primary server keeps in the block state exceeds the time set with the timer quiet command, the switch will try to communicate with the primary server again when it receives a RADIUS request. If the primary server recovers, the switch immediately restores the communication with the primary server instead of communicating with the secondary server, and at the same time restores the status of the primary server to the active state while keeping the status of the secondary server unchanged.

When both the primary and secondary servers are in active or block state, the switch sends packets only to the primary server.

Table 1-18 Set the status of RADIUS servers

Operation	Command	Description
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required By default, a RADIUS scheme named "system" has already been created in the system.
Set the status of the primary RADIUS authentication/authorization server	state primary authentication { block | active }	Optional By default, all the RADIUS servers in a customized RADIUS scheme are in the active state
Set the status of the primary RADIUS accounting server	state primary accounting { block | active }
Set the status of the secondary RADIUS authentication/authorization server	state secondary authentication { block | active }
Set the status of the secondary RADIUS accounting server	state secondary accounting { block | active }

 

1.4.8  Configuring the Attributes for Data to be Sent to RADIUS Servers

Table 1-19 Configure the attributes for data to be sent to the RADIUS servers

Operation	Command	Description
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required By default, a RADIUS scheme named "system" has already been created in the system.
Set the format of the user names to be sent to RADIUS servers	user-name-format { with-domain | without-domain }	Optional By default, the user names sent from the switch to RADIUS servers carry ISP domain names.
Set the units of measure for data flows sent to RADIUS servers	data-flow-format { data { byte | giga-byte | kilo-byte | mega-byte } | packet { giga-packet | kilo-packet | mega- packet | one-packet } }*	Optional By default, in a RADIIUS scheme, the unit of measure for data is byte and that for packets is one-packet.
Set the source IP address used by the switch to send RADIUS packets	RADIUS scheme view nas-ip ip-address	Optional By default, no source IP address is specified; and the IP address of the outbound interface is used as the source IP address.
	System view radius nas-ip ip-address

 

 

1.4.9  Configuring a Local RADIUS Authentication Server

Table 1-20 Configure local RADIUS authentication server

Operation	Command	Description
Enter system view	system-view	—
Create a local RADIUS authentication server	local-server nas-ip ip-address key password	Required By default, a local RADIUS authentication server, with NAS-IP 127.0.0.1, has already been created.

 

 

1.4.10  Configuring the Timers of RADIUS Servers

If the switch gets no response from the RADIUS server after sending out a RADIUS request (authentication/authorization request or accounting request) and waiting for a period of time, it should retransmit the packet to ensure that the user can obtain the RADIUS service. This wait time is called response timeout time of RADIUS servers; and the timer in the switch system that is used to control this wait time is called the response timeout timer of RADIUS servers.

Table 1-21 Set the timers of RADIUS server

Operation	Command	Description
Enter system view	system-view	—
Create a RADIUS scheme and enter its view	radius scheme radius-scheme-name	Required By default, a RADIUS scheme named "system" has already been created in the system.
Set the response timeout time of RADIUS servers	timer response-timeout seconds	Optional By default, the response timeout timer of RADIUS servers expires in three seconds.
Set the wait time for the primary server to restore the active state	timer quiet  minutes	Optional By default, the primary server waits five minutes before restoring the active state.
Set the real-time accounting interval	timer realtime-accounting minutes	Optional By default, the real-time accounting interval is 12 minutes.

 

 

1.5  HWTACACS Configuration

1.5.1  Creating a HWTACAS Scheme

HWTACACS protocol is configured scheme by scheme. Therefore, you must create a HWTACACS scheme and enter HWTACACS view before you perform other configuration tasks.

Table 1-22 Create a HWTACACS scheme

Operation	Command	Description
Enter system view	system-view	—
Create a HWTACACS scheme and enter HWTACACS view	hwtacacs scheme hwtacacs-scheme-name	Required By default, no HWTACACS scheme exists.

 

 

1.5.2  Configuring HWTACACS Authentication Servers

Table 1-23 Configure HWTACACS authentication servers

Operation	Command	Description
Enter system view	system-view	—
Create a HWTACACS scheme and enter its view	hwtacacs scheme hwtacacs-scheme-name	Required By default, no HWTACACS scheme exists.
Set the IP address and port number of the primary TACACS authentication server	primary authentication ip-address [ port ]	Required By default, the IP address of the primary authentication server is 0.0.0.0, and the port number is 49
Set the IP address and port number of the secondary TACACS authentication server	secondary authentication ip-address [ port ]	Required By default, the IP address of the secondary authentication server is 0.0.0.0, and the port number is 49.

 

 

1.5.3  Configuring HWTACACS Authorization Servers

Table 1-24 Configure TACACS authorization servers

Operation	Command	Description
Enter system view	system-view	—
Create a HWTACACS scheme and enter its view	hwtacacs scheme hwtacacs-scheme-name	Required By default, no HWTACACS scheme exists.
Set the IP address and port number of the primary TACACS authorization server	primary authorization ip-address [ port ]	Required By default, the IP address of the primary authorization server is 0.0.0.0, and the port number is 49
Set the IP address and port number of the secondary TACACS authorization server	secondary authorization ip-address [ port ]	Required By default, the IP address of the secondary authorization server is 0.0.0.0, and the port number is 49.

 

 

1.5.4  Configuring HWTACACS Accounting Servers

Table 1-25 Configure HWTACACS accounting servers

Operation	Command	Description
Enter system view	system-view	—
Create a HWTACACS scheme and enter its view	hwtacacs scheme hwtacacs-scheme-name	Required By default, no HWTACACS scheme exists.
Set the IP address and port number of the primary TACACS accounting server	primary accounting ip-address [ port ]	Required By default, the IP address of the primary accounting server is 0.0.0.0, and the port number is 49.
Set the IP address and port number of the secondary TACACS accounting server	secondary accounting ip-address [ port ]	Required By default, the IP address of the secondary accounting server is 0.0.0.0, and the port number is 49.
enable the switch to buffer the stop-accounting requests that bring no response.	stop-accounting-buffer enable	Optional By default, the switch is enabled to buffer the stop-accounting requests that bring no response.
Enable the stop-accounting packets retransmission function and set the maximum number of attempts	retry stop-accounting retry-times	Optional By default, the stop-accounting packets retransmission function is enabled and the system can transmit a stop-accounting request for 100 times.

 

 

1.5.5  Configuring Shared Keys for RADIUS Packets

When using a TACACS server as an AAA server, you can set a key to improve the communication security between the router and the TACACS server.

The TACACS client and server adopt MD5 algorithm to encrypt the exchanged HWTACACS packets. The two parties verify the validity of the exchanged packets by using the shared keys that have been set on them, and can accept and respond to the packets sent from each other only if both of them have the same shared keys.

Table 1-26 Configure shared keys for TACACS packets

Operation	Command	Description
Enter system view	system-view	—
Create a HWTACACS scheme and enter its view	hwtacacs scheme hwtacacs-scheme-name	Required By default, no HWTACACS scheme exists.
Set a shared key for the HWTACACS accounting/authentication/authorization packets	key { accounting | authorization | authentication } string	Required By default, the TACACS server does not have a key.

 

1.5.6  Configuring the Attributes for Data to be Sent to TACACS Servers

Table 1-27 Configure the attributes for data to be sent to TACACS servers

Operation	Command	Description
Enter system view	system-view	—
Create a HWTACACS scheme and enter its view	hwtacacs scheme hwtacacs-scheme-name	Required By default, no HWTACACS scheme exists.
Set the format of the user names to be sent to TACACS servers	user-name-format { with-domain | without-domain }	Optional By default, the user names sent from the switch to TACACS servers carry ISP domain names.
Set the units of measure for data flows sent to TACACS servers	data-flow-format data { byte | giga-byte | kilo-byte | mega-byte }	Optional By default, in a TACACS scheme, the unit of measure for data is byte and that for packets is one-packet.
	data-flow-format packet { giga-packet | kilo-packet | mega-packet | one-packet }
Set the source IP address used by the switch to send HWTACACS packets	HWTACACS view nas-ip ip-address	Optional By default, no source IP address is specified; the IP address of the outbound interface is used as the source IP address.
	System view hwtacacs nas-ip ip-address

 

 

1.5.7  Configuring the Timers of TACACS Servers

Table 1-28 Configure the timers of TACACS servers

Operation	Command	Description
Enter system view	system-view	—
Create a HWTACACS scheme and enter its view	hwtacacs scheme hwtacacs-scheme-name	Required By default, no HWTACACS scheme exists.
Set the response timeout time of TACACS servers	timer response-timeout seconds	Optional By default, the response timeout time is five seconds.
Set the wait time for the primary server to restore the active state	timer quiet  minutes	Optional By default, the primary server waits five minutes before restoring the active state.
Set the real-time accounting interval	timer realtime-accounting minutes	Optional By default, the real-time accounting interval is 12 minutes.

 

 

1.6  Displaying and Maintaining AAA & RADIUS & HWTACACS Information

After the above configurations, you can execute the display commands in any view to view the operation of AAA, RADIUS and HWTACACS and verify your configuration.

You can use the reset command in user view to clear the corresponding statistics.

Table 1-29 Display AAA information

Operation	Command	Description
Display the configuration information about one specific or all ISP domains	display domain [ isp-name ]	You can execute the display command in any view
Display the information about user connections	display connection [ access-type { dot1x | mac-authentication } | domain domain-name | interface interface-type interface-number | ip ip-address | mac mac-address | vlan vlan-id | ucibindex ucib-index | user-name user-name ]
Display the information about local users	display local-user [ domain isp-name | idle-cut { disable | enable } | vlan vlan-id | service-type { lan-access | telnet | ssh | terminal | ftp } | state { active | block } | user-name user-name ]

 

Table 1-30 Display  and maintain RADIUS protocol information

Operation	Command	Description
Display the statistics about local RADIUS authentication server	display local-server statistics	You can execute the display command in any view
Display the configuration information about one specific or all RADIUS schemes	display radius scheme [ radius-scheme-name ]
Display the statistics about RADIUS packets	display radius statistics
Display the buffered no-response stop-accounting request packets	display stop-accounting-buffer { radius-scheme radius-scheme-name | session-id session-id | time-range start-time stop-time | user-name user-name }
Delete the buffered no-response stop-accounting request packets	reset stop-accounting-buffer { radius-scheme radius-scheme-name | session-id session-id | time-range start-time stop-time | user-name user-name }	You can execute the reset command in user view
Clear the statistics about the RADIUS protocol	reset radius statistics

 

Table 1-31 Display and maintain HWTACACS protocol information

Operation	Command	Description
Display the configuration or statistic information about one specific or all HWTACACS schemes	display hwtacacs [ hwtacacs-scheme-name [ statistics] ]	You can execute the display command in any view
Display the buffered stop-accounting request packets that are not responded to	display stop-accounting-buffer { hwtacacs-scheme hwtacacs-scheme-name | session-id session-id | time-range start-time stop-time | user-name user-name }
Clear the statistics about the TACACS protocol	reset hwtacacs statistics { accounting | authentication | authorization | all }	You can execute the reset command in user view
Delete the buffered stop-accounting request packets that are not responded to	reset stop-accounting-buffer { hwtacacs-scheme hwtacacs-scheme-name | session-id session-id | time-range start-time stop-time | user-name user-name }

 

1.7  AAA & RADIUS & HWTACACS Configuration Example

1.7.1  Remote RADIUS Authentication of Telnet/SSH Users

 

 

I. Network requirements

In the network environment shown in Figure 1-7, you are required to configure the switch so that the Telnet users logging into the switch are authenticated by the RADIUS server.

l           A RADIUS server with IP address 10.110.91.164 is connected to the switch. This server will be used as the authentication server.

l           On the switch, set the shared key that is used to exchange packets with the authentication RADIUS server to "expert".

You can use a CAMS server as the RADIUS server. If you use a third-party RADIUS server, you can select standard or extended as the server type in the RADIUS scheme. When you use a CAMS server, you should select extended for server-type in the RADIUS scheme.

On the RADIUS server:

l           Set the shared key it uses to exchange packets with the switch to "expert".

l           Set the port number for authentication.

l           Add Telnet user names and login passwords.

The Telnet user name added to the RADIUS server must be in the format of userid@isp-name if you have configure the switch to include domain names in the user names to be sent to the RADIUS server.

II. Network diagram

Figure 1-7 Remote RADIUS authentication of Telnet users

III. Configuration procedure

# Enable Telnet server

<Sysname> system-view

[Sysname] telnet server enable

# Adopt AAA authentication for Telnet users.

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Configure an ISP domain.

[Sysname] domain cams

[Sysname-isp-cams] access-limit enable 10

[Sysname-isp-cams] quit

# Configure optional accounting. This configuration is required if the CAMS server also serves as the RADIUS severer, since the CAMS server does not respond to accounting packets. If independent RADIUS server, Windows 2000 for example, is used, this configuration is not required.

[Sysname-isp-cams] accounting optional

[Sysname-isp-cams] quit

# Configure a RADIUS scheme.

[Sysname] radius scheme cams

[Sysname-radius-cams] primary authentication 10.110.91.164 1812

[Sysname-radius-cams] primary accounting 10.110.91.164 1813

[Sysname-radius-cams] key authentication expert

[Sysname-radius-cams] key accounting expert

[Sysname-radius-cams] server-type extended

[Sysname-radius-cams] user-name-format with-domain

[Sysname-radius-cams] quit

# Configure AAA scheme for the domain. If authentication, authorization and accounting all are required, you need to configure authentication scheme, authorization scheme and accounting scheme. If only one or two types of services are required, you just configure the corresponding items accordingly.

[Sysname] domain cams

[Sysname-isp-cams] authentication login radius-scheme cams

[Sysname-isp-cams] authorization login radius-scheme cams

[Sysname-isp-cams] accounting login radius-scheme cams

# Configure default AAA scheme, in which user type is not check.

[Sysname] domain cams

[Sysname-isp-cams] authentication default radius-scheme cams

[Sysname-isp-cams] authorization default radius-scheme cams

[Sysname-isp-cams] accounting default radius-scheme cams

1.7.2  Local Authentication, Authorization and Accounting for FTP/Telnet of Users

 

 

I. Network requirements

Make local authentication, authorization and accounting schemes on the switch for Telnet users.

II. Networking diagram

Figure 1-8 Local authentication, authorization and accounting configuration for Telnet users

III. Configuration procedure

1)         Method 1: Using local authentication, authorization and accounting.

# Set Telnet users to use AAA scheme.

<Sysname> system-view

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Create local user telnet.

[Sysname] local-user telnet

[Sysname-luser-telnet] service-type telnet

[Sysname-luser-telnet] password simple H3C

[Sysname-luser-telnet] attribute idle-cut 5 access-limit 5

[Sysname-luser-telnet] quit

[Sysname] domain system

[Sysname-isp-system] authentication login local

[Sysname-isp-system] authorization login local

[Sysname-isp-system] accounting login local

# Configure default AAA schemes, in which user type is not checked.

[Sysname-isp-system] authentication default local

[Sysname-isp-system] authorization default local

[Sysname-isp-system] accounting default local

The user enters the username userid @system, to use the authentication of the system domain.

2)         Method 2: using a local RADIUS server

This method is similar to the remote authentication method described in section 1.7.1  . You only need to change the server IP address, the authentication password, and the UDP port number for authentication service in configuration step "Configure a RADIUS scheme" in section 1.7.1  to 127.0.0.1, H3C, and 1645 respectively, and configure local users

1.7.3  TACACS Authentication/Authorization and Accounting of Telnet Users

I. Network requirements

You are required to configure the switch so that the Telnet users logging in to the TACACS server are authenticated, authorized and accounted. Configure the switch to A TACACS server with IP address 10.110.91.164 is connected to the switch. This server will be used as the AAA server. On the switch, set the shared key that is used to exchange packets with the AAA TACACS server to "expert". Configure the switch to strip off the domain name in the user name to be sent to the TACACS server.

Configure the shared key to “expert” on the TACACS server for exchanging packets with the switch.

II. Networking diagram

Figure 1-9 Remote TACACS authentication authorization and accounting of Telnet users

III. Configuration procedure

# Enable Telnet server

<Sysname> system-view

[Sysname] telnet server enable

#Set Telnet users to use AAA scheme

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Configure HWTACACS scheme

[Sysname] hwtacacs scheme hwtac

[Sysname-hwtacacs-hwtac] primary authentication 10.110.91.164 49

[Sysname-hwtacacs-hwtac] primary authorization 10.110.91.164 49

[Sysname-hwtacacs-hwtac] primary accounting 10.110.91.164 49

[Sysname-hwtacacs-hwtac] key authentication expert

[Sysname-hwtacacs-hwtac] key authorization expert

[Sysname-hwtacacs-hwtac] key accounting expert

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

[Sysname-hwtacacs-hwtac] quit

# Configure AAA scheme for the domain

[Sysname] domain hwtacacs

[Sysname-isp-hwtacacs] authentication login hwtacacs-scheme hwtac

[Sysname-isp-hwtacacs] authorization login hwtacacs-scheme hwtac

[Sysname-isp-hwtacacs] accounting login hwtacacs-scheme hwtac

# Configure default AAA schemes, in which user type is not checked.

[Sysname] domain hwtacacs

[Sysname-isp-hwtacacs] authentication default hwtacacs-scheme hwtac

[Sysname-isp-hwtacacs] authorization default hwtacacs-scheme hwtac

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

1.7.4  Local Authentication, HWTACACS Authorization and RADIUS Accounting of Telnet users

I. Network requirements

Set the switch to perform local authentication, HWTACACS authorization and RADIUS accounting. The username and password both are telnet.

Configure the switch to A TACACS server with IP address 10.110.91.165 is connected to the switch. This server will be used as the Accounting server. On the switch, set the shared key that is used to exchange packets with the Accounting TACACS server to "expert".

For the AAA applications of users of other access types, their AAA configurations on the domain are similar to those of Telnet users, except different access types.

II. Networking diagram

Figure 1-10 Local authentication, HWTACACS authorization and RADIUS accounting of Telnet users

III. Configuration procedure

# Enable Telnet server

<Sysname> system-view

[Sysname] telnet server enable

# Set Telnet users to use AAA scheme

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Configure a HWTACACS scheme.

[Sysname] hwtacacs scheme hwtac

[Sysname-hwtacacs-hwtac] primary authorization 10.110.91.164 49

[Sysname-hwtacacs-hwtac] key authorization expert

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

[Sysname-hwtacacs-hwtac] quit

# Configure a RADIUS scheme.

[Sysname] radius scheme cams

[Sysname-radius-cams] primary accounting 10.110.91.165 1813

[Sysname-radius-cams] key accounting expert

[Sysname-radius-cams] server-type extended

[Sysname-radius-cams] user-name-format with-domain

[Sysname-radius-cams] quit

#Create local user telnet.

[Sysname] local-user telnet

[Sysname-luser-telnet] service-type telnet

[Sysname-luser-telnet] password simple telnet

#Configure AAA scheme for the domain

 [Sysname] domain test

[Sysname-isp-test] authentication login local

[Sysname-isp-test] authorization login hwtacacs-scheme hwtac

[Sysname-isp-test] accounting login radius-scheme cams

# Configure default AAA schemes, in which user type is not checked.

[Sysname] domain test

[Sysname-isp-test] authentication default local

[Sysname-isp-test] authorization default hwtacacs-scheme hwtac

[Sysname-isp-test] accounting default radius-scheme cams

1.8  Troubleshooting AAA & RADIUS & HWTACACS Configuration

1.8.1  Troubleshooting the RADIUS Protocol

The RADIUS protocol is at the application layer in the TCP/IP protocol suite. This protocol prescribes how the switch and the RADIUS server of the ISP exchange user information with each other.

Symptom 1: User authentication/authorization always fails.

Possible reasons and solutions:

l           The user name is not in the userid@isp-name format, or no default ISP domain is specified on the switch — Use the correct user name format, or set a default ISP domain on the switch.

l           The user is not configured in the database of the RADIUS server — Check the database of the RADIUS server, make sure that the configuration information about the user exists.

l           The user input an incorrect password — Be sure to input the correct password.

l           The switch and the RADIUS server have different shared keys — Compare the shared keys at the two ends, make sure they are identical.

l           The switch cannot communicate with the RADIUS server (you can determine by pinging the RADIUS server from the switch) — Take measures to make the switch communicate with the RADIUS server normally.

Symptom 2: RADIUS packets cannot be sent to the RADIUS server.

Possible reasons and solutions:

l           The communication links (physical/link layer) between the switch and the RADIUS server is disconnected/blocked — Take measures to make the links connected/unblocked.

l           None or incorrect RADIUS server IP address is set on the switch — Be sure to set a correct RADIUS server IP address.

l           One or all AAA UDP port settings are incorrect — Be sure to set the same UDP port numbers as those on the RADIUS server.

Symptom 3: The user passes the authentication and gets authorized, but the accounting information cannot be transmitted to the RADIUS server.

Possible reasons and solutions:

l           The accounting port number is not properly set — Be sure to set a correct port number for RADIUS accounting.

l           The switch requests that both the authentication/authorization server and the accounting server use the same device (with the same IP address), but in fact they are not resident on the same device — Be sure to configure the RADIUS servers on the switch according to the actual situation.

1.8.2  Troubleshooting the HWTACACS Protocol

See the previous section if you encounter an HWTACACS fault.