Table of Contents

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

1.1 AAA/RADIUS/HWTACACS Overview. 1-1

1.1.1 Introduction to AAA. 1-1

1.1.2 Introduction to RADIUS. 1-2

1.1.3 Introduction to HWTACACS. 1-9

1.1.4 Protocols and Standards. 1-11

1.2 Configuration Task List 1-11

1.2.1 RADIUS Configuration Task List 1-12

1.2.2 HWTACACS Configuration Task List 1-13

1.3 Configuring AAA. 1-13

1.3.1 Configuration Prerequisites. 1-14

1.3.2 Creating an ISP Domain. 1-14

1.3.3 Configuring ISP Domain Attributes. 1-15

1.3.4 Configuring Authentication Methods for an ISP Domain. 1-15

1.3.5 Configuring AAA Authorization Methods for an ISP Domain. 1-17

1.3.6 Configuring AAA Accounting Methods for an ISP Domain. 1-20

1.3.7 Configuring Local User Attributes. 1-22

1.3.8 Tearing down User Connections Forcibly. 1-25

1.4 Configuring RADIUS. 1-26

1.4.1 Creating a RADIUS Scheme. 1-26

1.4.2 Specifying the RADIUS Authentication/Authorization Servers. 1-27

1.4.3 Configuring the RADIUS Accounting Servers and Relevant Parameters. 1-28

1.4.4 Setting the Shared Key for RADIUS Packets. 1-29

1.4.5 Setting Maximum Number of RADIUS Request Retransmission Attempts. 1-30

1.4.6 Setting the Supported RADIUS Server Type. 1-31

1.4.7 Setting the Status of RADIUS Servers. 1-31

1.4.8 Configuring Attributes Related to Data to Be Sent to the RADIUS Server 1-32

1.4.9 Configuring Local RADIUS Server 1-33

1.4.10 Setting Timers Regarding RADIUS Servers. 1-34

1.5 Configuring HWTACACS. 1-35

1.5.1 Creating a HWTACACS scheme. 1-35

1.5.2 Specifying the HWTACACS Authentication Servers. 1-36

1.5.3 Specifying the HWTACACS Authorization Servers. 1-36

1.5.4 Specifying the HWTACACS Accounting Servers. 1-37

1.5.5 Setting the Shared Key for HWTACACS Packets. 1-38

1.5.6 Configuring Attributes Related to the Data Sent to the HWTACACS Server 1-39

1.5.7 Setting Timers Regarding HWTACACS Servers. 1-40

1.6 Displaying and Maintaining AAA/RADIUS/HWTACACS. 1-41

1.6.1 Displaying and Maintaining AAA. 1-41

1.6.2 Displaying and Maintaining RADIUS. 1-41

1.6.3 Displaying and Maintaining HWTACACS. 1-42

1.7 AAA/RADIUS/HWTACACS Configuration Examples. 1-43

1.7.1 AAA for Telnet/SSH Users by a RADIUS Server 1-43

1.7.2 AAA for FTP/Telnet Users by the Device Itself 1-45

1.7.3 AAA for Telnet Users by a HWTACACS Server 1-47

1.7.4 AAA for Telnet Users by Separate Servers. 1-48

1.8 Troubleshooting AAA/RADIUS/HWTACACS. 1-50

1.8.1 Troubleshooting RADIUS. 1-50

1.8.2 Troubleshooting HWTACACS. 1-51

 

Chapter 1  AAA/RADIUS/HWTACACS Configuration

When configuring AAA/RADIUS/HWTACACS, go to these sections for information you are interested in:

l           AAA/RADIUS/HWTACACS Overview

l           Configuration Task List

l           Configuring AAA

l           Configuring RADIUS

l           Configuring HWTACACS

l           Displaying and Maintaining AAA/RADIUS/HWTACACS

l           AAA/RADIUS/HWTACACS Configuration Examples

l           Troubleshooting AAA/RADIUS/HWTACACS

1.1  AAA/RADIUS/HWTACACS Overview

This section covers these topics:

l           Introduction to AAA

l           Introduction to RADIUS

l           Introduction to HWTACACS

l           Protocols and Standards

1.1.1  Introduction to AAA

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

AAA usually uses a client/server model, where the client runs on the network access server (NAS) and the server maintains user information centrally. In an AAA network, a NAS is a server for users but a client for the AAA servers, as shown in Figure 1-1.

Figure 1-1 AAA networking diagram

When a user tries to establish a connection to the NAS and to obtain the rights to access other networks or some network resources, the NAS authenticates the user or the corresponding connection. The NAS can transparently pass the user’s AAA information to the server (RADIUS server or HWTACACS server). The RADIUS/HWTACACS protocol defines how to exchange user information between a NAS and a server.

In the AAA network shown in Figure 1-1, there is a RADIUS server and a HWTACACS server. You can determine the authentication, authorization and accounting methods according to the actual requirements. For example, you can use the RADIUS server for authentication and authorization, and the HWTACACS server for accounting.

The three security functions are described as follows:

l           Authentication: Identifies remote users and judges whether a user is legal.

l           Authorization: Grants different users different rights. For example, a user logging into the server can be granted the permission to access and print the files in the server.

l           Accounting: Records all network service usage information of users, including the service type, start and end time, and traffic. In this way, accounting can be used for not only accounting itself, but also network security surveillance.

You can use AAA to provide only one or two security functions, if desired. For example, if your company only wants employees to be authenticated before they access specific resources, you can configure only an authentication server. If some users need higher priorities, you also need to configure an authorization server.

As mentioned above, AAA provides a uniform framework to implement network security management. It is a security mechanism that enables authenticated and authorized entities to access specific resources and records operations by the entities. The AAA framework thus allows for excellent scalability and centralized user information management.

AAA can be implemented through multiple protocols. Currently, the device supports using RADIUS and HWTACACS for AAA, and RADIUS is often used in practice.

1.1.2  Introduction to RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol in a client/server model. RADIUS can protect networks against unauthorized access and is often used in network environments where both high security and remote user access are required. Based on UDP, RADIUS defines the RADIUS packet format and the message transfer mechanism, and uses UDP port 1812 as the authentication port and 1813 as the accounting port.

RADIUS was originally designed for dial-in user access. With the diversification of access methods, RADIUS has been extended to support more access methods, for example, Ethernet access and ADSL access. It uses authentication and authorization in providing access services and uses accounting to collect and record usage information of network resources.

I. Client/server model

l           Client: The RADIUS client runs on the NASs located throughout the network. It passes user information to designated RADIUS servers and acts on the responses (for example, rejects or accepts user access requests).

l           Server: The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network service access. It authenticates a user after receiving a connection request and returns the processing result (for example, rejecting or accepting the user access request) to the client.

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

Figure 1-2 RADIUS server components

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 keys and IP addresses.

l           Dictionary: Stores information about the meanings of RADIUS protocol attributes and their values.

II. Securty and authentication mechanisms

Information exchanged between a RADIUS client and the RADIUS server is authenticated with a shared key, which is never transmitted over the network. This enhances the information exchange security. In addition, to prevent user passwords from being intercepted in non-secure networks, RADIUS encrypts passwords before transmitting them.

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

III. Basic message exchange process of RADIUS

Figure 1-3 depicts the basic message exchange process of RADIUS.

Figure 1-3 Basic message exchange process of RADIUS

The following is how RADIUS operates:

1)         The host initiates a connection request carrying the username and password to the RADIUS client.

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

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

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

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

6)         The subscriber accesses the network resources.

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

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

9)         The subscriber stops access to network resources.

IV. 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 backup server mechanism. Figure 1-4 shows the RADIUS packet structure.

Figure 1-4 RADIUS packet structure

Descriptions of the 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 or stop 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 and detecting retransmitted request packets. The request and response packets of the same type have the same identifier.

3)         The Length field (2-byte long) indicates the length of the entire packet, including the Code, Identifier, Length, Authenticator, and Attribute fields. The value of the field is in the range 20 to 4096. Bytes beyond the length are considered the padding and are neglected after being received. 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 replies from the RADIUS server, and is also used in the password hiding algorithm. There are two kinds of authenticators: request authenticator and response authenticator.

5)         The Attribute field, with a variable length, carries the specific authentication, authorization, and accounting information for defining configuration details of the 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 indicates the type of the attribute. Commonly used attributes for RADIUS authentication, authorization and accounting 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

No.	Name	No.	Name
1	User-Name	45	Acct-Authentic
2	User-Password	46	Acct-Session-Time
3	CHAP-Password	47	Acct-Input-Packets
4	NAS-IP-Address	48	Acct-Output-Packets
5	NAS-Port	49	Acct-Terminate-Cause
6	Service-Type	50	Acct-Multi-Session-Id
7	Framed-Protocol	51	Acct-Link-Count
8	Framed-IP-Address	52	Acct-Input-Gigawords
9	Framed-IP-Netmask	53	Acct-Output-Gigawords
10	Framed-Routing	54	(unassigned)
11	Filter-ID	55	Event-Timestamp
12	Framed-MTU	56-59	(unassigned)
13	Framed-Compression	60	CHAP-Challenge
14	Login-IP-Host	61	NAS-Port-Type
15	Login-Service	62	Port-Limit
16	Login-TCP-Port	63	Login-LAT-Port
17	(unassigned)	64	Tunnel-Type
18	Reply_Message	65	Tunnel-Medium-Type
19	Callback-Number	66	Tunnel-Client-Endpoint
20	Callback-ID	67	Tunnel-Server-Endpoint
21	(unassigned)	68	Acct-Tunnel-Connection
22	Framed-Route	69	Tunnel-Password
23	Framed-IPX-Network	70	ARAP-Password
24	State	71	ARAP-Features
25	Class	72	ARAP-Zone-Access
26	Vendor-Specific	73	ARAP-Security
27	Session-Timeout	74	ARAP-Security-Data
28	Idle-Timeout	75	Password-Retry
29	Termination-Action	76	Prompt
30	Called-Station-Id	77	Connect-Info
31	Calling-Station-Id	78	Configuration-Token
32	NAS-Identifier	79	EAP-Message
33	Proxy-State	80	Message-Authenticator
34	Login-LAT-Service	81	Tunnel-Private-Group-id
35	Login-LAT-Node	82	Tunnel-Assignment-id
36	Login-LAT-Group	83	Tunnel-Preference
37	Framed-AppleTalk-Link	84	ARAP-Challenge-Response
38	Framed-AppleTalk-Network	85	Acct-Interim-Interval
39	Framed-AppleTalk-Zone	86	Acct-Tunnel-Packets-Lost
40	Acct-Status-Type	87	NAS-Port-Id
41	Acct-Delay-Time	88	Framed-Pool
42	Acct-Input-Octets	89	(unassigned)
43	Acct-Output-Octets	90	Tunnel-Client-Auth-id
44	Acct-Session-Id	91	Tunnel-Server-Auth-id

 

 

V. Extended RADIUS Attributes

The RADIUS protocol features excellent extensibility. Attribute 26 (Vender-Specific) defined by RFC 2865 allows a vender to define extended attributes to implement functions that the standard RADIUS protocol does not provide.

A vendor can encapsulate multiple type-length-value (TLV) sub-attributes in RADIUS packets for extension in applications. As shown in Figure 1-5, a sub-attribute that can be encapsulated in Attribute 26 consists of the following four parts:

l           Vendor-ID (four bytes): Indicates the ID of the vendor. Its most significant byte is 0 and the other three bytes contain a code complying with RFC 1700. The vendor ID of H3C is 2011.

l           Vendor-Type: Indicates the type of the sub-attribute.

l           Vendor-Length: Indicates the length of the sub-attribute.

l           Vendor-Data: Indicates the contents of the sub-attribute.

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

1.1.3  Introduction to HWTACACS

Huawei Terminal Access Controller Access Control System (HWTACACS) is an enhanced security protocol based on TACACS (RFC 1492). Similar to RADIUS, it uses a client/server model for information exchange between NAS and HWTACACS server.

HWTACACS is mainly used to provide AAA services for Point-to-Point Protocol (PPP) users, Virtual Private Dial-up Network (VPDN) users, and terminal users. In a typical HWTACACS application, a terminal user needs to log into the device for operations, and HWTACACS authenticates, authorizes and keeps accounting for the user. Working as the HWTACACS client, the device sends the username and password to the HWTACACS sever for authentication. After passing authentication and being authorized, the user can log into the device to perform operations.

I. Differences between HWTACACS and RADIUS

HWTACACS and RADIUS have many common features, like implementing AAA, using a client/server model, using shared keys for user information security and having good flexibility and extensibility. Meanwhile, they also have differences, as listed in Table 1-3.

Table 1-3 Primary differences between HWTACACS and RADIUS

HWTACACS	RADIUS
Uses TCP (port 49), providing more reliable network transmission	Uses UDP, providing higher transport efficiency
Encrypts the entire packet except for the HWTACACS header	Encrypts only the user password field in an authentication packet
Protocol packets are complicated and authorization is independent of authentication. Authentication and authorization can be deployed on different HWTACACS servers.	Protocol packets are simple and authorization is combined with authentication.
Supports authorized use of configuration commands. For example, an authenticated login user can be authorized to configure the device.	Does not support authorized use of configuration commands.

 

II. Basic message exchange process of HWTACACS

The following takes a 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 Telnet user sends an access request to the NAS.

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

3)         The HWTACACS server sends back an authentication response requesting the username.

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

5)         The user inputs the username.

6)         After receiving the username from the user, the HWTACACS client sends to the server a continue-authentication packet carrying the username.

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

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

9)         The user inputs the password.

10)     After receiving the login password, the HWTACACS client sends to the HWTACACS server a continue-authentication packet carrying the login password.

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

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

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

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

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

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

17)     The user logs off.

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

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

1.1.4  Protocols and Standards

The protocols and standards related to AAA, RADIUS, and HWTACACS include:

l           RFC 2865: Remote Authentication Dial In User Service (RADIUS)

l           RFC 2866: RADIUS Accounting

l           RFC 2867: RADIUS Accounting Modifications for Tunnel Protocol Support

l           RFC 2868: RADIUS Attributes for Tunnel Protocol Support

l           RFC 2869: RADIUS Extensions

l           RFC 1492: An Access Control Protocol, Sometimes Called TACACS

1.2  Configuration Task List

The basic procedure to configure AAA/RADIUS/HWTACACS is as follows:

1)         Configure AAA methods, selecting local authentication, RADIUS authentication, or HWTACACS authentication as required.

2)         Create an ISP domain for the users and configure the domain to use the AAA methods configured in Step 1.

3)         For local authentication, configure local user attributes and add local users; for RADIUS/HWTACACS authentication, configure user attributes on the remote RADIUS/HWTACACS server.

 

 

AAA Configuration Task List

Task	Remarks
Creating an ISP Domain	Required
Configuring ISP Domain Attributes	Optional
Configuring Authentication Methods 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 AAA Authorization Methods for an ISP Domain	Optional
Configuring AAA Accounting Methods for an ISP Domain	Optional
Configuring Local User Attributes	Optional
Tearing down User Connections Forcibly	Optional

 

1.2.1  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 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 Data to Be Sent to the RADIUS Server	Optional
Configuring Local RADIUS Server	Optional
Setting Timers Regarding RADIUS Servers	Optional

 

1.2.2  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 HWTACACS 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 users (such as 802.1x authentication users and MAC authentication users), login users (SSH, Telnet, FTP, and terminal users), Portal users, PPP 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

An Internet service provider (ISP) domain represents a group of users belonging to it. For a username in the userid@isp-name format, 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. As users of different ISPs may have different user attributes (such as username and password structure, service type, and rights), you need to configure ISP domains to distinguish the users. In addition, you need to configure different attribute sets including the AAA policies (such as the RADIUS schemes) for the ISP domains.

For the device, each user belongs to an ISP domain. Up to 16 ISP domains can be configured on a device. 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	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

 

 

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 or 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
Define an IP address pool for allocating addresses to PPP users	ip pool pool-number low-ip-address [ high-ip-address ]	Optional No IP address pool is configured by default.

 

 

1.3.4  Configuring Authentication Methods 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.

AAA supports the following authentication modes:

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

l           Local authentication: Authentication is performed by the NAS. User information (including username, password, and attributes) is configured on the access 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: The access device cooperates with a RADIUS or HWTACACS server to authenticate users. As for RADIUS, the device can use the standard RADIUS protocol or extended RADIUS protocol in collaboration with systems like CAMS to implement user authentication. Remote authentication features centralized information management, high capacity, high reliability, and support for centralized authentication for multiple devices.

You can configure AAA authentication to work alone without authorization and accounting. If you do not perform any authentication configuration, the system-default ISP domain uses the local authentication mode.

Before configuring authentication methods, 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 method 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 method for all access modes or service types.

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

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create an ISP domain or enter ISP domain view	domain isp-name	Required
Specify an authentication method for all types of users	authentication default { hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none | radius-scheme radius-scheme-name [ local ] |	Optional local by default
Specify the authentication method for LAN users	authentication lan-access { local | none | radius-scheme radius-scheme-name [ local ] }	Optional
Specify the authentication method for login users	authentication login { hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none | radius-scheme radius-scheme-name [ local ] }	Optional
Specify the authentication method for Portal users	authentication portal { none | radius-scheme radius-scheme-name }	Optional
Specify the authentication method for PPP users	authentication ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none | radius-scheme radius-scheme-name [ local ] }	Optional

 

 

1.3.5  Configuring AAA Authorization Methods for an ISP Domain

In AAA, authorization is a separate process at the same level as authentication and accounting. Its responsibility is to send authorization requests to the specified authorization server and to send authorization information to users authorized. Authorization is not required.

AAA supports the following authorization modes:

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

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

l           Remote authorization: The access device cooperates with a RADIUS or HWTACACS server to authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS authorization can work only after RADIUS authentication is successful, and the authorization information is carried in the Access-Accept message. HWTACACS authorization is separate from HWTACACS authentication, and the authorization information is carried in the authorization response after successful authentication.

Authorization method configuration is optional in AAA configuration. If you do not perform any authorization configuration, the system-default domain uses the local authorization mode. With the authorization mode 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, console users who use the console, AUX, or asynchronous serial ports or Telnet/SSH to connect to the device, such as Telnet or SSH users). The default right for FTP users is to use the root directory of the device.

To configure authorization methods, follow the steps below:

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 method 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 method for all access modes or service types.

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

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create an ISP domain or enter ISP domain view	domain isp-name	Required
Specify the authorization method for all types of users	authorization default { hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none | radius-scheme radius-scheme-name [ local ] }	Optional local by default
Specify the authorization method for command line users	authorization command hwtacacs-scheme hwtacacs-scheme-name	Optional
Specify the authorization method for LAN users	authorization lan-access { local | none | radius-scheme radius-scheme-name [ local ] }	Optional
Specify the authorization method for login users	authorization login { hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none | radius-scheme radius-scheme-name [ local ] }	Optional
Specify the authorization method for Portal users	authorization portal { none | radius-scheme radius-scheme-name }	Optional
Specify the authorization method for PPP users	authorization ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none | radius-scheme radius-scheme-name [ local ] }	Optional

 

 

1.3.6  Configuring AAA Accounting Methods 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.

AAA supports the following accounting modes:

l           No accounting: The system does not perform accounting on the users.

l           Local accounting: Local accounting is implemented on the access device. It is for controlling the number of local user connections and collecting statistics on the number of users; it does not provide statistics for user charge.

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

Accounting is not required, and therefore accounting method configuration is optional. If you do not perform any accounting configuration, the system-default domain uses local accounting.

To configure authorization methods, follow the steps below:

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 method 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 method for all access modes or service types.

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

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create an ISP domain or enter ISP domain view	domain isp-name	Required
Enable the accounting optional feature	accounting optional	Optional By default, accounting-optional is disabled when an ISP domain is created.
Specify the accounting method for all types of users	accounting default { hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none | radius-scheme radius-scheme-name [ local ] }	Optional Local by default
Specify the accounting method for LAN users	accounting lan-access { local | none | radius-scheme radius-scheme-name [ local ] }	Optional
Specify the accounting method for login users	accounting login { hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none | radius-scheme radius-scheme-name [ local ] }	Optional
Specify the accounting method for Portal users	accounting portal { none | radius-scheme radius-scheme-name }	Optional
Specify the accounting method for PPP users	accounting ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none | radius-scheme radius-scheme-name [ local ] }	Optional

 

 

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
	Authorize the user to use the FTP service	service-type ftp	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.
	Authorize the user to use the PPP service and configure the callback attribute and caller number	service-type ppp [ call-number call-number [ : subcall-number ] | callback-nocheck | callback-number callback-number ]	Optional By default, no service is authorized to a user and, if the PPP service is authorized, callback without authentication is enabled, no callback number is specified, and the system does not authenticate the caller number of ISDN users.
	Set the callback attributes and calling number attributes for PPP users	service-type ppp [ call-number call-number [ : subcall-number ] | callback-nocheck | callback-number callback-number ]	Optional By default, the system does not authorize users to use any service. By default, no authentication will be performed for callback, no callback number will be set, and no calling number will be authenticated for ISDN users if users are authorized to use the PPP service.
Set the priority level of the user		level level	Optional 0 by default
Set attributes for a LAN user		attribute { access-limit max-user-number | idle-cut minute | ip ip-address | location { nas-ip ip-address port slot-number subslot-number port-number | port slot-number subslot-number port-number } | mac mac-address | vlan vlanid } *	Optional If the specified user is bound to a remote port, you must specify the nas-ip (127.0.0.1 by default, indicating the local device) keyword for the user. If the user is bound to a local port, you need not specify the nas-ip keyword.

 

 

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 user connections forcibly	cut connection { access-type { dot1x | mac-authentication | portal } | 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 user connections

 

1.4  Configuring RADIUS

The RADIUS protocol is configured on a per scheme basis. 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 device 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	Required By default, the system has created a RADIUS scheme named “system”.

 

 

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 By default, the system has created a RADIUS scheme named “system”.
Specify the primary RADIUS authentication/authorization server	primary authentication ip-address [ port-number ]	Required Configure at least one of the commands No authentication server by default
Specify the secondary RADIUS authentication/authorization server	secondary authentication ip-address [ port-number ]

 

 

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 By default, the system has created a RADIUS scheme named “system”.
Specify the primary RADIUS accounting server	primary accounting ip-address [ port-number ]	Required Configure at least one of the commands No accounting server by default
Specify the secondary RADIUS accounting server	secondary accounting ip-address [ port-number ]
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

 

 

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 By default, a RADIUS scheme named “system” has been created in the system.
Set the shared key for RADIUS authentication/authorization or accounting packets	key { accounting | authentication } string	Required No shared key by default.

 

 

1.4.5  Setting Maximum Number of RADIUS Request Retransmission Attempts

Since RADIUS uses UDP datagrams to carry data, the communication process is not reliable. If a device 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 By default, a RADIUS scheme named “system” has been created in the system.
Set the number of retransmission attempts of RADIUS packets	retry retry-times	Optional 3 by default

 

 

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 By default, a RADIUS scheme named “system” has been created in the system.
Specify the RADIUS server type supported by the device	server-type { extended | standard }	Optional By default, the supported RADIUS server type is standard. In the default system scheme, the default RADIUS server type is 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.

After the status of a primary server stays blocked for a period specified by the timer quiet command, the device tries to communicate with the primary server. If the primary server has resumed, the device turns to use the primary server and stops communicating with the secondary server. In this case, the status of the primary server is active again and the status of the secondary server remains the same. After accounting starts, the communication between the client and the secondary server remains unchanged.

If both the primary server and the secondary server are in the state of active or blocked, the device sends the packets only to the primary server.

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 By default, a RADIUS scheme named “system” has been created in the system.
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 }

 

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

Follow these steps to configure the attributes related to data to be 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 By default, a RADIUS scheme named “system” has been created in the system.
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
		radius nas-ip ip-address

 

 

1.4.9  Configuring Local RADIUS Server

The device, as a RADIUS client, supports the traditional service: perform user authentication using an authentication/authorization server and accounting server respectively. Furthermore, it provides local simple RADIUS server functions (including authentication, authorization and accounting).You can execute the following commands to configure the parameters of the local RADIUS server.

Follow the steps below to configure the local RADIUS server.

To do...	Use the Command...	Remarks
Enter system view	system-view	—
Configure local RADIUS server	local-server nas-ip ip-address key password	Required By default, no parameters are configured for the local RADIUS server.

 

 

1.4.10  Setting Timers Regarding RADIUS Servers

If a device 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 device uses the RADIUS server response timeout timer to control the transmission 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 By default, a RADIUS scheme named “system” has been created in the system.
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

 

 

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 No HWTACACS scheme exists by default.

 

 

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 No HWTACACS scheme exists by default.
Specify the primary HWTACACS authentication server	primary authentication ip-address [ port-number ]	Required Configure at least one of the commands No authentication server by default
Specify the secondary HWTACACS authentication server	secondary authentication ip-address [ port-number ]

 

 

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 No HWTACACS scheme exists by default.
Specify the primary HWTACACS authorization server	primary authorization ip-address [ port-number ]	Required Configure at least one of the commands No authorization server by default
Specify the secondary HWTACACS authorization server	secondary authorization ip-address [ port-number ]

 

 

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 No HWTACACS scheme exists by default.
Specify the primary HWTACACS accounting server	primary accounting ip-address [ port-number ]	Optional By default, both the primary and secondary accounting servers take 0.0.0.0 as the IP address and 49 as the TCP port number.
Specify the secondary HWTACACS accounting server	secondary accounting ip-address [ port-number ]
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

 

 

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 No HWTACACS scheme exists by default.
Set the shared keys for HWTACACS authentication, authorization, and accounting packets	key { accounting | authorization | authentication } string	Required No shared key exists by default.

 

1.5.6  Configuring Attributes Related to the Data Sent to the HWTACACS 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 No HWTACACS scheme exists 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
		hwtacacs nas-ip ip-address

 

 

1.5.7  Setting Timers Regarding HWTACACS Servers

Follow these steps to set timers regarding HWTACACS 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 No HWTACACS scheme exists by default.
Set the HWTACACS server response timeout timer	timer response-timeout seconds	Optional 5 seconds by default
Set the quiet timer for the primary server	timer quiet minutes	Optional 5 minutes by default
Set the real-time accounting interval	timer realtime-accounting minutes	Optional 12 minutes by default

 

 

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 ] [ slot slot-number ]	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 | ppp | ssh | telnet | terminal } | state { active | block } | user-name user-name | vlan vlan-id ] [ slot slot-number ]

 

1.6.2  Displaying and Maintaining RADIUS

To do…	Use the command…	Remarks
Display the statistics of the local RADIUS authentication server	display local-server statistics	Available in any view
Display the configuration information of a specified RADIUS scheme or all RADIUS schemes	display radius [ radius-server-name ] [ slot slot-number ]
Display statistics about RADIUS packets	display radius statistics [ slot slot-number ]
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 } [ slot slot-number ]
Clear the statistics of RADIUS	reset radius statistics [ slot slot-number ]	Available in user view
Delete the buffered stop-accounting packets that are not responded	reset stop-accounting-buffer { radius-scheme radius-server-name | session-id session-id | time-range start-time stop-time | user-name user-name } [ slot slot-number ]
Clear the statistics of the local server.	reset local-server statistics

 

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 [ slot slot-number ] ] ]	Available in any view
Display information about buffered stop-accounting requests that get no responses	display stop-accounting-buffer { hwtacacs-scheme hwtacacs-scheme-name | session-id session-id | time-range start-time stop-time | user-name user-name } [ slot slot-number ]
Clear the statistics of HWTACACS	reset hwtacacs statistics { accounting | all | authentication | authorization } [ slot slot-number ]	Available in user view
Clear the buffered stop-accounting packets that are not responded	reset stop-accounting-buffer { hwtacacs-scheme hwtacacs-scheme-name | session-id session-id | time-range start-time stop-time | user-name user-name } [ slot slot-number ]

 

1.7  AAA/RADIUS/HWTACACS Configuration Examples

1.7.1  AAA for Telnet/SSH Users by a RADIUS Server

 

 

I. Network requirements

l           Configure the switch so that the RADIUS server can perform authentication, authorization and accounting to Telnet users, as shown in Figure 1-7.

l           Connect the RADIUS server of CAMS (functioning as an authentication/accounting RADIUS server) to the switch. The IP address of the server is 10.1.1.1.

l           Configure the shared key whereby the switch and authentication RADIUS server exchange packets as expert, configure the shared key whereby the switch and accounting RADIUS server exchange packets as expert, and configure the username sent to the RADIUS server to contain domain name information.

l           Configure the shared key whereby to exchange packets with the switch to expert on the RADIUS server, set the number of the port for authentication and accounting, and add a Telnet username and login password (the format of the username is userid@isp-name).

II. Network diagram

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

III. Configuration procedure

# Enable the Telnet server on the switch.

<Sysname> system-view

[Sysname] telnet server enable

# Configure the switch to use AAA for authenticating Telnet users.

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Create an ISP domain.

[Sysname] domain 1

# Configure the accounting to be optional. As a CAMS server does not respond to any accounting packets, this is required for a CAMS server.

[Sysname-isp-1] accounting optional

[Sysname-isp-1] quit

# Configure the RADIUS scheme.

<Sysname> system-view

[Sysname] radius scheme rad

[Sysname-radius-rad] primary authentication 10.1.1.1 1812

[Sysname-radius-rad] primary accounting 10.1.1.1 1813

[Sysname-radius-rad] key authentication expert

[Sysname-radius-rad] key accounting expert

[Sysname-radius-rad] server-type extended

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

[Sysname-radius-rad] quit

# Apply the AAA schemes to the domain. Here all the three schemes of authentication, authorization, and accounting schemes are configured.

<Sysname> system-view

[Sysname] domain 1

[Sysname-isp-1] authentication login radius-scheme rad

[Sysname-isp-1] authorization login radius-scheme rad

[Sysname-isp-1] accounting login radius-scheme rad

[Sysname-isp-1] quit

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

[Sysname] domain 1

[Sysname-isp-1] authentication default radius-scheme rad

[Sysname-isp-1] authorization default radius-scheme rad

[Sysname-isp-1] accounting default radius-scheme rad

1.7.2  AAA for FTP/Telnet Users by the Device Itself

 

 

I. Network requirements

As shown in Figure 1-8, configure the switch to perform local authentication, authorization, and accounting of Telnet users.

II. Network diagram

Figure 1-8 Configure local authentication/authorization/accounting for Telnet users

III. Configuration procedure

1)         Solution 1: Use local authentication, authorization, and accounting

# Enable the Telnet server on the device.

<Sysname> system-view

[Sysname] telnet server enable

# Configure the switch to use AAA for Telnet users.

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Create local user named telnet.

<Sysname> system-view

[Sysname] local-user telnet

[Sysname-luser-telnet] service-type telnet

[Sysname-luser-telnet] password simple aabbccddeeff

[Sysname-luser-telnet] quit

# Configure the AAA schemes the ISP domain as local authentication, authorization and accounting.

[Sysname] domain system

[Sysname-isp-system] authentication login local

[Sysname-isp-system] authorization login local

[Sysname-isp-system] accounting login local

[Sysname-isp-system] quit

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

[Sysname] domain system

[Sysname-isp-system] authentication default local

[Sysname-isp-system] authorization default local

[Sysname-isp-system] accounting default local

When a user is telneting into the router, the user can use the user name of userid @system for local authentication.

2)         Solution 2: Use the local RADIUS server

This solution is similar to that given in AAA for Telnet/SSH Users by a RADIUS Server. But you only need to do the following:

l           Configuring the local user;

l           Configuring the authentication/authorization server, with IP address 126.0.0.1, shared key aabbcc, UDP port for authentication/authorization 1645, and UDP port for accounting 1646.

l           Configuring the local RADIUS server, with IP address 126.0.0.1, shared key aabbcc.

The detailed configuration is as follows:

# Enable the Telnet server on the device.

<Sysname> system-view

[Sysname] telnet server enable

# Configure the switch to use AAA for Telnet users.

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Create a local user named telnet.

[Sysname] local-user telnet

[Sysname-luser-telnet] service-type telnet

[Sysname-luser-telnet] password simple aabbccddeeff

[Sysname-luser-telnet] quit

# Configure the RADIUS scheme.

[Sysname] radius scheme rad

[Sysname-radius-rad] primary authentication 126.0.0.1 1645

[Sysname-radius-rad] primary accounting 126.0.0.1 1646

[Sysname-radius-rad] key authentication aabbcc

[Sysname-radius-rad] key accounting aabbcc

[Sysname-radius-rad] server-type extended

# Specify the AAA scheme for the domain.

[Sysname] domain 1

[Sysname-isp-1] authentication login radius-scheme rad

[Sysname-isp-1] authorization login radius-scheme rad

[Sysname-isp-1] accounting login radius-scheme rad

[Sysname-isp-cams] quit

# Specify the local RADIUS server.

[Sysname] local-server nas-ip 126.0.0.1 key aabbcc

1.7.3  AAA for Telnet Users by a HWTACACS Server

I. Network requirements

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

l           The HWTACACS server is used for authentication, authentication, and accounting, and is connected to the switch. Its IP address is 10.1.1.1.

l           On the switch, set the shared keys for authentication, authorization, and accounting packets to expert. The username that the switch sends to the HWTACACS server contains no domain name.

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

II. Network diagram

Figure 1-9 Configure AAA for Telnet users by a HWTACACS Server

III. Configuration procedure

# Enable the Telnet server function on the switch.

<Sysname> system-view

[Sysname] telnet server enable

# Configure AAA for Telnet users.

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Configure the HWTACACS scheme.

<Sysname> system-view

[Sysname] hwtacacs scheme hwtac

[Sysname-hwtacacs-hwtac] primary authentication 10.1.1.1 49

[Sysname-hwtacacs-hwtac] primary authorization 10.1.1.1 49

[Sysname-hwtacacs-hwtac] primary accounting 10.1.1.1 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

# Specify the AAA schemes for the domain.

<Sysname> system-view

[Sysname] domain 1

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

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

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

[Sysname-isp-1] quit

# Or configure the default AAA schemes for all types of users.

[Sysname] domain 1

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

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

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

1.7.4  AAA for Telnet Users by Separate Servers

I. Network requirements

As shown in Figure 1-10, 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 telnet and telnet123456.

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

 

 

II. Network diagram

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

III. Configuration procedure

# Enable the Telnet server on the switch.

<Sysname> system-view

[Sysname] telnet server enable

# Configure the switch to use AAA for Telnet users.

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Configure the HWTACACS scheme.

<Sysname> system-view

[Sysname] hwtacacs scheme hwtac

[Sysname-hwtacacs-hwtac] primary authorization 10.1.1.2 49

[Sysname-hwtacacs-hwtac] key authorization expert

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

[Sysname-hwtacacs-hwtac] quit

# Configure the RADIUS scheme.

<Sysname> system-view

[Sysname] radius scheme rd

[Sysname-radius-rd] primary accounting 10.1.1.1 1813

[Sysname-radius-rd] key accounting expert

[Sysname-radius-rd] server-type extended

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

[Sysname-radius-rd] quit

# Create local user named telnet.

<Sysname> system-view

[Sysname] local-user telnet

[Sysname-luser-telnet] service-type telnet

[Sysname-luser-telnet] password simple telnet123456

# Configure the AAA schemes of the ISP domain.

<Sysname> system-view

[Sysname] domain 1

[Sysname-isp-1] authentication login local

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

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

[Sysname-isp-1] quit

# Or configure the default AAA schemes for all types of users.

[Sysname] domain 1

[Sysname-isp-1] authentication default local

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

[Sysname-isp-1] accounting default radius-scheme rd

1.8  Troubleshooting AAA/RADIUS/HWTACACS

1.8.1  Troubleshooting RADIUS

Symptom 1: User authentication/authorization always fails.

Analysis:

l           The username is not in the format of “userid@isp-name”, or no default ISP domain is specified for the device.

l           This user is not available in the database of the RADIUS server.

l           The user does not enter a correct password.

l           The shared key on the RADIUS server is different from that on the device.

l           The device cannot communicate with the RADIUS server (you can check the communication by pinging the RADIUS server on the device).

Solution:

Check that:

l           The NAS and the RADIUS server can communicate normally.

l           The username is in the userid@isp-name format and a default ISP domain is specified on the NAS.

l           The user is configured on the RADIUS server.

l           The correct password is entered.

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

Symptom 2: RADIUS packets cannot reach the RADIUS server.

Analysis:

l           The device fails to communicate with the RADIUS server (on physical layer or link layer).

l           No IP address is assigned to the RADIUS server on the device.

l           The UDP ports for authentication/authorization and accounting are not configured correctly.

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

Solution:

Check that:

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

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

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

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

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

Analysis:

l           The accounting port is not correctly configured.

l           The accounting server and authentication/authorization server are not the same equipment. However, the device requires that authentication/authorization and accounting should be performed on the same server (they should have the same IP address).

Solution:

Check that:

l           The accounting port number is correctly set.

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