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

1.2 Configuration Task. 1-11

1.3 AAA Configuration. 1-13

1.3.1 Configuration Prerequisites. 1-13

1.3.2 Creating an ISP Domain. 1-14

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

1.3.4 Configuring an AAA Scheme for an ISP Domain. 1-15

1.3.5 Configuring Dynamic VLAN Assignment 1-18

1.3.6 Configuring the Attributes of a Local User 1-20

1.3.7 Cutting Down User Connections Forcibly. 1-22

1.4 RADIUS Configuration. 1-22

1.4.1 Creating a RADIUS Scheme. 1-23

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 Messages. 1-26

1.4.5 Configuring Maximum Number of Transmission Attempts of RADIUS Request 1-27

1.4.6 Configuring to Support a Type of RADIUS Server 1-28

1.4.7 Configuring the Status of RADIUS Servers. 1-28

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

1.4.9 Configuring Local RADIUS Authentication Server 1-30

1.4.10 Configuring the Timers of RADIUS Servers. 1-31

1.4.11 Enabling the Sending of Trap Message When a RADIUS Server is Down. 1-32

1.4.12 Enabling the User Re-Authentication at Restart Function. 1-33

1.5 HWTACACS Configuration. 1-34

1.5.1 Creating a HWTACAS Scheme. 1-34

1.5.2 Configuring HWTACACS Authentication Servers. 1-35

1.5.3 Configuring HWTACACS Authorization Servers. 1-36

1.5.4 Configuring HWTACACS Accounting Servers. 1-37

1.5.5 Configuring Shared Keys for HWTACACS Messages. 1-37

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

1.5.7 Configuring the Timers of TACACS Servers. 1-39

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

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

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

1.7.2 Local Authentication of FTP/Telnet Users. 1-44

1.7.3 HWTACACS Authentication and Authorization of Telnet Users. 1-45

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

1.8.1 Troubleshooting RADIUS Configuration. 1-46

1.8.2 Troubleshooting HWTACACS Configuration. 1-47

Chapter 2 EAD Configuration. 2-1

2.1 Introduction to EAD. 2-1

2.2 Typical Network Application of EAD. 2-1

2.3 EAD Configuration. 2-2

2.4 EAD Configuration Example. 2-3

 

Chapter 1  AAA & RADIUS & HWTACACS Configuration

1.1  Overview

1.1.1  Introduction to AAA

AAA is an acronym for the three security functions: authentication, authorization and accounting. It provides a uniform framework for you to configure the three security functions to implement 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 are available to the users who can access the network, and

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

Accordingly, AAA provides the following three functions:

I. Authentication

AAA supports the following authentication methods:

l           None authentication: Users are trusted and are not checked for their validity. Generally, this method is not recommended.

l           Local authentication: User information (including user name, password, and some other attributes) is configured on this device, and users are authenticated on this device instead of on a remote device. Local authentication is fast and requires lower operational cost, but has the deficiency that information storage capacity is limited by device hardware.

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

II. Authorization

AAA supports the following authorization methods:

l           Direct authorization: Users are trusted and directly authorized.

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

l           RADIUS authorization: Users are authorized after they pass RADIUS authentication. In RADIUS protocol, authentication and authorization are combined together, and authorization cannot be performed alone without authentication.

l           HWTACACS authorization: Users are authorized by a 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 a remote RADIUS or TACACS server.

Generally, AAA adopts 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.

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 forms of user name and password, different service types/access 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 based on client/server structure. It can prevent unauthorized access to your 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 message format and message transfer mechanism of RADIUS, and define 1812 as the authentication port and 1813 as the accounting port.

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

l           Client: RADIUS Client runs on dial-in access server devices throughout the network.

RADIUS is based on client/server model. A switch acting as a RADIUS client passes user information to a specified RADIUS server, and takes appropriate action (such as establishing/terminating user connection) depending on the responses returned from the server. The RADIUS server receives user connection requests, authenticates users, and returns all required information to the switch.

Generally, a RADIUS server maintains the following three databases (see Figure 1-1):

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

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

l           Dictionary: The information stored in this database is used to interpret the attributes and attribute values in the RADIUS protocol.

Figure 1-1 Databases in a RADIUS server

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

II. Basic message exchange procedure in RADIUS

The messages exchanged between a RADIUS client (a switch, for example) and a RADIUS server are verified through a shared key. This enhances the security. The RADIUS protocol combines the authentication and authorization processes together by sending authorization information along with 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 to the RADIUS client an authentication response (Access-Accept), which contains the user’s access right information. If the authentication fails, the server 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 attribute value = start) to the RADIUS server.

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

6)         The user starts to access network resources.

7)         The RADIUS client sends a stop-accounting request (Accounting-Request, with the Status-Type attribute value = stop) to the RADIUS server.

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

9)         The access to network resources is ended.

III. RADIUS message format

RADIUS messages are transported over UDP, which does not guarantee reliable delivery of messages between RADIUS server and client. As a remedy, RADIUS adopts the following mechanisms: timer management, retransmission, and backup server. Figure 1-3 depicts the format of RADIUS messages.

Figure 1-3 RADIUS message format

1)         The Code field (one byte) decides the type of RADIUS message, as shown in Table 1-1.

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

Code	Message type	Message description
1	Access-Request	Direction: client->server. The client transmits this message to the server to determine if the user can access the network. This message 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 message to the client if all the attribute values carried in the Access-Request message are acceptable (that is, the user passes the authentication).
3	Access-Reject	Direction: server->client. The server transmits this message to the client if any attribute value carried in the Access-Request message is unacceptable (that is, the user fails the authentication).
4	Accounting-Request	Direction: client->server. The client transmits this message 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 message). This message carries almost the same attributes as those carried in the Access-Request message.
5	Accounting-Response	Direction: server->client. The server transmits this message to the client to notify the client that it has received the Accounting-Request message and has correctly recorded the accounting information.

 

2)         The Identifier field (one byte) is used to match requests and responses. It changes whenever the content of the Attributes field change, and whenever a valid response has been received for a previous request, but remains unchanged for message retransmission.

3)         The Length field (two bytes) specifies the total length of the message (including the Code, Identifier, Length, Authenticator and Attributes fields). The bytes beyond the length are regarded as padding and are ignored upon reception. If a received message is shorter than what the Length field indicates, it is discarded.

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

5)         The Attributes field contains specific authentication/authorization/accounting information to provide the configuration details of a request or response message. This field contains a list of field triplet (Type, Length and Value):

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

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

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

Table 1-2 RADIUS attributes

Type field value	Attribute type	Type field value	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 has 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 format of attribute 26. The Vendor-ID field used to identify a vendor occupies four bytes, where the first byte is 0, and the other three bytes are defined in RFC 1700. Here, the vendor can encapsulate multiple customized sub-attributes (containing vendor-specific Type, Length and Value) to implement a RADIUS extension.

Figure 1-4 Vendor-specific attribute format

1.1.4  Introduction to HWTACACS

I. What is HWTACACS

HWTACACS (Huawei terminal access controller access control system) is an enhanced security protocol based on TACACS (RFC 1492). Similar to the RADIUS protocol, it implements AAA for different types of users (such as PPP, VPDN, and terminal users) through communicating with TACACS server in client-server mode.

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

Table 1-3 Differences between HWTACACS and RADIUS

HWTACACS	RADIUS
Adopts TCP, providing more reliable network transmission.	Adopts UDP.
Encrypts the entire message except the HWTACACS header.	Encrypts only the password field in authentication message.
Separates authentication from authorization. For example, you can use one TACACS server for authentication and another TACACS server for authorization.	Combines authentication and authorization.
Is more suitable for security control.	Is more suitable for accounting.
Supports configuration command authorization.	Does not support.

 

In a typical HWTACACS application (as shown in Figure 1-5), a dial-up or terminal user needs to log into the switch to perform some operations. As a HWTACACS client, the switch sends the username and password to the TACACS server for authentication. After passing authentication and being authorized, the user successfully logs into the switch to perform operations.

Figure 1-5 Network diagram for a typical HWTACACS application

II. Basic message exchange procedure in HWTACACS

The following text takes telnet user as an example to describe how HWTACACS implements authentication, authorization, and accounting for a user. Figure 1-6 illustrates the basic message exchange procedure:

Figure 1-6 AAA implementation procedure for a telnet user

The basic message exchange procedure is as follows:

1)         A user sends a login request to the switch acting as a TACACS client, which then sends an authentication start request to the TACACS.

2)         The TACACS server returns an authentication response, asking for the username. Upon receiving the response, the TACACS client requests the user for the username.

3)         After receiving the username from the user, the TACACS client sends an authentication continuance message carrying the username.

4)         The TACACS server returns an authentication response, asking for the password. Upon receiving the response, the TACACS client requests the user for the login password.

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

6)         The TACACS server returns an authentication response, indicating that the user has passed the authentication.

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

8)         The TACACS server returns an authorization response, indicating that the user has passed the authorization.

9)         After receiving 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 to the TACACS server.

11)     The TACACS server returns 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 returns an accounting response, indicating that it has received the accounting stop request.

1.2  Configuration Task

Table 1-4 Configuration tasks

Configuration task		Description	Related section
AAA configuration	Creating an ISP domain	Required	Section 1.3.2  “Creating an ISP Domain”
	Configuring the attributes of an ISP domain	Optional	Section 1.3.3  “Configuring the Attributes of an ISP Domain”
	Configuring an AAA scheme for an ISP domain	Required If local authentication is adopted, refer to section 1.3.6  “Configuring the Attributes of a Local User”. If RADIUS authentication is adopted, refer to section 1.4  “RADIUS Configuration”.	Section 1.3.4  “Configuring an AAA Scheme for an ISP Domain”
	Configuring dynamic VLAN assignment	Optional	Section 1.3.5  “Configuring Dynamic VLAN Assignment”
	Configuring the attributes of a local user	Optional	Section 1.3.6  “Configuring the Attributes of a Local User”
	Cutting down user connections forcibly	Optional	Section 1.3.7  “Cutting Down User Connections Forcibly”
RADIUS configuration	Creating a RADIUS scheme	Required	Section 1.4.1  “Creating a RADIUS Scheme”
	Configuring RADIUS authentication/authorization servers	Required	Section 1.4.2  “Configuring RADIUS Authentication/Authorization Servers”
	Configuring RADIUS accounting servers	Required	Section 1.4.3  “Configuring RADIUS Accounting Servers”
	Configuring shared keys for RADIUS messages	Optional	Section 1.4.4  “Configuring Shared Keys for RADIUS Messages”
	Configuring the maximum number of transmission attempts of a RADIUS request	Optional	Section 1.4.5  “Configuring Maximum Number of Transmission Attempts of RADIUS Request”
	Configuring to support a type of RADIUS server	Optional	Section 1.4.6  “Configuring to Support a Type of RADIUS Server”
	Configuring the status of RADIUS servers	Optional	Section 1.4.7  “Configuring the Status of RADIUS Servers”
	Configuring 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”
	Configuring local RADIUS authentication server	Optional	Section 1.4.9  “Configuring Local RADIUS Authentication Server”
	Configuring the timers of RADIUS servers	Optional	Section 1.4.10  “Configuring the Timers of RADIUS Servers”
	Enabling the sending of trap message when a RADIUS server is down	Optional	Section 1.4.11  “Enabling the Sending of Trap Message When a RADIUS Server is Down”
	Enabling the user re-authentication at restart function	Optional	Section 1.4.12  “Enabling the User Re-Authentication at Restart Function”
HWTACACS configuration	Creating a HWTACAS scheme	Required	Section 1.5.1  “Creating a HWTACAS Scheme”
	Configuring HWTACACS authentication servers	Required	Section 1.5.2  “Configuring HWTACACS Authentication Servers”
	Configuring HWTACACS authorization servers	Required	Section 1.5.3  “Configuring HWTACACS Authorization Servers”
	Configuring HWTACACS accounting servers	Optional	Section 1.5.4  “Configuring HWTACACS Accounting Servers”
	Configuring shared keys for HWTACACS messages	Optional	Section 1.5.5  “Configuring Shared Keys for HWTACACS Messages”
	Configuring 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”
	Configuring the timers of TACACS servers	Optional	Section 1.5.7  “Configuring the Timers of TACACS Servers”

 

1.3  AAA Configuration

The purpose of AAA configuration is to provide network access services to legal users and at the same time protect your network device against unauthorized access. If you need to use ISP domains to implement AAA management on access users, you should first configure ISP domains.

1.3.1  Configuration Prerequisites

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

l           RADIUS scheme (radius-scheme): You can reference a configured RADIUS scheme to provide 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 HWTACACS 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, or set an ISP domain as the default ISP domain	domain { isp-name | default { disable | enable isp-name } }	Required If no ISP domain is set as the default ISP domain, the ISP domain "system" is used as the default ISP domain.

 

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 and enter its view, or enter the view of an existing ISP domain	domain isp-name	Required
Set the status of the ISP domain	state { active | block }	Optional By default, an ISP domain is in the active state, that is, all the users in the domain are allowed to request network service.
Set the maximum number of access users that can be contained in the ISP domain	access-limit { disable | enable max-user-number }	Optional By default, there is no limit on the number of access users that can be contained in an ISP domain.
Set the user idle-cut function	idle-cut { disable | enable minute flow }	Optional By default, the user idle-cut function is disabled.
Set the accounting-optional switch	accounting optional	Optional By default, the accounting-optional switch is closed.
Set the messenger function	messenger time { enable limit interval | disable }	Optional By default, the messenger 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 an AAA Scheme for an ISP Domain

You can configure an AAA scheme in one of the following two ways:

I. Configuring a combined AAA scheme

You can use the scheme command to specify an AAA scheme for an ISP domain. If you specify a RADIUS or HWTACACS scheme, the authentication, authorization and accounting will be uniformly implemented by the RADIUS or TACACS server(s) specified in the RADIUS or HWTACACS scheme. In this way, you cannot specify different schemes for authentication, authorization and accounting respectively.

Table 1-7 Configure a combined AAA scheme

Operation	Command	Description
Enter system view	system-view	—
Create an ISP domain and enter its view, or enter the view of an existing ISP domain	domain isp-name	Required
Configure an AAA scheme for the ISP domain	scheme { local | none | radius-scheme radius-scheme-name [ local ] | hwtacacs-scheme hwtacacs-scheme-name [ local ] }	Required By default, an ISP domain uses the local AAA scheme.
Configure an RADIUS scheme for the ISP domain	radius-scheme radius-scheme-name	Optional This command has the same function as the scheme radius-scheme command.

 

 

II. Configuring separate AAA schemes

You can use the authentication, authorization, and accounting commands to specify a scheme for each of the three AAA functions (authentication, authorization and accounting) respectively. The following gives the implementations of this separate way for the services supported by AAA.

l           For terminal users

Authentication: RADIUS, local, HWTACACS or none.

Authorization: none or HWTACACS.

Accounting: RADIUS, HWTACACS or none.

You can use an arbitrary combination of the above implementations for your AAA scheme configuration.

l           For FTP users

Only authentication is supported for FTP users.

Authentication: RADIUS, local, or RADIUS-local.

Perform the following configuration in ISP domain view.

Table 1-8 Configure separate AAA schemes

Operation	Command	Description
Enter system view	system-view	—
Create an ISP domain and enter its view, or enter the view of an existing ISP domain	domain isp-name	Required
Configure an authentication scheme for the ISP domain	authentication { radius-scheme radius-scheme-name [ local ] | hwtacacs-scheme hwtacacs-scheme-name [ local ] | local | none }	Optional By default, no separate authentication scheme is configured.
Configure an authorization scheme for the ISP domain	authorization { none | hwtacacs-scheme hwtacacs-scheme-name }	Optional By default, no separate authorization scheme is configured.
Configure an accounting scheme for the ISP domain	accounting { none | radius-scheme radius-scheme-name | hwtacacs-scheme hwtacacs-scheme-name }	Optional By default, no separate accounting scheme is configured.

 

 

1.3.5  Configuring Dynamic VLAN Assignment

The dynamic VLAN assignment feature enables a switch to dynamically add the switch ports of successfully authenticated users to different VLANs according to the attributes assigned by the RADIUS server, so as to control the network resources that different users can access.

Currently, the switch supports the following two types of assigned VLAN IDs: integer and string.

l           Integer: If the RADIUS authentication server assigns integer type of VLAN IDs, you can set the VLAN assignment mode to integer on the switch (this is also the default mode on the switch). Then, upon receiving an integer ID assigned by the RADIUS authentication server, the switch adds the port to the VLAN whose VLAN ID is equal to the assigned integer ID. If no such a VLAN exists, the switch first creates a VLAN with the assigned ID, and then adds the port to the newly created VLAN.

l           String: If the RADIUS authentication server assigns string type of VLAN IDs, you can set the VLAN assignment mode to string on the switch. Then, upon receiving a string ID assigned by the RADIUS authentication server, the switch compares the ID with existing VLAN names on the switch. If it finds a match, it adds the port to the corresponding VLAN. Otherwise, the VLAN assignment fails and the user fails the authentication.

In actual applications, to use this feature together with Guest VLAN, you should better set port control to port-based mode.

Table 1-9 Configure dynamic VLAN assignment

Operation	Command	Description
Enter system view	system-view	—
Create an ISP domain and enter its view	domain isp-name	—
Set the VLAN assignment mode	vlan-assignment-mode { integer | string }	Optional By default, the VLAN assignment mode is integer.
Create a VLAN and enter its view	vlan vlan-id	—
Set a VLAN name for VLAN assignment	name string	This operation is required if the VLAN assignment mode is set to string.

 

 

1.3.6  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 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 by 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 local user	password { simple | cipher } password	Optional
Set the status of the local user	state { active | block }	Optional By default, the user is in active state, that is, the user is allowed to request network services.
Authorize the user to access specified type(s) of service	service-type { ftp | lan-access | { telnet | ssh | terminal }* [ level level ] }	Required By default, the system does not authorize the user to access any service.
Set the privilege level of the user	level level	Optional By default, the privilege 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 second | access-limit max-user-number | vlan vlan-id | location { nas-ip ip-address port port-number | port port-number } }*	Optional When binding the user to a remote port, you must use nas-ip ip-address to specify a remote access server IP address (here, ip-address is 127.0.0.1 by default, representing this device). When binding the user to a local port, you need not use nas-ip ip-address.

 

 

1.3.7  Cutting Down User Connections Forcibly

Table 1-11 Cut down user connections forcibly

Operation	Command	Description
Enter system view	system-view	—
Cut down user connections forcibly	cut connection { all | access-type { dot1x | mac-authentication } | domain isp-name | interface interface-type interface-number | ip ip-address | mac mac-address | radius-scheme radius-scheme-name | vlan vlan-id | ucibindex ucib-index | user-name user-name }	Required

 

 

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 type of server, you can configure two servers in a RADIUS scheme: primary server and secondary server. A RADIUS scheme has some parameters such as IP addresses of the primary and secondary servers, shared keys, and types of the RADIUS servers.

In an actual network environment, you can configure the above parameters as required. But you should configure at least one authentication/authorization server and one accounting server, and you should keep the RADIUS server port settings on the switch consistent with those on the RADIUS servers.

 

 

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	—
Enable RADIUS authentication and accounting ports	radius client enable	Optional By default, RADIUS authentication and accounting ports are enabled.
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 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 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 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 accounting-optional switch	accounting optional	You must select one from the two operations. By default, the accounting-optional switch is closed, that is, accounting is 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 primary RADIUS accounting server	primary accounting ip-address [ port-number ]
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 request buffering	stop-accounting-buffer enable	Optional By default, stop-accounting request buffering is enabled.
Set the maximum number of transmission attempts of a buffered stop-accounting request.	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 allowed number of continuous real-time accounting failures	retry realtime-accounting retry-times	Optional By default, the maximum allowed number of continuous real-time accounting failures is five. If five continuous failures occur, the switch cuts down the user connection.

 

 

1.4.4  Configuring Shared Keys for RADIUS Messages

Both RADIUS client and server adopt MD5 algorithm to encrypt RADIUS messages before they are exchanged between the two parties. The two parties verify the validity of the RADIUS messages received from each other by using the shared keys that have been set on them, and can accept and respond to the messages only when both parties have the same shared key.

Table 1-15 Configure shared keys for RADIUS messages

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 RADIUS authentication/authorization messages	key authentication string	Required
Set a shared key for RADIUS accounting messages	key accounting string	Required

 

 

1.4.5  Configuring Maximum Number of Transmission Attempts of RADIUS Request

The communication in RADIUS is unreliable because this protocol uses UDP packets to carry its 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 switch gets no answer after it has tried the maximum number of times to transmit the request, the switch considers that the request fails.

Table 1-16 Configure the maximum transmission attempts of a 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 a RADIUS request	retry retry-times	Optional By default, the system can try three times to transmit a RADIUS request.

 

1.4.6  Configuring to Support a Type of RADIUS Server

Table 1-17 Configure to support a type 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.
Configure the switch to support a type of RADIUS server	server-type { extended | standard }	Optional

 

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 turn to the secondary server and exchange messages with the secondary server.

After the primary server remains in the block state for a set time (set by the timer quiet command), the switch will try to communicate with the primary server again when it receives a RADIUS request. If it finds that the primary server has recovered, 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 active 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 messages 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, the primary RADIUS servers in the default RADIUS scheme "system" are in the active state, the secondary servers in the scheme are in the block state, and all RADIUS servers in all other RADIUS schemes are in the block 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 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 server	user-name-format { with-domain | without-domain }	Optional By default, the user names sent from the switch to RADIUS server carry ISP domain names.
Set the units of data flows 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 data unit and packet unit for outgoing RADIUS flows are byte and one-packet respectively.
Set the source IP address of outgoing RADIUS messages	RADIUS scheme view nas-ip ip-address	Optional By default, no source IP address is set; and the IP address of the corresponding outbound interface is used as the source IP address.
	System view radius nas-ip ip-address

 

 

1.4.9  Configuring Local RADIUS Authentication Server

Table 1-20 Configure local RADIUS authentication server

Operation	Command	Description
Enter system view	system-view	—
Enable UDP port for local RADIUS authentication server	local-server enable	Optional By default, the UDP port for local RADIUS authentication server is enabled.
Configure local RADIUS authentication server	local-server nas-ip ip-address key password	Required By default, local RADIUS authentication server is configured with an NAS IP address of 127.0.0.1.

 

 

1.4.10  Configuring the Timers of RADIUS Servers

After sending out a RADIUS request (authentication/authorization request or accounting request) to a RADIUS server, the switch waits for a response from the server. The maximum time that the switch can wait for the response is called the response timeout time of RADIUS servers, and the corresponding timer in the switch system is called the response timeout timer of RADIUS servers. If the switch gets no answer within the response timeout time, it needs to retransmit the request to ensure that the user can obtain RADIUS service.

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 turn to the secondary server and exchange messages with the secondary server.

After the primary server remains in the block state for a specific time (set by the timer quiet command), the switch will try to communicate with the primary server again when it has a RADIUS request. If it finds that the primary server has recovered, 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 active while keeping the status of the secondary server unchanged.

To control the interval at which users are charged in real time, you can set the real-time accounting interval. After the setting, the switch periodically sends online users' accounting information to RADIUS server at the set interval.

Table 1-21 Set the timers 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 response timeout time of RADIUS servers	timer response-timeout seconds	Optional By default, the response timeout time of RADIUS servers is three seconds.
Set the time that the switch waits before it try to re-communicate with primary server and restore the status of the primary server to active	timer quiet minutes	Optional By default, the switch waits five minutes before it restores the status of the primary server to active.
Set the real-time accounting interval	timer realtime-accounting minutes	Optional By default, the real-time accounting interval is 12 minutes.

 

1.4.11  Enabling the Sending of Trap Message When a RADIUS Server is Down

Table 1-22 Enable the sending of trap message when a RADIUS server is down

Operation	Command	Description
Enter system view	system-view	—
Enable the sending of trap message when a RADIUS server is down	radius trap { authentication-server-down | accounting-server-down }	Optional By default, the switch does not send trap message when a RADIUS server is down.

 

 

1.4.12  Enabling the User Re-Authentication at Restart Function

 

 

In an environment that a CAMS server is used to implement AAA functions, if the switch reboots after an exclusive user (a user whose concurrent online number is set to 1 on the CAMS) gets authenticated and authorized and begins being charged, the switch will give a prompt that the user has already been online when the user re-logs into the network before the CAMS performs online user detection, and the user cannot get authenticated. In this case, the user can access the network again only when the CAMS administrator manually removes the user's online information.

The user re-authentication at restart function is designed to resolve this problem. After this function is enabled, every time the switch restarts:

1)         The switch generates an Accounting-On message, which mainly contains the following information: NAS-ID, NAS-IP-address (source IP address), and session ID.

2)         The switch sends the Accounting-On message to the CAMS at regular intervals.

3)         Once the CAMS receives the Accounting-On message, it sends a response to the switch. At the same time it finds and deletes the original online information of the users who were accessing the network through the switch before the restart according to the information (NAS-ID, NAS-IP-address and session ID) contained in the message, and ends the accounting for the users depending on the last accounting update message.

4)         Once the switch receives the response from the CAMS, it stops sending Accounting-On messages.

5)         If the switch does not receive any response from the CAMS after it has tried the configured maximum number of times to send the Accounting-On message, it will not send the Accounting-On message any more.

 

 

Table 1-23 Enable the user re-authentication at restart function

Operation	Command	Description
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Enable the user re-authentication at restart function	accounting-on enable [ send times | interval interval ]	By default, this function is disabled. If you use this command without any parameter, the system will try at most 15 times to send an Accounting-On message at the interval of three seconds.

 

1.5  HWTACACS Configuration

1.5.1  Creating a HWTACAS Scheme

The HWTACACS protocol configuration is performed on a scheme basis. Therefore, you must create a HWTACACS scheme and enter HWTACACS view before performing other configuration tasks.

Table 1-24 Create a HWTACACS scheme

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.

 

 

1.5.2  Configuring HWTACACS Authentication Servers

Table 1-25 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 0.
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 0.

 

 

1.5.3  Configuring HWTACACS Authorization Servers

Table 1-26 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 0.
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 0.

 

 

1.5.4  Configuring HWTACACS Accounting Servers

Table 1-27 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 0.
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 0.
Enable the stop-accounting message retransmission function and set the maximum number of transmission attempts of a buffered stop-accounting message	retry stop-accounting retry-times	Optional By default, the stop-accounting messages retransmission function is enabled and the system can transmit a buffered stop-accounting request for 100 times.

 

 

1.5.5  Configuring Shared Keys for HWTACACS Messages

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

The TACACS client and server adopt MD5 algorithm to encrypt HWTACACS messages before they are exchanged between the two parties. The two parties verify the validity of the HWTACACS messages received from each other by using the shared keys that have been set on them, and can accept and respond to the messages only when both parties have the same shared key.

Table 1-28 Configure shared keys for HWTACACS messages

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 HWTACACS authentication, authorization or accounting messages	key { accounting | authorization | authentication } string	Required By default, no such key is set.

 

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

Table 1-29 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 server	user-name-format { with-domain | without-domain }	Optional By default, the user names sent from the switch to TACACS server carry ISP domain names.
Set the units of data flows to TACACS servers	data-flow-format data { byte | giga-byte | kilo-byte | mega-byte }	Optional By default, in a TACACS scheme, the data unit and packet unit for outgoing HWTACACS flows are byte and one-packet respectively.
	data-flow-format packet { giga-packet | kilo-packet | mega-packet | one-packet }
Set the source IP address of outgoing HWTACACS messages	HWTACACS scheme view nas-ip ip-address	Optional By default, no source IP address is set; the IP address of the corresponding 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-30 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 time that the switch must wait before it can restore the status of the primary server to active	timer quiet minutes	Optional By default, the switch must wait five minutes before it can restore the status of the primary server to active.
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 configuration result and operation status 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-31 Display AAA information

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

 

Table 1-32 Display and maintain RADIUS protocol information

Operation	Command	Description
Display RADIUS message statistics about local RADIUS authentication server	display local-server statistics	You can execute the display command in any view.
Display configuration information about one specific or all RADIUS schemes	display radius scheme [ radius-scheme-name ]
Display RADIUS message statistics	display radius statistics
Display buffered non-response stop-accounting requests	display stop-accounting-buffer { radius-scheme radius-scheme-name | session-id session-id | time-range start-time stop-time | user-name user-name }
Delete buffered non-response stop-accounting requests	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 RADIUS message statistics	reset radius statistics

 

Table 1-33 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 buffered non-response stop-accounting requests	display stop-accounting-buffer { hwtacacs-scheme hwtacacs-scheme-name | session-id session-id | time-range start-time stop-time | user-name user-name }
Clear HWTACACS message statistics	reset hwtacacs statistics { accounting | authentication | authorization | all }	You can execute the reset command in user view.
Delete buffered non-response stop-accounting requests	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 it uses to exchange messages with the authentication RADIUS server to "expert".

You can use a CAMS server as the RADIUS server. You can select standard or extended as the server-type in a RADIUS scheme.

On the RADIUS server:

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

l           Set the authentication port number.

l           Add Telnet user names and login passwords.

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

II. Network diagram

Figure 1-7 Remote RADIUS authentication of Telnet users

III. Configuration procedure

# Enter system view.

<H3C> system-view

[H3C]

# Adopt AAA authentication for Telnet users.

[H3C] user-interface vty 0 4

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

[H3C-ui-vty0-4] quit

# Configure an ISP domain.

[H3C] domain cams

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

[H3C-isp-cams] quit

# Configure a RADIUS scheme.

[H3C] radius scheme cams

[H3C-radius-cams] accounting optional

[H3C-radius-cams] primary authentication 10.110.91.164 1812

[H3C-radius-cams] key authentication expert

[H3C-radius-cams] server-type Extended

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

[H3C-radius-cams] quit

# Associate the ISP domain with the RADIUS scheme.

[H3C] domain cams

[H3C-isp-cams] scheme radius-scheme cams

A Telnet user logging into the switch by a name in the format of userid @cams belongs to the cams domain and will be authenticated according to the configuration of the cams domain.

1.7.2  Local Authentication of FTP/Telnet Users

 

 

I. Network requirements

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

II. Network diagram

Figure 1-8 Local authentication of Telnet users

III. Configuration procedure

Method 1: Using local authentication scheme.

# Enter system view.

<H3C> system-view

[H3C]

# Adopt AAA authentication for Telnet users.

[H3C] user-interface vty 0 4

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

[H3C-ui-vty0-4] quit

# Create and configure a local user named "telnet".

[H3C] local-user telnet

[H3C-luser-telnet] service-type telnet

[H3C-luser-telnet] password simple h3c

[H3C-luser-telnet] attribute idle-cut 300 access-limit 5

[H3C-luser-telnet] quit

[H3C] domain system

[H3C-isp-system] scheme local

A Telnet user logging into the switch with the name telnet@system belongs to the "system" domain and will be authenticated according to the configuration of the "system" domain.

Method 2: using 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 of the authentication server to 127.0.0.1, h3c, and 1645 respectively in the configuration step "Configure a RADIUS scheme" in section 1.7.1  , and configure local users (whether the names of local users carry domain names should be consistent with the configuration in the RADIUS scheme).

1.7.3  HWTACACS Authentication and Authorization of Telnet Users

I. Network requirements

You are required to configure the switch so that the Telnet users logging into the switch are authenticated and authorized by the TACACS server.

A TACACS server with IP address 10.110.91.164 is connected to the switch. This server will be used as the authentication and authorization server. On the switch, set both authentication and authorization shared keys that are used to exchange messages with the TACACS server to "expert". Configure the switch to strip domain names off user names before sending user names to the TACACS server.

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

II. Network diagram

Figure 1-9 Remote HWTACACS authentication and authorization of Telnet users

III. Configuration procedure

# Add a Telnet user.

(Omitted here)

# Configure a HWTACACS scheme.

<H3C> system-view

[H3C] hwtacacs scheme hwtac

[H3C-hwtacacs-hwtac] primary authentication 10.110.91.164 49

[H3C-hwtacacs-hwtac] primary authorization 10.110.91.164 49

[H3C-hwtacacs-hwtac] key authentication expert

[H3C-hwtacacs-hwtac] key authorization expert

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

[H3C-hwtacacs-hwtac] quit

# Configure the domain name of the HWTACACS scheme to hwtac.

[H3C] domain hwtacacs

[H3C-isp-hwtacacs] scheme hwtacacs-scheme hwtac

1.8  Troubleshooting AAA & RADIUS & HWTACACS Configuration

1.8.1  Troubleshooting RADIUS Configuration

The RADIUS protocol operates 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 the default ISP domain is not correctly 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 HWTACACS Configuration

See the previous section if you encounter an HWTACACS fault.

 

Chapter 2  EAD Configuration

2.1  Introduction to EAD

Endpoint admission defense (EAD) is an attack defense solution. Using this solution, you can enhance the active defense capability of network endpoints, prevents viruses and worms from spreading on the network, and protects the entire network by limiting the access rights of insecure endpoints.

With the cooperation of switch, AAA sever, security policy server and security client, EAD is able to evaluate the security compliance of network endpoints and dynamically control their access rights.

With EAD, a switch:

l           Verifies the validity of the session control packets it receives according to the source IP addresses of the packets: It regards only those packets sourced from authentication or security policy server as valid.

l           Dynamically adjusts the VLAN, rate, packet scheduling priority and access control list (ACL) for user terminals according to session control packets, whereby to control the access rights of users dynamically.

2.2  Typical Network Application of EAD

EAD checks the security status of users before they can access the network, and forcibly implements user access control policies according to the check results. In this way, it can isolate the users that are not compliant with security standard and force these users to update their virus databases and install system patches. Figure 2-1 shows a typical network application of EAD.

Figure 2-1 Typical network application of EAD

After a client passes the authentication, the security Client (software installed on the client PC) interacts with the security policy server to check the security status of the client. If the client is not compliant with the security standard, the security policy server issues an ACL to the switch, which then inhibits the client from accessing any parts of the network except for the virus/patch server.

After the client is patched and compliant with the required security standard, the security policy server reissues an ACL to the switch, which then assigns access right to the client so that the client can access more network resources.

2.3  EAD Configuration

The EAD configuration includes:

l           Configuring the attributes of access users (such as user name, user type, and password). For local authentication, you need to configure these attributes on the switch; for remote authentication, you need to configure these attributes on the AAA sever.

l           Configuring RADIUS scheme.

l           Configuring the IP address of the security policy server.

l           Associating domain with RADIUS scheme.

EAD is commonly used in RADIUS authentication environment.

This section mainly describes the configuration of security policy server IP address. For other related configuration, refer to Chapter 1  “AAA & RADIUS & HWTACACS Configuration”.

Table 2-1 EAD configuration

Operation	Command	Description
Enter system view	system-view	—
Enter RADIUS scheme view	radius scheme radius-scheme-name	—
Configure the RADIUS server type to extended	server-type extended	Required
Configure the IP address of a security policy server	security-policy-server ip-address	Required Each RADIUS scheme supports up to eight IP addresses of security policy servers.

 

2.4  EAD Configuration Example

I. Network requirements

In Figure 2-2:

l           A user is connected to Ethernet1/0/1 on the switch.

l           The user adopts 802.1x client supporting H3C extended function.

l           You are required to configure the switch to use RADIUS server for remote user authentication and use security policy server for EAD control on users.

The following are the configuration tasks:

l           Connect the RADIUS authentication server 10.110.91.164 and the switch, and configure the switch to use port number 1812 to communicate with the server.

l           Configure the authentication server type to extended.

l           Configure the encryption password for exchanging messages between the switch and RADIUS server to “expert”.

l           Configure the IP address 10.110.91.166 of the security policy server.

II. Network diagram

Figure 2-2 EAD configuration

III. Configuration procedure

# Configure 802.1x on the switch. Refer to the 802.1x part in H3C S3600 Series Ethernet Switches Operation Manual for detailed description.

# Configure a domain.

<H3C> system-view

[H3C] domain system

[H3C-isp-system] quit

# Configure a RADIUS scheme.

[H3C] radius scheme cams

[H3C-radius-cams] primary authentication 10.110.91.164 1812

[H3C-radius-cams] accounting optional

[H3C-radius-cams] key authentication expert

[H3C-radius-cams] server-type extended

# Configure the IP address of the security policy server.

[H3C-radius-cams] security-policy-server 10.110.91.166

# Associate the domain with the RADIUS scheme.

[H3C-radius-cams] quit

[H3C] domain system

[H3C-isp-system] radius-scheme cams