H3C S3100-52P Ethernet Switch Operation Manual-Release 1500(V1.02)

HomeSupportResource CenterSwitchesH3C S3100 Switch SeriesH3C S3100 Switch SeriesTechnical DocumentsConfigure & DeployConfiguration GuidesH3C S3100-52P Ethernet Switch Operation Manual-Release 1500(V1.02)
16-AAA-RADIUS-HWTACACS Operation
Title Size Download
16-AAA-RADIUS-HWTACACS Operation 539.98 KB

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

1.3 AAA Configuration. 1-12

1.3.1 Configuration Prerequisites. 1-13

1.3.2 Creating an ISP Domain. 1-13

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

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

1.3.5 Configuring Dynamic VLAN Assignment 1-17

1.3.6 Configuring the Attributes of a Local User 1-19

1.3.7 Cutting Down User Connections Forcibly. 1-21

1.4 RADIUS Configuration. 1-21

1.4.1 Creating a RADIUS Scheme. 1-22

1.4.2 Configuring RADIUS Authentication/Authorization Servers. 1-23

1.4.3 Configuring RADIUS Accounting Servers. 1-24

1.4.4 Configuring Shared Keys for RADIUS Messages. 1-25

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

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

1.4.7 Configuring the Status of RADIUS Servers. 1-27

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

1.4.9 Configuring Local RADIUS Authentication Server 1-29

1.4.10 Configuring the Timers of RADIUS Servers. 1-30

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

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

1.5 HWTACACS Configuration. 1-33

1.5.1 Creating a HWTACAS Scheme. 1-33

1.5.2 Configuring HWTACACS Authentication Servers. 1-34

1.5.3 Configuring HWTACACS Authorization Servers. 1-35

1.5.4 Configuring HWTACACS Accounting Servers. 1-36

1.5.5 Configuring Shared Keys for HWTACACS Messages. 1-36

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

1.5.7 Configuring the Timers of TACACS Servers. 1-38

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

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

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

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

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

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

1.8.1 Troubleshooting RADIUS Configuration. 1-45

1.8.2 Troubleshooting HWTACACS Configuration. 1-46

 


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.

 

  Caution:

l      On an S3100-52P Ethernet Switch, each access user belongs to an ISP domain. You can configure up to 16 ISP domains on the switch. When a user logs in, if no ISP domain name is carried in the user name, the switch assumes that the user belongs to the default ISP domain.

l      If the system does not find any available accounting server or fails to communicate with any accounting server when it performs accounting for a user, it will not disconnect the user as long as the accounting optional command has been executed, though it cannot perform accounting for the user in this case.

l      The self-service server location function needs the cooperation of a self-service-supported RADIUS server (such as CAMS, that is, comprehensive access management server). Through self-service, users can manage and control their account or card numbers by themselves. A server installed with the self-service software is called a self-service server.

 

&  Note:

H3C's CAMS Server is a service management system used to manage networks and secure networks and user information. With the cooperation of other networking devices (such as switches) in a network, a CAMS server can implement the AAA functions and right management.

 

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.

 

  Caution:

l      You can execute the scheme radius-scheme radius-scheme-name command to adopt an already configured RADIUS scheme to implement all the three AAA functions. If you adopt the local scheme, only the authentication and authorization functions are implemented, the accounting function cannot be implemented.

l      If you execute the scheme radius-scheme radius-scheme-name local command, the local scheme is used as the secondary scheme in case no RADIUS server is available. That is, if the communication between the switch and a RADIUS server is normal, no local authentication is performed; otherwise, local authentication is performed.

l      If you execute the scheme hwtacacs-scheme hwtacacs-scheme-name local command, the local scheme is used as the secondary scheme in case no TACACS server is available. That is, if the communication between the switch and a TACACS server is normal, no local authentication is performed; otherwise, local authentication is performed.

l      If you execute the scheme local or scheme none command to adopt local or none as the primary scheme, the local authentication is performed or no authentication is performed. In this case you cannot specify any RADIUS scheme at the same time.

 

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.

 

&  Note:

l      If a combined AAA scheme is configured as well as the separate authentication, authorization and accounting schemes, the separate ones will be adopted in precedence.

l      RADIUS scheme and local scheme do not support the separation of authentication and authorization. Therefore, pay attention when you make authentication and authorization configuration for a domain: When the scheme radius-scheme or scheme local command is executed and the authentication command is not executed, the authorization information returned from the RADIUS or local scheme still takes effect even if the authorization none command is executed.

 

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.

 

  Caution:

l      In string mode, if the VLAN ID assigned by the RADIUS server is a character string containing only digits (for example, 1024), the switch first regards it as an integer VLAN ID: the switch transforms the string to an integer value and judges if the value is in the valid VLAN ID range; if it is, the switch adds the authenticated port to the VLAN with the integer value as the VLAN ID (VLAN 1024, for example).

l      To implement dynamic VLAN assignment on a port where both MSTP and 802.1x are enabled, you must set the MSTP port to an edge port.

 

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.

 

  Caution:

l      The following characters are not allowed in the user-name string: /:*?<>. And you cannot input more than one “@” in the string.

l      After the local-user password-display-mode cipher-force command is executed, any password will be displayed in cipher mode even though you specify to display a user password in plain text by using the password command.

l      If a user name and password is required for user authentication (RADIUS authentication as well as local authentication), the command level that a user can access after login is determined by the privilege level of the user. For SSH users using RSA shared key for authentication, the commands they can access are determined by the levels set on their user interfaces.

l      If the configured authentication method is none or password authentication, the command level that a user can access after login is determined by the level of the user interface.

 

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

 

&  Note:

You can use the display connection command to view the connections of Telnet and FTP users, but you cannot use the cut connection command to cut down their connections.

 

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.

 

&  Note:

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

 

1.4.1  Creating a RADIUS Scheme

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

Table 1-12 Create a RADIUS scheme

Operation

Command

Description

Enter system view

system-view

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.

 

  Caution:

A RADIUS scheme can be referenced by multiple ISP domains simultaneously.

 

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.

 

  Caution:

l      The authentication response sent from the RADIUS server to the RADIUS client carries authorization information. Therefore, you need not (and cannot) specify a separate RADIUS authorization server.

l      In an actual network environment, you can specify one server as both the primary and secondary authentication/authorization servers, as well as specifying two RADIUS servers as the primary and secondary authentication/authorization servers respectively.

l      The IP address and port number of the primary authentication server used by the default RADIUS scheme "system" are 127.0.0.1 and 1645.

 

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.

 

  Caution:

l      In an actual network environment, you can specify one server as both the primary and secondary accounting servers, as well as specifying two RADIUS servers as the primary and secondary accounting servers respectively. In addition, because RADIUS adopts different UDP ports to exchange authentication/authorization messages and accounting messages, you must set a port number for accounting different from that set for authentication/authorization.

l      With stop-accounting request buffering enabled, the switch first buffers the stop-accounting request that gets no response from the RADIUS accounting server, and then retransmits the request to the RADIUS accounting server until it gets a response, or the maximum number of transmission attempts is reached (in this case, it discards the request).

l      You can set the maximum allowed number of continuous real-time accounting failures. If the number of continuously failed real-time accounting requests to the RADIUS server reaches the set maximum number, the switch cuts down the user connection.

l      The IP address and port number of the primary accounting server of the default RADIUS scheme "system" are 127.0.0.1 and 1646 respectively.

l      Currently, RADIUS does not support the accounting of FTP users.

 

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

 

  Caution:

The authentication/authorization shared key and the accounting shared key you set on the switch must be respectively consistent with the shared key on the authentication/authorization server and the shared key on the accounting server.

 

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

 

  Caution:

l      Generally, the access users are named in the userid@isp-name format. Here, isp-name behind the @ character represents the ISP domain name, by which the device determines which ISP domain a user belongs to. However, some old RADIUS servers cannot accept the user names that carry ISP domain names. In this case, it is necessary to remove domain names from user names before sending the user names to RADIUS server. For this reason, the user-name-format command is designed for you to specify whether or not ISP domain names are carried in the user names to be sent to RADIUS server.

l      For a RADIUS scheme, if you have specified to remove ISP domain names from user names, you should not use this RADIUS scheme in more than one ISP domain. Otherwise, such errors may occur: the RADIUS server regards two different users having the same name but belonging to different ISP domains as the same user (because the usernames sent to it are the same).

l      In the default RADIUS scheme "system", ISP domain names are removed from user names by default.

 

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.

 

  Caution:

l      If you adopt the local RADIUS authentication server function, the UDP port number of the authentication/authorization server must be 1645, the UDP port number of the accounting server must be 1646, and the IP addresses of the servers must be set to the addresses of this switch.

l      The message encryption key set by the local-server nas-ip ip-address key password command must be identical with the authentication/authorization message encryption key set by the key authentication command in the RADIUS scheme view of the RADIUS scheme on the specified NAS that uses this switch as its authentication server.

l      Acting as local RADIUS authentication server, the switch can provide authentication service to up to 16 network access servers (NAS) (including the switch itself) at the same time.

 

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.

 

&  Note:

l      This configuration takes effect on all RADIUS schemes.

l      The switch considers a RADIUS server as being down if it has tried the configured maximum times to send a message to the RADIUS server but does not receive any response.

 

1.4.12  Enabling the User Re-Authentication at Restart Function

 

&  Note:

The user re-authentication at restart function applies to the environment where the RADIUS authentication/authorization and accounting server is CAMS.

 

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.

 

&  Note:

The switch can automatically generate the main attributes (NAS-ID, NAS-IP-address and session ID) contained in Accounting-On messages. However, you can also manually configure the NAS-IP-address with the nas-ip command. If you choose to manually configure the attribute, be sure to configure an appropriate valid IP address. If this attribute is not configured, the switch will automatically choose the IP address of a VLAN interface as the NAS-IP-address.

 

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.

 

  Caution:

l      The system supports up to 16 HWTACACS schemes. You can delete a HWTACACS scheme only when it is not referenced.

l      If the Fabric function is enabled on the switch, you cannot create any HWTACACS scheme, because the two are exclusive to each other.

 

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.

 

  Caution:

l      You are not allowed to configure the same IP address for both primary and secondary authentication servers. If you do this, the system will prompt that the configuration fails.

l      You can remove an authentication server setting only when there is no active TCP connection that is sending authentication messages to the server.

 

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.

 

  Caution:

l      You are not allowed to configure the same IP address for both primary and secondary authorization servers. If you do this, the system will prompt that the configuration fails.

l      You can remove a server only when it is not used by any active TCP connection for sending authorization messages.

 

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.

 

  Caution:

l      You are not allowed to configure the same IP address for both primary and secondary accounting servers. If you do this, the system will prompt that the configuration fails.

l      You can remove a server only when it is not used by any active TCP connection for sending accounting messages.

 

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

 

  Caution:

Generally, the access users are named in the userid@isp-name format. Where, isp-name behind the @ character represents the ISP domain name. If the TACACS server does not accept the user names that carry ISP domain names, it is necessary to remove domain names from user names before they are sent to TACACS server.

 

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.

 

  Caution:

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

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

l      The setting of real-time accounting interval somewhat depends on the performance of the TACACS client and server devices: A shorter interval requires higher device performance.

 

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

 

&  Note:

The configuration procedure for remote authentication of SSH users by RADIUS server is similar to that for Telnet users. The following text only takes Telnet users as example to describe the configuration procedure for remote authentication.

 

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

 

&  Note:

The configuration procedure for local authentication of FTP users is similar to that for Telnet users. The following text only takes Telnet users as example to describe the configuration procedure for local authentication.

 

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.