- Table of Contents
-
- H3C S3600 Operation Manual-Release 1602(V1.02)
- 00-1Cover
- 00-2Product Overview
- 01-CLI Operation
- 02-Login Operation
- 03-Configuration File Management Operation
- 04-VLAN Operation
- 05-IP Address and Performance Operation
- 06-Voice VLAN Operation
- 07-GVRP Operation
- 08-Port Basic Configuration Operation
- 09-Link Aggregation Operation
- 10-Port Isolation Operation
- 11-Port Security-Port Binding Operation
- 12-DLDP Operation
- 13-MAC Address Table Management Operation
- 14-Auto Detect Operation
- 15-MSTP Operation
- 16-Routing Protocol Operation
- 17-Multicast Operation
- 18-802.1x and System Guard Operation
- 19-AAA Operation
- 20-Web Authentication Operation
- 21-MAC Address Authentication Operation
- 22-VRRP Operation
- 23-ARP Operation
- 24-DHCP Operation
- 25-ACL Operation
- 26-QoS-QoS Profile Operation
- 27-Web Cache Redirection Operation
- 28-Mirroring Operation
- 29-IRF Fabric Operation
- 30-Cluster Operation
- 31-PoE-PoE Profile Operation
- 32-UDP Helper Operation
- 33-SNMP-RMON Operation
- 34-NTP Operation
- 35-SSH Operation
- 36-File System Management Operation
- 37-FTP-SFTP-TFTP Operation
- 38-Information Center Operation
- 39-System Maintenance and Debugging Operation
- 40-VLAN-VPN Operation
- 41-HWPing Operation
- 42-IPv6 Management Operation
- 43-DNS Operation
- 44-Smart Link-Monitor Link Operation
- 45-Access Management Operation
- 46-Appendix
- Related Documents
-
Title | Size | Download |
---|---|---|
19-AAA Operation | 470.11 KB |
Table of Contents
Creating an ISP Domain and Configuring Its Attributes
Configuring an AAA Scheme for an ISP Domain
Configuring Dynamic VLAN Assignment
Configuring the Attributes of a Local User
Cutting Down User Connections Forcibly
RADIUS Configuration Task List
Configuring RADIUS Authentication/Authorization Servers
Configuring RADIUS Accounting Servers
Configuring Shared Keys for RADIUS Messages
Configuring the Maximum Number of RADIUS Request Transmission Attempts
Configuring the Type of RADIUS Servers to be Supported
Configuring the Status of RADIUS Servers
Configuring the Attributes of Data to be Sent to RADIUS Servers
Configuring the Local RADIUS Server
Configuring Timers for RADIUS Servers
Enabling Sending Trap Message when a RADIUS Server Goes Down
Enabling the User Re-Authentication at Restart Function
HWTACACS Configuration Task List
Configuring TACACS Authentication Servers
Configuring TACACS Authorization Servers
Configuring TACACS Accounting Servers
Configuring Shared Keys for HWTACACS Messages
Configuring the Attributes of Data to be Sent to TACACS Servers
Configuring the Timers Regarding TACACS Servers
Displaying and Maintaining AAA Configuration
Displaying and Maintaining AAA Configuration
Displaying and Maintaining RADIUS Protocol Configuration
Displaying and Maintaining HWTACACS Protocol Configuration
Remote RADIUS Authentication of Telnet/SSH Users
Local Authentication of FTP/Telnet Users
HWTACACS Authentication and Authorization of Telnet Users
Troubleshooting RADIUS Configuration
Troubleshooting HWTACACS Configuration
Typical Network Application of EAD
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.
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 |
Required |
||
Required |
|||
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 |
|||
Optional |
|||
Optional |
|||
Optional |
Complete the following tasks to configure AAA (configuring separate AAA schemes for an ISP domain):
Task |
Remarks |
|
AAA configuration |
Required |
|
Required |
||
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. |
||
Optional |
||
Optional |
||
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:
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 |
Required |
|
Required |
||
Required |
||
Optional |
||
Configuring the Maximum Number of RADIUS Request Transmission Attempts |
Optional |
|
Optional |
||
Optional |
||
Configuring the Attributes of Data to be Sent to RADIUS Servers |
Optional |
|
Optional |
||
Enabling Sending Trap Message when a RADIUS Server Goes Down |
Optional |
|
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 |
Required |
|
Required |
||
Required |
||
Optional |
||
Configuring the Maximum Number of RADIUS Request Transmission Attempts |
Optional |
|
Optional |
||
Optional |
||
Configuring the Attributes of Data to be Sent to RADIUS Servers |
Optional |
|
Required |
||
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 |
Required |
|
Required |
||
Required |
||
Optional |
||
Optional |
||
Configuring the Attributes of Data to be Sent to TACACS Servers |
Optional |
|
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
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