- Table of Contents
- Related Documents
-
01-Text
Download Book (2.19 MB)AAA implementation on the device
AAA configuration considerations and task list
Configuring AAA methods for ISP domains
Configuring ISP domain attributes
Configuring authentication methods for an ISP domain
Configuring authorization methods for an ISP domain
Configuring accounting methods for an ISP domain
Configuring the RADIUS session-control feature
Configuring the RADIUS DAS feature
Changing the DSCP priority for RADIUS packets
Configuring the RADIUS attribute translation feature
Setting the maximum number of concurrent login users
Displaying and maintaining AAA
AAA for SSH users by an HWTACACS server
Local authentication, HWTACACS authorization, and RADIUS accounting for SSH users
Authentication and authorization for SSH users by a RADIUS server
RADIUS packet delivery failure
Password updating and expiration
Password not displayed in any form
Password control configuration task list
Setting global password control parameters
Setting user group password control parameters
Setting local user password control parameters
Setting super password control parameters
Displaying and maintaining password control
Password control configuration example
Displaying and maintaining keychain··
Keychain configuration example
Distributing a local host public key
Configuring a peer host public key
Importing a peer host public key from a public key file
Entering a peer host public key
Displaying and maintaining public keys
Examples of public key management
Example for entering a peer host public key
Example for importing a public key from a public key file
Configuring the device as an SSH server
SSH server configuration task list
Configuring the user lines for SSH login··
Configuring a client's host public key
Configuring the SSH management parameters
Configuring the device as an Stelnet client
Stelnet client configuration task list
Specifying the source IP address for SSH packets
Establishing a connection to an Stelnet server
Configuring the device as an SFTP client
SFTP client configuration task list
Specifying the source IP address for SFTP packets
Establishing a connection to an SFTP server
Terminating the connection with the SFTP server
Configuring the device as an SCP client
SCP client configuration task list
Establishing a connection to an SCP server
Specifying algorithms for SSH2
Specifying key exchange algorithms for SSH2
Specifying public key algorithms for SSH2·
Specifying encryption algorithms for SSH2·
Specifying MAC algorithms for SSH2·
Displaying and maintaining SSH
Stelnet configuration examples
Password authentication enabled Stelnet server configuration example
Publickey authentication enabled Stelnet server configuration example
Password authentication enabled Stelnet client configuration example
Publickey authentication enabled Stelnet client configuration example
Password authentication enabled SFTP server configuration example
Publickey authentication enabled SFTP client configuration example
SCP configuration example with password authentication
NETCONF over SSH configuration example with password authentication
Configuring attack detection and prevention
Attacks that the device can prevent
Attack detection and prevention configuration task list
Configuring an attack defense policy
Creating an attack defense policy
Configuring a single-packet attack defense policy
Configuring a scanning attack defense policy
Configuring a flood attack defense policy
Configuring attack detection exemption··
Applying an attack defense policy to the device
Enabling log non-aggregation for single-packet attack events
Configuring TCP fragment attack prevention
Displaying and maintaining attack detection and prevention
Attack detection and prevention configuration examples
Attack defense policy device application configuration example
Configuring TCP attack prevention
Configuring Naptha attack prevention
Configuring the IPv4SG feature
Enabling IPv4SG on an interface
Configuring a static IPv4SG binding
Configuring the IPv6SG feature
Enabling IPv6SG on an interface
Configuring a static IPv6SG binding
Displaying and maintaining IPSG
Static IPv4SG configuration example
Dynamic IPv4SG using DHCP snooping configuration example
Dynamic IPv4SG using DHCP relay agent configuration example
Static IPv6SG configuration example
Dynamic IPv6SG using DHCPv6 relay agent configuration example
Configuring ARP attack protection
ARP attack protection configuration task list
Configuring unresolvable IP attack protection
Configuring ARP source suppression
Configuring ARP blackhole routing
Displaying and maintaining unresolvable IP attack protection
Configuring ARP packet rate limit
Configuring source MAC-based ARP attack detection
Displaying and maintaining source MAC-based ARP attack detection
Configuring ARP packet source MAC consistency check
Configuring ARP active acknowledgement
Configuration example (on a DHCP server)
Configuration example (on a DHCP relay agent)
Configuring ARP attack detection
Configuring user validity check
Configuring ARP packet validity check
Configuring ARP restricted forwarding
Enabling ARP attack detection logging
Displaying and maintaining ARP attack detection
User validity check and ARP packet validity check configuration example
ARP restricted forwarding configuration example
Configuring ARP scanning and fixed ARP
Configuration restrictions and guidelines
Configuring ARP gateway protection
Enabling source MAC consistency check for ND messages
Displaying and maintaining uRPF
Interface-specific uRPF configuration example
Global uRPF configuration example
Configuration restrictions and guidelines
Configuration changes in FIPS mode
Displaying and maintaining FIPS
Entering FIPS mode through automatic reboot
Entering FIPS mode through manual reboot
Exiting FIPS mode through automatic reboot
Exiting FIPS mode through manual reboot
Configuring AAA
Overview
Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing network access management. This feature specifies the following security functions:
· Authentication—Identifies users and verifies their validity.
· Authorization—Grants different users different rights, and controls the users' access to resources and services. For example, you can permit office users to read and print files and prevent guests from accessing files on the device.
· Accounting—Records network usage details of users, including the service type, start time, and traffic. This function enables time-based and traffic-based charging and user behavior auditing.
AAA uses a client/server model. The client runs on the access device, or the network access server (NAS), which authenticates user identities and controls user access. The server maintains user information centrally. See Figure 1.
Figure 1 AAA network diagram
To access networks or resources beyond the NAS, a user sends its identity information to the NAS. The NAS transparently passes the user information to AAA servers and waits for the authentication, authorization, and accounting result. Based on the result, the NAS determines whether to permit or deny the access request.
AAA has various implementations, including RADIUS and HWTACACS. RADIUS is most often used.
The network in Figure 1 has one RADIUS server and one HWTACACS server. You can use different servers to implement different security functions. For example, you can use the HWTACACS server for authentication and authorization, and use the RADIUS server for accounting.
You can choose the security functions provided by AAA as needed. For example, if your company wants employees to be authenticated before they access specific resources, you would deploy an authentication server. If network usage information is needed, you would also configure an accounting server.
The device performs dynamic password authentication.
RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. The protocol can protect networks against unauthorized access and is often used in network environments that require both high security and remote user access.
The RADIUS authorization process is combined with the RADIUS authentication process, and user authorization information is piggybacked in authentication responses. RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting.
RADIUS was originally designed for dial-in user access, and has been extended to support additional access methods, such as Ethernet and ADSL.
Client/server model
The RADIUS client runs on the NASs located throughout the network. It passes user information to RADIUS servers and acts on the responses to, for example, reject or accept user access requests.
The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network service access.
The RADIUS server operates using the following process:
1. Receives authentication, authorization, and accounting requests from RADIUS clients.
2. Performs user authentication, authorization, or accounting.
3. Returns user access control information (for example, rejecting or accepting the user access request) to the clients.
The RADIUS server can also act as the client of another RADIUS server to provide authentication proxy services.
The RADIUS server maintains the following databases:
· Users—Stores user information, such as the usernames, passwords, applied protocols, and IP addresses.
· Clients—Stores information about RADIUS clients, such as shared keys and IP addresses.
· Dictionary—Stores RADIUS protocol attributes and their values.
Figure 2 RADIUS server databases
Information exchange security mechanism
The RADIUS client and server exchange information between them with the help of shared keys, which are preconfigured on the client and server. A RADIUS packet has a 16-byte field called Authenticator. This field includes a signature generated by using the MD5 algorithm, the shared key, and some other information. The receiver of the packet verifies the signature and accepts the packet only when the signature is correct. This mechanism ensures the security of information exchanged between the RADIUS client and server.
The shared keys are also used to encrypt user passwords that are included in RADIUS packets.
User authentication methods
The RADIUS server supports multiple user authentication methods, such as PAP, CHAP, and EAP.
Basic RADIUS packet exchange process
Figure 3 illustrates the interactions between a user host, the RADIUS client, and the RADIUS server.
Figure 3 Basic RADIUS packet exchange process
RADIUS uses in the following workflow:
1. The host sends a connection request that includes the user's username and password to the RADIUS client.
2. The RADIUS client sends an authentication request (Access-Request) to the RADIUS server. The request includes the user's password, which has been processed by the MD5 algorithm and shared key.
3. The RADIUS server authenticates the username and password. If the authentication succeeds, the server sends back an Access-Accept packet that contains the user's authorization information. If the authentication fails, the server returns an Access-Reject packet.
4. The RADIUS client permits or denies the user according to the authentication result. If the result permits the user, the RADIUS client sends a start-accounting request (Accounting-Request) packet to the RADIUS server.
5. The RADIUS server returns an acknowledgment (Accounting-Response) packet and starts accounting.
6. The user accesses the network resources.
7. The host requests the RADIUS client to tear down the connection.
8. The RADIUS client sends a stop-accounting request (Accounting-Request) packet to the RADIUS server.
9. The RADIUS server returns an acknowledgment (Accounting-Response) and stops accounting for the user.
10. The RADIUS client notifies the user of the termination.
RADIUS packet format
RADIUS uses UDP to transmit packets. The protocol also uses a series of mechanisms to ensure smooth packet exchange between the RADIUS server and the client. These mechanisms include the timer mechanism, the retransmission mechanism, and the backup server mechanism.
Figure 4 RADIUS packet format
Descriptions of the fields are as follows:
· The Code field (1 byte long) indicates the type of the RADIUS packet. Table 1 gives the main values and their meanings.
Table 1 Main values of the Code field
Code |
Packet type |
Description |
1 |
Access-Request |
From the client to the server. A packet of this type includes user information for the server to authenticate the user. It must contain the User-Name attribute and can optionally contain the attributes of NAS-IP-Address, User-Password, and NAS-Port. |
2 |
Access-Accept |
From the server to the client. If all attribute values included in the Access-Request are acceptable, the authentication succeeds, and the server sends an Access-Accept response. |
3 |
Access-Reject |
From the server to the client. If any attribute value included in the Access-Request is unacceptable, the authentication fails, and the server sends an Access-Reject response. |
4 |
Accounting-Request |
From the client to the server. A packet of this type includes user information for the server to start or stop accounting for the user. The Acct-Status-Type attribute in the packet indicates whether to start or stop accounting. |
5 |
Accounting-Response |
From the server to the client. The server sends a packet of this type to notify the client that it has received the Accounting-Request and has successfully recorded the accounting information. |
· The Identifier field (1 byte long) is used to match response packets with request packets and to detect duplicate request packets. The request and response packets of the same exchange process for the same purpose (such as authentication or accounting) have the same identifier.
· The Length field (2 bytes long) indicates the length of the entire packet (in bytes), including the Code, Identifier, Length, Authenticator, and Attributes fields. Bytes beyond this length are considered padding and are ignored by the receiver. If the length of a received packet is less than this length, the packet is dropped.
· The Authenticator field (16 bytes long) is used to authenticate responses from the RADIUS server and to encrypt user passwords. There are two types of authenticators: request authenticator and response authenticator.
· The Attributes field (variable in length) includes authentication, authorization, and accounting information. This field can contain multiple attributes, each with the following subfields:
? Type—Type of the attribute.
? Length—Length of the attribute in bytes, including the Type, Length, and Value subfields.
? Value—Value of the attribute. Its format and content depend on the Type subfield.
Commonly used RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868. For more information, see "Commonly used standard RADIUS attributes."
Table 2 Commonly used RADIUS attributes
No. |
Attribute |
No. |
Attribute |
1 |
User-Name |
45 |
Acct-Authentic |
2 |
User-Password |
46 |
Acct-Session-Time |
3 |
CHAP-Password |
47 |
Acct-Input-Packets |
4 |
NAS-IP-Address |
48 |
Acct-Output-Packets |
5 |
NAS-Port |
49 |
Acct-Terminate-Cause |
6 |
Service-Type |
50 |
Acct-Multi-Session-Id |
7 |
Framed-Protocol |
51 |
Acct-Link-Count |
8 |
Framed-IP-Address |
52 |
Acct-Input-Gigawords |
9 |
Framed-IP-Netmask |
53 |
Acct-Output-Gigawords |
10 |
Framed-Routing |
54 |
(unassigned) |
11 |
Filter-ID |
55 |
Event-Timestamp |
12 |
Framed-MTU |
56-59 |
(unassigned) |
13 |
Framed-Compression |
60 |
CHAP-Challenge |
14 |
Login-IP-Host |
61 |
NAS-Port-Type |
15 |
Login-Service |
62 |
Port-Limit |
16 |
Login-TCP-Port |
63 |
Login-LAT-Port |
17 |
(unassigned) |
64 |
Tunnel-Type |
18 |
Reply-Message |
65 |
Tunnel-Medium-Type |
19 |
Callback-Number |
66 |
Tunnel-Client-Endpoint |
20 |
Callback-ID |
67 |
Tunnel-Server-Endpoint |
21 |
(unassigned) |
68 |
Acct-Tunnel-Connection |
22 |
Framed-Route |
69 |
Tunnel-Password |
23 |
Framed-IPX-Network |
70 |
ARAP-Password |
24 |
State |
71 |
ARAP-Features |
25 |
Class |
72 |
ARAP-Zone-Access |
26 |
Vendor-Specific |
73 |
ARAP-Security |
27 |
Session-Timeout |
74 |
ARAP-Security-Data |
28 |
Idle-Timeout |
75 |
Password-Retry |
29 |
Termination-Action |
76 |
Prompt |
30 |
Called-Station-Id |
77 |
Connect-Info |
31 |
Calling-Station-Id |
78 |
Configuration-Token |
32 |
NAS-Identifier |
79 |
EAP-Message |
33 |
Proxy-State |
80 |
Message-Authenticator |
34 |
Login-LAT-Service |
81 |
Tunnel-Private-Group-ID |
35 |
Login-LAT-Node |
82 |
Tunnel-Assignment-id |
36 |
Login-LAT-Group |
83 |
Tunnel-Preference |
37 |
Framed-AppleTalk-Link |
84 |
ARAP-Challenge-Response |
38 |
Framed-AppleTalk-Network |
85 |
Acct-Interim-Interval |
39 |
Framed-AppleTalk-Zone |
86 |
Acct-Tunnel-Packets-Lost |
40 |
Acct-Status-Type |
87 |
NAS-Port-Id |
41 |
Acct-Delay-Time |
88 |
Framed-Pool |
42 |
Acct-Input-Octets |
89 |
(unassigned) |
43 |
Acct-Output-Octets |
90 |
Tunnel-Client-Auth-id |
44 |
Acct-Session-Id |
91 |
Tunnel-Server-Auth-id |
Extended RADIUS attributes
The RADIUS protocol features excellent extensibility. The Vendor-Specific attribute (attribute 26) allows a vendor to define extended attributes. The extended attributes can implement functions that the standard RADIUS protocol does not provide.
A vendor can encapsulate multiple subattributes in the TLV format in attribute 26 to provide extended functions. As shown in Figure 5, a subattribute encapsulated in attribute 26 consists of the following parts:
· Vendor-ID—ID of the vendor. The most significant byte is 0. The other three bytes contains a code compliant to RFC 1700.
· Vendor-Type—Type of the subattribute.
· Vendor-Length—Length of the subattribute.
· Vendor-Data—Contents of the subattribute.
The device supports RADIUS subattributes with a vendor ID of 25506. For more information, see "Proprietary RADIUS subattributes (vendor ID 25506)."
Figure 5 Format of attribute 26
HWTACACS
HWTACACS typically provides AAA services for PPP, VPDN, and terminal users. In a typical HWTACACS scenario, terminal users need to log in to the NAS. Working as the HWTACACS client, the NAS sends users' usernames and passwords to the HWTACACS server for authentication. After passing authentication and obtaining authorized rights, a user logs in to the device and performs operations. The HWTACACS server records the operations that each user performs.
Differences between HWTACACS and RADIUS
HWTACACS and RADIUS have many features in common, such as using a client/server model, using shared keys for data encryption, and providing flexibility and scalability. Table 3 lists the primary differences between HWTACACS and RADIUS.
Table 3 Primary differences between HWTACACS and RADIUS
HWTACACS |
RADIUS |
Uses TCP, which provides reliable network transmission. |
Uses UDP, which provides high transport efficiency. |
Encrypts the entire packet except for the HWTACACS header. |
Encrypts only the user password field in an authentication packet. |
Protocol packets are complicated and authorization is independent of authentication. Authentication and authorization can be deployed on different HWTACACS servers. |
Protocol packets are simple and the authorization process is combined with the authentication process. |
Supports authorization of configuration commands. Access to commands depends on both the user's roles and authorization. A user can use only commands that are permitted by the user roles and authorized by the HWTACACS server. |
Does not support authorization of configuration commands. Access to commands solely depends on the user's roles. For more information about user roles, see Fundamentals Configuration Guide. |
Basic HWTACACS packet exchange process
Figure 6 describes how HWTACACS performs user authentication, authorization, and accounting for a Telnet user.
Figure 6 Basic HWTACACS packet exchange process for a Telnet user
HWTACACS operates using in the following workflow:
1. A Telnet user sends an access request to the HWTACACS client.
2. The HWTACACS client sends a start-authentication packet to the HWTACACS server when it receives the request.
3. The HWTACACS server sends back an authentication response to request the username.
4. Upon receiving the response, the HWTACACS client asks the user for the username.
5. The user enters the username.
6. After receiving the username from the user, the HWTACACS client sends the server a continue-authentication packet that includes the username.
7. The HWTACACS server sends back an authentication response to request the login password.
8. Upon receipt of the response, the HWTACACS client prompts the user for the login password.
9. The user enters the password.
10. After receiving the login password, the HWTACACS client sends the HWTACACS server a continue-authentication packet that includes the login password.
11. If the authentication succeeds, the HWTACACS server sends back an authentication response to indicate that the user has passed authentication.
12. The HWTACACS client sends a user authorization request packet to the HWTACACS server.
13. If the authorization succeeds, the HWTACACS server sends back an authorization response, indicating that the user is now authorized.
14. Knowing that the user is now authorized, the HWTACACS client pushes its CLI to the user and permits the user to log in.
15. The HWTACACS client sends a start-accounting request to the HWTACACS server.
16. The HWTACACS server sends back an accounting response, indicating that it has received the start-accounting request.
17. The user logs off.
18. The HWTACACS client sends a stop-accounting request to the HWTACACS server.
19. The HWTACACS server sends back a stop-accounting response, indicating that the stop-accounting request has been received.
AAA implementation on the device
This section describes AAA user management and methods.
User management based on ISP domains and user access types
AAA manages users based on the users' ISP domains and access types.
On a NAS, each user belongs to one ISP domain. The NAS determines the ISP domain to which a user belongs based on the username entered by the user at login.
Figure 7 Determining the ISP domain for a user by username
AAA manages users in the same ISP domain based on the users' access types. The device supports the following user access types:
· Login—Login users include SSH, Telnet, FTP, and terminal users that log in to the device. Terminal users can access through a console port.
· HTTP or HTTPS—Users log in to the device through HTTP or HTTPS.
AAA methods
AAA supports configuring different authentication, authorization, and accounting methods for different types of users in an ISP domain. The NAS determines the ISP domain and access type of a user. The NAS also uses the methods configured for the access type in the domain to control the user's access.
AAA also supports configuring a set of default methods for an ISP domain. These default methods are applied to users for which no AAA methods are configured.
The device supports the following authentication methods:
· No authentication—This method trusts all users and does not perform authentication. For security purposes, do not use this method.
· Local authentication—The NAS authenticates users by itself, based on the locally configured user information including the usernames, passwords, and attributes. Local authentication allows high speed and low cost, but the amount of information that can be stored is limited by the size of the storage space.
· Remote authentication—The NAS works with a RADIUS or HWTACACS server to authenticate users. The server manages user information in a centralized manner. Remote authentication provides high capacity, reliable, and centralized authentication services for multiple NASs. You can configure backup methods to be used when the remote server is not available.
The device supports the following authorization methods:
· No authorization—The NAS performs no authorization exchange. The following default authorization information applies after users pass authentication:
? Login users obtain the level-0 user role. For more information about the level-0 user role, see RBAC configuration in Fundamentals Configuration Guide.
? The working directory for FTP, SFTP, and SCP login users is the root directory of the NAS. However, the users do not have permission to access the root directory.
· Local authorization—The NAS performs authorization according to the user attributes locally configured for users.
· Remote authorization—The NAS works with a RADIUS or HWTACACS server to authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS authorization can work only after RADIUS authentication is successful, and the authorization information is included in the Access-Accept packet. HWTACACS authorization is separate from HWTACACS authentication, and the authorization information is included in the authorization response after successful authentication. You can configure backup methods to be used when the remote server is not available.
The device supports the following accounting methods:
· No accounting—The NAS does not perform accounting for the users.
· Local accounting—Local accounting is implemented on the NAS. It counts and controls the number of concurrent users that use the same local user account, but does not provide statistics for charging.
· Remote accounting—The NAS works with a RADIUS server or HWTACACS server for accounting. You can configure backup methods to be used when the remote server is not available.
In addition, the device provides the following login services to enhance device security:
· Command authorization—Enables the NAS to let the authorization server determine whether a command entered by a login user is permitted. Login users can execute only commands permitted by the authorization server. For more information about command authorization, see Fundamentals Configuration Guide.
· Command accounting—When command authorization is disabled, command accounting enables the accounting server to record all valid commands executed on the device. When command authorization is enabled, command accounting enables the accounting server to record all authorized commands. For more information about command accounting, see Fundamentals Configuration Guide.
· User role authentication—Authenticates each user that wants to obtain another user role without logging out or getting disconnected. For more information about user role authentication, see Fundamentals Configuration Guide.
AAA for MPLS L3VPNs
You can deploy AAA across VPNs in an MPLS L3VPN scenario where clients in different VPNs are centrally authenticated. The deployment enables forwarding of RADIUS and HWTACACS packets across MPLS VPNs. For example, as shown in Figure 8, you can deploy AAA across the VPNs. The left PE connects the user private networks to the MPLS backbone and acts as a NAS. The NAS transparently delivers the AAA packets of private users in VPN 1 and VPN 2 to the AAA servers in VPN 3 for centralized authentication. The servers process authentication packets separately for private users from different VPNs.
Protocols and standards
· RFC 2865, Remote Authentication Dial In User Service (RADIUS)
· RFC 2866, RADIUS Accounting
· RFC 2867, RADIUS Accounting Modifications for Tunnel Protocol Support
· RFC 2868, RADIUS Attributes for Tunnel Protocol Support
· RFC 2869, RADIUS Extensions
· RFC 5176, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
· RFC 1492, An Access Control Protocol, Sometimes Called TACACS
RADIUS attributes
Commonly used standard RADIUS attributes
No. |
Attribute |
Description |
1 |
User-Name |
Name of the user to be authenticated. |
2 |
User-Password |
User password for PAP authentication, only present in Access-Request packets when PAP authentication is used. |
3 |
CHAP-Password |
Digest of the user password for CHAP authentication, only present in Access-Request packets when CHAP authentication is used. |
4 |
NAS-IP-Address |
IP address for the server to use to identify the client. Typically, a client is identified by the IP address of its access interface. This attribute is only present in Access-Request packets. |
5 |
NAS-Port |
Physical port of the NAS that the user accesses. |
6 |
Service-Type |
Type of service that the user has requested or type of service to be provided. |
7 |
Framed-Protocol |
Encapsulation protocol for framed access. |
8 |
Framed-IP-Address |
IP address assigned to the user. |
11 |
Filter-ID |
Name of the filter list. |
12 |
Framed-MTU |
MTU for the data link between the user and NAS. |
14 |
Login-IP-Host |
IP address of the NAS interface that the user accesses. |
15 |
Login-Service |
Type of service that the user uses for login. |
18 |
Reply-Message |
Text to be displayed to the user, which can be used by the server to communicate information, for example, the authentication failure reason. |
26 |
Vendor-Specific |
Vendor-specific proprietary attribute. A packet can contain one or more proprietary attributes, each of which can contain one or more subattributes. |
27 |
Session-Timeout |
Maximum service duration for the user before termination of the session. |
28 |
Idle-Timeout |
Maximum idle time permitted for the user before termination of the session. |
31 |
Calling-Station-Id |
User identification that the NAS sends to the server. For the LAN access service provided by an H3C device, this attribute includes the MAC address of the user. |
32 |
NAS-Identifier |
Identification that the NAS uses to identify itself to the RADIUS server. |
40 |
Acct-Status-Type |
Type of the Accounting-Request packet. Possible values include: · 1—Start. · 2—Stop. · 3—Interim-Update. · 4—Reset-Charge. · 7—Accounting-On. (Defined in the 3rd Generation Partnership Project.) · 8—Accounting-Off. (Defined in the 3rd Generation Partnership Project.) · 9 to 14—Reserved for tunnel accounting. · 15—Reserved for failed. |
45 |
Acct-Authentic |
Authentication method used by the user. Possible values include: · 1—RADIUS. · 2—Local. · 3—Remote. |
60 |
CHAP-Challenge |
CHAP challenge generated by the NAS for MD5 calculation during CHAP authentication. |
61 |
NAS-Port-Type |
Type of the physical port of the NAS that is authenticating the user. Possible values include: · 15—Ethernet. · 16—Any type of ADSL. · 17—Cable. (With cable for cable TV.) · 19—WLAN-IEEE 802.11. · 201—VLAN. · 202—ATM. If the port is an ATM or Ethernet one and VLANs are implemented on it, the value of this attribute is 201. |
64 |
Tunnel-Type |
Tunneling protocols used. The value 13 represents VLAN. |
65 |
Tunnel-Medium-Type |
Transport medium type to use for creating a tunnel. For VLAN assignment, the value must be 6 to indicate the 802 media plus Ethernet. |
79 |
EAP-Message |
Used to encapsulate EAP packets to allow RADIUS to support EAP authentication. |
80 |
Message-Authenticator |
Used for authentication and verification of authentication packets to prevent spoofing Access-Requests. This attribute is present when EAP authentication is used. |
81 |
Tunnel-Private-Group-ID |
Group ID for a tunnel session. To assign VLANs, the NAS conveys VLAN IDs by using this attribute. |
87 |
NAS-Port-Id |
String for describing the port of the NAS that is authenticating the user. |
Proprietary RADIUS subattributes (vendor ID 25506)
Table 4 lists all RADIUS subattributes with a vendor ID of 25506. Support for these subattributes depends on the device model.
Table 4 RADIUS subattributes (vendor ID 25506)
No. |
Subattribute |
Description |
1 |
Input-Peak-Rate |
Peak rate in the direction from the user to the NAS, in bps. |
2 |
Input-Average-Rate |
Average rate in the direction from the user to the NAS, in bps. |
3 |
Input-Basic-Rate |
Basic rate in the direction from the user to the NAS, in bps. |
4 |
Output-Peak-Rate |
Peak rate in the direction from the NAS to the user, in bps. |
5 |
Output-Average-Rate |
Average rate in the direction from the NAS to the user, in bps. |
6 |
Output-Basic-Rate |
Basic rate in the direction from the NAS to the user, in bps. |
15 |
Remanent_Volume |
Total amount of data available for the connection, in different units for different server types. |
17 |
ISP-ID |
ISP domain where the user obtains authorization information. |
20 |
Command |
Operation for the session, used for session control. Possible values include: · 1—Trigger-Request. · 2—Terminate-Request. · 3—SetPolicy. · 4—Result. · 5—PortalClear. |
25 |
Result_Code |
Result of the Trigger-Request or SetPolicy operation, zero for success and any other value for failure. |
26 |
Connect_ID |
Index of the user connection. |
27 |
PortalURL |
PADM redirect URL assigned to PPPoE users. |
28 |
Ftp_Directory |
FTP, SFTP, or SCP user working directory. When the RADIUS client acts as the FTP, SFTP, or SCP server, this attribute is used to set the working directory for an FTP, SFTP, or SCP user on the RADIUS client. |
29 |
Exec_Privilege |
EXEC user priority. |
32 |
NAT-IP-Address |
Public IP address assigned to the user when the source IP address and port are translated. |
33 |
NAT-Start-Port |
Start port number of the port range assigned to the user when the source IP address and port are translated. |
34 |
NAT-End-Port |
End port number of the port range assigned to the user when the source IP address and port are translated. |
59 |
NAS_Startup_Timestamp |
Startup time of the NAS in seconds, which is represented by the time elapsed after 00:00:00 on Jan. 1, 1970 (UTC). |
60 |
Ip_Host_Addr |
User IP address and MAC address included in authentication and accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space is required between the IP address and the MAC address. |
61 |
User_Notify |
Information that must be sent from the server to the client transparently. |
62 |
User_HeartBeat |
Hash value assigned after an 802.1X user passes authentication, which is a 32-byte string. This attribute is stored in the user list on the NAS and verifies the handshake packets from the 802.1X user. This attribute only exists in Access-Accept and Accounting-Request packets. |
98 |
Multicast_Receive_Group |
IP address of the multicast group that the user's host joins as a receiver. This subattribute can appear multiple times in a multicast packet to indicate that the user belongs to multiple multicast groups. |
100 |
IP6_Multicast_Receive_Group |
IPv6 address of the multicast group that the user's host joins as a receiver. This subattribute can appear multiple times in a multicast packet to indicate that the user belongs to multiple multicast groups. |
101 |
MLD-Access-Limit |
Maximum number of MLD multicast groups that the user can join concurrently. |
102 |
local-name |
L2TP local tunnel name. |
103 |
IGMP-Access-Limit |
Maximum number of IGMP multicast groups that the user can join concurrently. |
104 |
VPN-Instance |
MPLS L3VPN instance to which a user belongs. |
105 |
ANCP-Profile |
ANCP profile name. |
135 |
Client-Primary-DNS |
IP address of the primary DNS server. |
136 |
Client-Secondary-DNS |
IP address of the secondary DNS server. |
140 |
User_Group |
User groups assigned after the SSL VPN user passes authentication. A user can belong to multiple user groups that are separated by semicolons. This attribute is used to work with the SSL VPN device. |
144 |
Acct_IPv6_Input_Octets |
Bytes of IPv6 packets in the inbound direction. The measurement unit depends on the configuration on the device. |
145 |
Acct_IPv6_Output_Octets |
Bytes of IPv6 packets in the outbound direction. The measurement unit depends on the configuration on the device. |
146 |
Acct_IPv6_Input_Packets |
Number of IPv6 packets in the inbound direction. The measurement unit depends on the configuration on the device. |
147 |
Acct_IPv6_Output_Packets |
Number of IPv6 packets in the outbound direction. The measurement unit depends on the configuration on the device. |
148 |
Acct_IPv6_Input_Gigawords |
Bytes of IPv6 packets in the inbound direction. The measurement unit is 4G bytes. |
149 |
Acct_IPv6_Output_Gigawords |
Bytes of IPv6 packets in the outbound direction. The measurement unit is 4G bytes. |
210 |
Av-Pair |
Vendor-specific attribute pair. Available attribute pairs include: · Dynamically assigned WEP key in the format of leap:session-key=xxx. · Server-assigned voice VLAN in the format of device-traffic-class=voice. · Server-assigned user role in the format of shell:role=xxx. · Server-assigned ACL in the format of url-redirect-acl=xxx. · Server-assigned Web redirect URL in the format of url-redirect=xxx. |
215 |
Accounting-Level |
ITA traffic level in the range of 1 to 8. |
216 |
Ita-Policy |
ITA policy name. |
230 |
Nas-Port |
Interface through which the user is connected to the NAS. |
246 |
Auth_Detail_Result |
Accounting details. The server sends Access-Accept packets with subattributes 246 and 250 in the following situations: · 1—The subscriber charge is overdue. The subscriber is allowed to access network resources in the whitelist. If the subscriber accesses other network resources, the device redirects it to the URL specified by subattribute 250. · 2—The broadband lease of the subscriber expires. The device redirects the subscriber to the URL specified by subattribute 250 when the subscriber requests to access webpages for the first time. |
247 |
Input-Committed-Burst-Size |
Committed burst size from the user to the NAS, in bits. The total length cannot exceed 4 bytes for this field. This subattribute must be assigned together with the Input-Average-Rate attribute. |
248 |
Output-Committed-Burst-Size |
Committed burst size from the NAS to the user, in bits. The total length cannot exceed 4 bytes for this field. This subattribute must be assigned together with the Output-Average-Rate attribute. |
249 |
authentication-type |
Authentication type. The value can be: · 1—Intranet access authentication. · 2—Internet access authentication. If the packet does not contain this subattribute, common authentication applies. |
250 |
WEB-URL |
Redirect URL for users. |
251 |
Subscriber-ID |
Family plan ID. |
252 |
Subscriber-Profile |
QoS policy name for the family plan of the subscriber. |
255 |
Product_ID |
Product name. |
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
AAA configuration considerations and task list
To configure AAA, complete the following tasks on the NAS:
1. Configure the required AAA schemes:
? Local authentication—Configure local users and the related attributes, including the usernames and passwords, for the users to be authenticated.
? Remote authentication—Configure the required RADIUS and HWTACACS schemes.
2. Configure AAA methods for the users' ISP domains. Remote AAA methods need to use the configured RADIUS and HWTACACS schemes.
Figure 9 AAA configuration procedure
To configure AAA, perform the following tasks:
Tasks at a glance |
(Required.) Perform a minimum one of the following tasks to configure local users or AAA schemes: |
(Required.) Configure AAA methods for ISP domains: 1. (Required.) Creating an ISP domain 2. (Optional.) Configuring ISP domain attributes 3. (Required.) Perform a minimum one of the following tasks to configure AAA authentication, authorization, and accounting methods for the ISP domain: ? Configuring authentication methods for an ISP domain |
(Optional.) Configuring the RADIUS session-control feature |
(Optional.) Configuring the RADIUS DAS feature |
(Optional.) Changing the DSCP priority for RADIUS packets |
(Optional.) Configuring the RADIUS attribute translation feature |
(Optional.) Setting the maximum number of concurrent login users |
(Optional.) Configuring a NAS-ID profile |
(Optional.) Configuring the device ID |
Configuring AAA schemes
This section includes information on configuring local users, RADIUS schemes, and HWTACACS schemes.
Configuring local users
To implement local authentication, authorization, and accounting, create local users and configure user attributes on the device. The local users and attributes are stored in the local user database on the device. A local user is uniquely identified by the combination of a username and a user type.
The following shows the configurable local user attributes:
· Service type—Services that the user can use. Local authentication checks the service types of a local user. If none of the service types is available, the user cannot pass authentication.
Service types include FTP, HTTP, HTTPS, SSH, Telnet, and terminal.
· User state—Whether or not a local user can request network services. There are two user states: active and blocked. A user in active state can request network services, but a user in blocked state cannot.
· Upper limit of concurrent logins using the same user name—Maximum number of users that can concurrently access the device by using the same user name. When the number reaches the upper limit, no more local users can access the device by using the user name.
· User group—Each local user belongs to a local user group and has all attributes of the group. The attributes include the password control attributes and authorization attributes. For more information about local user group, see "Configuring user group attributes."
· Authorization attributes—Authorization attributes indicate the user's rights after it passes local authentication. For support information about authorization attributes, see "Configuring local user attributes."
Configure the authorization attributes based on the service type of local users.
You can configure an authorization attribute in user group view or local user view. The setting of an authorization attribute in local user view takes precedence over the attribute setting in user group view.
? The attribute configured in user group view takes effect on all local users in the user group.
? The attribute configured in local user view takes effect only on the local user.
· Password control attributes—Password control attributes help control password security for device management users. Password control attributes include password aging time, minimum password length, password composition checking, password complexity checking, and login attempt limit.
You can configure a password control attribute in system view, user group view, or local user view. A password control attribute with a smaller effective range has a higher priority. For more information about password management and global password configuration, see "Configuring password control."
Local user configuration task list
Tasks at a glance |
(Required.) Configuring local user attributes |
(Optional.) Configuring user group attributes |
Configuring local user attributes
When you configure local user attributes, follow these guidelines:
· When you use the password-control enable command to globally enable the password control feature, local user passwords are not displayed.
· You can configure authorization attributes and password control attributes in local user view or user group view. The setting in local user view takes precedence over the setting in user group view.
To configure local user attributes:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Add a local user and enter local user view. |
local-user user-name [ class manage ] |
By default, no local users exist. |
3. (Optional.) Configure a password for the local user. |
·
In non-FIPS mode: ·
In FIPS mode: |
The default settings are as follows: · In non-FIPS mode, no password is configured for a local user. A local user can pass authentication after entering the correct username and passing attribute checks. · In FIPS mode, no password is configured for a local user. A local user cannot pass authentication. |
4. Assign services to the local user. |
·
In non-FIPS mode: ·
In FIPS mode: |
By default, no services are authorized to a local user. |
5. (Optional.) Place the local user to the active or blocked state. |
state { active | block } |
By default, a local user is in active state and can request network services. |
6. (Optional.) Set the upper limit of concurrent logins using the local user name. |
access-limit max-user-number |
By default, the number of concurrent logins is not limited for the local user. This command takes effect only when local accounting is configured for the local user. It does not apply to FTP, SFTP, or SCP users. These users do not support accounting. |
7. (Optional.) Configure authorization attributes for the local user. |
authorization-attribute { idle-cut minutes | user-role role-name | work-directory directory-name } * |
The following default settings apply: · The working directory for FTP, SFTP, and SCP users is the root directory of the NAS. However, the users do not have permission to access the root directory. · The network-operator user role is assigned to local users that are created by a network-admin or level-15 user. |
8. (Optional.) Configure password control attributes for the local user. |
·
Set the password aging time: ·
Set the minimum password length: ·
Configure the password composition policy: ·
Configure the password complexity
checking policy: ·
Configure the maximum login attempts
and the action to take if there is a login failure: |
By default, the local user uses password control attributes of the user group to which the local user belongs. |
9. (Optional.) Assign the local user to a user group. |
group group-name |
By default, a local user belongs to the user group system. |
Configuring user group attributes
User groups simplify local user configuration and management. A user group contains a group of local users and has a set of local user attributes. You can configure local user attributes for a user group to implement centralized user attributes management for the local users in the group. Local user attributes that are manageable include authorization attributes.
By default, every new local user belongs to the default user group system and has all attributes of the group. To assign a local user to a different user group, use the group command in local user view.
To configure user group attributes:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a user group and enter user group view. |
user-group group-name |
By default, a system-defined user group exists. The group name is system. |
3. Configure authorization attributes for the user group. |
authorization-attribute { idle-cut minutes | work-directory directory-name } * |
By default, no authorization attributes are configured for a user group. |
4. (Optional.) Configure password control attributes for the user group. |
·
Set the password aging time: ·
Set the minimum password length: ·
Configure the password composition policy: ·
Configure the password complexity
checking policy: ·
Configure the maximum login attempts
and the action to take for login failures: |
By default, the user group uses the global password control settings. For more information, see "Configuring password control." |
Displaying and maintaining local users and local user groups
Execute display commands in any view.
Task |
Command |
Display the local user configuration and online user statistics. |
display local-user [ class manage | idle-cut { disable | enable } | service-type { ftp | http | https | ssh | telnet | terminal } | state { active | block } | user-name user-name class manage | vlan vlan-id ] |
Display the user group configuration. |
display user-group { all | name group-name } |
Configuring RADIUS schemes
A RADIUS scheme specifies the RADIUS servers that the device can work with and defines a set of parameters. The device uses the parameters to exchange information with the RADIUS servers, including the server IP addresses, UDP port numbers, shared keys, and server types.
Configuration task list
Configuring a test profile for RADIUS server status detection
Use a test profile to detect whether a RADIUS authentication server is reachable at a detection interval. To detect the RADIUS server status, you must configure the RADIUS server to use this test profile in a RADIUS scheme.
With the test profile specified, the device sends a detection packet to the RADIUS server within each detection interval. The detection packet is a simulated authentication request that includes the specified user name in the test profile.
· If the device receives a response from the server within the interval, it sets the server to the active state.
· If the device does not receive any response from the server within the interval, it sets the server to the blocked state.
The device refreshes the RADIUS server status at each detection interval according to the detection result.
The device stops detecting the status of the RADIUS server when one of the following operations is performed:
· The RADIUS server is removed from the RADIUS scheme.
· The test profile configuration is removed for the RADIUS server in RADIUS scheme view.
· The test profile is deleted.
· The RADIUS server is manually set to the blocked state.
· The RADIUS scheme is deleted.
To configure a test profile for RADIUS server status detection:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure a test profile for detecting the status of RADIUS authentication servers. |
radius-server test-profile profile-name username name [ interval interval ] |
By default, no test profiles exist. You can configure multiple test profiles in the system. |
Creating a RADIUS scheme
Create a RADIUS scheme before performing any other RADIUS configurations. You can configure a maximum of 16 RADIUS schemes. A RADIUS scheme can be used by multiple ISP domains.
To create a RADIUS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a RADIUS scheme and enter RADIUS scheme view. |
radius scheme radius-scheme-name |
By default, no RADIUS schemes exist. |
Specifying the RADIUS authentication servers
A RADIUS authentication server completes authentication and authorization together, because authorization information is piggybacked in authentication responses sent to RADIUS clients.
You can specify one primary authentication server and a maximum of 16 secondary authentication servers for a RADIUS scheme. Secondary servers provide AAA services when the primary server becomes unavailable. The device searches for an active server in the order the secondary servers are configured.
If redundancy is not required, specify only the primary server. A RADIUS authentication server can function as the primary authentication server for one scheme and a secondary authentication server for another scheme at the same time.
When RADIUS server load sharing is enabled, the device distributes the workload over all servers without considering the primary and secondary server roles. The device checks the weight value and number of currently served users for each active server, and then determines the most appropriate server in performance to receive an authentication request.
To specify RADIUS authentication servers for a RADIUS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Specify RADIUS authentication servers. |
·
Specify the primary RADIUS authentication
server: ·
Specify a secondary RADIUS authentication
server: |
By default, no authentication servers are specified. To support server status detection, specify an existing test profile for the RADIUS authentication server. If the test profile does not exist, the device cannot detect the server status. Two authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. The weight keyword takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme. |
Specifying the RADIUS accounting servers and the relevant parameters
You can specify one primary accounting server and a maximum of 16 secondary accounting servers for a RADIUS scheme. Secondary servers provide AAA services when the primary server becomes unavailable. The device searches for an active server in the order the secondary servers are configured.
If redundancy is not required, specify only the primary server. A RADIUS accounting server can function as the primary accounting server for one scheme and a secondary accounting server for another scheme at the same time.
When RADIUS server load sharing is enabled, the device distributes the workload over all servers without considering the primary and secondary server roles. The device checks the weight value and number of currently served users for each active server, and then determines the most appropriate server in performance to receive an accounting request.
The device sends a stop-accounting request to the accounting server in the following situations:
· The device receives a connection teardown request from a host.
· The device receives a connection teardown command from an administrator.
When the maximum number of real-time accounting attempts is reached, the device disconnects users that have no accounting responses.
RADIUS does not support accounting for FTP, SFTP, and SCP users.
To specify RADIUS accounting servers and the relevant parameters for a RADIUS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Specify RADIUS accounting servers. |
·
Specify the primary RADIUS accounting server: ·
Specify a secondary RADIUS accounting server: |
By default, no accounting servers are specified. Two accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. The weight keyword takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme. |
4. (Optional.) Set the maximum number of real-time accounting attempts. |
retry realtime-accounting retries |
The default setting is 5. |
Specifying the shared keys for secure RADIUS communication
The RADIUS client and server use the MD5 algorithm and shared keys to generate the Authenticator value for packet authentication and user password encryption. The client and server must use the same key for each type of communication.
A key configured in this task is for all servers of the same type (accounting or authentication) in the scheme. The key has a lower priority than a key configured individually for a RADIUS server.
To specify a shared key for secure RADIUS communication:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Specify a shared key for secure RADIUS communication. |
key { accounting | authentication } { cipher | simple } string |
By default, no shared key is specified for secure RADIUS communication. The shared key configured on the device must be the same as the shared key configured on the RADIUS server. |
Specifying an MPLS L3VPN instance for the scheme
The VPN instance specified for a RADIUS scheme applies to all authentication and accounting servers in that scheme. If a VPN instance is also configured for an individual RADIUS server, the VPN instance specified for the RADIUS scheme does not take effect on that server.
To specify a VPN instance for a scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Specify a VPN instance for the RADIUS scheme. |
vpn-instance vpn-instance-name |
By default, a RADIUS scheme belongs to the public network. |
Setting the username format and traffic statistics units
A username is in the userid@isp-name format, where the isp-name argument represents the user's ISP domain name. By default, the ISP domain name is included in a username. However, older RADIUS servers might not recognize usernames that contain the ISP domain names. In this case, you can configure the device to remove the domain name of each username to be sent.
If two or more ISP domains use the same RADIUS scheme, configure the RADIUS scheme to keep the ISP domain name in usernames for domain identification.
The device reports online user traffic statistics in accounting packets. The traffic measurement units are configurable, but they must be the same as the traffic measurement units configured on the RADIUS accounting servers.
To set the username format and the traffic statistics units for a RADIUS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Set the format for usernames sent to the RADIUS servers. |
user-name-format { keep-original | with-domain | without-domain } |
By default, the ISP domain name is included in a username. |
4. (Optional.) Set the data flow and packet measurement units for traffic statistics. |
data-flow-format { data { byte | giga-byte | kilo-byte | mega-byte } | packet { giga-packet | kilo-packet | mega-packet | one-packet } } * |
By default, traffic is counted in bytes and packets. |
Setting the maximum number of RADIUS request transmission attempts
RADIUS uses UDP packets to transfer data. Because UDP communication is not reliable, RADIUS uses a retransmission mechanism to improve reliability. A RADIUS request is retransmitted if the NAS does not receive a server response for the request within the response timeout timer. For more information about the RADIUS server response timeout timer, see "Setting RADIUS timers."
You can set the maximum number for the NAS to retransmit a RADIUS request to the same server. When the maximum number is reached, the NAS tries to communicate with other RADIUS servers in active state. If no other servers are in active state at the time, the NAS considers the authentication or accounting attempt a failure.
To set the maximum number of RADIUS request transmission attempts:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Set the maximum number of RADIUS request transmission attempts. |
retry retries |
The default setting is 3. |
Setting the status of RADIUS servers
To control the RADIUS servers with which the device communicates when the current servers are no longer available, set the status of RADIUS servers to blocked or active. You can specify one primary RADIUS server and multiple secondary RADIUS servers. The secondary servers function as the backup of the primary server. When the RADIUS server load sharing feature is disabled, the device chooses servers based on the following rules:
· When the primary server is in active state, the device communicates with the primary server.
· If the primary server fails, the device performs the following operations:
? Changes the server status to blocked.
? Starts a quiet timer for the server.
? Tries to communicate with a secondary server in active state that has the highest priority.
· If the secondary server is unreachable, the device performs the following operations:
? Changes the server status to blocked.
? Starts a quiet timer for the server.
? Tries to communicate with the next secondary server in active state that has the highest priority.
· The search process continues until the device finds an available secondary server or has checked all secondary servers in active state. If no server is available, the device considers the authentication or accounting attempt a failure.
· When the quiet timer of a server expires or you manually set the server to the active state, the status of the server changes back to active. The device does not check the server again during the authentication or accounting process.
· When you remove a server in use, communication with the server times out. The device looks for a server in active state by first checking the primary server, and then checking secondary servers in the order they are configured.
· When all servers are in blocked state, the device only tries to communicate with the primary server.
· When one or more servers are in active state, the device tries to communicate with these active servers only, even if the servers are unavailable.
· When a RADIUS server's status changes automatically, the device changes this server's status accordingly in all RADIUS schemes in which this server is specified.
· When a RADIUS server is manually set to blocked, server detection is disabled for the server, regardless of whether a test profile has been specified for the server. When the RADIUS server is set to active state, server detection is enabled for the server on which an existing test profile is specified.
By default, the device sets the status of all RADIUS servers to active. However, in some situations, you must change the status of a server. For example, if a server fails, you can change the status of the server to blocked to avoid communication attempts to the server.
When RADIUS server load sharing is enabled, the device distributes the workload over all servers without considering the primary and secondary server roles. The device checks the weight value and number of currently served users for each active server, and then determines the most appropriate server in performance to receive an AAA request.
In RADIUS server load sharing, once the device sends a start-accounting request to a server for a user, it forwards all subsequent accounting requests of the user to the same server. If the accounting server is unreachable, the device returns an accounting failure message rather than searching for another active accounting server.
To set the status of RADIUS servers:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Set the RADIUS server status. |
·
Set the status of the primary RADIUS
authentication server: ·
Set the status of the primary RADIUS
accounting server: ·
Set the status of a secondary RADIUS
authentication server: ·
Set the status of a secondary RADIUS
accounting server: |
By default, a RADIUS server is in active state. The configured server status cannot be saved to any configuration file, and can only be viewed by using the display radius scheme command. After the device restarts, all servers are restored to the active state. |
Enabling the RADIUS server load sharing feature
By default, the device communicates with RADIUS servers based on the server roles. It first attempts to communicate with the primary server, and, if the primary server is unavailable, it then searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication. In this process, the workload is always placed on the active server.
Use the RADIUS server load sharing feature to dynamically distribute the workload over multiple servers regardless of their server roles. The device forwards an AAA request to the most appropriate server of all active servers in the scheme after it compares the weight values and numbers of currently served users. Specify a weight value for each RADIUS server based on the AAA capacity of the server. A larger weight value indicates a higher AAA capacity.
In RADIUS server load sharing, once the device sends a start-accounting request to a server for a user, it forwards all subsequent accounting requests of the user to the same server. If the accounting server is unreachable, the device returns an accounting failure message rather than searching for another active accounting server.
To enable the RADIUS server load sharing feature:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Enable the RADIUS server load sharing feature. |
server-load-sharing enable |
By default, this feature is disabled. |
Specifying the source IP address for outgoing RADIUS packets
The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon receiving a RADIUS packet, a RADIUS server checks whether the source IP address of the packet is the IP address of a managed NAS.
· If it is the IP address of a managed NAS, the server processes the packet.
· If it is not the IP address of a managed NAS, the server drops the packet.
The source address of outgoing RADIUS packets is typically the IP address of an egress interface on the NAS to communicate with the RADIUS server. However, in some situations, you must change the source IP address. For example, when VRRP is configured for stateful failover, configure the virtual IP of the uplink VRRP group as the source address.
You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view or in system view.
· The IP address specified in RADIUS scheme view applies only to one RADIUS scheme.
· The IP address specified in system view applies to all RADIUS schemes in which the RADIUS servers are in a VPN or the public network.
Before sending a RADIUS packet, the NAS selects a source IP address in the following order:
1. The source IP address specified for the RADIUS scheme.
2. The source IP address specified in system view for the VPN or public network, depending on where the RADIUS server resides.
3. The IP address of the outbound interface specified by the route.
To specify a source IP address for all RADIUS schemes in a VPN or the public network:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Specify a source IP address for outgoing RADIUS packets. |
radius nas-ip { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] |
By default, the primary IP address of the RADIUS packet outbound interface is used as the source IP address. |
To specify a source IP address for a RADIUS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Specify a source IP address for outgoing RADIUS packets. |
nas-ip { ipv4-address | ipv6 ipv6-address } |
By default, the source IP address specified by the radius nas-ip command in system view is used. If the source IP address is not specified, the primary IP address of the outbound interface is used. |
Setting RADIUS timers
The device uses the following types of timers to control communication with a RADIUS server:
· Server response timeout timer (response-timeout)—Defines the RADIUS request retransmission interval. The timer starts immediately after a RADIUS request is sent. If the device does not receive a response from the RADIUS server before the timer expires, it resends the request.
· Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If one server is not reachable, the device changes the server status to blocked, starts this timer for the server, and tries to communicate with another server in active state. After the server quiet timer expires, the device changes the status of the server back to active.
· Real-time accounting timer (realtime-accounting)—Defines the interval at which the device sends real-time accounting packets to the RADIUS accounting server for online users.
When you set RADIUS timers, follow these guidelines:
· Consider the number of secondary servers when you configure the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout timer. If the RADIUS scheme includes many secondary servers, the retransmission process might be too long and the client connection in the access module, such as Telnet, can time out.
· When the client connections have a short timeout period, a large number of secondary servers can cause the initial authentication or accounting attempt to fail. In this case, reconnect the client rather than adjusting the RADIUS packet transmission attempts and server response timeout timer. Typically, the next attempt will succeed, because the device has blocked the unreachable servers to shorten the time to find a reachable server.
· Make sure the server quiet timer is set correctly. A timer that is too short might result in frequent authentication or accounting failures. This is because the device will continue to attempt to communicate with an unreachable server that is in active state. A timer that is too long might temporarily block a reachable server that has recovered from a failure. This is because the server will remain in blocked state until the timer expires.
· A short real-time accounting interval helps improve accounting precision but requires many system resources. When there are 1000 or more users, set the interval to 15 minutes or longer.
To set RADIUS timers:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Set the RADIUS server response timeout timer. |
timer response-timeout seconds |
The default setting is 3 seconds. |
4. Set the quiet timer for the servers. |
timer quiet minutes |
The default setting is 5 minutes. |
5. Set the real-time accounting timer. |
timer realtime-accounting interval [ second ] |
The default setting is 12 minutes. |
Configuring the RADIUS accounting-on feature
When the accounting-on feature is enabled, the device automatically sends an accounting-on packet to the RADIUS server after the entire device reboots. Upon receiving the accounting-on packet, the RADIUS server logs out all online users so they can log in again through the device. Without this feature, users cannot log in again after the reboot, because the RADIUS server considers them to come online.
You can configure the interval for which the device waits to resend the accounting-on packet and the maximum number of retries.
The extended accounting-on feature enhances the accounting-on feature in a distributed architecture. For the extended accounting-on feature to take effect, the RADIUS server must run on IMC and the accounting-on feature must be enabled.
To configure the accounting-on feature for a RADIUS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Enable accounting-on. |
accounting-on enable [ interval interval | send send-times ] * |
By default, the accounting-on feature is disabled. |
4. (Optional.) Enable extended accounting-on. |
accounting-on extended |
By default, extended accounting-on is disabled. |
Interpreting the RADIUS class attribute as CAR parameters
A RADIUS server may deliver CAR parameters for user-based traffic monitoring and control by using the RADIUS class attribute (attribute 25) in RADIUS packets. You can configure the device to interpret the class attribute to CAR parameters.
To configure the device to interpret the RADIUS class attribute as CAR parameters:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Interpret the RADIUS class attribute as CAR parameters. |
attribute 25 car |
By default, the RADIUS class attribute is not interpreted as CAR parameters. |
Configuring the Login-Service attribute check method for SSH, FTP, and terminal users
· Strict—Matches Login-Service attribute values 50, 51, and 52 for SSH, FTP, and terminal services, respectively.
· Loose—Matches the standard Login-Service attribute value 0 for SSH, FTP, and terminal services.
An Access-Accept packet received for a user must contain the matching attribute value. Otherwise, the user cannot log in to the device.
Use the loose check method only when the server does not issue Login-Service attribute values 50, 51, and 52 for SSH, FTP, and terminal users.
To configure the Login-Service attribute check method for SSH, FTP, and terminal users:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Configure the Login-Service attribute check method for SSH, FTP, and terminal users. |
attribute 15 check-mode { loose | strict } |
The default check method is strict. |
Configuring the MAC address format for RADIUS attribute 31
RADIUS servers of different types might have different requirements for the MAC address format in RADIUS attribute 31. Configure the MAC address format for RADIUS attribute 31 to meet the requirements of the RADIUS servers.
To configure the MAC address format for RADIUS attribute 31:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Configure the MAC address format for RADIUS attribute 31. |
attribute 31 mac-format section { six | three } separator separator-character { lowercase | uppercase } |
By default, a MAC address is in the format of HH-HH-HH-HH-HH-HH. The MAC address is separated by hyphen (-) into six sections with letters in upper case. |
Setting the data measurement unit for the Remanent_Volume attribute
The Remanent_Volume attribute is H3C proprietary. The RADIUS server uses this attribute in authentication or real-time accounting responses to notify the device of the current amount of data available for online users.
Perform this task to set the data measurement unit for the Remanent_Volume attribute. Make sure the configured measurement unit is the same as the user data measurement unit on the RADIUS server.
To set the data measurement unit for the Remanent_Volume attribute:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
3. Set the data measurement unit for the Remanent_Volume attribute. |
attribute remanent-volume unit { byte | giga-byte | kilo-byte | mega-byte } |
By default, the data measurement unit is kilobyte. |
Enabling SNMP notifications for RADIUS
When SNMP notifications are enabled for RADIUS, the SNMP agent supports the following notifications generated by RADIUS:
· RADIUS server unreachable notification—The RADIUS server cannot be reached. RADIUS generates this notification if it does not receive a response to an accounting or authentication request within the specified number of RADIUS request transmission attempts.
· RADIUS server reachable notification—The RADIUS server can be reached. RADIUS generates this notification for a previously blocked RADIUS server after the quiet timer expires.
· Excessive authentication failures notification—The number of authentication failures compared to the total number of authentication attempts exceeds the specified threshold.
For RADIUS SNMP notifications to be sent correctly, you must also configure SNMP on the device. For more information about SNMP configuration, see the network management and monitoring configuration guide for the device.
To enable SNMP notifications for RADIUS:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable SNMP notifications for RADIUS. |
snmp-agent trap enable radius [ accounting-server-down | accounting-server-up | authentication-error-threshold | authentication-server-down | authentication-server-up ] * |
By default, all SNMP notifications are disabled for RADIUS. |
Displaying and maintaining RADIUS
Execute display commands in any view and reset commands in user view.
Task |
Command |
Display the RADIUS scheme configuration. |
display radius scheme [ radius-scheme-name ] |
Display RADIUS packet statistics. |
display radius statistics |
Clear RADIUS statistics. |
reset radius statistics |
Configuring HWTACACS schemes
Configuration task list
Tasks at a glance |
(Required.) Creating an HWTACACS scheme |
(Required.) Specifying the HWTACACS authentication servers |
(Optional.) Specifying the HWTACACS authorization servers |
(Optional.) Specifying the HWTACACS accounting servers |
(Required.) Specifying the shared keys for secure HWTACACS communication |
(Optional.) Specifying an MPLS L3VPN instance for the scheme |
(Optional.) Setting the username format and traffic statistics units |
(Optional.) Specifying the source IP address for outgoing HWTACACS packets |
(Optional.) Setting HWTACACS timers |
Creating an HWTACACS scheme
Create an HWTACACS scheme before performing any other HWTACACS configurations. You can configure a maximum of 16 HWTACACS schemes. An HWTACACS scheme can be used by multiple ISP domains.
To create an HWTACACS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create an HWTACACS scheme and enter HWTACACS scheme view. |
hwtacacs scheme hwtacacs-scheme-name |
By default, no HWTACACS schemes exist. |
Specifying the HWTACACS authentication servers
You can specify one primary authentication server and a maximum of 16 secondary authentication servers for an HWTACACS scheme. When the primary server is not available, the device searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.
If redundancy is not required, specify only the primary server. An HWTACACS server can function as the primary authentication server in one scheme and as the secondary authentication server in another scheme at the same time.
To specify HWTACACS authentication servers for an HWTACACS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter HWTACACS scheme view. |
hwtacacs scheme hwtacacs-scheme-name |
N/A |
3. Specify HWTACACS authentication servers. |
·
Specify the primary HWTACACS authentication
server: ·
Specify a secondary HWTACACS authentication
server: |
By default, no authentication servers are specified. Two HWTACACS authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. |
Specifying the HWTACACS authorization servers
You can specify one primary authorization server and a maximum of 16 secondary authorization servers for an HWTACACS scheme. When the primary server is not available, the device searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.
If redundancy is not required, specify only the primary server. An HWTACACS server can function as the primary authorization server of one scheme and as the secondary authorization server of another scheme at the same time.
To specify HWTACACS authorization servers for an HWTACACS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter HWTACACS scheme view. |
hwtacacs scheme hwtacacs-scheme-name |
N/A |
3. Specify HWTACACS authorization servers. |
·
Specify the primary HWTACACS authorization
server: ·
Specify a secondary HWTACACS authorization
server: |
By default, no authorization servers are specified. Two HWTACACS authorization servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. |
Specifying the HWTACACS accounting servers
You can specify one primary accounting server and a maximum of 16 secondary accounting servers for an HWTACACS scheme. When the primary server is not available, the device searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.
If redundancy is not required, specify only the primary server. An HWTACACS server can function as the primary accounting server of one scheme and as the secondary accounting server of another scheme at the same time.
HWTACACS does not support accounting for FTP, SFTP, and SCP users.
To specify HWTACACS accounting servers for an HWTACACS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter HWTACACS scheme view. |
hwtacacs scheme hwtacacs-scheme-name |
N/A |
3. Specify HWTACACS accounting servers. |
·
Specify the primary HWTACACS accounting
server: ·
Specify a secondary HWTACACS accounting
server: |
By default, no accounting servers are specified. Two HWTACACS accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. |
Specifying the shared keys for secure HWTACACS communication
The HWTACACS client and server use the MD5 algorithm and shared keys to generate the Authenticator value for packet authentication and user password encryption. The client and server must use the same key for each type of communication.
Perform this task to configure shared keys for servers in an HWTACACS scheme. The keys take effect on all servers for which a shared key is not individually configured.
To specify a shared key for secure HWTACACS communication:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter HWTACACS scheme view. |
hwtacacs scheme hwtacacs-scheme-name |
N/A |
3. Specify a shared key for secure HWTACACS authentication, authorization, or accounting communication. |
key { accounting | authentication | authorization } { cipher | simple } string |
By default, no shared key is specified for secure HWTACACS communication. The shared key configured on the device must be the same as the shared key configured on the HWTACACS server. |
Specifying an MPLS L3VPN instance for the scheme
The VPN instance specified for an HWTACACS scheme applies to all servers in that scheme. If a VPN instance is also configured for an individual HWTACACS server, the VPN instance specified for the HWTACACS scheme does not take effect on that server.
To specify a VPN instance for an HWTACACS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter HWTACACS scheme view. |
hwtacacs scheme hwtacacs-scheme-name |
N/A |
3. Specify a VPN instance for the HWTACACS scheme. |
vpn-instance vpn-instance-name |
By default, an HWTACACS scheme belongs to the public network. |
Setting the username format and traffic statistics units
A username is typically in the userid@isp-name format, where the isp-name argument represents the user's ISP domain name. By default, the ISP domain name is included in a username. If HWTACACS servers do not recognize usernames that contain ISP domain names, you can configure the device to send usernames without domain names to the servers.
If two or more ISP domains use the same HWTACACS scheme, configure the HWTACACS scheme to keep the ISP domain name in usernames for domain identification.
The device reports online user traffic statistics in accounting packets. The traffic measurement units are configurable, but they must be the same as the traffic measurement units configured on the HWTACACS accounting servers.
To set the username format and traffic statistics units for an HWTACACS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter HWTACACS scheme view. |
hwtacacs scheme hwtacacs-scheme-name |
N/A |
3. Set the format of usernames sent to the HWTACACS servers. |
user-name-format { keep-original | with-domain | without-domain } |
By default, the ISP domain name is included in a username. |
4. (Optional.) Set the data flow and packet measurement units for traffic statistics. |
data-flow-format { data { byte | giga-byte | kilo-byte | mega-byte } | packet { giga-packet | kilo-packet | mega-packet | one-packet } } * |
By default, traffic is counted in bytes and packets. |
Specifying the source IP address for outgoing HWTACACS packets
The source IP address of HWTACACS packets that a NAS sends must match the IP address of the NAS configured on the HWTACACS server. An HWTACACS server identifies a NAS by IP address. When the HWTACACS server receives a packet, it checks whether the source IP address of the packet is the IP address of a managed NAS.
· If it is the IP address of a managed NAS, the server processes the packet.
· If it is not the IP address of a managed NAS, the server drops the packet.
To communicate with the HWTACACS server, the source address of outgoing HWTACACS packets is typically the IP address of an egress interface on the NAS. However, in some situations, you must change the source IP address. For example, when VRRP is configured for stateful failover, configure the virtual IP of the uplink VRRP group as the source address.
You can specify the source IP address for outgoing HWTACACS packets in HWTACACS scheme view or in system view.
· The IP address specified in HWTACACS scheme view applies to one HWTACACS scheme.
· The IP address specified in system view applies to all HWTACACS schemes in which the HWTACACS servers are in a VPN or the public network.
Before sending an HWTACACS packet, the NAS selects a source IP address in the following order:
1. The source IP address specified for the HWTACACS scheme.
2. The source IP address specified in system view for the VPN or public network, depending on where the HWTACACS server resides.
3. The IP address of the outbound interface specified by the route.
To specify a source IP address for all HWTACACS schemes of a VPN or the public network:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Specify a source IP address for outgoing HWTACACS packets. |
hwtacacs nas-ip { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] |
By default, the primary IP address of the HWTACACS packet outbound interface is used as the source IP address. |
To specify a source IP address for an HWTACACS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter HWTACACS scheme view. |
hwtacacs scheme hwtacacs-scheme-name |
N/A |
3. Specify the source IP address of outgoing HWTACACS packets. |
nas-ip { ipv4-address | ipv6 ipv6-address } |
By default, the source IP address specified by the hwtacacs nas-ip command in system view is used. If the source IP address is not specified, the primary IP address of the outbound interface is used. |
Setting HWTACACS timers
The device uses the following timers to control communication with an HWTACACS server:
· Server response timeout timer (response-timeout)—Defines the HWTACACS server response timeout timer. The device starts this timer immediately after an HWTACACS authentication, authorization, or accounting request is sent. If the device does not receive a response from the server within the timer, it sets the server to blocked. Then, the device sends the request to another HWTACACS server.
· Real-time accounting timer (realtime-accounting)—Defines the interval at which the device sends real-time accounting packets to the HWTACACS accounting server for online users.
· Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If a server is not reachable, the device changes the server status to blocked, starts this timer for the server, and tries to communicate with another server in active state. After the server quiet timer expires, the device changes the status of the server back to active.
The server quiet timer setting affects the status of HWTACACS servers. If the scheme includes one primary HWTACACS server and multiple secondary HWTACACS servers, the device communicates with the HWTACACS servers based on the following rules:
· When the primary server is in active state, the device communicates with the primary server.
· If the primary server fails, the device performs the following operations:
? Changes the server status to blocked.
? Starts a quiet timer for the server.
? Tries to communicate with a secondary server in active state that has the highest priority.
· If the secondary server is unreachable, the device performs the following operations:
? Changes the server status to blocked.
? Starts a quiet timer for the server.
? Tries to communicate with the next secondary server in active state that has the highest priority.
· The search process continues until the device finds an available secondary server or has checked all secondary servers in active state. If no server is available, the device considers the authentication, authorization, or accounting attempt a failure.
· When the quiet timer of a server expires, the status of the server changes back to active. The device does not check the server again during the authentication, authorization, or accounting process.
· When you remove a server in use, communication with the server times out. The device looks for a server in active state by first checking the primary server, and then checking secondary servers in the order they are configured.
· When all servers are in blocked state, the device only tries to communicate with the primary server.
· When one or more servers are in active state, the device tries to communicate with these servers only, even if they are unavailable.
· When an HWTACACS server's status changes automatically, the device changes this server's status accordingly in all HWTACACS schemes in which this server is specified.
To set HWTACACS timers:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter HWTACACS scheme view. |
hwtacacs scheme hwtacacs-scheme-name |
N/A |
3. Set the HWTACACS server response timeout timer. |
timer response-timeout seconds |
By default, the HWTACACS server response timeout timer is 5 seconds. |
4. Set the real-time accounting interval. |
timer realtime-accounting minutes |
By default, the real-time accounting interval is 12 minutes. A short interval helps improve accounting precision but requires many system resources. When there are 1000 or more users, set a longer interval. |
5. Set the server quiet timer. |
timer quiet minutes |
By default, the server quiet timer is 5 minutes. |
Displaying and maintaining HWTACACS
Execute display commands in any view and reset commands in user view.
Task |
Command |
Display the configuration or server statistics of HWTACACS schemes. |
display hwtacacs scheme [ hwtacacs-scheme-name [ statistics ] ] |
Clear HWTACACS statistics. |
reset hwtacacs statistics { accounting | all | authentication | authorization } |
Configuring AAA methods for ISP domains
You configure AAA methods for an ISP domain by specifying configured AAA schemes in ISP domain view. Each ISP domain has a set of system-defined AAA methods, which are local authentication, local authorization, and local accounting. If you do not configure any AAA methods for an ISP domain, the device uses the system-defined AAA methods for users in the domain.
AAA is available to login users after you enable scheme authentication for the users. For more information about the login authentication modes, see Fundamentals Configuration Guide.
Configuration prerequisites
To use local authentication for users in an ISP domain, configure local user accounts on the device first. See "Configuring local user attributes."
To use remote authentication, authorization, and accounting, create the required RADIUS or HWTACACS schemes. For more information about the scheme configuration, see "Configuring RADIUS schemes" and "Configuring HWTACACS schemes."
Creating an ISP domain
In a networking scenario with multiple ISPs, the device can connect to users of different ISPs. These users can have different user attributes, such as different username and password structures, different service types, and different rights. To manage users of different ISPs, configure AAA methods and domain attributes for each ISP domain as needed.
The device supports a maximum of 16 ISP domains, including the system-defined ISP domain system. You can specify one of the ISP domains as the default domain.
On the device, each user belongs to an ISP domain. If a user does not provide an ISP domain name at login, the device considers the user belongs to the default ISP domain.
The device chooses an authentication domain for each user in the following order:
1. The authentication domain specified for the access module.
2. The ISP domain in the username.
3. The default ISP domain of the device.
If the chosen domain does not exist on the device, the device searches for the ISP domain that accommodates users assigned to nonexistent domains. If no such ISP domain is configured, user authentication fails.
When you configure an ISP domain, follow these restrictions and guidelines:
· An ISP domain cannot be deleted when it is the default ISP domain. Before you use the undo domain command, change the domain to a non-default ISP domain by using the undo domain default enable command.
· You can modify the settings of the system-defined ISP domain system, but you cannot delete the domain.
To create an ISP domain:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create an ISP domain and enter ISP domain view. |
domain isp-name |
By default, a system-defined ISP domain exists. The domain name is system. |
3. Return to system view. |
quit |
N/A |
4. (Optional.) Specify the default ISP domain. |
domain default enable isp-name |
By default, the default ISP domain is the system-defined ISP domain system. |
5. (Optional.) Specify the ISP domain to accommodate users that are assigned to nonexistent domains. |
domain if-unknown isp-name |
By default, no ISP domain is specified to accommodate users that are assigned to nonexistent domains. |
Configuring ISP domain attributes
In an ISP domain, you can configure the following attributes:
· Domain status—By placing the ISP domain in active or blocked state, you allow or deny network service requests from users in the domain.
· Authorization user group—The device assigns the authorization user group in the ISP domain to the authenticated users that do not receive the authorization attribute from the server. The authenticated users obtain all attributes of the user group.
· User online duration including idle timeout period—If a user goes offline due to connection failure or malfunction, the user's online duration sent to the server includes the idle timeout period. The online duration that is generated on the server is longer than the actual online duration of the user.
An ISP domain attribute applies to all users in the domain.
To configure ISP domain attributes:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter ISP domain view. |
domain isp-name |
N/A |
3. Place the ISP domain in active or blocked state. |
state { active | block } |
By default, an ISP domain is in active state, and users in the domain can request network services. |
4. Configure authorization attributes for authenticated users in the ISP domain. |
authorization-attribute user-group user-group-name |
By default, no authorization attributes exist. |
5. Configure the device to include the idle timeout period in the user online duration to be sent to the server. |
session-time include-idle-time |
By default, the user online duration sent to the server does not include the idle timeout period. |
Configuring authentication methods for an ISP domain
Configuration prerequisites
Before configuring authentication methods, complete the following tasks:
1. Determine the access type or service type to be configured. With AAA, you can configure an authentication method for each access type and service type.
2. Determine whether to configure the default authentication method for all access types or service types. The default authentication method applies to all access users. However, the method has a lower priority than the authentication method that is specified for an access type or service type.
Configuration guidelines
When configuring authentication methods, follow these guidelines:
· If the authentication method uses a RADIUS scheme and the authorization method does not use a RADIUS scheme, AAA accepts only the authentication result from the RADIUS server. The Access-Accept message from the RADIUS server also includes the authorization information, but the device ignores the information.
· If an HWTACACS scheme is specified, the device uses the entered username for role authentication. If a RADIUS scheme is specified, the device uses the username $enabn$ on the RADIUS server for role authentication. The variable n represents a user role level. For more information about user role authentication, see Fundamentals Configuration Guide.
Configuration procedure
To configure authentication methods for an ISP domain:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter ISP domain view. |
domain isp-name |
N/A |
3. Specify default authentication methods for all types of users. |
authentication default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } |
By default, the default authentication method is local. The none keyword is not supported in FIPS mode. |
4. Specify authentication methods for login users. |
authentication login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } |
By default, the default authentication methods are used for login users. The none keyword is not supported in FIPS mode. |
5. Specify authentication methods for obtaining a temporary user role. |
authentication super { hwtacacs-scheme hwtacacs-scheme-name | radius-scheme radius-scheme-name } * |
By default, the default authentication methods are used for obtaining a temporary user role. |
Configuring authorization methods for an ISP domain
Configuration prerequisites
Before configuring authorization methods, complete the following tasks:
1. Determine the access type or service type to be configured. With AAA, you can configure an authorization scheme for each access type and service type.
2. Determine whether to configure the default authorization method for all access types or service types. The default authorization method applies to all access users. However, the method has a lower priority than the authorization method that is specified for an access type or service type.
Configuration guidelines
When configuring authorization methods, follow these guidelines:
· The device supports HWTACACS authorization.
· To use a RADIUS scheme as the authorization method, specify the name of the RADIUS scheme that is configured as the authentication method for the ISP domain. If an invalid RADIUS scheme is specified as the authorization method, RADIUS authentication and authorization fail.
Configuration procedure
To configure authorization methods for an ISP domain:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter ISP domain view. |
domain isp-name |
N/A |
3. Specify default authorization methods for all types of users. |
authorization default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } |
By default, the authorization method is local. The none keyword is not supported in FIPS mode. |
4. Specify command authorization methods. |
authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local ] [ none ] | local [ none ] | none } |
By default, the default authorization methods are used for command authorization. The none keyword is not supported in FIPS mode. |
5. Specify authorization methods for login users. |
authorization login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } |
By default, the default authorization methods are used for login users. The none keyword is not supported in FIPS mode. |
Configuring accounting methods for an ISP domain
Configuration prerequisites
Before configuring accounting methods, complete the following tasks:
1. Determine the access type or service type to be configured. With AAA, you can configure an accounting method for each access type and service type.
2. Determine whether to configure the default accounting method for all access types or service types. The default accounting method applies to all access users. However, the method has a lower priority than the accounting method that is specified for an access type or service type.
Configuration guidelines
When configuring accounting methods, follow these guidelines:
· FTP, SFTP, and SCP users do not support accounting.
· Local accounting does not provide statistics for charging. It only counts and controls the number of concurrent users that use the same local user account. The threshold is configured by using the access-limit command.
Configuration procedure
To configure accounting methods for an ISP domain:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter ISP domain view. |
domain isp-name |
N/A |
3. Specify default accounting methods for all types of users. |
accounting default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } |
By default, the accounting method is local. The none keyword is not supported in FIPS mode. |
4. Specify the command accounting method. |
accounting command hwtacacs-scheme hwtacacs-scheme-name |
By default, the default accounting methods are used for command accounting. |
5. Specify accounting methods for login users. |
accounting login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] | local [ none ] | none | radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } |
By default, the default accounting methods are used for login users. The none keyword is not supported in FIPS mode. |
6. Configure access control for users that encounter accounting-start failures. |
accounting start-fail { offline | online } |
By default, the device allows users that encounter accounting-start failures to stay online. |
7. Configure access control for users that have failed all their accounting-update attempts. |
accounting update-fail { [ max-times max-times ] offline | online } |
By default, the device allows users that have failed all their accounting-update attempts to stay online. |
8. Configure access control for users that have used up their data quotas. |
accounting quota-out { offline | online } |
By default, the device logs off users that have used up their data quotas. |
9. Specify the accounting method for dual-stack users. |
accounting dual-stack { merge | separate } |
By default, the merge method is used. |
Configuring the RADIUS session-control feature
The RADIUS session-control feature can only work with the RADIUS server running on IMC. Enable this feature for the RADIUS server to dynamically change the user authorization information or forcibly disconnect users by using session-control packets. This task enables the device to receive RADIUS session-control packets on UDP port 1812.
To verify the session-control packets sent from a RADIUS server, specify the RADIUS server as a session-control client to the device. The IP, VPN instance, and shared key settings of the session-control client must be the same as the corresponding settings of the RADIUS server.
You can specify multiple session-control clients on the device.
The device matches a session-control packet to a session-control client based on IP and VPN instance settings, and then uses the shared key of the matched client to validate the packet.
The device searches the session-control client settings prior to searching all RADIUS settings for finding a server with matching IP and VPN instance settings. This process narrows the search scope for finding the matched RADIUS server.
The session-control client configuration takes effect only when the session-control feature is enabled.
To configure the RADIUS session-control feature:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable the RADIUS session-control feature. |
radius session-control enable |
By default, the RADIUS session-control feature is disabled. |
3. Specify a RADIUS session-control client. |
radius session-control client { ip ipv4-address | ipv6 ipv6-address } [ key { cipher | simple } string | vpn-instance vpn-instance-name ] * |
By default, no RADIUS session-control clients are specified. The device searches all RADIUS scheme settings to verify session-control packets. |
Configuring the RADIUS DAS feature
Dynamic Authorization Extensions (DAE) to RADIUS, defined in RFC 5176, can perform the following operations:
· Log off online users.
· Change online user authorization information.
· Shut down or reboot the online users' access ports.
DAE uses the client/server model.
In a RADIUS network, the RADIUS server typically acts as the DAE client (DAC) and the NAS acts as the DAE server (DAS).
When the RADIUS DAS feature is enabled, the NAS performs the following operations:
1. Listens to the default or specified UDP port to receive DAE requests.
2. Logs off online users that match the criteria in the requests, changes their authorization information, or shuts down or reboots their access ports.
3. Sends DAE responses to the DAC.
DAE defines the following types of packets:
· Disconnect Messages (DMs)—The DAC sends DM requests to the DAS to log off specific online users.
· Change of Authorization Messages (CoA Messages)—The DAC sends CoA requests to the DAS to change the authorization information of specific online users or shut down or reboot the users' access ports.
To configure the RADIUS DAS feature:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable the RADIUS DAS feature and enter RADIUS DAS view. |
radius dynamic-author server |
By default, the RADIUS DAS feature is disabled. |
3. Specify a RADIUS DAC. |
client { ip ipv4-address | ipv6 ipv6-address } [ key { cipher | simple } string | vpn-instance vpn-instance-name ] * |
By default, no RADIUS DACs are specified. |
4. Specify the RADIUS DAS port. |
port port-number |
By default, the RADIUS DAS port is 3799. |
Changing the DSCP priority for RADIUS packets
The DSCP priority in the ToS field determines the transmission priority of RADIUS packets. A larger value represents a higher priority.
To change the DSCP priority for RADIUS packets:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Change the DSCP priority for RADIUS packets. |
radius [ ipv6 ] dscp dscp-value |
By default, the DSCP priority is 0 for RADIUS packets. |
Configuring the RADIUS attribute translation feature
The RADIUS attribute translation feature enables the device to work correctly with the RADIUS servers of different vendors that support RADIUS attributes incompatible with the device.
RADIUS attribute translation has the following implementations:
· Attribute conversion—Converts source RADIUS attributes into destination RADIUS attributes based on RADIUS attribute conversion rules.
· Attribute rejection—Rejects RADIUS attributes based on RADIUS attribute rejection rules.
When the RADIUS attribute translation feature is enabled, the device processes RADIUS packets as follows:
· For the sent RADIUS packets:
? Deletes the rejected attributes from the packets.
? Uses the destination RADIUS attributes to replace the attributes that match RADIUS attribute conversion rules in the packets.
· For the received RADIUS packets:
? Ignores the rejected attributes in the packets.
? Interprets the attributes that match RADIUS attribute conversion rules as the destination RADIUS attributes.
To identify proprietary RADIUS attributes, you can define the attributes as extended RADIUS attributes, and then convert the extended RADIUS attributes to device-supported attributes.
To configure the RADIUS attribute translation feature for a RADIUS scheme:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. (Optional.) Define an extended RADIUS attribute. |
radius attribute extended attribute-name [ vendor vendor-id ] code attribute-code type { binary | date | integer | interface-id | ip | ipv6 | ipv6-prefix | octets | string } |
By default, no user-defined extended RADIUS attributes exist. Repeat this command to define multiple extended RADIUS attributes. |
3. Enter RADIUS scheme view. |
radius scheme radius-scheme-name |
N/A |
4. Enable the RADIUS attribute translation feature. |
attribute translate |
By default, this feature is disabled. |
5. Configure a RADIUS attribute conversion rule. |
attribute convert src-attr-name to dest-attr-name { { access-accept | access-request | accounting } * | { received | sent } * } |
By default, no RADIUS attribute conversion rules exist. Repeat this command to add multiple RADIUS attribute conversion rules. |
6. Configure a RADIUS attribute rejection rule. |
attribute reject attr-name { { access-accept | access-request | accounting } * | { received | sent } * } |
By default, no RADIUS attribute rejection rules exist. Repeat this command to add multiple RADIUS attribute rejection rules. |
To configure the RADIUS attribute translation feature for a RADIUS DAS:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. (Optional.) Define an extended RADIUS attribute. |
radius attribute extended attribute-name [ vendor vendor-id ] code attribute-code type { binary | date | integer | interface-id | ip | ipv6 | ipv6-prefix | octets | string } |
By default, no user-defined extended RADIUS attributes exist. Repeat this command to define multiple extended RADIUS attributes. |
3. Enter RADIUS DAS view. |
radius dynamic-author server |
N/A |
4. Enable the RADIUS attribute translation feature. |
attribute translate |
By default, this feature is disabled. |
5. Configure a RADIUS attribute conversion rule. |
attribute convert src-attr-name to dest-attr-name { { coa-ack | coa-request } * | { received | sent } * } |
By default, no RADIUS attribute conversion rules exist. Repeat this command to add multiple RADIUS attribute conversion rules. |
6. Configure a RADIUS attribute rejection rule. |
attribute reject attr-name { { coa-ack | coa-request } * | { received | sent } * } |
By default, no RADIUS attribute rejection rules exist. Repeat this command to add multiple RADIUS attribute rejection rules. |
Setting the maximum number of concurrent login users
Perform this task to set the maximum number of concurrent users that can log on to the device through a specific protocol, regardless of their authentication methods. The authentication methods include no authentication, local authentication, and remote authentication.
To set the maximum number of concurrent login users:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the maximum number of concurrent login users. |
·
In non-FIPS mode: ·
In FIPS mode: |
By default, the maximum number of concurrent login users is 32 for each user type. |
Configuring a NAS-ID profile
By default, the device sends its device name in the NAS-Identifier attribute of all RADIUS requests.
A NAS-ID profile enables you to send different NAS-Identifier attribute strings in RADIUS requests from different VLANs. The strings can be organization names, service names, or any user categorization criteria, depending on the administrative requirements.
For example, map the NAS-ID companyA to all VLANs of company A. The device will send companyA in the NAS-Identifier attribute for the RADIUS server to identify requests from any Company A users.
A NAS-ID can be bound with more than one VLAN, but a VLAN can be bound with only one NAS-ID.
To configure a NAS-ID profile:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a NAS-ID profile and enter NAS-ID profile view. |
aaa nas-id profile profile-name |
By default, no NAS-ID profiles exist. |
3. Configure a NAS-ID and VLAN binding in the profile. |
nas-id nas-identifier bind vlan vlan-id |
By default, no NAS-ID and VLAN bindings exist. |
Configuring the device ID
RADIUS uses the value of the Acct-Session-ID attribute as the accounting ID for a user. The device generates an Acct-Session-ID value for each online user based on the system time, random digits, and device ID.
To configure the device ID:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure the device ID. |
aaa device-id device-id |
By default, the device ID is 0. |
Displaying and maintaining AAA
Execute display commands in any view.
Task |
Command |
Display the configuration of ISP domains. |
display domain [ isp-name ] |
AAA configuration examples
AAA for SSH users by an HWTACACS server
Network requirements
As shown in Figure 10, configure the switch to meet the following requirements:
· Use the HWTACACS server for SSH user authentication, authorization, and accounting.
· Assign the default user role network-operator to SSH users after they pass authentication.
· Exclude domain names from the usernames sent to the HWTACACS server.
· Use expert as the shared keys for secure HWTACACS communication.
Configuration procedure
1. Configure the HWTACACS server:
# Set the shared keys to expert for secure communication with the switch. (Details not shown.)
# Add an account for the SSH user and specify the password. (Details not shown.)
2. Configure the switch:
# Configure IP addresses for the interfaces. (Details not shown.)
# Create an HWTACACS scheme.
<Switch> system-view
[Switch] hwtacacs scheme hwtac
# Specify the primary authentication server.
[Switch-hwtacacs-hwtac] primary authentication 10.1.1.1 49
# Specify the primary authorization server.
[Switch-hwtacacs-hwtac] primary authorization 10.1.1.1 49
# Specify the primary accounting server.
[Switch-hwtacacs-hwtac] primary accounting 10.1.1.1 49
# Set the shared keys to expert in plaintext form for secure HWTACACS communication.
[Switch-hwtacacs-hwtac] key authentication simple expert
[Switch-hwtacacs-hwtac] key authorization simple expert
[Switch-hwtacacs-hwtac] key accounting simple expert
# Exclude domain names from the usernames sent to the HWTACACS server.
[Switch-hwtacacs-hwtac] user-name-format without-domain
[Switch-hwtacacs-hwtac] quit
# Create an ISP domain named bbb and configure the domain to use the HWTACACS scheme for authentication, authorization, and accounting of login users.
[Switch-isp-bbb] authentication login hwtacacs-scheme hwtac
[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting login hwtacacs-scheme hwtac
[Switch-isp-bbb] quit
# Create local RSA and DSA key pairs.
[Switch] public-key local create rsa
[Switch] public-key local create dsa
# Enable the SSH service.
[Switch] ssh server enable
# Enable scheme authentication for user lines VTY 0 through VTY 63.
[Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme
[Switch-line-vty0-63] quit
# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.
[Switch] role default-role enable
Verifying the configuration
# Initiate an SSH connection to the switch, and enter the correct username and password. The user logs in to the switch. (Details not shown.)
# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)
Local authentication, HWTACACS authorization, and RADIUS accounting for SSH users
Network requirements
As shown in Figure 11, configure the switch to meet the following requirements:
· Perform local authentication for SSH servers.
· Use the HWTACACS server and RADIUS server for SSH user authorization and accounting, respectively.
· Exclude domain names from the usernames sent to the servers.
· Assign the default user role network-operator to SSH users after they pass authentication.
Configure an account with the username hello for the SSH user. Configure the shared keys to expert for secure communication with the HWTACACS server and RADIUS server.
Configuration procedure
1. Configure the HWTACACS server. (Details not shown.)
2. Configure the RADIUS server. (Details not shown.)
3. Configure the switch:
# Configure IP addresses for interfaces. (Details not shown.)
# Create local RSA and DSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa
[Switch] public-key local create dsa
# Enable the SSH service.
[Switch] ssh server enable
# Enable scheme authentication for user lines VTY 0 through VTY 63.
[Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme
[Switch-line-vty0-63] quit
# Configure an HWTACACS scheme.
[Switch] hwtacacs scheme hwtac
[Switch-hwtacacs-hwtac] primary authorization 10.1.1.2 49
[Switch-hwtacacs-hwtac] key authorization simple expert
[Switch-hwtacacs-hwtac] user-name-format without-domain
[Switch-hwtacacs-hwtac] quit
# Configure a RADIUS scheme.
[Switch] radius scheme rd
[Switch-radius-rd] primary accounting 10.1.1.1 1813
[Switch-radius-rd] key accounting simple expert
[Switch-radius-rd] user-name-format without-domain
[Switch-radius-rd] quit
# Create a device management user.
[Switch] local-user hello class manage
# Assign the SSH service to the local user.
[Switch-luser-manage-hello] service-type ssh
# Set the password to 123456TESTplat&! in plaintext form for the local user. In FIPS mode, you must set the password in interactive mode.
[Switch-luser-manage-hello] password simple 123456TESTplat&!
[Switch-luser-manage-hello] quit
# Create an ISP domain named bbb and configure the login users to use local authentication, HWTACACS authorization, and RADIUS accounting.
[Switch] domain bbb
[Switch-isp-bbb] authentication login local
[Switch-isp-bbb] authorization login hwtacacs-scheme hwtac
[Switch-isp-bbb] accounting login radius-scheme rd
[Switch-isp-bbb] quit
# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.
[Switch] role default-role enable
Verifying the configuration
# Initiate an SSH connection to the switch, and enter the username hello@bbb and the correct password. The user logs in to the switch. (Details not shown.)
# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)
Authentication and authorization for SSH users by a RADIUS server
Network requirements
As shown in Figure 12, configure the switch to meet the following requirements:
· Use the RADIUS server for SSH user authentication and authorization.
· Include domain names in the usernames sent to the RADIUS server.
· Assign the default user role network-operator to SSH users after they pass authentication.
The RADIUS server runs on IMC. Add an account with the username hello@bbb on the RADIUS server.
The RADIUS server and the switch use expert as the shared key for secure RADIUS communication. The ports for authentication and accounting are 1812 and 1813, respectively.
Configuration procedure
1. Configure the RADIUS server on IMC 5.0:
|
NOTE: In this example, the RADIUS server runs on IMC PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101). |
# Add the switch to the IMC Platform as an access device.
Log in to IMC, click the Service tab, and select User Access Manager > Access Device Management > Access Device from the navigation tree. Then, click Add to configure an access device as follows:
a. Set the shared key for secure RADIUS communication to expert.
b. Set the ports for authentication and accounting to 1812 and 1813, respectively.
c. Select the service type Device Management Service.
d. Select the access device type H3C.
e. Select the access device from the device list or manually add the access device (with the IP address 10.1.1.2).
f. Leave the default settings for other parameters and click OK.
The IP address of the access device specified here must be the same as the source IP address of the RADIUS packets sent from the switch. The source IP address is chosen in the following order on the switch:
? IP address specified by the nas-ip command.
? IP address specified by the radius nas-ip command.
? IP address of the outbound interface (the default).
Figure 13 Adding the switch as an access device
# Add an account for device management.
Click the User tab, and select Access User View > Device Mgmt User from the navigation tree. Then, click Add to configure a device management account as follows:
a. Enter the account name hello@bbb and specify the password.
b. Select the service type SSH.
c. Specify 10.1.1.0 to 10.1.1.255 as the IP address range of the hosts to be managed.
d. Click OK.
|
NOTE: The IP address range must contain the IP address of the switch. |
Figure 14 Adding an account for device management
2. Configure the switch:
# Configure the IP addresses for interfaces. (Details not shown.)
# Create local RSA and DSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa
[Switch] public-key local create dsa
# Enable the SSH service.
[Switch] ssh server enable
# Enable scheme authentication for user lines VTY 0 through VTY 63.
[Switch] line vty 0 63
[Switch-line-vty0-63] authentication-mode scheme
[Switch-line-vty0-63] quit
# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.
[Switch] role default-role enable
# Create a RADIUS scheme.
[Switch] radius scheme rad
# Specify the primary authentication server.
[Switch-radius-rad] primary authentication 10.1.1.1 1812
# Set the shared key to expert in plaintext form for secure communication with the server.
[Switch-radius-rad] key authentication simple expert
# Include domain names in the usernames sent to the RADIUS server.
[Switch-radius-rad] user-name-format with-domain
[Switch-radius-rad] quit
# Create an ISP domain named bbb and configure authentication, authorization, and accounting methods for login users.
[Switch] domain bbb
[Switch-isp-bbb] authentication login radius-scheme rad
[Switch-isp-bbb] authorization login radius-scheme rad
[Switch-isp-bbb] accounting login none
[Switch-isp-bbb] quit
Verifying the configuration
# Initiate an SSH connection to the switch, and enter the username hello@bbb and the correct password. The user logs in to the switch. (Details not shown.)
# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)
Troubleshooting RADIUS
RADIUS authentication failure
Symptom
User authentication always fails.
Analysis
Possible reasons include:
· A communication failure exists between the NAS and the RADIUS server.
· The username is not in the userid@isp-name format, or the ISP domain is not correctly configured on the NAS.
· The user is not configured on the RADIUS server.
· The password entered by the user is incorrect.
· The RADIUS server and the NAS are configured with different shared keys.
Solution
To resolve the problem:
1. Verify the following items:
? The NAS and the RADIUS server can ping each other.
? The username is in the userid@isp-name format and the ISP domain is correctly configured on the NAS.
? The user is configured on the RADIUS server.
? The correct password is entered.
? The same shared key is configured on both the RADIUS server and the NAS.
2. If the problem persists, contact H3C Support.
RADIUS packet delivery failure
Symptom
RADIUS packets cannot reach the RADIUS server.
Analysis
Possible reasons include:
· A communication failure exists between the NAS and the RADIUS server.
· The NAS is not configured with the IP address of the RADIUS server.
· The authentication and accounting UDP ports configured on the NAS are incorrect.
· The RADIUS server's authentication and accounting port numbers are being used by other applications.
Solution
To resolve the problem:
1. Verify the following items:
? The link between the NAS and the RADIUS server works well at both the physical and data link layers.
? The IP address of the RADIUS server is correctly configured on the NAS.
? The authentication and accounting UDP port numbers configured on the NAS are the same as those of the RADIUS server.
? The RADIUS server's authentication and accounting port numbers are available.
2. If the problem persists, contact H3C Support.
RADIUS accounting error
Symptom
A user is authenticated and authorized, but accounting for the user is not normal.
Analysis
The accounting server configuration on the NAS is not correct. Possible reasons include:
· The accounting port number configured on the NAS is incorrect.
· The accounting server IP address configured on the NAS is incorrect. For example, the NAS is configured to use a single server to provide authentication, authorization, and accounting services, but in fact the services are provided by different servers.
Solution
To resolve the problem:
1. Verify the following items:
? The accounting port number is correctly configured.
? The accounting server IP address is correctly configured on the NAS.
2. If the problem persists, contact H3C Support.
Troubleshooting HWTACACS
Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS."
Configuring password control
Overview
Password control allows you to implement the following features:
· Manage login and super password setup, expirations, and updates for device management users.
· Control user login status based on predefined policies.
Local users are divided into two types: device management users and network access users. This feature applies only to device management users. For more information about local users, see "Configuring AAA."
Password setting
Minimum password length
You can define the minimum length of user passwords. If a user enters a password that is shorter than the minimum length, the system rejects the password.
Password composition policy
A password can be a combination of characters from the following types:
· Uppercase letters A to Z.
· Lowercase letters a to z.
· Digits 0 to 9.
· Special characters in Table 5.
Character name |
Symbol |
Character name |
Symbol |
Ampersand sign |
& |
Apostrophe |
' |
Asterisk |
* |
At sign |
@ |
Back quote |
` |
Back slash |
\ |
Blank space |
N/A |
Caret |
^ |
Colon |
: |
Comma |
, |
Dollar sign |
$ |
Dot |
. |
Equal sign |
= |
Exclamation point |
! |
Left angle bracket |
< |
Left brace |
{ |
Left bracket |
[ |
Left parenthesis |
( |
Minus sign |
- |
Percent sign |
% |
Plus sign |
+ |
Pound sign |
# |
Quotation marks |
" |
Right angle bracket |
> |
Right brace |
} |
Right bracket |
] |
Right parenthesis |
) |
Semi-colon |
; |
Slash |
/ |
Tilde |
~ |
Underscore |
_ |
Vertical bar |
| |
Depending on the system's security requirements, you can set the minimum number of character types a password must contain and the minimum number of characters for each type, as shown in Table 6.
Table 6 Password composition policy
Password combination level |
Minimum number of character types |
Minimum number of characters for each type |
Level 1 |
One |
One |
Level 2 |
Two |
One |
Level 3 |
Three |
One |
Level 4 |
Four |
One |
In non-FIPS mode, all the combination levels are available for a password. In FIPS mode, only the level 4 combination is available for a password.
When a user sets or changes a password, the system checks if the password meets the combination requirement. If not, the operation fails.
Password complexity checking policy
A less complicated password such as a password containing the username or repeated characters is more likely to be cracked. For higher security, you can configure a password complexity checking policy to ensure that all user passwords are relatively complicated. With such a policy configured, when a user configures a password, the system checks the complexity of the password. If the password is complexity-incompliant, the configuration will fail.
You can apply the following password complexity requirements:
· A password cannot contain the username or the reverse of the username. For example, if the username is abc, a password such as abc982 or 2cba is not complex enough.
· A character or number cannot be included three or more times consecutively. For example, password a111 is not complex enough.
Password updating and expiration
Password updating
This feature allows you to set the minimum interval at which users can change their passwords. If a user logs in to change the password but the time passed since the last change is less than this interval, the system denies the request. For example, if you set this interval to 48 hours, a user cannot change the password twice within 48 hours.
The set minimum interval is not effective when a user is prompted to change the password at the first login or after its password aging time expires.
Password expiration
Password expiration imposes a lifecycle on a user password. After the password expires, the user needs to change the password.
If a user enters an expired password when logging in, the system displays an error message. The user is prompted to provide a new password and to confirm it by entering it again. The new password must be valid, and the user must enter exactly the same password when confirming it.
Telnet users, SSH users, and console users can change their own passwords. The administrator must change passwords for FTP users.
Early notice on pending password expiration
When a user logs in, the system checks whether the password will expire in a time equal to or less than the specified notification period. If so, the system notifies the user when the password will expire and provides a choice for the user to change the password. If the user sets a new password that is complexity-compliant, the system records the new password and the setup time. If the user chooses not to change the password or the user fails to change it, the system allows the user to log in using the current password.
Telnet users, SSH users, and console users can change their own passwords. The administrator must change passwords for FTP users.
Login with an expired password
You can allow a user to log in a certain number of times within a period of time after the password expires. For example, if you set the maximum number of logins with an expired password to 3 and the time period to 15 days, a user can log in three times within 15 days after the password expires.
Password history
With this feature enabled, the system stores passwords that a user has used. When a user changes the password, the system compares the new password with the current password and those stored in the password history records. The new password must be different from the current one and those stored in the history records by a minimum of four characters. The four characters must be different from one another. Otherwise, the system will display an error message, and the password will not be changed.
You can set the maximum number of history password records for the system to maintain for each user. When the number of history password records exceeds your setting, the most recent record overwrites the earliest one.
Current login passwords of device management users are not stored in the password history, because a device management user password is saved in cipher text and cannot be recovered to a plaintext password.
User login control
First login
If the global password control feature is enabled, users must change the password at first login before they can access the system. In this situation, password changes are not subject to the minimum password update interval.
Login attempt limit
Limiting the number of consecutive login failures can effectively prevent password guessing.
Login attempt limit takes effect on FTP and VTY users. It does not take effect on the following types of users:
· Nonexistent users (users not configured on the device).
· Users logging in to the device through console ports.
If a user fails to log in, the system adds the user account and the user's IP address to the password control blacklist. After making the maximum number of consecutive attempts, login attempt limit limits the user and user account in any of the following ways:
· Disables the user account until the account is manually removed from the password control blacklist.
· Allows the user to continue using the user account. The user's IP address and user account are removed from the password control blacklist when the user uses this account to successfully log in to the device.
· Disables the user account for a period of time.
The user can use the account to log in when either of the following conditions exists:
? The locking timer expires.
? The account is manually removed from the password control blacklist before the locking timer expires.
|
NOTE: This account is locked only for this user. Other users can still use this account, and the blacklisted user can use other user accounts. |
Maximum account idle time
You can set the maximum account idle time for user accounts. When an account is idle for this period of time since the last successful login, the account becomes invalid.
Password not displayed in any form
For security purposes, nothing is displayed when a user enters a password.
Logging
The system logs all successful password changing events and user adding events to the password control blacklist.
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
Password control configuration task list
The password control features can be configured in several different views, and different views support different features. The settings configured in different views or for different objects have the following application ranges:
· Settings for super passwords apply only to super passwords.
· Settings in local user view apply only to the password of the local user.
· Settings in user group view apply to the passwords of the local users in the user group if you do not configure password policies for these users in local user view.
· Global settings in system view apply to the passwords of the local users in all user groups if you do not configure password policies for these users in both local user view and user group view.
For local user passwords, the settings with a smaller application scope have higher priority.
To configure password control, perform the following tasks:
Tasks at a glance |
(Required.) Enabling password control |
(Optional.) Setting global password control parameters |
(Optional.) Setting user group password control parameters |
(Optional.) Setting local user password control parameters |
(Optional.) Setting super password control parameters |
Enabling password control
Enabling the global password control feature is the prerequisite for all password control configurations to take effect. Then, for a specific password control feature to take effect, enable this password control feature.
After the global password control feature is enabled, you cannot display the password and super password configurations for device management users by using the corresponding display commands. However, the configuration for network access user passwords can be displayed. The first password configured for device management users must contain a minimum of four different characters.
To ensure correct function of password control, configure the device to use NTP to obtain the UTC time. After global password control is enabled, password control will record the UTC time when the password is set. The recorded UTC time might not be consistent with the actual UTC time due to power failure or device reboot. The inconsistency will cause the password expiration feature to malfunction. For information about NTP, see Network Management and Monitoring Configuration Guide.
To enable password control:
Step |
Command |
Remarks |
system-view |
N/A |
|
2. Enable the global password control feature. |
password-control enable |
· In non-FIPS mode, the global password control feature is disabled by default. · In FIPS mode, the global password control feature is enabled, and cannot be disabled by default. |
3. (Optional.) Enable a specific password control feature. |
password-control { aging | composition | history | length } enable |
By default, all four password control features are enabled. |
Setting global password control parameters
The password expiration time, minimum password length, and password composition policy can be configured in system view, user group view, or local user view. The password settings with a smaller application scope have higher priority. Global settings in system view apply to the passwords of the local users in all user groups if you do not configure password policies for these users in both local user view and user group view.
The password-control login-attempt command takes effect immediately and can affect the users already in the password control blacklist. Other password control configurations do not take effect on users that have been logged in or passwords that have been configured.
To set global password control parameters:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the password expiration time. |
password-control aging aging-time |
The default setting is 90 days. |
3. Set the minimum password update interval. |
password-control update interval interval |
The default setting is 24 hours. |
4. Set the minimum password length. |
password-control length length |
· In non-FIPS mode, the default setting is 10 characters. · In FIPS mode, the default length is 15 characters. |
5. Configure the password composition policy. |
password-control composition type-number type-number [ type-length type-length ] |
The following default settings apply: · In non-FIPS mode, a password must contain a minimum of one character type and a minimum of one character for each type. · In FIPS mode, a password must contain a minimum of four character types and a minimum of one character for each type. |
6. Configure the password complexity checking policy. |
password-control complexity { same-character | user-name } check |
By default, the system does not perform password complexity checking. |
7. Set the maximum number of history password records for each user. |
password-control history max-record-number |
The default setting is 4. |
8. Configure the login attempt limit. |
password-control login-attempt login-times [ exceed { lock | lock-time time | unlock } ] |
By default, the maximum number of login attempts is 3 and a user failing to log in after the specified number of attempts must wait for 1 minute before trying again. |
9. Set the number of days during which a user is notified of the pending password expiration. |
password-control alert-before-expire alert-time |
The default setting is 7 days. |
10. Set the maximum number of days and maximum number of times that a user can log in after the password expires. |
password-control expired-user-login delay delay times times |
By default, a user can log in three times within 30 days after the password expires. |
11. Set the maximum account idle time. |
password-control login idle-time idle-time |
The default setting is 90 days. |
Setting user group password control parameters
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a user group and enter its view. |
user-group group-name |
By default, no user groups exist. For information about how to configure a user group, see "Configuring AAA." |
3. Configure the password expiration time for the user group. |
password-control aging aging-time |
By default, the password expiration time of the user group equals the global password expiration time. |
4. Configure the minimum password length for the user group. |
password-control length length |
By default, the minimum password length of the user group equals the global minimum password length. |
5. Configure the password composition policy for the user group. |
password-control composition type-number type-number [ type-length type-length ] |
By default, the password composition policy of the user group equals the global password composition policy. |
6. Configure the password complexity checking policy for the user group. |
password-control complexity { same-character | user-name } check |
By default, the password complexity checking policy of the user group equals the global password complexity checking policy. |
7. Configure the login attempt limit. |
password-control login-attempt login-times [ exceed { lock | lock-time time | unlock } ] |
By default, the login-attempt policy of the user group equals the global login-attempt policy. |
Setting local user password control parameters
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a device management user and enter its view. |
local-user user-name class manage |
By default, no local users exist. Local user password control applies to device management users instead of network access users. For information about how to configure a local user, see "Configuring AAA." |
3. Configure the password expiration time for the local user. |
password-control aging aging-time |
By default, the setting equals that for the user group to which the local user belongs. If no expiration time is configured for the user group, the global setting applies to the local user. |
4. Configure the minimum password length for the local user. |
password-control length length |
By default, the setting equals that for the user group to which the local user belongs. If no minimum password length is configured for the user group, the global setting applies to the local user. |
5. Configure the password composition policy for the local user. |
password-control composition type-number type-number [ type-length type-length ] |
By default, the settings equal those for the user group to which the local user belongs. If no password composition policy is configured for the user group, the global settings apply to the local user. |
6. Configure the password complexity checking policy for the local user. |
password-control complexity { same-character | user-name } check |
By default, the settings equal those for the user group to which the local user belongs. If no password complexity checking policy is configured for the user group, the global settings apply to the local user. |
7. Configure the login attempt limit. |
password-control login-attempt login-times [ exceed { lock | lock-time time | unlock } ] |
By default, the settings equal those for the user group to which the local user belongs. If no login-attempt policy is configured for the user group, the global settings apply to the local user. |
Setting super password control parameters
The super password allows you to obtain a temporary user role without reconnecting to the device. For more information, see Fundamentals Configuration Guide.
To set super password control parameters:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the password expiration time for super passwords. |
password-control super aging aging-time |
The default setting is 90 days. |
3. Configure the minimum length for super passwords. |
password-control super length length |
· In non-FIPS mode, the default setting is 10 characters. · In FIPS mode, the default setting is 15 characters. |
4. Configure the password composition policy for super passwords. |
password-control super composition type-number type-number [ type-length type-length ] |
The following default settings apply: · In non-FIPS mode, a super password must contain a minimum of one character type and a minimum of one character for each type. · In FIPS mode, a super password must contain a minimum of four character types and a minimum of one character for each type. |
Displaying and maintaining password control
Execute display commands in any view and reset commands in user view.
Task |
Command |
Display password control configuration. |
display password-control [ super ] |
Display information about users in the password control blacklist. |
display password-control blacklist [ user-name user-name | ip ipv4-address | ipv6 ipv6-address ] |
Delete users from the password control blacklist. |
reset password-control blacklist [ user-name user-name ] |
Clear history password records. |
reset password-control history-record [ user-name user-name | super [ role role name ] ] |
|
NOTE: The reset password-control history-record command can delete the history password records of one or all users even when the password history feature is disabled. |
Password control configuration example
Network requirements
Configure a global password control policy to meet the following requirements:
· A password must contain a minimum of 16 characters.
· A password must contain a minimum of four character types and a minimum of four characters for each type.
· An FTP or VTY user failing to provide the correct password in two successive login attempts is permanently prohibited from logging in.
· A user can log in five times within 60 days after the password expires.
· A password expires after 30 days.
· The minimum password update interval is 36 hours.
· The maximum account idle time is 30 days.
· A password cannot contain the username or the reverse of the username.
· No character appears consecutively three or more times in a password.
Configure a super password control policy for user role network-operator to meet the following requirements:
· A super password must contain a minimum of 24 characters.
· A super password must contain a minimum of four character types and a minimum of five characters for each type.
Configure a password control policy for local Telnet user test to meet the following requirements:
· The password must contain a minimum of 24 characters.
· The password must contain a minimum of four character types and a minimum of five characters for each type.
· The password for the local user expires after 20 days.
Configuration procedure
# Enable the password control feature globally.
<Sysname> system-view
[Sysname] password-control enable
# Disable a user account permanently if a user fails two consecutive login attempts on the user account.
[Sysname] password-control login-attempt 2 exceed lock
# Set all passwords to expire after 30 days.
[Sysname] password-control aging 30
# Globally set the minimum password length to 16 characters.
[Sysname] password-control length 16
# Set the minimum password update interval to 36 hours.
[Sysname] password-control update-interval 36
# Specify that a user can log in five times within 60 days after the password expires.
[Sysname] password-control expired-user-login delay 60 times 5
# Set the maximum account idle time to 30 days.
[Sysname] password-control login idle-time 30
# Refuse any password that contains the username or the reverse of the username.
[Sysname] password-control complexity user-name check
# Specify that no character can be included three or more times consecutively in a password.
[Sysname] password-control complexity same-character check
# Globally specify that all passwords must each contain a minimum of four character types and a minimum of four characters for each type.
[Sysname] password-control composition type-number 4 type-length 4
# Set the minimum super password length to 24 characters.
[Sysname] password-control super length 24
# Specify that a super password must contain a minimum of four character types and a minimum of five characters for each type.
[Sysname] password-control super composition type-number 4 type-length 5
# Configure a super password used for switching to user role network-operator as 123456789ABGFTweuix@#$%! in plain text.
[Sysname] super password role network-operator simple 123456789ABGFTweuix@#$%!
# Create a device management user named test.
[Sysname] local-user test class manage
# Set the service type of the user to Telnet.
[Sysname-luser-manage-test] service-type telnet
# Set the minimum password length to 24 for the local user.
[Sysname-luser-manage-test] password-control length 24
# Specify that the password of the local user must contain a minimum of four character types and a minimum of five characters for each type.
[Sysname-luser-manage-test] password-control composition type-number 4 type-length 5
# Set the password for the local user to expire after 20 days.
[Sysname-luser-manage-test] password-control aging 20
# Configure the password of the local user in interactive mode.
[Sysname-luser-manage-test] password
Password:
Confirm :
Updating user information. Please wait ... ...
[Sysname-luser-manage-test] quit
Verifying the configuration
# Display the global password control configuration.
<Sysname> display password-control
Global password control configurations:
Password control: Enabled
Password aging: Enabled (30 days)
Password length: Enabled (16 characters)
Password composition: Enabled (4 types, 4 characters per type)
Password history: Enabled (max history record:4)
Early notice on password expiration: 7 days
Maximum login attempts: 2
Action for exceeding login attempts: Lock
Minimum interval between two updates: 36 hours
User account idle time: 30 days
Logins with aged password: 5 times in 60 days
Password complexity: Enabled (username checking)
Enabled (repeated characters checking)
# Display the password control configuration for super passwords.
<Sysname> display password-control super
Super password control configurations:
Password aging: Enabled (90 days)
Password length: Enabled (24 characters)
Password composition: Enabled (4 types, 5 characters per type)
# Display the password control configuration for local user test.
<Sysname> display local-user user-name test class manage
Total 1 local users matched.
Device management user test:
State: Active
Service type: Telnet
User group: system
Bind attributes:
Authorization attributes:
Work directory: flash:
User role list: network-operator
Password control configurations:
Password aging: 20 days
Password length: 24 characters
Password composition: 4 types, 5 characters per type
Configuring keychains
Overview
A keychain, a sequence of keys, provides dynamic authentication to ensure secure communication by periodically changing the key and authentication algorithm without service interruption.
Each key in a keychain has a key string, authentication algorithm, sending lifetime, and receiving lifetime. These settings can be different for the keys. When the system time is within the lifetime of a key in a keychain, an application uses the key to authenticate incoming and outgoing packets. The keys in the keychain take effect one by one according to the sequence of the configured lifetimes. In this way, the authentication algorithms and keys are dynamically changed to implement dynamic authentication.
A keychain operates in absolute time mode. In this mode, each time point during a key's lifetime is the UTC time and is not affected by the system's time zone or daylight saving time.
Configuration procedure
Follow these guidelines when you configure a keychain:
· To make sure only one key in a keychain is used at a time to authenticate packets to a peer, set non-overlapping sending lifetimes for the keys in the keychain.
· The keys used by the local device and the peer device must have the same authentication algorithm and key string.
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a keychain and enter keychain view. |
keychain keychain-name [ mode absolute ] |
By default, no keychains exist. |
3. (Optional.) Set the kind value in the TCP Enhanced Authentication Option. |
tcp-kind kind-value |
By default, the kind value is 254. When the local device uses TCP to communicate with a peer device from another vendor, make sure both devices have the same kind value setting. If they do not have the same value, use this command to modify the kind value on the local device. |
4. (Optional.) Set an algorithm ID for a TCP authentication algorithm. |
tcp-algorithm-id { hmac-md5 | md5 } algorithm-id |
By default, the algorithm ID is 3 for the MD5 authentication algorithm, and is 5 for the HMAC-MD5 authentication algorithm. When the local device uses TCP to communicate with a peer device from another vendor, make sure both devices have the same algorithm ID setting. If they do not have the same algorithm ID, use this command to modify the algorithm ID on the local device. |
5. (Optional.) Set a tolerance time for accept keys in the keychain. |
accept-tolerance { value | infinite } |
By default, no tolerance time is configured for accept keys in a keychain. |
6. Create a key and enter key view. |
key key-id |
By default, no keys exist. |
7. Specify an authentication algorithm for the key. |
authentication-algorithm { hmac-md5 | hmac-sha-256 | md5 } |
By default, no authentication algorithm is specified for a key. |
8. Configure a key string for the key. |
key-string { cipher | plain } string |
By default, no key string is configured. |
9. Set the sending lifetime in UTC mode for the key. |
send-lifetime utc start-time start-date { duration { duration-value | infinite } | to end-time end-date } |
By default, the sending lifetime is not configured for a key. |
10. Set the receiving lifetime in UTC mode for the key. |
accept-lifetime utc start-time start-date { duration { duration-value | infinite } | to end-time end-date } |
By default, the receiving lifetime is not configured for a key. |
11. (Optional.) Specify the key as the default send key. |
default-send-key |
By default, no key in a keychain is specified as the default send key. |
Displaying and maintaining keychain
Execute display commands in any view.
Task |
Command |
Display keychain information. |
display keychain [ name keychain-name [ key key-id ] ] |
Keychain configuration example
Network requirements
As shown in Figure 15, establish an OSPF neighbor relationship between Switch A and Switch B, and use a keychain to authenticate packets between the switches. Configure key 1 and key 2 for the keychain and make sure key 2 is used immediately when key 1 expires.
Configuration procedure
Configuring Switch A
# Configure IP addresses for interfaces. (Details not shown.)
# Configure OSPF.
<SwitchA> system-view
[SwitchA] ospf 1 router-id 1.1.1.1
[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
# Create a keychain named abc, and specify the absolute time mode for it.
[SwitchA] keychain abc mode absolute
# Create key 1 for keychain abc, specify an authentication algorithm, and configure a key string and the sending and receiving lifetimes for the key.
[SwitchA-keychain-abc] key 1
[SwitchA-keychain-abc-key-1] authentication-algorithm md5
[SwitchA-keychain-abc-key-1] key-string plain 123456
[SwitchA-keychain-abc-key-1] send-lifetime utc 10:00:00 2015/02/06 to 11:00:00 2015/02/06
[SwitchA-keychain-abc-key-1] accept-lifetime utc 10:00:00 2015/02/06 to 11:00:00 2015/02/06
[SwitchA-keychain-abc-key-1] quit
# Create key 2 for keychain abc, specify an authentication algorithm, and configure a key string and the sending and receiving lifetimes for the key.
[SwitchA-keychain-abc] key 2
[SwitchA-keychain-abc-key-2] authentication-algorithm hmac-md5
[SwitchA-keychain-abc-key-2] key-string plain pwd123
[SwitchA-keychain-abc-key-2] send-lifetime utc 11:00:00 2015/02/06 to 12:00:00 2015/02/06
[SwitchA-keychain-abc-key-2] accept-lifetime utc 11:00:00 2015/02/06 to 12:00:00 2015/02/06
[SwitchA-keychain-abc-key-2] quit
[SwitchA-keychain-abc] quit
# Configure VLAN-interface 100 to use keychain abc for authentication.
[SwitchA] interface vlan-interface 100
[SwitchA-Vlan-interface100] ospf authentication-mode keychain abc
[SwitchA-Vlan-interface100] quit
Configuring Switch B
# Configure IP addresses for interfaces. (Details not shown.)
# Configure OSPF.
[SwitchB] ospf 1 router-id 2.2.2.2
[SwitchB-ospf-1] area 0
[SwitchB-ospf-1-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchB-ospf-1] quit
# Create a keychain named abc, and specify the absolute time mode for it.
[SwitchB] keychain abc mode absolute
# Create key 1 for keychain abc, specify an authentication algorithm, and configure a key string and the sending and receiving lifetimes for the key.
[SwitchB-keychain-abc] key 1
[SwitchB-keychain-abc-key-1] authentication-algorithm md5
[SwitchB-keychain-abc-key-1] key-string plain 123456
[SwitchB-keychain-abc-key-1] send-lifetime utc 10:00:00 2015/02/06 to 11:00:00 2015/02/06
[SwitchB-keychain-abc-key-1] accept-lifetime utc 10:00:00 2015/02/06 to 11:00:00 2015/02/06
[SwitchB-keychain-abc-key-1] quit
# Create key 2 for keychain abc, specify an authentication algorithm, and configure a key string and the sending and receiving lifetimes for the key.
[SwitchB-keychain-abc] key 2
[SwitchB-keychain-abc-key-2] authentication-algorithm hmac-md5
[SwitchB-keychain-abc-key-2] key-string plain pwd123
[SwitchB-keychain-abc-key-2] send-lifetime utc 11:00:00 2015/02/06 to 12:00:00 2015/02/06
[SwitchB-keychain-abc-key-2] accept-lifetime utc 11:00:00 2015/02/06 to 12:00:00 2015/02/06
[SwitchB-keychain-abc-key-2] quit
[SwitchB-keychain-abc] quit
# Configure VLAN-interface 100 to use keychain abc for authentication.
[SwitchB] interface vlan-interface 100
[SwitchB-Vlan-interface100] ospf authentication-mode keychain abc
[SwitchB-Vlan-interface100] quit
Verifying the configuration
1. When the system time is within the lifetime from 10:00:00 to 11:00:00 on the day 2015/02/06, verify the status of the keys in keychain abc.
# Display keychain information on Switch A. The output shows that key 1 is the valid key.
[SwitchA] display keychain
Keychain name : abc
Mode : absolute
Accept tolerance : 0
TCP kind value : 254
TCP algorithm value
HMAC-MD5 : 5
MD5 : 3
Default send key ID : None
Active send key ID : 1
Active accept key IDs: 1
Key ID : 1
Key string : $c$3$dYTC8QeOKJkwFwP2k/rWL+1p6uMTw3MqNg==
Algorithm : md5
Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Send status : Active
Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Accept status : Active
Key ID : 2
Key string : $c$3$7TSPbUxoP1ytOqkdcJ3K3x0BnXEWl4mOEw==
Algorithm : hmac-md5
Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Send status : Inactive
Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Accept status : Inactive
# Display keychain information on Switch B. The output shows that key 1 is the valid key.
[SwitchB]display keychain
Keychain name : abc
Mode : absolute
Accept tolerance : 0
TCP kind value : 254
TCP algorithm value
HMAC-MD5 : 5
MD5 : 3
Default send key ID : None
Active send key ID : 1
Active accept key IDs: 1
Key ID : 1
Key string : $c$3$/G/Shnh6heXWprlSQy/XDmftHa2JZJBSgg==
Algorithm : md5
Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Send status : Active
Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Accept status : Active
Key ID : 2
Key string : $c$3$t4qHAw1hpZYN0JKIEpXPcMFMVT81u0hiOw==
Algorithm : hmac-md5
Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Send status : Inactive
Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Accept status : Inactive
2. When the system time is within the lifetime from 11:00:00 to 12:00:00 on the day 2015/02/06, verify the status of the keys in keychain abc.
# Display keychain information on Switch A. The output shows that key 2 becomes the valid key.
[SwitchA]display keychain
Keychain name : abc
Mode : absolute
Accept tolerance : 0
TCP kind value : 254
TCP algorithm value
HMAC-MD5 : 5
MD5 : 3
Default send key ID : None
Active send key ID : 2
Active accept key IDs: 2
Key ID : 1
Key string : $c$3$dYTC8QeOKJkwFwP2k/rWL+1p6uMTw3MqNg==
Algorithm : md5
Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Send status : Inactive
Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Accept status : Inactive
Key ID : 2
Key string : $c$3$7TSPbUxoP1ytOqkdcJ3K3x0BnXEWl4mOEw==
Algorithm : hmac-md5
Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Send status : Active
Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Accept status : Active
# Display keychain information on Switch B. The output shows that key 2 becomes the valid key.
[SwitchB]display keychain
Keychain name : abc
Mode : absolute
Accept tolerance : 0
TCP kind value : 254
TCP algorithm value
HMAC-MD5 : 5
MD5 : 3
Default send key ID : None
Active send key ID : 1
Active accept key IDs: 1
Key ID : 1
Key string : $c$3$/G/Shnh6heXWprlSQy/XDmftHa2JZJBSgg==
Algorithm : md5
Send lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Send status : Inactive
Accept lifetime : 10:00:00 2015/02/06 to 11:00:00 2015/02/06
Accept status : Inactive
Key ID : 2
Key string : $c$3$t4qHAw1hpZYN0JKIEpXPcMFMVT81u0hiOw==
Algorithm : hmac-md5
Send lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Send status : Active
Accept lifetime : 11:00:00 2015/02/06 to 12:00:00 2015/02/06
Accept status : Active
Managing public keys
Overview
This chapter describes public key management for the following asymmetric key algorithms:
· Revest-Shamir-Adleman Algorithm (RSA).
· Digital Signature Algorithm (DSA).
· Elliptic Curve Digital Signature Algorithm (ECDSA).
Many security applications (for example, SSH) use asymmetric key algorithms to secure communications between two parties, as shown in Figure 16. Asymmetric key algorithms use two separate keys (one public and one private) for encryption and decryption. Symmetric key algorithms use only one key.
Figure 16 Encryption and decryption
A key owner can distribute the public key in plain text on the network but must keep the private key in privacy. It is mathematically infeasible to calculate the private key even if an attacker knows the algorithm and the public key.
The security applications use the asymmetric key algorithms for the following purposes:
· Encryption and decryption—Any public key receiver can use the public key to encrypt information, but only the private key owner can decrypt the information.
· Digital signature—The key owner uses the private key to digitally sign information to be sent. The receiver decrypts the information with the sender's public key to verify information authenticity.
RSA, DSA, and ECDSA can all perform digital signature, but only RSA can perform encryption and decryption.
Asymmetric key algorithms enable secure key distribution on an insecure network. The security strength of an asymmetric key varies by the key modulus length as with any symmetric key algorithm.
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
Creating a local key pair
When you create a local key pair, follow these guidelines:
· The key algorithm must be the same as required by the security application.
· When you create an RSA or DSA key pair, enter an appropriate key modulus length at the prompt. The longer the key modulus length, the higher the security, and the longer the key generation time.
When you create an ECDSA key pair, choose the appropriate elliptic curve. The elliptic curve determines the ECDSA key length. The longer the key length, the higher the security, and the longer the key generation time.
See Table 7 for more information about key modulus lengths and key lengths.
· If you do not assign the key pair a name, the system assigns the default name to the key pair and marks the key pair as default. You can also assign the default name to another key pair, but the system does not mark the key pair as default. The key pair name must be unique among all manually named key pairs that use the same key algorithm. If a name conflict occurs, the system asks whether you want to overwrite the existing key pair.
· The key pairs are automatically saved and can survive system reboots.
Table 7 A comparison of different types of asymmetric key algorithms
Type |
Generated key pairs |
Modulus/key length |
RSA |
· In non-FIPS mode: ? One host key pair, if you specify a key pair name. ? One
server key pair and one host key pair, if you do not specify a key pair name. · In FIPS mode: One host key pair. NOTE: Only SSH 1.5 uses the RSA server key pair. |
·
In non-FIPS mode: 512 to 2048 bits, 1024 bits
by default. · In FIPS mode: 2048 bits. |
DSA |
One host key pair. |
·
In non-FIPS mode: 512 to 2048 bits, 1024 bits. · In FIPS mode: 2048 bits. |
ECDSA |
One host key pair. |
· In non-FIPS mode: 192, 256, 384, or 521 bits. · In FIPS mode: 256, 384, or 521 bits. |
To create a local key pair:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a local key pair. |
·
In non-FIPS mode: ·
In FIPS mode: |
By default, no local key pairs exist. |
Distributing a local host public key
For applications such as SSH, you must distribute a local host public key to a peer device so the peer device can perform the following operations:
· Use the public key to encrypt information sent to the local device.
· Authenticate the digital signature signed by the local device.
To distribute a local host public key, you must first export or display the key.
· Export a host public key:
? Export a host public key to a file.
? Export a host public key to the monitor screen, and then save it to a file.
After the key is exported to a file, transfer the file to the peer device. On the peer device, import the key from the file.
· Display a host public key.
After the key is displayed, record the key, for example, copy it to an unformatted file. On the peer device, you must literally enter the key.
Exporting a host public key
When you export a host public key, follow these restrictions and guidelines:
· If you specify a file name in the command, the command exports the key to the specified file.
· If you do not specify a file name, the command exports the key to the monitor screen. You must manually save the exported key to a file.
To export a local host public key:
Step |
Command |
1. Enter system view. |
system-view |
2. Export a local host public key. |
· Export an RSA host public key: ? In
non-FIPS mode: ? In FIPS mode: ·
Export an ECDSA host public key: ·
Export a DSA host public key: |
Displaying a host public key
Perform the following tasks in any view:
Task |
Command |
Display local RSA public keys. |
display public-key local rsa public [ name key-name ] |
Display local ECDSA public keys. |
display public-key local ecdsa public [ name key-name ] |
Display local DSA public keys. |
display public-key local dsa public [ name key-name ] |
|
NOTE: Do not distribute the RSA server public key serverkey (default) to a peer device. |
Destroying a local key pair
To avoid key compromise, destroy the local key pair and generate a new pair after any of the following conditions occurs:
· An intrusion event has occurred.
· The storage media of the device is replaced.
To destroy a local key pair:
Step |
Command |
1. Enter system view. |
system-view |
2. Destroy a local key pair. |
public-key local destroy { dsa | ecdsa | rsa } [ name key-name ] |
Configuring a peer host public key
To encrypt information sent to a peer device or authenticate the digital signature of the peer device, you must configure the peer device's public key on the local device.
You can configure the peer host public key by using the following methods:
· Import the peer host public key from a public key file (recommended).
· Manually enter (type or copy) the peer host public key.
Importing a peer host public key from a public key file
Before you perform this task, make sure you have exported the host public key to a file on the peer device and obtained the file from the peer device. For information about exporting a host public key, see "Exporting a host public key."
After you import the key, the system automatically converts the imported public key to a string in the Public Key Cryptography Standards (PKCS) format.
To import a peer host public key from a public key file:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Import a peer host public key from a public key file. |
public-key peer keyname import sshkey filename |
By default, no peer host public keys exist. |
Entering a peer host public key
Before you perform this task, make sure you have displayed the key on the peer device and recorded the key. For information about displaying a host public key, see "Displaying a host public key."
Use the display public-key local public command to display the public key on the peer device. The format of the public key displayed in any other way might be incorrect. If the key is not in the correct format, the system discards the key and displays an error message. If the key is valid, the system saves the key.
Always import rather than enter the peer host public key if you are not sure whether the device supports the format of the recorded peer host public key.
To enter a peer host public key:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Specify a name for the peer host public key and enter public key view. |
public-key peer keyname |
By default, no peer host public keys exist. |
3. Type or copy the key. |
N/A |
You can use spaces and carriage returns, but the system does not save them. |
4. Return to system view. |
peer-public-key end |
When you exit public key view, the system automatically saves the peer host public key. |
Displaying and maintaining public keys
Execute display commands in any view.
Task |
Command |
Display local public keys. |
display public-key local { dsa | ecdsa | rsa } public [ name key-name ] |
Display peer host public keys. |
display public-key peer [ brief | name publickey-name ] |
Examples of public key management
Example for entering a peer host public key
Network requirements
As shown in Figure 17, to prevent illegal access, Device B authenticates Device A through a digital signature. Before configuring authentication parameters on Device B, configure the public key of Device A on Device B.
· Configure Device B to use the asymmetric key algorithm of RSA to authenticate Device A.
· Manually specify the host public key of Device A on Device B.
Configuration procedure
1. Configure Device A:
# Create local RSA key pairs with default names on Device A, and use the default modulus length 1024 bits.
<DeviceA> system-view
[DeviceA] public-key local create rsa
The range of public key modulus is (512 ~ 2048).
If the key modulus is greater than 512, it will take a few minutes.
Press CTRL+C to abort.
Input the modulus length [default = 1024]:
Generating Keys...
.................++++++
......................................++++++
.....++++++++
..............++++++++
Create the key pair successfully.
# Display all local RSA public keys.
[DeviceA] display public-key local rsa public
=============================================
Key name: hostkey (default)
Key type: RSA
Time when key pair created: 16:48:31 2011/05/12
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B
8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E
45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257
6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788
CB47440AF6BB25ACA50203010001
=============================================
Key name: serverkey (default)
Key type: RSA
Time when key pair created: 16:48:31 2011/05/12
Key code:
307C300D06092A864886F70D0101010500036B003068026100C9451A80F7F0A9BA1A90C7BC
1C02522D194A2B19F19A75D9EF02219068BD7FD90FCC2AF3634EEB9FA060478DD0A1A49ACE
E1362A4371549ECD85BA04DEE4D6BB8BE53B6AED7F1401EE88733CA3C4CED391BAE633028A
AC41C80A15953FB22AA30203010001
2. Configure Device B:
# Enter the host public key of Device A in public key view. The key must be literally the same as displayed on