H3C S3600 Operation Manual-Release 1602(V1.02)

HomeSupportSwitchesH3C S3600 Switch SeriesConfigure & DeployConfiguration GuidesH3C S3600 Operation Manual-Release 1602(V1.02)
19-AAA Operation
Title Size Download
19-AAA Operation 470.11 KB

Table of Contents

1 AAA Overview·· 1-1

Introduction to AAA· 1-1

Authentication· 1-1

Authorization· 1-2

Accounting· 1-2

Introduction to ISP Domain· 1-2

Introduction to AAA Services· 1-2

Introduction to RADIUS· 1-2

Introduction to HWTACACS· 1-7

2 AAA Configuration· 2-1

AAA Configuration Task List 2-1

Creating an ISP Domain and Configuring Its Attributes· 2-2

Configuring an AAA Scheme for an ISP Domain· 2-3

Configuring Dynamic VLAN Assignment 2-6

Configuring the Attributes of a Local User 2-7

Cutting Down User Connections Forcibly· 2-9

RADIUS Configuration Task List 2-9

Creating a RADIUS Scheme· 2-11

Configuring RADIUS Authentication/Authorization Servers· 2-11

Configuring RADIUS Accounting Servers· 2-12

Configuring Shared Keys for RADIUS Messages· 2-13

Configuring the Maximum Number of RADIUS Request Transmission Attempts· 2-14

Configuring the Type of RADIUS Servers to be Supported· 2-14

Configuring the Status of RADIUS Servers· 2-14

Configuring the Attributes of Data to be Sent to RADIUS Servers· 2-15

Configuring the Local RADIUS Server 2-16

Configuring Timers for RADIUS Servers· 2-17

Enabling Sending Trap Message when a RADIUS Server Goes Down· 2-18

Enabling the User Re-Authentication at Restart Function· 2-19

HWTACACS Configuration Task List 2-20

Creating a HWTACACS Scheme· 2-20

Configuring TACACS Authentication Servers· 2-21

Configuring TACACS Authorization Servers· 2-21

Configuring TACACS Accounting Servers· 2-22

Configuring Shared Keys for HWTACACS Messages· 2-22

Configuring the Attributes of Data to be Sent to TACACS Servers· 2-23

Configuring the Timers Regarding TACACS Servers· 2-24

Displaying and Maintaining AAA Configuration· 2-25

Displaying and Maintaining AAA Configuration· 2-25

Displaying and Maintaining RADIUS Protocol Configuration· 2-25

Displaying and Maintaining HWTACACS Protocol Configuration· 2-26

AAA Configuration Examples· 2-26

Remote RADIUS Authentication of Telnet/SSH Users· 2-26

Local Authentication of FTP/Telnet Users· 2-28

HWTACACS Authentication and Authorization of Telnet Users· 2-29

Troubleshooting AAA· 2-30

Troubleshooting RADIUS Configuration· 2-30

Troubleshooting HWTACACS Configuration· 2-30

3 EAD Configuration· 3-1

Introduction to EAD· 3-1

Typical Network Application of EAD· 3-1

EAD Configuration· 3-2

EAD Configuration Example· 3-2

 


AAA Overview

 

l          The configuration of ISP domain delimiter is added. See Creating an ISP Domain and Configuring Its Attributes.

l          The configuration of HWTACACS authentication scheme for user level switching is added. See Configuring an AAA Scheme for an ISP Domain.

l          The configuration of the MAC address format for the Calling-Station-Id field in RADIUS packets is added. See Configuring the Attributes of Data to be Sent to RADIUS Servers.

 

Introduction to AAA

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

l          Authentication: Defines what users can access the network,

l          Authorization: Defines what services can be available to the users who can access the network, and

l          Accounting: Defines how to charge the users who are using network resources.

Typically, AAA operates in the client/server model: the client runs on the managed resources side while the server stores the user information. Thus, AAA is well scalable and can easily implement centralized management of user information.

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 username, 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. You can use standard or extended RADIUS protocols in conjunction with such systems as iTELLIN/CAMS for user authentication. Remote authentication allows convenient centralized management and is feature-rich. However, to implement remote authentication, a server is needed and must be configured properly.

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.

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.

Introduction to ISP Domain

An Internet service provider (ISP) domain is a group of users who belong to the same ISP. For a username in the format of userid@isp-name or userid.isp-name, the isp-name following the "@" or “.” character is the ISP domain name. The access device uses userid as the username 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 username 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.

Introduction to AAA Services

Introduction to RADIUS

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

What is RADIUS

Remote Authentication Dial-in User Service (RADIUS) is a distributed service 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 network access servers throughout the network.

RADIUS operates in the client/server model.

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

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

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 username and password.

2)        The RADIUS client receives the username 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 authorization 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.

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

 

Introduction to HWTACACS

What is HWTACACS

Huawei Terminal Access Controller Access Control System (HWTACACS) 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 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

 

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

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.

 


AAA Configuration Task List

You need to configure AAA to provide network access services for legal users while protecting network devices and preventing unauthorized access and repudiation behavior.

Complete the following tasks to configure AAA (configuring a combined AAA scheme for an ISP domain):

Task

Remarks

AAA configuration

Creating an ISP Domain and Configuring Its Attributes

Required

Configuring a combined AAA scheme

Required

Configuring an AAA Scheme for an ISP Domain

None authentication

l      Use one of the authentication methods

l      You need to configure RADIUS or HWATACACS before performing RADIUS or HWTACACS authentication

Local authentication

RADIUS authentication

HWTACACS authentication

Configuring Dynamic VLAN Assignment

Optional

Configuring the Attributes of a Local User

Optional

Cutting Down User Connections Forcibly

Optional

 

Complete the following tasks to configure AAA (configuring separate AAA schemes for an ISP domain):

Task

Remarks

AAA configuration

Creating an ISP Domain and Configuring Its Attributes

Required

Configuring separate AAA schemes

Required

Configuring an AAA Scheme for an ISP Domain

Required

With separate AAA schemes, you can specify authentication, authorization and accounting schemes respectively.

You need to configure RADIUS or HWATACACS before performing RADIUS or HWTACACS authentication.

Configuring Dynamic VLAN Assignment

Optional

Configuring the Attributes of a Local User

Optional

Cutting Down User Connections Forcibly

Optional

 

Creating an ISP Domain and Configuring Its Attributes

Follow these steps to create an ISP domain and configure its attributes:

To do…

Use the command…

Remarks

Enter system view

system-view

Configure the form of the delimiter between the username and the ISP domain name

domain delimiter { at | dot }

Optional

By default, the delimiter between the username and the ISP domain name is “@”.

Create an 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.

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 the ISP domain can accommodate

access-limit { disable | enable max-user-number }

Optional

By default, there is no limit on the number of access users that the ISP domain can accommodate.

Set the idle-cut function

idle-cut { disable | enable minute flow }

Optional

By default, the idle-cut function is disabled.

Set the accounting-optional switch

accounting optional

Optional

By default, the accounting-optional switch is off.

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.

 

Note that:

l          On an S3600 series 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 username, the switch assumes that the user belongs to the default ISP domain.

l          If you have configured to use "." as the delimiter, for a username that contains multiple ".", the first "." will be used as the domain delimiter.

l          If you have configured to use "@" as the delimiter, the "@" must not appear more than once in the username. If “.” is the delimiter, the username must not contain any “@”.

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 does 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 RADIUS server that supports self-service, such as Comprehensive Access Management Server (CAMS). Through self-service, users can manage and control their account or card numbers by themselves. A server installed with self-service software is called a self-service server.

 

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

 

Configuring an AAA Scheme for an ISP Domain

You can configure either a combined AAA scheme or separate AAA schemes.

Configuring a combined AAA scheme

You can use the scheme command to specify an AAA scheme for an ISP domain.

Follow these steps to configure a combined AAA scheme:

To do…

Use the command…

Remarks

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.

 

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, the local scheme is not used; otherwise, the local scheme is used.

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, the local scheme is not used; if the TACACS server is not reachable or there is a key error or NAS IP error, the local scheme is used.

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 or HWTACACS scheme at the same time.

l          If you configure to use none as the primary scheme, FTP users of the domain cannot pass authentication. Therefore, you cannot specify none as the primary scheme if you want to enable FTP service.

 

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.

1)        For terminal users

l          Authentication: RADIUS, local, HWTACACS or none.

l          Authorization: none or HWTACACS.

l          Accounting: RADIUS, HWTACACS or none.

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

2)        For FTP users

Only authentication is supported for FTP users.

Authentication: RADIUS, local, or HWTACACS.

Follow these steps to configure separate AAA schemes:

To do…

Use the command…

Remarks

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 a HWTACACS authentication scheme for user level switching

authentication super hwtacacs-scheme hwtacacs-scheme-name

Optional

By default, no HWTACACS 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.

 

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.

l          The S3600 series switches adopt hierarchical protection for command lines so as to inhibit users at lower levels from using higher level commands to configure the switches. For details about configuring a HWTACACS authentication scheme for low-to-high user level switching, refer to Switching User Level in the Command Line Interface Operation.

 

Configuration guidelines

Suppose a combined AAA scheme is available. The system selects AAA schemes according to the following principles:

l          If authentication, authorization, accounting each have a separate scheme, the separate schemes are used.

l          If you configure only a separate authentication scheme (that is, there are no separate authorization and accounting schemes configured), the combined scheme is used for authorization and accounting. In this case, if the combined scheme uses RADIUS or HWTACACS, the system never uses the secondary scheme for authorization and accounting.

l          If you configure no separate scheme, the combined scheme is used for authentication, authorization, and accounting. In this case, if the system uses the secondary local scheme for authentication, it also does so for authorization and accounting; if the system uses the first scheme for authentication, it also does so for authorization and accounting, even if authorization and accounting fail.

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. For more information, refer to Basic 802.1x Configuration of 802.1x and System Guard Operation.

Follow these steps to configure dynamic VLAN assignment:

To do…

Use the command…

Remarks

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.

 

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.

 

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

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

To do…

Use the command…

Remarks

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

Required

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.

Configure the authorized VLAN for the local user

authorization vlan string

Required

By default, no authorized VLAN is configured for the local user.

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.

 

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

l          If the clients connected to a port have different authorized VLANs, only the first client passing the MAC address authentication can be assigned with an authorized VLAN. The switch will not assign authorized VLANs for subsequent users passing MAC address authentication. In this case, you are recommended to connect only one MAC address authentication user or multiple users with the same authorized VLAN to a port.

l          For local RADIUS authentication to take effect, the VLAN assignment mode must be set to string after you specify authorized VLANs for local users.

 

Cutting Down User Connections Forcibly

Follow these steps to cut down user connections forcibly:

To do…

Use the command…

Remarks

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

 

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

 

RADIUS Configuration Task List

H3C’s Ethernet switches can function not only as RADIUS clients but also as local RADIUS servers.

Complete the following tasks to configure RADIUS (the switch functions as a RADIUS client):

Task

Remarks

Configuring the RADIUS client

Creating a RADIUS Scheme

Required

Configuring RADIUS Authentication/Authorization Servers

Required

Configuring RADIUS Accounting Servers

Required

Configuring Shared Keys for RADIUS Messages

Optional

Configuring the Maximum Number of RADIUS Request Transmission Attempts

Optional

Configuring the Type of RADIUS Servers to be Supported

Optional

Configuring the Status of RADIUS Servers

Optional

Configuring the Attributes of Data to be Sent to RADIUS Servers

Optional

Configuring Timers for RADIUS Servers

Optional

Enabling Sending Trap Message when a RADIUS Server Goes Down

Optional

Enabling the User Re-Authentication at Restart Function

Optional

Configuring the RADIUS server

Refer to the configuration of the RADIUS Server.

 

Complete the following tasks to configure RADIUS (the switch functions as a local RADIUS server):

Task

Remarks

Configuring the RADIUS server

Creating a RADIUS Scheme

Required

Configuring RADIUS Authentication/Authorization Servers

Required

Configuring RADIUS Accounting Servers

Required

Configuring Shared Keys for RADIUS Messages

Optional

Configuring the Maximum Number of RADIUS Request Transmission Attempts

Optional

Configuring the Type of RADIUS Servers to be Supported

Optional

Configuring the Status of RADIUS Servers

Optional

Configuring the Attributes of Data to be Sent to RADIUS Servers

Optional

Configuring the Local RADIUS Server

Required

Configuring Timers for RADIUS Servers

Optional

Enabling Sending Trap Message when a RADIUS Server Goes Down

Optional

Configuring the RADIUS client

Refer to the configuration of the RADIUS client

 

The RADIUS service 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.

 

Actually, the RADIUS service 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 AAA Configuration).

 

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.

Follow these steps to create a RADIUS scheme:

To do…

Use the command…

Remarks

Enter system view

system-view

Enable RADIUS authentication port

radius client enable

Optional

By default, RADIUS authentication port is 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.

 

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

 

Configuring RADIUS Authentication/Authorization Servers

Follow these steps to configure RADIUS authentication/authorization servers:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a RADIUS scheme and enter its view

radius scheme radius-scheme-name

Required

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 for a newly created RADIUS scheme.

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 for a newly created RADIUS scheme.

 

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.

 

Configuring RADIUS Accounting Servers

Follow these steps to configure RADIUS accounting servers:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a RADIUS scheme and enter its view

radius scheme radius-scheme-name

Required

By default, a RADIUS scheme named "system" has already been created in the system.

Set the IP address and port number of the primary RADIUS accounting server

primary accounting ip-address [ port-number ]

Required

By default, the IP address and UDP port number of the primary accounting server are 0.0.0.0 and 1813 for a newly created RADIUS scheme.

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 for a newly created RADIUS scheme.

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.

 

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.

 

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.

Follow these steps to configure shared keys for RADIUS messages:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a RADIUS scheme and enter its view

radius scheme radius-scheme-name

Required

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

By default, no shared key is created.

Set a shared key for RADIUS accounting messages

key accounting string

Required

By default, no shared key is created.

 

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.

 

Configuring the Maximum Number of RADIUS Request Transmission Attempts

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.

Follow these steps to configure the maximum transmission attempts of a RADIUS request:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a RADIUS scheme and enter its view

radius scheme radius-scheme-name

Required

By default, a RADIUS scheme named "system" has already been created in the system.

Set the maximum number of RADIUS request transmission attempts

retry retry-times

Optional

By default, the system can try three times to transmit a RADIUS request.

 

Configuring the Type of RADIUS Servers to be Supported

Follow these steps to configure the type of RADIUS servers to be supported:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a RADIUS scheme and enter its view

radius scheme radius-scheme-name

Required

By default, a RADIUS scheme named "system" has already been created in the system.

Configure the type of RADIUS servers to be supported

server-type { extended | standard }

Optional

 

l          If you change the RADIUS server type, the units of data flows sent to RADIUS servers will be restored to the defaults.

l          When the third party RADIUS server is used, you can select standard or extended as the server-type in a RADIUS scheme; when the CAMS server is used, you can select extended as the server-type in a RADIUS scheme.

 

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.

Follow these steps to set the status of RADIUS servers:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a RADIUS scheme and enter 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 RADIUS servers specified with IP addresses in the RADIUS scheme are all in the active state.

Set the status of the primary RADIUS accounting server

state primary accounting { block | active }

Set the status of the secondary RADIUS authentication/authorization server

state secondary authentication { block | active }

Set the status of the secondary RADIUS accounting server

state secondary accounting { block | active }

 

Configuring the Attributes of Data to be Sent to RADIUS Servers

Follow these steps to configure the attributes of data to be sent to RADIUS servers:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a RADIUS scheme and enter its view

radius scheme radius-scheme-name

Required

By default, a RADIUS scheme named "system" has already been created in the system.

Set the format of the usernames to be sent to RADIUS server

user-name-format { with-domain | without-domain }

Optional

By default, the usernames 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 RADIUS scheme, the data unit and packet unit for outgoing RADIUS flows are byte and one-packet respectively.

Set the MAC address format of the Calling-Station-Id (Type 31) field in RADIUS packets

calling-station-id mode { mode1 | mode2 } { lowercase | uppercase }

Optional

By default, the MAC address format is XXXX-XXXX-XXXX, in lowercase.

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

 

l          Generally, the access users are named in the userid@isp-name or userid.isp-name format. Here, isp-name after the “@” or “.” 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 usernames that carry ISP domain names. In this case, it is necessary to remove domain names from usernames before sending the usernames 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 usernames to be sent to RADIUS server.

l          For a RADIUS scheme, if you have specified to remove ISP domain names from usernames, 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 usernames by default.

l          The purpose of setting the MAC address format of the Calling-Station-Id (Type 31) field in RADIUS packets is to improve the switch’s compatibility with different RADIUS servers. This setting is necessary when the format of Calling-Station-Id field recognizable to RADIUS servers is different from the default MAC address format on the switch. For details about field formats recognizable to RADIUS servers, refer to the corresponding RADIUS server manual.

 

Configuring the Local RADIUS Server

The switch provides the local RADIUS server function (including authentication and authorization), also known as the local RADIUS server function, in addition to RADIUS client service, where separate authentication/authorization server and the accounting server are used for user authentication.

Follow these steps to configure the local RADIUS server function:

To do…

Use the command…

Remarks

Enter system view

system-view

Enable UDP ports for local RADIUS services

local-server enable

Optional

By default, the UDP ports for local RADIUS services are enabled.

Configure the parameters of the local RADIUS server

local-server nas-ip ip-address key password

Required

By default, a local RADIUS server is configured with an NAS IP address of 127.0.0.1.

 

l          If you adopt the local RADIUS 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          The switch supports IP addresses and shared keys for up to 16 network access servers (NAS). That is, when acting as the local RADIUS server, the switch can provide authentication service to up to 16 network access servers (including the switch itself) at the same time.

l          When acting as the local RADIUS server, the switch does not support EAP authentication (that is you cannot set the 802.1x authentication method as eap by using the dot1x authentication-method eap command).

 

Configuring Timers for 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.

Follow these steps to set timers for RADIUS servers:

To do…

Use the command…

Remarks

Enter system view

system-view

Create a RADIUS scheme and enter its view

radius scheme radius-scheme-name

Required

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.

 

Enabling Sending Trap Message when a RADIUS Server Goes Down

Follow these steps to specify to send trap message when a RADIUS server goes down:

To do…

Use the command…

Remarks

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.

 

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.

 

Enabling the User Re-Authentication at Restart Function

 

The user re-authentication at restart function applies only 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.

 

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.

 

Follow these steps to enable the user re-authentication at restart function:

To do…

Use the command…

Remarks

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.

 

HWTACACS Configuration Task List

Complete the following tasks to configure HWTACACS:

Task

Remarks

Configuring the TACACS client

Creating a HWTACACS Scheme

Required

Configuring TACACS Authentication Servers

Required

Configuring TACACS Authorization Servers

Required

Configuring TACACS Accounting Servers

Optional

Configuring Shared Keys for RADIUS Messages

Optional

Configuring the Attributes of Data to be Sent to TACACS Servers

Optional

Configuring the Timers Regarding TACACS Servers

Optional

Configuring the TACACS server

Refer to the configuration of TACACS servers.

 

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

Follow these steps to create a HWTACACS scheme:

To do…

Use the command…

Remarks

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.

 

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.

 

Configuring TACACS Authentication Servers

Follow these steps to configure TACACS authentication servers:

To do…

Use the command…

Remarks

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 ]

Optional

By default, the IP address of the secondary authentication server is 0.0.0.0, and the port number is 0.

 

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.

 

Configuring TACACS Authorization Servers

Follow these steps to configure TACACS authorization servers:

To do…

Use the command…

Remarks

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 ]

Optional

By default, the IP address of the secondary authorization server is 0.0.0.0, and the port number is 0.

 

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.

 

Configuring TACACS Accounting Servers

Follow these steps to configure TACACS accounting servers:

To do…

Use the command…

Remarks

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.

 

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.

 

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.

Follow these steps to configure shared keys for HWTACACS messages:

To do…

Use the command…

Remarks

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.

 

Configuring the Attributes of Data to be Sent to TACACS Servers

Follow these steps to configure the attributes for data to be sent to TACACS servers:

To do…

Use the command…

Remarks

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 usernames to be sent to TACACS server

user-name-format { with-domain | without-domain }

Optional

By default, the usernames 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

 

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

 

Configuring the Timers Regarding TACACS Servers

Follow these steps to configure the timers regarding TACACS servers:

To do…

Use the command…

Remarks

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.

 

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.

 

Displaying and Maintaining AAA Configuration

Displaying and Maintaining AAA Configuration

To do…

Use the command…

Remarks

Display configuration information about one specific or all ISP domains

display domain [ isp-name ]

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

 

Displaying and Maintaining RADIUS Protocol Configuration

To do…

Use the command…

Remarks

Display RADIUS message statistics about local RADIUS server

display local-server statistics

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

Available in user view

Clear RADIUS message statistics

reset radius statistics

 

Displaying and Maintaining HWTACACS Protocol Configuration

To do…

Use the command…

Remarks

Display the configuration or statistic information about one specific or all HWTACACS schemes

display hwtacacs [ hwtacacs-scheme-name [ statistics ] ]

Available in any view

Display buffered non-response stop-accounting requests

display stop-accounting-buffer { hwtacacs-scheme hwtacacs-scheme-name

Clear HWTACACS message statistics

reset hwtacacs statistics { accounting | authentication | authorization | all }

Available in user view

Delete buffered non-response stop-accounting requests

reset stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name

 

AAA Configuration Examples

Remote RADIUS Authentication of Telnet/SSH Users

 

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.

 

Network requirements

In the network environment shown in Figure 2-1, 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 authentication server with IP address 10.110.91.164 is connected to the switch.

l          On the switch, set the shared key it uses to exchange messages with the authentication RADIUS server to aabbcc.

l          A CAMS server is used as the RADIUS server. You can select extended as the server-type in a RADIUS scheme.

l          On the RADIUS server, set the shared key it uses to exchange messages with the switch to aabbcc, set the authentication port number, and add Telnet usernames and login passwords.

The Telnet usernames 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 usernames to be sent to the RADIUS server in the RADIUS scheme.

Network diagram

Figure 2-1 Remote RADIUS authentication of Telnet users

 

Configuration procedure

# Enter system view.

<Sysname> system-view

# Adopt AAA authentication for Telnet users.

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Configure an ISP domain.

[Sysname] domain cams

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

[Sysname-isp-cams] quit

# Configure a RADIUS scheme.

[Sysname] radius scheme cams

[Sysname-radius-cams] accounting optional

[Sysname-radius-cams] primary authentication 10.110.91.164 1812

[Sysname-radius-cams] key authentication aabbcc

[Sysname-radius-cams] server-type Extended

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

[Sysname-radius-cams] quit

# Associate the ISP domain with the RADIUS scheme.

[Sysname] domain cams

[Sysname-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.

Local Authentication of FTP/Telnet Users

 

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.

 

Network requirements

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

Network diagram

Figure 2-2 Local authentication of Telnet users

 

Configuration procedure

Method 1: Using local authentication scheme.

# Enter system view.

<Sysname> system-view

# Adopt AAA authentication for Telnet users.

[Sysname] user-interface vty 0 4

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

[Sysname-ui-vty0-4] quit

# Create and configure a local user named telnet.

[Sysname] local-user telnet

[Sysname-luser-telnet] service-type telnet

[Sysname-luser-telnet] password simple aabbcc

[Sysname-luser-telnet] quit

# Configure an authentication scheme for the default “system” domain.

[Sysname] domain system

[Sysname-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 Remote RADIUS Authentication of Telnet/SSH Users. However, you need to:

l          Change the server IP address, and the UDP port number of the authentication server to 127.0.0.1, and 1645 respectively in the configuration step "Configure a RADIUS scheme" in Remote RADIUS Authentication of Telnet/SSH Users.

l          Enable the local RADIUS server function, set the IP address and shared key for the network access server to 127.0.0.1 and aabbcc, respectively.

l          Configure local users.

HWTACACS Authentication and Authorization of Telnet Users

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 aabbcc. Configure the switch to strip domain names off usernames before sending usernames to the TACACS server.

Configure the shared key to aabbcc on the TACACS server for exchanging messages with the switch.

Network diagram

Figure 2-3 Remote HWTACACS authentication and authorization of Telnet users

 

Configuration procedure

# Add a Telnet user.

(Omitted here)

# Configure a HWTACACS scheme.

<Sysname> system-view

[Sysname] hwtacacs scheme hwtac

[Sysname-hwtacacs-hwtac] primary authentication 10.110.91.164 49

[Sysname-hwtacacs-hwtac] primary authorization 10.110.91.164 49

[Sysname-hwtacacs-hwtac] key authentication aabbcc

[Sysname-hwtacacs-hwtac] key authorization aabbcc

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

[Sysname-hwtacacs-hwtac] quit

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

[Sysname] domain hwtacacs

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

Troubleshooting AAA

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 username is not in the userid@isp-name or userid.isp-name format, or the default ISP domain is not correctly specified on the switch — Use the correct username 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.

Troubleshooting HWTACACS Configuration

See the previous section if you encounter an HWTACACS fault.

 


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.

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 3-1 shows a typical network application of EAD.

Figure 3-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.

EAD Configuration

The EAD configuration includes:

l          Configuring the attributes of access users (such as username, 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 a RADIUS scheme.

l          Configuring the IP address of the security policy server.

l          Associating the ISP domain with the 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 AAA Overview.

Follow these steps to configure EAD:

To do…

Use the command…

Remarks

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.

 

EAD Configuration Example

Network requirements

In Figure 3-2:

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

l          The user adopts 802.1x client supporting EAD 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.

Network diagram

Figure 3-2 EAD configuration

 

Configuration procedure

# Configure 802.1x on the switch. Refer to “Configuring 802.1x” in 802.1x and System Guard Configuration.

# Configure a domain.

<Sysname> system-view

[Sysname] domain system

[Sysname-isp-system] quit

# Configure a RADIUS scheme.

[Sysname] radius scheme cams

[Sysname-radius-cams] primary authentication 10.110.91.164 1812

[Sysname-radius-cams] accounting optional

[Sysname-radius-cams] key authentication expert

[Sysname-radius-cams] server-type extended

# Configure the IP address of the security policy server.

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

# Associate the domain with the RADIUS scheme.

[Sysname-radius-cams] quit

[Sysname] domain system

[Sysname-isp-system] radius-scheme cams

 

  • Cloud & AI
  • InterConnect
  • Intelligent Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become a Partner
  • Partner Resources
  • Partner Business Management
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网