Contents

Configuring AAA ··············································································1

Overview ·································································································································· 1
RADIUS ···························································································································· 2
HWTACACS ······················································································································ 6
LDAP ································································································································ 9
AAA implementation on the device ························································································ 12
AAA for VPNs ··················································································································· 14
RADIUS server feature of the device ····················································································· 14
Protocols and standards ····································································································· 15
RADIUS attributes ············································································································· 15
FIPS compliance······················································································································ 20
AAA configuration considerations and task list ··············································································· 20
Configuring local users ·············································································································· 21
Local user configuration task list ··························································································· 22
Configuring non-guest local user attributes ············································································· 22
Configuring local guest attributes ·························································································· 25
Configuring user group attributes ·························································································· 26
Managing local guests ········································································································ 26
Configuring the auto-delete feature of local users ····································································· 28
Displaying and maintaining local users and local user groups ····················································· 28
Configuring RADIUS schemes ···································································································· 28
Configuration task list ········································································································· 28
Configuring an EAP profile ·································································································· 29
Configuring a test profile for RADIUS server status detection ······················································ 30
Creating a RADIUS scheme ································································································ 31
Specifying the RADIUS authentication servers········································································· 31
Specifying the RADIUS accounting servers and the relevant parameters······································· 32
Specifying the shared keys for secure RADIUS communication ··················································· 33
Specifying an MPLS L3VPN instance for the scheme ································································ 33
Setting the username format and traffic statistics units ······························································ 34
Setting the maximum number of RADIUS request transmission attempts ······································ 34
Setting the status of RADIUS servers ···················································································· 35
Enabling forcibly sending stop-accounting packets ··································································· 36
Enabling the RADIUS server load sharing feature ···································································· 37
Specifying the source IP address for outgoing RADIUS packets ·················································· 37
Setting RADIUS timers ······································································································· 39
Configuring the RADIUS accounting-on feature ······································································· 40
Interpreting the RADIUS class attribute as CAR parameters ······················································· 40
Configuring the Login-Service attribute check method for SSH, FTP, and terminal users ·················· 41
Configuring the MAC address format for RADIUS attribute 31 ····················································· 41
Setting the data measurement unit for the Remanent_Volume attribute········································· 42
Enabling SNMP notifications for RADIUS ··············································································· 42
Displaying and maintaining RADIUS ······················································································ 42
Configuring HWTACACS schemes ······························································································ 43
Configuration task list ········································································································· 43
Creating an HWTACACS scheme ························································································· 43
Specifying the HWTACACS authentication servers ··································································· 44
Specifying the HWTACACS authorization servers ···································································· 44
Specifying the HWTACACS accounting servers ······································································· 45
Specifying the shared keys for secure HWTACACS communication ············································· 46
Specifying an MPLS L3VPN instance for the scheme ································································ 47
Setting the username format and traffic statistics units ······························································ 47
Specifying the source IP address for outgoing HWTACACS packets ············································ 47
Setting HWTACACS timers ································································································· 49
Displaying and maintaining HWTACACS ················································································ 50
Configuring LDAP schemes ······································································································· 51
Configuration task list ········································································································· 51

i
 Creating an LDAP server ···································································································· 51
Configuring the IP address of the LDAP server ········································································ 51
Specifying the LDAP version ································································································ 51
Setting the LDAP server timeout period ·················································································· 52
Configuring administrator attributes ······················································································· 52
Configuring LDAP user attributes ·························································································· 52
Configuring an LDAP attribute map ······················································································· 53
Creating an LDAP scheme ·································································································· 54
Specifying the LDAP authentication server·············································································· 54
Specifying the LDAP authorization server ··············································································· 54
Specifying an LDAP attribute map for LDAP authorization ·························································· 55
Displaying and maintaining LDAP ························································································· 55
Configuring AAA methods for ISP domains ···················································································· 55
Configuration prerequisites ·································································································· 55
Creating an ISP domain ······································································································ 55
Configuring ISP domain attributes ························································································· 56
Configuring authentication methods for an ISP domain ······························································ 58
Configuring authorization methods for an ISP domain ······························································· 59
Configuring accounting methods for an ISP domain ·································································· 60
Displaying and maintaining ISP domains ················································································ 61
Configuring the RADIUS session-control feature ············································································· 62
Configuring the RADIUS DAS feature ··························································································· 62
Changing the DSCP priority for RADIUS packets ············································································ 63
Configuring the RADIUS attribute translation feature ······································································· 63
Setting the maximum number of concurrent login users···································································· 65
Configuring a NAS-ID profile ······································································································ 65
Configuring the device ID··········································································································· 66
Configuring the RADIUS server feature ························································································ 66
Configuration restrictions and guidelines ················································································ 66
Configuration task list ········································································································· 66
Specifying RADIUS clients ·································································································· 66
Activating the RADIUS server configuration ············································································ 67
Displaying and maintaining RADIUS users and clients ······························································ 67
Configuring the connection recording policy ··················································································· 67
Overview ························································································································· 67
Configuration restrictions and guidelines ················································································ 68
Configuration procedure ····································································································· 68
Displaying and maintaining the connection recording policy ························································ 68
AAA configuration examples······································································································· 68
AAA for SSH users by an HWTACACS server ········································································· 68
Local authentication, HWTACACS authorization, and RADIUS accounting for SSH users ················· 70
Authentication and authorization for SSH users by a RADIUS server ············································ 72
Authentication for SSH users by an LDAP server ····································································· 75
AAA for 802.1X users by a RADIUS server ············································································· 79
Local guest configuration and management example ································································ 83
Authentication and authorization of 802.1X users by the device as a RADIUS server ······················· 85
Troubleshooting RADIUS··········································································································· 88
RADIUS authentication failure ······························································································ 88
RADIUS packet delivery failure ···························································································· 88
RADIUS accounting error ···································································································· 89
Troubleshooting HWTACACS ····································································································· 89
Troubleshooting LDAP ·············································································································· 89
LDAP authentication failure ································································································· 89

ii
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

Internet

Network

Remote user NAS RADIUS server

HWTACACS server

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, HWTACACS, and LDAP. 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.

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

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

3
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

From the client to the server. A packet of this type includes user
information for the server to authenticate the user. It must contain
1 Access-Request
the User-Name attribute and can optionally contain the attributes of
NAS-IP-Address, User-Password, and NAS-Port.
From the server to the client. If all attribute values included in the
2 Access-Accept Access-Request are acceptable, the authentication succeeds, and
the server sends an Access-Accept response.
From the server to the client. If any attribute value included in the
3 Access-Reject Access-Request is unacceptable, the authentication fails, and the
server sends an Access-Reject response.
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.
4 Accounting-Request
The Acct-Status-Type attribute in the packet indicates whether to
start or stop accounting.
From the server to the client. The server sends a packet of this type
5 Accounting-Response 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.

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

5
 No. Attribute No. Attribute

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 the 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
HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security
protocol based on TACACS (RFC 1492). HWTACACS is similar to RADIUS, and uses a client/server
model for information exchange between the NAS and the HWTACACS server.
HWTACACS typically provides AAA services for 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'

6
 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

Uses UDP, which provides high transport efficiency.
transmission.
Encrypts the entire packet except for the Encrypts only the user password field in an
HWTACACS header. authentication packet.
Protocol packets are complicated and authorization
Protocol packets are simple and the authorization
is independent of authentication. Authentication and
process is combined with the authentication
authorization can be deployed on different
process.
HWTACACS servers.
Supports authorization of configuration commands.
Does not support authorization of configuration
Access to commands depends on both the user's
commands. Access to commands solely depends on
roles and authorization. A user can use only
the user's roles. For more information about user
commands that are permitted by the user roles and
roles, see Fundamentals Configuration Guide.
authorized by the HWTACACS server.

Basic HWTACACS packet exchange process

Figure 6 describes how HWTACACS performs user authentication, authorization, and accounting for
a Telnet user.

7
Figure 6 Basic HWTACACS packet exchange process for a Telnet user
Host HWTACACS client HWTACACS server

1) The user tries to log in

2) Start-authentication packet

3) Authentication response requesting the username

4) Request for username

5) The user enters the username

6) Continue-authentication packet with the username

7) Authentication response requesting the password

8) Request for password

9) The user enters the password

10) Continue-authentication packet with the password

11) Response indicating successful authentication

12) User authorization request packet

13) Response indicating successful authorization

14) The user logs in successfully

15) Start-accounting request

16) Response indicating the start of accounting

17) The user logs off

18) Stop-accounting request

19) Stop-accounting response

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.

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

LDAP
The Lightweight Directory Access Protocol (LDAP) provides standard multiplatform directory service.
LDAP was developed on the basis of the X.500 protocol. It improves the following functions of X.500:
• Read/write interactive access.
• Browse.
• Search.
LDAP is suitable for storing data that does not often change. The protocol is used to store user
information. For example, LDAP server software Active Directory Server is used in Microsoft
Windows operating systems. The software stores the user information and user group information
for user login authentication and authorization.
LDAP directory service
LDAP uses directories to maintain the organization information, personnel information, and resource
information. The directories are organized in a tree structure and include entries. An entry is a set of
attributes with distinguished names (DNs). The attributes are used to store information such as
usernames, passwords, emails, computer names, and phone numbers.
LDAP uses a client/server model, and all directory information is stored in the LDAP server.
Commonly used LDAP server products include Microsoft Active Directory Server, IBM Tivoli
Directory Server, and Sun ONE Directory Server.
LDAP authentication and authorization
AAA can use LDAP to provide authentication and authorization services for users. LDAP defines a
set of operations to implement its functions. The main operations for authentication and authorization
are the bind operation and search operation.
• The bind operation allows an LDAP client to perform the following operations:
{ Establish a connection with the LDAP server.
{ Obtain the access rights to the LDAP server.
{ Check the validity of user information.
• The search operation constructs search conditions and obtains the directory resource
information of the LDAP server.
In LDAP authentication, the client completes the following tasks:

9
 1. Uses the LDAP server administrator DN to bind with the LDAP server. After the binding is
created, the client establishes a connection to the server and obtains the right to search.
2. Constructs search conditions by using the username in the authentication information of a user.
The specified root directory of the server is searched and a user DN list is generated.
3. Binds with the LDAP server by using each user DN and password. If a binding is created, the
user is considered legal.
In LDAP authorization, the client performs the same tasks as in LDAP authentication. When the
client constructs search conditions, it obtains both authorization information and the user DN list.
Basic LDAP authentication process
The following example illustrates the basic LDAP authentication process for a Telnet user.
Figure 7 Basic LDAP authentication process for a Telnet user

The following shows the basic LDAP authentication process:

1. A Telnet user initiates a connection request and sends the username and password to the
LDAP client.
2. After receiving the request, the LDAP client establishes a TCP connection with the LDAP
server.
3. To obtain the right to search, the LDAP client uses the administrator DN and password to send
an administrator bind request to the LDAP server.
4. The LDAP server processes the request. If the bind operation is successful, the LDAP server
sends an acknowledgment to the LDAP client.
5. The LDAP client sends a user DN search request with the username of the Telnet user to the
LDAP server.
6. After receiving the request, the LDAP server searches for the user DN by the base DN, search
scope, and filtering conditions. If a match is found, the LDAP server sends a response to notify
the LDAP client of the successful search. There might be one or more user DNs found.
7. The LDAP client uses the obtained user DN and the entered user password as parameters to
send a user DN bind request to the LDAP server. The server will check whether the user
password is correct.

10
 8. The LDAP server processes the request, and sends a response to notify the LDAP client of the
bind operation result. If the bind operation fails, the LDAP client uses another obtained user DN
as the parameter to send a user DN bind request to the LDAP server. This process continues
until a DN is bound successfully or all DNs fail to be bound. If all user DNs fail to be bound, the
LDAP client notifies the user of the login failure and denies the user's access request.
9. The LDAP client saves the user DN that has been bound and exchanges authorization packets
with the authorization server.
{ If LDAP authorization is used, see the authorization process shown in Figure 8.
{ If another method is expected for authorization, the authorization process of that method
applies.
10. After successful authorization, the LDAP client notifies the user of the successful login.
Basic LDAP authorization process
The following example illustrates the basic LDAP authorization process for a Telnet user.
Figure 8 Basic LDAP authorization process for a Telnet user

The following shows the basic LDAP authorization process:

1. A Telnet user initiates a connection request and sends the username and password to the
device. The device will act as the LDAP client during authorization.
2. After receiving the request, the device exchanges authentication packets with the
authentication server for the user:
{ If LDAP authentication is used, see the authentication process shown in Figure 7.
− If the device (the LDAP client) uses the same LDAP server for authentication and
authorization, skip to step 6.
− If the device (the LDAP client) uses different LDAP servers for authentication and
authorization, skip to step 4.
{ If another authentication method is used, the authentication process of that method applies.
The device acts as the LDAP client. Skip to step 3.
3. The LDAP client establishes a TCP connection with the LDAP authorization server.
4. To obtain the right to search, the LDAP client uses the administrator DN and password to send
an administrator bind request to the LDAP server.
5. The LDAP server processes the request. If the bind operation is successful, the LDAP server
sends an acknowledgment to the LDAP client.

11
 6. The LDAP client sends an authorization search request with the username of the Telnet user to
the LDAP server. If the user uses the same LDAP server for authentication and authorization,
the client sends the request with the saved user DN of the Telnet user to the LDAP server.
7. After receiving the request, the LDAP server searches for the user information by the base DN,
search scope, filtering conditions, and LDAP attributes. If a match is found, the LDAP server
sends a response to notify the LDAP client of the successful search.
8. After successful authorization, the LDAP client notifies the user of the successful login.

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 9 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:
• LAN—LAN users must pass 802.1X or MAC authentication to come online.
• Login—Login users include SSH, Telnet, FTP, and terminal users who log in to the device.
Terminal users can access through a console port.
• Portal—Portal users must pass portal authentication to access the network.
• ONU—ONU users must pass ONU authentication to access the network.

NOTE:
The device also provides authentication modules (such as 802.1X) for implementation of user
authentication management policies. If you configure these authentication modules, the ISP
domains for users of the access types depend on the configuration of the authentication modules.

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 whom no AAA methods are configured.

12
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, HWTACACS, or LDAP 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:
{ Non-login users can access the network.
{ 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, HWTACACS, or LDAP 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 who 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 who wants to obtain another user role
without logging out or getting disconnected. For more information about user role authentication,
see Fundamentals Configuration Guide.

13
AAA for VPNs
You can deploy AAA across VPNs to enable forwarding of authentication, authorization, and
accounting packets across VPNs. For example, as shown in Figure 10, the PE at the left side of the
MPLS backbone 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. Authentication packets
of private users in different VPNs do not affect each other.
Figure 10 Network diagram

This feature can also help an MCE to implement portal authentication for VPNs. For more
information about MCE, see MPLS Configuration Guide. For more information about portal
authentication, see "Configuring portal authentication."

RADIUS server feature of the device

Enable the RADIUS server feature of the device to work with RADIUS clients for user authentication
and authorization. The device can act as a dedicated RADIUS server or as both a RADIUS server
and a RADIUS client at the same time.
The RADIUS server feature provides for flexible networks with less cost. As shown in Figure 11,
Device A provides RADIUS server functions at the distribution layer; Device B and Device C are
configured with RADIUS schemes to implement user authentication and authorization at the access
layer.
Figure 11 Network diagram

The RADIUS server feature supports the following operations:

14
 • Manages RADIUS user data, which is generated from local user information and includes user
name, password, description, authorization ACL, authorization VLAN, and expiration time.
• Allows you to add, modify, and delete RADIUS clients. A RADIUS client is identified by the IP
address and includes attribute information such as the shared key. The RADIUS server feature
processes authentication requests only from the recorded RADIUS clients and ignores
requests from unknown clients.
• Authenticates and authorizes users of the network access type. The server does not provide
accounting.
When the RADIUS server receives a RADIUS packet, it performs the following actions:
1. Verifies that the packet is sent from a recorded RADIUS client.
2. Verifies the packet with the shared key.
3. Verifies that the user account exists, the password is correct, and other attributes meet the
requirements (for example, the account is in the validity period).
4. Determines the authentication result and authorizes specific privileges to the authenticated
user.
The RADIUS server feature of the device has the following restrictions:
• The authentication port is fixed at UDP 1812 and cannot be modified.
• The feature is supported on IPv4 networks, but not on IPv6 networks.
• The server provides only PAP and CHAP authentication methods.
• User names sent to the RADIUS server cannot include a domain name.

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
• RFC 1777, Lightweight Directory Access Protocol
• RFC 2251, Lightweight Directory Access Protocol (v3)

RADIUS attributes
Commonly used standard RADIUS attributes

No. Attribute Description

1 User-Name Name of the user to be authenticated.

User password for PAP authentication, only present in Access-Request
2 User-Password
packets when PAP authentication is used.
Digest of the user password for CHAP authentication, only present in
3 CHAP-Password
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

15
No. Attribute Description
only present in Access-Request packets.
5 NAS-Port Physical port of the NAS that the user accesses.
Type of service that the user has requested or type of service to be
6 Service-Type
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.
MTU for the data link between the user and NAS. For example, this
12 Framed-MTU attribute can be used to define the maximum size of EAP packets
allowed to be processed in 802.1X EAP authentication.
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.
Text to be displayed to the user, which can be used by the server to
18 Reply-Message communicate information, for example, the authentication failure
reason.
Vendor-specific proprietary attribute. A packet can contain one or more
26 Vendor-Specific proprietary attributes, each of which can contain one or more
subattributes.
Maximum service duration for the user before termination of the
27 Session-Timeout
session.
Maximum idle time permitted for the user before termination of the
28 Idle-Timeout
session.
User identification that the NAS sends to the server. For the LAN
31 Calling-Station-Id 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.
Type of the Accounting-Request packet. Possible values include:
• 1—Start.
• 2—Stop.
• 3—Interim-Update.
• 4—Reset-Charge.
40 Acct-Status-Type • 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.
Authentication method used by the user. Possible values include:
• 1—RADIUS.
45 Acct-Authentic
• 2—Local.
• 3—Remote.
CHAP challenge generated by the NAS for MD5 calculation during
60 CHAP-Challenge
CHAP authentication.
Type of the physical port of the NAS that is authenticating the user.
Possible values include:
61 NAS-Port-Type
• 15—Ethernet.
• 16—Any type of ADSL.

16
 No. Attribute Description
• 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.
Transport medium type to use for creating a tunnel.
65 Tunnel-Medium-Type For VLAN assignment, the value must be 6 to indicate the 802 media
plus Ethernet.
Used to encapsulate EAP packets to allow RADIUS to support EAP
79 EAP-Message
authentication.
Used for authentication and verification of authentication packets to
80 Message-Authenticator prevent spoofing Access-Requests. This attribute is present when EAP
authentication is used.
Group ID for a tunnel session. To assign VLANs, the NAS conveys
81 Tunnel-Private-Group-ID
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 proprietary RADIUS subattributes with a vendor ID of 25506. Support for these
subattributes depends on the device model.
Table 4 Proprietary 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.
Total amount of data available for the connection, in different units for
15 Remanent_Volume
different server types.
17 ISP-ID ISP domain where the user obtains authorization information.
Operation for the session, used for session control. Possible values
include:
• 1—Trigger-Request.
20 Command • 2—Terminate-Request.
• 3—SetPolicy.
• 4—Result.
• 5—PortalClear.
Result of the Trigger-Request or SetPolicy operation, zero for success
25 Result_Code
and any other value for failure.
26 Connect_ID Index of the user connection.

17
No. Subattribute Description

FTP, SFTP, or SCP user working directory.

28 Ftp_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.
Startup time of the NAS in seconds, which is represented by the time
59 NAS_Startup_Timestamp
elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
User IP address and MAC address included in authentication and
60 Ip_Host_Addr 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.
Information that must be sent from the server to the client
61 User_Notify
transparently.
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
62 User_HeartBeat NAS and verifies the handshake packets from the 802.1X user. This
attribute only exists in Access-Accept and Accounting-Request
packets.
IP address of the multicast group that the user's host joins as a
98 Multicast_Receive_Group receiver. This subattribute can appear multiple times in a multicast
packet to indicate that the user belongs to multiple multicast groups.
IPv6 address of the multicast group that the user's host joins as a
IP6_Multicast_Receive_G
100 receiver. This subattribute can appear multiple times in a multicast
roup
packet to indicate that the user belongs to multiple multicast groups.
Maximum number of MLD multicast groups that the user can join
101 MLD-Access-Limit
concurrently.
102 local-name L2TP local tunnel name.
Maximum number of IGMP multicast groups that the user can join
103 IGMP-Access-Limit
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.
Bytes of IPv6 packets in the inbound direction. The measurement unit
144 Acct_IPv6_Input_Octets
depends on the configuration on the device.
Bytes of IPv6 packets in the outbound direction. The measurement unit
145 Acct_IPv6_Output_Octets
depends on the configuration on the device.
Number of IPv6 packets in the inbound direction. The measurement
146 Acct_IPv6_Input_Packets
unit depends on the configuration on the device.
Acct_IPv6_Output_Packe Number of IPv6 packets in the outbound direction. The measurement
147
ts unit depends on the configuration on the device.
Acct_IPv6_Input_Gigawor Bytes of IPv6 packets in the inbound direction. The measurement unit
148
ds is 4G bytes.
Acct_IPv6_Output_Gigaw Bytes of IPv6 packets in the outbound direction. The measurement unit
149
ords is 4G bytes.
Vendor-specific attribute pair. Available attribute pairs include:
210 Av-Pair • Dynamically assigned WEP key in the format of
leap:session-key=xxx.

18
No. Subattribute Description
• 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.
• Server-deployed command to reboot a port, in the format of
subscriber:command=bounce-host-port.
• Server-assigned port shutdown duration in the format of
bounce:seconds=xxx.
• Server-deployed command to shut down a port, in the format of
subscriber:command=disable-host-port.
• Server-assigned VSI in the format of vxlan:vsi-name=xxx.
• VSI-based ACL resource assignment capability in the format of
ACL:match-by-vsiindex=x. Value 1 of x indicates that this feature
is supported, and the other values of x are reserved.
• Server-assigned blackhole MAC address attribute in the format of
mac:block-mac=xxx.
• Server-assigned MAC authentication offline detect timer (in
seconds) in the format of mac-authentication:
offline-detect-time=xxx. Value 0 of xxx indicates that MAC
authentication offline detection is disabled.
• Server-assigned MAC authentication offline detection flag in the
format of mac-authentication: offline-detect-check=x. x has the
following values:
{ 0—The device does not search for the ARP snooping entry or
ND snooping entry of the MAC address.
{ 1—The device searches for the ARP snooping entry or ND
snooping entry of the MAC address.
230 Nas-Port Interface through which the user is connected to the NAS.
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
246 Auth_Detail_Result
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.
Committed burst size from the user to the NAS, in bits. The total length
Input-Committed-Burst-Si cannot exceed 4 bytes for this field.
247
ze This subattribute must be assigned together with the
Input-Average-Rate attribute.
Committed burst size from the NAS to the user, in bits. The total length
Output-Committed-Burst- cannot exceed 4 bytes for this field.
248
Size This subattribute must be assigned together with the
Output-Average-Rate attribute.
Authentication type. The value can be:
• 1—Intranet access authentication.
249 authentication-type • 2—Internet access authentication.
If the packet does not contain this subattribute, common authentication
applies.

19
 No. Subattribute Description

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, HWTACACS, and LDAP
schemes.
2. Configure AAA methods for the users' ISP domains. Remote AAA methods need to use the
configured RADIUS, HWTACACS, and LDAP schemes.
Figure 12 AAA configuration procedure

Local AAA

Configure AAA methods for

different types of users or/and
Configure local users and related the default methods for all
attributes types of users

Authentication method
none/ local (the default)/scheme

Create an ISP domain +

No AAA and enter ISP domain
view Authorization method
none/ local (the default)/scheme

Accounting method
Configure the RADIUS, HWTACACS, none/ local (the default)/scheme
or LDAP schemes to be used

Remote AAA

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:
• Configuring local users

20
 Tasks at a glance
• Configuring RADIUS schemes
• Configuring HWTACACS schemes
• Configuring LDAP 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
{ Configuring authorization methods for an ISP domain
{ Configuring accounting 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
(Optional.) Configuring the RADIUS server feature
(Optional.) Configuring the connection recording policy

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.
Local users are classified into the following types:
• Device management user—User who logs in to the device for device management.
• Network access user—User who accesses network resources through the device. Network
access users also include guests who access the network temporarily. Guests can use only
LAN and portal services.
The following shows the configurable local user attributes:
• Description—Descriptive information of the user.
• 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, LAN access, ONU, portal, 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
who 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.

21
 • 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."
• Binding attributes—Binding attributes control the scope of users, and are checked during
local authentication of a user. If the attributes of a user do not match the binding attributes
configured for the local user account, the user cannot pass authentication. Binding attributes
include the IP address, access port, MAC address, and native VLAN. For support and usage
information about binding attributes, see "Configuring non-guest local user attributes."
• Authorization attributes—Authorization attributes indicate the user's rights after it passes
local authentication. For support information about authorization attributes, see "Configuring
non-guest 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
local 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."
• Validity period—Time period in which a network access user is considered valid for
authentication.

Local user configuration task list

Tasks at a glance

(Required.) Configure local user attributes based on the user type:

• Configuring non-guest local user attributes
• Configuring local guest attributes
(Optional.) Configuring user group attributes
(Optional.) Managing local guests
(Optional.) Configuring the auto-delete feature of local users

Configuring non-guest local user attributes

Non-guest local user attributes apply to all local users except guests. When you configure non-guest
local user attributes, follow these guidelines:
• If password control is enabled globally by using the password-control enable command, the
device does not display local user passwords or retain them in the running configuration. When
you globally disable the password control feature, local user passwords are automatically
restored to the running configuration. To display the running configuration, use the display
current-configuration command.
• 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.

22
• Configure the location binding attribute based on the service types of users.
{ For 802.1X users, specify the 802.1X-enabled Layer 2 Ethernet interfaces or Layer 2
aggregate interfaces through which the users access the device.
{ For MAC authentication users, specify the MAC authentication-enabled Layer 2 Ethernet
interfaces or Layer 2 aggregate interfaces through which the users access the device.
{ For Web authentication users, specify Web authentication-enabled Layer 2 Ethernet
interfaces through which the users access the device.
{ For portal users, specify the portal-enabled interfaces through which the users access the
device. Specify the Layer 2 Ethernet interfaces if portal is enabled on VLAN interfaces and
the portal roaming enable command is not configured.
To configure non-guest local user attributes:

Step Command Remarks

1. Enter system view. system-view N/A
2. Add a local user and local-user user-name [ class
enter local user view. By default, no local users exist.
{ manage | network } ]
The default settings are as follows:
• For a network access user: • In non-FIPS mode, no password is
password { cipher | simple } configured for a local user. A local
string user can pass authentication after
• For a device management entering the correct username and
3. (Optional.) Configure passing attribute checks.
user:
a password for the
local user. { In non-FIPS mode: • In FIPS mode, no password is
password [ { hash | configured for a local user. A local
simple } string ] user cannot pass authentication.
{ In FIPS mode: As a best practice to enhance security,
password configure a password for each local
user.
By default, no description is configured
4. (Optional.) Configure for a local user.
a description for the description text
local user. You can configure descriptions only for
network access users.
• For a network access user:
service-type { lan-access |
onu | portal }
• For a device management
user:
5. Assign services to the { In non-FIPS mode: By default, no services are authorized to
local user. service-type { ftp | { http | a local user.
https | ssh | telnet |
terminal } * }
{ In FIPS mode:
service-type { https | ssh
| terminal } *
6. (Optional.) Place the
local user to the active By default, a local user is in active state
state { active | block }
or blocked state. and can request network services.

By default, the number of concurrent

7. (Optional.) Set the logins is not limited for the local user.
upper limit of This command takes effect only when
concurrent logins access-limit max-user-number local accounting is configured for the
using the local user local user. It does not apply to FTP,
name. SFTP, or SCP users, who do not
support accounting.

23
Step Command Remarks

8. (Optional.) Configure bind-attribute { ip ip-address |

binding attributes for location interface interface-type By default, no binding attributes are
the local user. interface-number | mac configured for a local user.
mac-address | vlan vlan-id } *
The following default settings apply:
• The working directory for FTP,
SFTP, and SCP users is the root
directory of the NAS. However, the
authorization-attribute { acl users do not have permission to
acl-number | idle-cut minutes | access the root directory.
9. (Optional.) Configure
authorization ip-pool ipv4-pool-name | • The network-operator user role is
attributes for the local ipv6-pool ipv6-pool-name | assigned to local users that are
user. session-timeout minutes | created by a network-admin or
user-role role-name | vlan vlan-id | level-15 user on the default MDC.
work-directory directory-name } * • The mdc-operator user role is
assigned to local users that are
created by an mdc-admin or
level-15 user on a non-default
MDC.
• Set the password aging time:
password-control aging
aging-time
• Set the minimum password
length:
password-control length
length
• Configure the password
composition policy:
password-control
composition type-number
10. (Optional.) Configure type-number [ type-length
password control type-length ] By default, the local user uses password
attributes for the local control attributes of the user group to
• Configure the password which the local user belongs.
user. complexity checking policy:
password-control
complexity
{ same-character |
user-name } check
• Configure the maximum login
attempts and the action to
take if there is a login failure:
password-control
login-attempt login-times
[ exceed { lock | lock-time
time | unlock } ]
11. (Optional.) Assign the
local user to a user By default, a local user belongs to the
group group-name
group. user group system.

validity-datetime { from start-date

12. (Optional.) Configure start-time to expiration-date By default, a local user does not expire.
the validity period for expiration-time | from start-date You can configure validity periods only
the local user. start-time | to expiration-date for network access users.
expiration-time }

24
Configuring local guest attributes
Create local guests and configure guest attributes to control temporary network access behavior.
Guests can access the network after passing local authentication. You can configure the recipient
addresses and email attribute information to the local guests and guest sponsors.
To configure local guest attributes:

Step Command Remarks

1. Enter system view. system-view N/A
2. Create a local guest and local-user user-name class
enter local guest view. By default, no local guests exist.
network guest
3. Configure a password for the password { cipher | simple } By default, no password is
local guest. string configured for a local guest.
4. Configure a description for By default, no description is
the local guest. description text
configured for a local guest.
5. Specify the name of the local By default, no name is specified for a
guest. full-name name-string
local guest.
6. Specify the company of the By default, no company is specified
local guest. company company-name
for a local guest.
7. Specify the phone number of By default, no phone number is
the local guest. phone phone-number
specified for a local guest.
By default, no email address is
specified for a local guest.
8. Specify the email address of
the local guest. email email-string The device sends email notifications
to this address to inform the guest of
the account information.
9. Specify the sponsor name for sponsor-full-name By default, no sponsor name is
the local guest. name-string specified for a local guest.
10. Specify the sponsor
department for the local sponsor-department By default, no sponsor department is
guest. department-string specified for a local guest.

By default, no sponsor email

address is specified for a local
11. Specify the sponsor email guest.
address for the local guest. sponsor-email email-string
The device sends email notifications
to this address to inform the sponsor
of the guest information.
validity-datetime { from By default, a local guest does not
12. Configure the validity period start-date start-time to expire.
for the local guest. expiration-date expiration-time |
from start-date start-time | to Expired guests cannot pass local
expiration-date expiration-time } authentication.

13. Assign the local guest to a By default, a local guest belongs to

user group. group group-name the system-defined user group
system.

14. Configure the local guest By default, a local guest is in active

status. state { active | block } state and is allowed to request
network services.

25
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 By default, a system-defined

enter user group view. user-group group-name user group exists. The group
name is system.
authorization-attribute { acl
acl-number | idle-cut minutes |
3. Configure authorization ip-pool ipv4-pool-name | ipv6-pool By default, no authorization
attributes for the user ipv6-pool-name | session-timeout attributes are configured for a
group. minutes | user-role role-name | vlan user group.
vlan-id | work-directory
directory-name } *
• Set the password aging time:
password-control aging
aging-time
• Set the minimum password
length:
password-control length
length
• Configure the password
composition policy:
password-control
composition type-number By default, the user group uses
4. (Optional.) Configure type-number [ type-length the global password control
password control attributes type-length ] settings. For more information,
for the user group. • Configure the password see "Configuring password
complexity checking policy: control."
password-control complexity
{ same-character |
user-name } check
• Configure the maximum login
attempts and the action to take
for login failures:
password-control
login-attempt login-times
[ exceed { lock | lock-time time
| unlock } ]

Managing local guests

The local guest management features are for maintenance and access control of local guests.
The device provides the following local guest management features:

26
• Local guest creation—Allows to manually create local guests and configure guest account
attributes, including user name, password, and email address.
• Email notification—The device notifies the local guests or guest sponsors by email of the
guest account information.
• Local guest creation in batch—Create a batch of local guests.
• Local guest import—Import guest account information from a .csv file to create local guests
on the device based on the imported information.
• Local guest export—Export local guest account information to a .csv file. You can import the
account information to other devices as needed.
To manage local guests:

Step Command Remarks

1. Enter system view system-view N/A
By default, no subject and body
local-guest email format to are configured.
2. Configure the subject and { guest | manager | sponsor }
body of email notifications. { body body-string | subject The manager keyword is not
sub-string } supported in the current software
version.
3. Configure the email sender
address in the email By default, no email sender
local-guest email sender
notifications sent by the address is configured for the email
email-address
device for local guests. notifications sent by the device.

4. Specify an SMTP server for

sending email notifications of local-guest email smtp-server By default, no SMTP server is
local guests. url-string specified.

5. (Optional.) Import guest local-user-import class network

account information from guest url url-string
a .csv file in the specified validity-datetime start-date
path to create local guests start-time to expiration-date N/A
based on the imported expiration-time
information. [ auto-create-group | override |
start-line line-number ] *
local-guest generate
username-prefix name-prefix
[ password-prefix
Batch generated local guests
6. (Optional.) Create local password-prefix ] suffix
share the same name prefix. You
guests in batch. suffix-number [ group
can also configure a password
group-name ] count user-count
prefix to be shared by the guests.
validity-datetime start-date
start-time to expiration-date
expiration-time
7. (Optional.) Export local guest
account information to a .csv local-user-export class network
N/A
file in the specified path. guest url url-string

8. Return to user view. quit N/A

9. (Optional.) Send email local-guest send-email The email contents include the
notifications to the local user-name user-name to { guest user name, password, and validity
guest or the guest sponsor. | sponsor } period of the guest account.

27
Configuring the auto-delete feature of local users
This feature enables the device to examine the validity of local users at fixed time periods of 10
minutes and automatically delete expired local users.
To configure the auto-delete feature of local users:

Step Command Remarks

1. Enter system view system-view N/A
2. Enable the local user
auto-delete feature. local-user auto-delete enable By default, the feature is disabled.

Displaying and maintaining local users and local user groups

Execute display commands in any view.

Task Command

display local-user [ class { manage | network [ guest ] } | idle-cut

Display the local user
{ disable | enable } | service-type { ftp | http | https | lan-access | onu |
configuration and online user
portal | ssh | telnet | terminal } | state { active | block } | user-name
statistics.
user-name class { manage | network [ guest ] } | vlan vlan-id ]
Display the user group
display user-group { all | name group-name }
configuration information.

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 host names, IP addresses, UDP port numbers, shared keys, and server types.

Configuration task list

If the authentication server in a RADIUS scheme is provided by the RADIUS server feature on the
device, the RADIUS scheme only includes the following settings:
• RADIUS authentication server.
• Shared key for RADIUS communication.
• Username format for interaction with the RADIUS server.
Tasks for other settings are ignored.
To configure RADIUS schemes, perform the following tasks:

Tasks at a glance

(Optional.) Configuring an EAP profile

(Optional.) Configuring a test profile for RADIUS server status detection
(Required.) Creating a RADIUS scheme
(Required.) Specifying the RADIUS authentication servers

28
 Tasks at a glance

(Optional.) Specifying the RADIUS accounting servers and the relevant parameters
(Optional.) Specifying the shared keys for secure RADIUS communication
(Optional.) Specifying an MPLS L3VPN instance for the scheme
(Optional.) Setting the username format and traffic statistics units
(Optional.) Setting the maximum number of RADIUS request transmission attempts
(Optional.) Setting the status of RADIUS servers
(Optional.) Enabling forcibly sending stop-accounting packets
(Optional.) Enabling the RADIUS server load sharing feature
(Optional.) Specifying the source IP address for outgoing RADIUS packets
(Optional.) Setting RADIUS timers
(Optional.) Configuring the RADIUS accounting-on feature
(Optional.) Interpreting the RADIUS class attribute as CAR parameters
(Optional.) Configuring the Login-Service attribute check method for SSH, FTP, and terminal users
(Optional.) Configuring the MAC address format for RADIUS attribute 31
(Optional.) Setting the data measurement unit for the Remanent_Volume attribute
(Optional.) Enabling SNMP notifications for RADIUS

Configuring an EAP profile

An EAP profile is a collection of EAP authentication settings, including the EAP authentication
method and the CA certificate file. You can specify an EAP profile in a test profile for RADIUS server
status detection. EAP-based RADIUS server status detection provides more reliable server status
detection results than simple server status detection.
When you configure an EAP profile, follow these restrictions and guidelines:
• Before you specify a CA certificate file, use FTP or TFTP to transfer the CA certificate file to the
root directory of the default storage medium on the device. In an IRF fabric, make sure the CA
certificate file already exists in the root directory of the default storage medium on the master
device.
• You can specify an EAP profile in multiple test profiles.
• You can configure a maximum of 16 EAP profiles.
To configure an EAP profile:

Step Command Remarks

1. Enter system view. system-view N/A
2. Create an EAP profile and
enter EAP profile view. eap-profile eap-profile-name By default, no EAP profiles exist.

3. Specify the EAP method { md5 | peap-gtc |

By default, the EAP authentication
authentication method. peap-mschapv2 | ttls-gtc |
method is MD5-challenge.
ttls-mschapv2 }
By default, no CA certificate file is
4. Specify a CA certificate file
ca-file file-name specified for EAP authentication.
for EAP authentication.
You must specify a CA certificate

29
 Step Command Remarks
file to verify the RADIUS server
certificate if the EAP
authentication method is
PEAP-GTC, PEAP-MSCHAPv2,
TTLS-GTC, or TTLS-MSCHAPv2.

Configuring a test profile for RADIUS server status detection

Overview
To detect the reachability or availability of a RADIUS authentication server, specify a test profile for
the RADIUS server when you specify the server in a RADIUS scheme. With the test profile, the
device refreshes the RADIUS server status at each detection interval according to the detection
result. If the server is unreachable or unavailable, the device sets the status of the server to blocked.
If the server is reachable or available, the device sets the status of the server to active.
The device supports the following RADIUS server status detection methods:
• Simple detection—For a RADIUS server, the device simulates an authentication request with
the username and password specified in the test profile used by the server. The authentication
request is sent to the RADIUS server within each detection interval. The device determines that
the RADIUS server is reachable if the device receives a response from the server within the
interval.
• EAP-based detection—For a RADIUS server, the device simulates an EAP authentication
with the username and password specified in the test profile used by the server. The simulated
EAP authentication starts at the beginning of each detection interval. If the EAP authentication
completes within a detection interval, the device determines that the RADIUS server is
available.
Simulating a complete EAP authentication process, EAP-based detection provides more reliable
detection results than simple detection. As a best practice, configure EAP-based detection on a
network environment where EAP authentication is configured.
Configuration restrictions and guidelines
When you configure test profiles for RADIUS server status detection, follow these restrictions and
guidelines:
• You can configure multiple test profiles in the system.
• The device starts detecting the status of a RADIUS authentication server only if an existing test
profile is specified for the server.
• If you specify a nonexistent EAP profile in a test profile, the device performs simple detection for
the RADIUS servers that use the test profile. After the EAP profile is configured, the device will
start EAP-based detection at the next detection interval.
• The device stops detecting the status of a RADIUS server when one of the following operations
is performed:
{ The RADIUS server is removed from the RADIUS scheme.
{ The test profile configuration for the RADIUS server is removed in RADIUS scheme view.
{ The test profile specified for the RADIUS server is deleted.
{ The RADIUS server is manually set to the blocked state.
{ The RADIUS scheme that contains the RADIUS server is deleted.
Configuration procedure
To configure a test profile for RADIUS server status detection:

30
 Step Command Remarks
1. Enter system view. system-view N/A

2. Configure a test profile for radius-server test-profile

profile-name username name By default, no test profiles exist.
detecting the status of
RADIUS authentication [ password { cipher | simple } You can configure multiple test
servers. string ] [ interval interval ] profiles in the system.
[ eap-profile eap-profile-name ]

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 radius scheme By default, no RADIUS schemes
view. radius-scheme-name 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

• Specify the primary RADIUS By default, no authentication

authentication server: servers are specified.
primary authentication
3. Specify RADIUS { host-name | ipv4-address | ipv6 To support server status detection,
authentication servers. ipv6-address } [ port-number | specify an existing test profile for
key { cipher | simple } string | the RADIUS authentication server.
test-profile profile-name | If the test profile does not exist, the
vpn-instance device cannot detect the server

31
 Step Command Remarks
vpn-instance-name | weight status.
weight-value ] * Two authentication servers in a
• Specify a secondary RADIUS scheme, primary or secondary,
authentication server: cannot have the same
secondary authentication combination of host name, IP
{ host-name | ipv4-address | ipv6 address, port number, and VPN
ipv6-address } [ port-number | instance.
key { cipher | simple } string |
The weight keyword takes effect
test-profile profile-name |
only when the RADIUS server load
vpn-instance
sharing feature is enabled for the
vpn-instance-name | weight
RADIUS scheme.
weight-value ] *

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.
If you specify a maximum number of realtime accounting attempts, the device will disconnect users
from whom no accounting responses are received within the permitted attempts.
The device sends RADIUS stop-accounting requests when it receives connection teardown requests
from hosts or connection teardown commands from an administrator. However, the device might fail
to receive a response for a stop-accounting request in a single transmission. Enable the device to
buffer RADIUS stop-accounting requests that have not received responses from the accounting
server. The device will resend the requests until responses are received.
To limit the transmission times, set a maximum number of transmission attempts that can be made
for individual RADIUS stop-accounting requests. When the maximum attempts are made for a
request, the device discards the buffered request.
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

• Specify the primary RADIUS By default, no accounting

accounting server: servers are specified.
3. Specify RADIUS accounting primary accounting { host-name Two accounting servers in a
servers. | ipv4-address | ipv6 scheme, primary or
ipv6-address } [ port-number | key secondary, cannot have the
{ cipher | simple } string | same combination of host
vpn-instance vpn-instance-name name, IP address, port

32
 Step Command Remarks
| weight weight-value ] * number, and VPN instance.
• Specify a secondary RADIUS The weight keyword takes
accounting server: effect only when the RADIUS
secondary accounting server load sharing feature is
{ host-name | ipv4-address | ipv6 enabled for the RADIUS
ipv6-address } [ port-number | key scheme.
{ cipher | simple } string |
vpn-instance vpn-instance-name
| weight weight-value ] *
4. (Optional.) Set the maximum
number of real-time retry realtime-accounting retries The default setting is 5.
accounting attempts.
5. (Optional.) Enable buffering
of RADIUS stop-accounting
requests to which no By default, the buffering
stop-accounting-buffer enable
responses have been feature is enabled.
received.
6. (Optional.) Set the maximum
number of transmission
attempts for individual retry stop-accounting retries The default setting is 500.
RADIUS stop-accounting
requests.

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 radius scheme
view. N/A
radius-scheme-name
By default, no shared key is
specified for secure RADIUS
3. Specify a shared key for key { accounting | communication.
secure RADIUS authentication } { cipher | simple } The shared key configured on the
communication. string 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.

33
 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

N/A
radius-scheme-name

3. Specify a VPN instance for the By default, a RADIUS

RADIUS scheme. vpn-instance vpn-instance-name 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

N/A
radius-scheme-name
By default, the ISP domain name
is included in a username.
3. Set the format for usernames user-name-format
{ keep-original | with-domain | If the device is specified as the
sent to the RADIUS servers. RADIUS server in the scheme, the
without-domain }
username format must be
without-domain.
data-flow-format { data { byte |
4. (Optional.) Set the data flow giga-byte | kilo-byte |
and packet measurement By default, traffic is counted in
mega-byte } | packet
units for traffic statistics. bytes and packets.
{ giga-packet | kilo-packet |
mega-packet | one-packet } }*

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

34
 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

N/A
radius-scheme-name
3. Set the maximum number of
RADIUS request transmission retry retries The default setting is 3.
attempts.

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.

35
 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

• Set the status of the primary

RADIUS authentication server:
state primary authentication
{ active | block }
• Set the status of the primary
RADIUS accounting server:
state primary accounting { active By default, a RADIUS server
| block } is in active state.
• Set the status of a secondary The configured server status
RADIUS authentication server: cannot be saved to any
3. Set the RADIUS server state secondary authentication configuration file, and can
status. [ { host-name | ipv4-address | ipv6 only be viewed by using the
ipv6-address } [ port-number | display radius scheme
vpn-instance vpn-instance-name ] command. After the device
* ] { active | block } restarts, all servers are
• Set the status of a secondary restored to the active state.
RADIUS accounting server:
state secondary accounting
[ { host-name | ipv4-address | ipv6
ipv6-address } [ port-number |
vpn-instance vpn-instance-name ]
* ] { active | block }

Enabling forcibly sending stop-accounting packets

Typically, if the device does not send a start-accounting packet to the RADIUS server for an
authenticated user, it does not send a stop-accounting packet when the user goes offline. If the
server has generated a user entry for the user without start-accounting packets, it does not release
the user entry when the user goes offline. This feature forces the device to send stop-accounting
packets to the RADIUS server when the user goes offline for timely releasing the user entry on the
server.
To enable forcibly sending stop-accounting packets:

Step Command Remarks

1. Enter system view. system-view N/A
2. Enter RADIUS scheme radius scheme radius-scheme-name N/A

36
 Step Command Remarks
view.
By default, forcibly sending
3. Enable the device to send stop-accounting packets is
stop-accounting packets disabled. The device does
when users for which no stop-accounting-packet send-force not send stop-accounting
start-accounting packets packets when users for
are sent go offline. which no start-accounting
packets are sent go offline.

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 radius scheme
view. N/A
radius-scheme-name
3. Enable the RADIUS
server load sharing server-load-sharing enable By default, this feature is disabled.
feature.

Specifying the source IP address for outgoing RADIUS

packets
Overview
A RADIUS server identifies a NAS by its IP address. Upon receiving a RADIUS packet, the RADIUS
server checks the source IP address of the packet.
• 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.
Before sending a RADIUS packet, the NAS selects a source IP address for the packet 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.

37
 3. The IP address of the outbound interface specified by the route.
Configuration restrictions and guidelines
When you specify the source IP address for outgoing RADIUS packets, follow these restrictions and
guidelines:
• 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 for the specified
VPN or the public network.
The setting in RADIUS scheme view takes precedence over the setting in system view.
• The source IP address of RADIUS packets that a NAS sends must match the IP address of the
NAS that is configured on the RADIUS server.
• As a best practice, specify a loopback interface address as the source IP address for outgoing
RADIUS packets to avoid RADIUS packet loss caused by physical port errors.
• The source IP 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 IP address.
• You can directly specify a source IP address for outgoing RADIUS packets or specify a source
interface to provide the source IP address for outgoing RADIUS packets. The source interface
configuration and the source IP address configuration overwrite each other.
Configuration procedure
To specify a source interface or 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
radius nas-ip { interface By default, the source IP address
2. Specify a source interface or interface-type interface-number | of an outgoing RADIUS packet is
source IP address for { ipv4-address | ipv6 the primary IPv4 address or the
outgoing RADIUS packets. ipv6-address } [ vpn-instance IPv6 address of the outbound
vpn-instance-name ] } interface.

To specify a source interface or 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

N/A
radius-scheme-name
By default, the source IP
address of an outgoing RADIUS
3. Specify a source interface or packet is that specified by using
nas-ip { ipv4-address | interface
source IP address for the radius nas-ip command in
interface-type interface-number |
outgoing RADIUS packets. system view. If this command is
ipv6 ipv6-address }
not used, the source IP address
is the primary IP address of the
outbound interface.

38
Setting RADIUS timers
Overview
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.
Configuration restrictions and guidelines
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.
Configuration procedure
To set RADIUS timers:

Step Command Remarks

1. Enter system view. system-view N/A

2. Enter RADIUS scheme view. radius scheme

N/A
radius-scheme-name
3. Set the RADIUS server timer response-timeout
response timeout timer. The default setting is 3 seconds.
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 realtime-accounting

timer. The default setting is 12 minutes.
interval [ second ]

39
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.
The extended accounting-on feature is applicable to LAN users. The user data is saved to the cards
through which the users access the device. When the extended accounting-on feature is enabled,
the device automatically sends an accounting-on packet to the RADIUS server after a card reboots.
The packet contains the card identifier. Upon receiving the accounting-on packet, the RADIUS
server logs out all online users who access the device through the card. If no users have come online
through the card, the device does not send an accounting-on packet to the RADIUS server after the
card reboots.
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

N/A
radius-scheme-name

3. Enable accounting-on. accounting-on enable [ interval By default, the accounting-on

interval | send send-times ] * feature is disabled.
4. (Optional.) Enable extended By default, extended
accounting-on. accounting-on 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

N/A
radius-scheme-name

3. Interpret the RADIUS class By default, the RADIUS class

attribute as CAR parameters. attribute 25 car attribute is not interpreted as
CAR parameters.

40
Configuring the Login-Service attribute check method for
SSH, FTP, and terminal users
The device supports the following check methods for the Login-Service attribute (RADIUS attribute
15) of 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

N/A
radius-scheme-name
3. Configure the Login-Service
attribute check method for attribute 15 check-mode { loose | The default check method is
SSH, FTP, and terminal strict } strict.
users.

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

N/A
radius-scheme-name
By default, a MAC address is in
3. Configure the MAC address attribute 31 mac-format section the format of
format for RADIUS attribute { six | three } separator HH-HH-HH-HH-HH-HH. The
31. separator-character { lowercase | MAC address is separated by
uppercase } hyphen (-) into six sections with
letters in upper case.

41
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 radius scheme
view. N/A
radius-scheme-name
3. Set the data measurement
unit for the attribute remanent-volume unit
By default, the data measurement
Remanent_Volume { byte | giga-byte | kilo-byte |
unit is kilobyte.
attribute. mega-byte }

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
snmp-agent trap enable radius
[ accounting-server-down |
2. Enable SNMP notifications accounting-server-up | By default, all SNMP notifications
for RADIUS. authentication-error-threshold | are disabled for RADIUS.
authentication-server-down |
authentication-server-up ] *

Displaying and maintaining RADIUS

Execute display commands in any view and reset commands in user view.

42
 Task Command

Display the RADIUS scheme

display radius scheme [ radius-scheme-name ]
configuration.
Display authentication and accounting
display radius server-load statistics
load statistics on all RADIUS servers.
Display RADIUS packet statistics. display radius statistics
Display information about buffered
display stop-accounting-buffer { radius-scheme
RADIUS stop-accounting requests to
radius-scheme-name | session-id session-id | time-range
which no responses have been
start-time end-time | user-name user-name }
received.
Clear history authentication and
accounting load statistics from all reset radius server-load statistics
RADIUS servers.
Clear RADIUS statistics. reset radius statistics
Clear the buffered RADIUS reset stop-accounting-buffer { radius-scheme
stop-accounting requests to which no radius-scheme-name | session-id session-id | time-range
responses have been received. start-time end-time | user-name user-name }

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

43
 Step Command Remarks
2. Create an HWTACACS
scheme and enter hwtacacs scheme By default, no HWTACACS
HWTACACS scheme view. hwtacacs-scheme-name 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 hwtacacs scheme
scheme view. N/A
hwtacacs-scheme-name
• Specify the primary HWTACACS
authentication server:
primary authentication
{ host-name | ipv4-address | ipv6
ipv6-address } [ port-number | key By default, no authentication
{ cipher | simple } string | servers are specified.
single-connection | vpn-instance Two HWTACACS authentication
3. Specify HWTACACS vpn-instance-name ] * servers in a scheme, primary or
authentication servers. • Specify a secondary HWTACACS secondary, cannot have the
authentication server: same combination of host name,
secondary authentication IP address, port number, and
{ host-name | ipv4-address | ipv6 VPN instance.
ipv6-address } [ port-number | key
{ cipher | simple } string |
single-connection | vpn-instance
vpn-instance-name ] *

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

44
 Step Command Remarks
2. Enter HWTACACS hwtacacs scheme
scheme view. N/A
hwtacacs-scheme-name
• Specify the primary HWTACACS
authorization server:
primary authorization
{ host-name | ipv4-address | ipv6
ipv6-address } [ port-number | key
{ cipher | simple } string | By default, no authorization
single-connection | servers are specified.
vpn-instance Two HWTACACS authorization
3. Specify HWTACACS vpn-instance-name ] * servers in a scheme, primary or
authorization servers. • Specify a secondary HWTACACS secondary, cannot have the same
authorization server: combination of host name, IP
secondary authorization address, port number, and VPN
{ host-name | ipv4-address | ipv6 instance.
ipv6-address } [ port-number | key
{ cipher | simple } string |
single-connection |
vpn-instance
vpn-instance-name ] *

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.
The device sends HWTACACS stop-accounting requests when it receives connection teardown
requests from hosts or connection teardown commands from an administrator. However, the device
might fail to receive a response for a stop-accounting request in a single transmission. Enable the
device to buffer HWTACACS stop-accounting requests that have not received responses from the
accounting server. The device will resend the requests until responses are received.
To limit the transmission times, set a maximum number of attempts that can be made for transmitting
individual HWTACACS stop-accounting requests. When the maximum attempts are made for a
request, the device discards the buffered request.
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 hwtacacs scheme
scheme view. N/A
hwtacacs-scheme-name
• Specify the primary HWTACACS By default, no accounting servers
accounting server: are specified.
3. Specify HWTACACS primary accounting { host-name
| ipv4-address | ipv6 Two HWTACACS accounting
accounting servers. servers in a scheme, primary or
ipv6-address } [ port-number | key
{ cipher | simple } string | secondary, cannot have the same
single-connection | combination of host name, IP

45
 Step Command Remarks
vpn-instance address, port number, and VPN
vpn-instance-name ] * instance.
• Specify a secondary HWTACACS
accounting server:
secondary accounting
{ host-name | ipv4-address | ipv6
ipv6-address } [ port-number | key
{ cipher | simple } string |
single-connection |
vpn-instance
vpn-instance-name ] *
4. (Optional.) Enable
buffering of
HWTACACS
stop-accounting By default, the buffering feature is
stop-accounting-buffer enable
requests to which no enabled.
responses have been
received.
5. (Optional.) Set the
maximum number of
transmission attempts
for individual retry stop-accounting retries The default setting is 100.
HWTACACS
stop-accounting
requests.

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 hwtacacs scheme
view. N/A
hwtacacs-scheme-name
By default, no shared key is
3. Specify a shared key for specified for secure HWTACACS
secure HWTACACS key { accounting | communication.
authentication, authorization, authentication | authorization } The shared key configured on the
or accounting { cipher | simple } string device must be the same as the
communication. shared key configured on the
HWTACACS server.

46
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 hwtacacs scheme
view. N/A
hwtacacs-scheme-name

3. Specify a VPN instance for By default, an HWTACACS

the HWTACACS scheme. vpn-instance vpn-instance-name 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 hwtacacs scheme
view. N/A
hwtacacs-scheme-name
3. Set the format of usernames
sent to the HWTACACS user-name-format { keep-original By default, the ISP domain name
servers. | with-domain | without-domain } is included in a username.

data-flow-format { data { byte |

4. (Optional.) Set the data flow giga-byte | kilo-byte | mega-byte }
and packet measurement By default, traffic is counted in
| packet { giga-packet |
units for traffic statistics. bytes and packets.
kilo-packet | mega-packet |
one-packet } }*

Specifying the source IP address for outgoing HWTACACS

packets
Overview
An HWTACACS server identifies a NAS by IP address. When the HWTACACS server receives a
packet, it checks the source IP address of the packet.

47
 • 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.
Before sending an HWTACACS packet, the NAS selects a source IP address for the packet 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.
Configuration restrictions and guidelines
When you specify the source IP address for outgoing HWTACACS packets, follow these restrictions
and guidelines:
• 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 only to one HWTACACS
scheme.
{ The IP address specified in system view applies to all HWTACACS schemes for the
specified VPN or the public network.
The setting in HWTACACS scheme view takes precedence over the setting in system view.
• The source IP address of HWTACACS packets that a NAS sends must match the IP address of
the NAS that is configured on the HWTACACS server.
• As a best practice, specify a loopback interface address as the source IP address for outgoing
HWTACACS packets to avoid HWTACACS packet loss caused by physical port errors.
• The source IP address of outgoing HWTACACS packets is typically the IP address of an egress
interface on the NAS to communicate with the HWTACACS 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 IP address.
• You can directly specify a source IP address for outgoing HWTACACS packets or specify a
source interface to provide the source IP address for outgoing HWTACACS packets. The
source interface configuration and the source IP address configuration overwrite each other.
Configuration procedure
To specify a source interface or 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 interface or hwtacacs nas-ip { interface By default, the source IP address
source IP address for interface-type interface-number | of an outgoing HWTACACS
outgoing HWTACACS { ipv4-address | ipv6 packet is the primary IPv4
packets. ipv6-address } [ vpn-instance address or the IPv6 address of the
vpn-instance-name ] } outbound interface.

To specify a source interface or source IP address for an HWTACACS scheme:

Step Command Remarks

1. Enter system view. system-view N/A
2. Enter HWTACACS scheme hwtacacs scheme
view. N/A
hwtacacs-scheme-name
3. Specify a source interface or nas-ip { ipv4-address | interface By default, the source IP address

48
 Step Command Remarks
source IP address for interface-type interface-number | of an outgoing HWTACACS
outgoing HWTACACS ipv6 ipv6-address } packet is that specified by using
packets. the hwtacacs nas-ip command in
system view. If this command is
not used, the source IP address is
the primary IP address of the
outbound interface.

Setting HWTACACS timers

Overview
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.
Configuration restrictions and guidelines
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.

49
 • 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.
Configuration procedure
To set HWTACACS timers:

Step Command Remarks

1. Enter system view. system-view N/A
2. Enter HWTACACS scheme hwtacacs scheme
view. N/A
hwtacacs-scheme-name

3. Set the HWTACACS server By default, the HWTACACS

timer response-timeout
response timeout timer. server response timeout timer is 5
seconds
seconds.
By default, the real-time
accounting interval is 12 minutes.
4. Set the real-time accounting timer realtime-accounting A short interval helps improve
interval. minutes accounting precision but requires
many system resources. When
there are 1000 or more users, set
a longer interval.

5. Set the server quiet timer. By default, the server quiet timer
timer quiet minutes
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 display hwtacacs scheme [ hwtacacs-scheme-name

statistics of HWTACACS schemes. [ statistics ] ]
Display information about buffered
HWTACACS stop-accounting requests display stop-accounting-buffer hwtacacs-scheme
to which no responses have been hwtacacs-scheme-name
received.
reset hwtacacs statistics { accounting | all | authentication |
Clear HWTACACS statistics.
authorization }
Clear the buffered HWTACACS
reset stop-accounting-buffer hwtacacs-scheme
stop-accounting requests to which no
hwtacacs-scheme-name
responses have been received.

50
Configuring LDAP schemes
Configuration task list
Tasks at a glance

Configuring an LDAP server:

• (Required.) Creating an LDAP server
• (Required.) Configuring the IP address of the LDAP server
• (Optional.) Specifying the LDAP version
• (Optional.) Setting the LDAP server timeout period
• (Required.) Configuring administrator attributes
• (Required.) Configuring LDAP user attributes
(Optional.) Configuring an LDAP attribute map
(Required.) Creating an LDAP scheme
(Required.) Specifying the LDAP authentication server
(Optional.) Specifying the LDAP authorization server
(Optional.) Specifying an LDAP attribute map for LDAP authorization

Creating an LDAP server

Step Command Remarks
1. Enter system view. system-view N/A
2. Create an LDAP server
and enter LDAP server ldap server server-name By default, no LDAP servers exist.
view.

Configuring the IP address of the LDAP server

Step Command Remarks
1. Enter system view. System-view N/A
2. Enter LDAP server view. ldap server server-name N/A
By default, an LDAP server does
{ ip ip-address | ipv6 not have an IP address.
3. Configure the IP address of ipv6-address } [ port You can configure either an IPv4
the LDAP server. port-number ] [ vpn-instance address or an IPv6 address for an
vpn-instance-name ] LDAP server. The most recent
configuration takes effect.

Specifying the LDAP version

Specify the LDAP version on the NAS. The device supports LDAPv2 and LDAPv3. The LDAP
version specified on the device must be consistent with the version specified on the LDAP server.
To specify the LDAP version:

51
 Step Command Remarks
1. Enter system view. system-view N/A
2. Enter LDAP server view. ldap server server-name N/A
By default, LDAPv3 is used.
3. Specify the LDAP version. protocol-version { v2 | v3 } A Microsoft LDAP server supports
only LDAPv3.

Setting the LDAP server timeout period

If the device sends a bind or search request to an LDAP server without receiving the server's
response within the server timeout period, the authentication or authorization request times out.
Then, the device tries the backup authentication or authorization method. If no backup method is
configured in the ISP domain, the device considers the authentication or authorization attempt a
failure.
To set the LDAP server timeout period:

Step Command Remarks

1. Enter system view. system-view N/A
2. Enter LDAP server view. ldap server server-name N/A
3. Set the LDAP server By default, the LDAP server timeout
timeout period. server-timeout time-interval
period is 10 seconds.

Configuring administrator attributes

To configure the administrator DN and password for binding with the LDAP server during LDAP
authentication:

Step Command Remarks

1. Enter system view. system-view N/A
2. Enter LDAP server view. ldap server server-name N/A
By default, no administrator DN is
specified.
3. Specify the administrator The administrator DN specified on
DN. login-dn dn-string
the device must be the same as the
administrator DN configured on the
LDAP server.
4. Configure the login-password { cipher | By default, no administrator
administrator password. simple } string password is specified.

Configuring LDAP user attributes

To authenticate a user, an LDAP client must complete the following operations:
1. Establish a connection to the LDAP server.
2. Obtain the user DN from the LDAP server.

52
 3. Use the user DN and the user's password to bind with the LDAP server.
LDAP provides a DN search mechanism for obtaining the user DN. According to the mechanism, an
LDAP client sends search requests to the server based on the search policy determined by the
LDAP user attributes of the LDAP client.
The LDAP user attributes include:
• Search base DN.
• Search scope.
• Username attribute.
• Username format.
• User object class.
If the LDAP server contains many directory levels, a user DN search starting from the root directory
can take a long time. To improve efficiency, you can change the start point by specifying the search
base DN.
To configure LDAP user attributes:

Step Command Remarks

1. Enter system view. system-view N/A
2. Enter LDAP server view. ldap server server-name N/A
3. Specify the user search base By default, no user search base
DN. search-base-dn base-dn
DN is specified.
4. (Optional.) Specify the user search-scope { all-level | By default, the user search scope
search scope. single-level } is all-level.

5. (Optional.) Specify the user-parameters

By default, the username attribute
username attribute. user-name-attribute
is cn.
{ name-attribute | cn | uid }
user-parameters
6. (Optional.) Specify the user-name-format By default, the username format is
username format. { with-domain | without-domain.
without-domain }
By default, no user object class is
specified, and the default user
user-parameters object class on the LDAP server is
7. (Optional.) Specify the user used.
object class. user-object-class
object-class-name The default user object class for
this command varies by server
model.

Configuring an LDAP attribute map

Configure an LDAP attribute map to define a list of LDAP-AAA attribute mapping entries. To apply the
LDAP attribute map, specify the name of the LDAP attribute map in the LDAP scheme used for
authorization.
The LDAP attribute map feature enables the device to convert LDAP attributes obtained from an
LDAP authorization server to device-recognizable AAA attributes based on the mapping entries.
Because the device ignores unrecognized LDAP attributes, configure the mapping entries to include
important LDAP attributes that should not be ignored.
An LDAP attribute can be mapped only to one AAA attribute. Different LDAP attributes can be
mapped to the same AAA attribute.

53
 To configure an LDAP attribute map:

Step Command Remarks

1. Enter system view. system-view N/A
2. Create an LDAP attribute
map and enter LDAP By default, no LDAP attribute maps
ldap attribute-map map-name
attribute map view. exist.

map ldap-attribute By default, an LDAP attribute map

3. Configure a mapping ldap-attribute-name [ prefix does not have any mapping entries.
entry. prefix-value delimiter
delimiter-value ] aaa-attribute Repeat this command to configure
user-group multiple mapping entries.

Creating an LDAP scheme

You can configure a maximum of 16 LDAP schemes. An LDAP scheme can be used by multiple ISP
domains.
To create an LDAP scheme:

Step Command Remarks

1. Enter system view. system-view N/A
2. Create an LDAP scheme
and enter LDAP scheme ldap scheme
By default, no LDAP schemes exist.
view. ldap-scheme-name

Specifying the LDAP authentication server

Step Command Remarks
1. Enter system view. system-view N/A
2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A
3. Specify the LDAP authentication-server By default, no LDAP authentication
authentication server. server-name server is specified.

Specifying the LDAP authorization server

Step Command Remarks
1. Enter system view. system-view N/A
2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A
3. Specify the LDAP authorization-server By default, no LDAP authorization
authorization server. server-name server is specified.

54
Specifying an LDAP attribute map for LDAP authorization
Specify an LDAP attribute map for LDAP authorization to convert LDAP attributes obtained from the
LDAP authorization server to device-recognizable AAA attributes.
You can specify only one LDAP attribute map in an LDAP scheme.
To specify an LDAP attribute map for LDAP authorization:

Step Command Remarks

1. Enter system view. system-view N/A
2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A
3. Specify an LDAP attribute By default, no LDAP attribute map is
map. attribute-map map-name
specified.

Displaying and maintaining LDAP

Execute display commands in any view.

Task Command

Display the configuration of LDAP schemes. display ldap scheme [ ldap-scheme-name ]

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 non-guest local user attributes."
To use remote authentication, authorization, and accounting, create the required RADIUS,
HWTACACS, or LDAP schemes. For more information about the scheme configuration, see
"Configuring RADIUS schemes," "Configuring HWTACACS schemes," and "Configuring LDAP
schemes."

Creating an ISP domain

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

55
 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 who are assigned to nonexistent domains. If no such ISP domain is configured,
user authentication fails.

NOTE:
Support for the authentication domain configuration depends on the access module.

Configuration restrictions and guidelines

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 avoid RADIUS authentication, authorization, or accounting failures, use short domain names
to ensure that usernames containing a domain name do not exceed 253 characters.
Configuration procedure
To create an ISP domain:

Step Command Remarks

1. Enter system view. system-view N/A

2. Create an ISP domain and By default, a system-defined ISP

enter ISP domain view. domain isp-name domain exists. The domain name is
system.
3. Return to system view. quit N/A
4. (Optional.) Specify the domain default enable By default, the default ISP domain is the
default ISP domain. isp-name system-defined ISP domain system.
5. (Optional.) Specify the ISP
domain to accommodate By default, no ISP domain is specified to
domain if-unknown
users who are assigned to accommodate users who are assigned
isp-domain-name
nonexistent domains. 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 attributes—The device assigns the authorization attributes in the ISP domain to
the authenticated users who do not receive these attributes from the server. However, if the idle

56
 cut attribute is configured in the ISP domain, the device assigns the attribute to the
authenticated users. If no idle cut attribute is configured in the ISP domain, the device uses the
idle cut attribute assigned by the server. The device supports the following authorization
attributes:
{ Authorization ACL—The device restricts authenticated users to access only the network
resources permitted by the ACL. For portal users, the authorization ACL can be configured
in a preauthentication domain to authorize access to network resources before users pass
authentication.
{ Authorization CAR action—The attribute controls the traffic flow of authenticated users.
For portal users, the authorization CAR action can be configured in a preauthentication
domain to control traffic flow before users pass authentication.
{ Idle cut—It enables the device to check the traffic of each online user at the specified
direction in the domain at the idle timeout interval. The device logs out any users in the
domain whose total traffic in the idle timeout period at the specified direction is less than the
specified minimum traffic.
{ IPv4 address pool—The device assigns IPv4 addresses from the pool to authenticated
users in the domain.
{ IPv6 address pool—The device assigns IPv6 addresses from the pool to authenticated
users in the domain.
{ Redirect URL—The device redirects users in the domain to the URL after they pass
authentication.
{ Authorization user group—Authenticated users in the domain obtain all attributes of the
user group.
{ Maximum number of multicast groups—The attribute restricts the maximum number of
multicast groups that an authenticated user can join concurrently.
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
By default, an ISP domain is in
3. Place the ISP domain in active state, and users in the
active or blocked state. state { active | block }
domain can request network
services.
authorization-attribute { acl
The default settings are as
acl-number | car inbound cir
follows:
committed-information-rate [ pir
peak-information-rate ] outbound • The idle cut feature is
cir committed-information-rate disabled.
[ pir peak-information-rate ] | • An IPv4 user can
4. Configure authorization idle-cut minutes [ flow ] [ traffic concurrently join a maximum
attributes for authenticated { both | inbound | outbound } ] | of four IGMP multicast
users in the ISP domain. igmp max-access-number groups.
max-access-number | ip-pool • An IPv6 user can
ipv4-pool-name | ipv6-pool concurrently join a maximum
ipv6-pool-name | mld of four MLD multicast
max-access-number groups.
max-access-number | url
• No other authorization
url-string | user-group
attributes exist.
user-group-name }

5. Specify the user address user-address-type { ds-lite | By default, no user address type is
type in the ISP domain. ipv6 | nat64 | private-ds | specified.
private-ipv4 | public-ds |

57
 Step Command Remarks
public-ipv4 }
6. Specify the service type for
users in the ISP domain. service-type { hsi | stb | voip } By default, the service type is hsi.

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
authentication default { hwtacacs-scheme
hwtacacs-scheme-name [ radius-scheme By default, the default
3. Specify default radius-scheme-name ] [ local ] [ none ] | authentication method is
authentication methods ldap-scheme ldap-scheme-name [ local ] local.
for all types of users. [ none ] | local [ none ] | none |
radius-scheme radius-scheme-name The none keyword is not
[ hwtacacs-scheme supported in FIPS mode.
hwtacacs-scheme-name ] [ local ] [ none ] }
By default, the default
authentication lan-access { ldap-scheme authentication method is
4. Specify authentication ldap-scheme-name [ local ] [ none ] | local used for LAN users.
methods for LAN users. [ none ] | none | radius-scheme
radius-scheme-name [ local ] [ none ] } The none keyword is not
supported in FIPS mode.

authentication login { hwtacacs-scheme By default, the default

hwtacacs-scheme-name [ radius-scheme authentication method is
5. Specify authentication used for login users.
methods for login users. radius-scheme-name ] [ local ] [ none ] |
ldap-scheme ldap-scheme-name [ local ] The none keyword is not
[ none ] | local [ none ] | none | supported in FIPS mode.

58
 Step Command Remarks
radius-scheme radius-scheme-name
[ hwtacacs-scheme
hwtacacs-scheme-name ] [ local ] [ none ] }
By default, the default
authentication portal { ldap-scheme authentication method is
6. Specify authentication ldap-scheme-name [ local ] [ none ] | local used for portal users.
methods for portal users. [ none ] | none | radius-scheme
radius-scheme-name [ local ] [ none ] } The none keyword is not
supported in FIPS mode.

7. Specify authentication By default, the default

authentication super { hwtacacs-scheme
methods for obtaining a authentication method is
hwtacacs-scheme-name | radius-scheme
temporary user role. used for obtaining a
radius-scheme-name } *
temporary user role.
By default, the default
authentication onu { local [ none ] | none | authentication method is
8. Specify authentication used for ONU users.
methods for ONU users. radius-scheme radius-scheme-name [ local ]
[ none ] } The none keyword is not
supported in FIPS mode.

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 but not LDAP 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
authorization default
{ hwtacacs-scheme
hwtacacs-scheme-name By default, the authorization
3. Specify default method is local.
authorization methods for [ radius-scheme radius-scheme-name ]
all types of users. [ local ] [ none ] | local [ none ] | none | The none keyword is not
radius-scheme radius-scheme-name supported in FIPS mode.
[ hwtacacs-scheme
hwtacacs-scheme-name ] [ local ]

59
 Step Command Remarks
[ none ] }
By default, the default
authorization command authorization method is used
4. Specify command { hwtacacs-scheme for command authorization.
authorization methods. hwtacacs-scheme-name [ local ] [ none ] |
local [ none ] | none } The none keyword is not
supported in FIPS mode.
By default, the default
authorization lan-access { local [ none ] authorization method is used
5. Specify authorization for LAN users.
methods for LAN users. | none | radius-scheme
radius-scheme-name [ local ] [ none ] } The none keyword is not
supported in FIPS mode.
authorization login { hwtacacs-scheme
hwtacacs-scheme-name By default, the default
[ radius-scheme radius-scheme-name ] authorization method is used
6. Specify authorization [ local ] [ none ] | local [ none ] | none | for login users.
methods for login users. radius-scheme radius-scheme-name
[ hwtacacs-scheme The none keyword is not
hwtacacs-scheme-name ] [ local ] supported in FIPS mode.
[ none ] }
By default, the default
authorization portal { local [ none ] | authorization method is used
7. Specify authorization for portal users.
methods for portal users. none | radius-scheme
radius-scheme-name [ local ] [ none ] } 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 who 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 accounting default { hwtacacs-scheme By default, the accounting

60
 Step Command Remarks
methods for all types of hwtacacs-scheme-name method is local.
users. [ radius-scheme radius-scheme-name ] The none keyword is not
[ local ] [ none ] | local [ none ] | none | supported in FIPS mode.
radius-scheme radius-scheme-name
[ hwtacacs-scheme
hwtacacs-scheme-name ] [ local ]
[ none ] }

4. Specify the command accounting command By default, the default

accounting method. hwtacacs-scheme accounting method is used
hwtacacs-scheme-name for command accounting.
accounting lan-access { broadcast By default, the default
radius-scheme radius-scheme-name1 accounting method is used
5. Specify accounting radius-scheme radius-scheme-name2 for LAN users.
methods for LAN users. [ local ] [ none ] | local [ none ] | none |
radius-scheme radius-scheme-name The none keyword is not
[ local ] [ none ] } supported in FIPS mode.

accounting login { hwtacacs-scheme

hwtacacs-scheme-name By default, the default
[ radius-scheme radius-scheme-name ] accounting method is used
6. Specify accounting [ local ] [ none ] | local [ none ] | none | for login users.
methods for login users. radius-scheme radius-scheme-name
[ hwtacacs-scheme The none keyword is not
hwtacacs-scheme-name ] [ local ] supported in FIPS mode.
[ none ] }
accounting portal { broadcast By default, the default
radius-scheme radius-scheme-name1 accounting method is used
7. Specify accounting radius-scheme radius-scheme-name2 for portal users.
methods for portal users. [ local ] [ none ] | local [ none ] | none |
radius-scheme radius-scheme-name The none keyword is not
[ local ] [ none ] } supported in FIPS mode.

8. Configure access control By default, the device

for users who encounter allows users who
accounting start-fail { offline | online }
accounting-start failures. encounter accounting-start
failures to stay online.

9. Configure access control By default, the device

for users who have failed all allows users who have
accounting update-fail { [ max-times
their accounting-update failed all their
max-times ] offline | online }
attempts. accounting-update
attempts to stay online.
10. Configure access control
for users who have used up By default, the device logs
their data or time accounting quota-out { offline | online } off users who have used up
accounting quotas. their accounting quotas.

11. Specify the accounting

method for dual-stack accounting dual-stack { merge | By default, the merge
users. separate } method is used.

Displaying and maintaining ISP domains

Execute display commands in any view.

Task Command

Display configuration information about an ISP

display domain [ isp-name ]
domain or all ISP domains.

61
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 whose IP and VPN instance settings match the session-control packet. 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 session-control feature:

Step Command Remarks

1. Enter system view. system-view N/A
2. Enable the session-control By default, the session-control
feature. radius session-control enable
feature is disabled.
radius session-control client By default, no session-control
3. Specify a session-control { ip ipv4-address | ipv6 clients are specified. The device
client. ipv6-address } [ key { cipher | searches all RADIUS scheme
simple } string | vpn-instance settings to verify session-control
vpn-instance-name ] * packets.

Configuring the RADIUS DAS feature

Dynamic Authorization Extensions (DAE) to RADIUS, defined in RFC 5176, can log off online users
and change online user authorization information.
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 who match the criteria in the requests, changes their authorization
information, shuts down or reboots their access ports, or reauthenticates the users.
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.

62
 • Change of Authorization Messages (CoA Messages)—The DAC sends CoA requests to the
DAS to change the authorization information of specific online users, shut down or reboot the
users' access ports, or reauthenticate the users.
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 By default, the RADIUS DAS
radius dynamic-author server
DAS view. feature is disabled.

client { ip ipv4-address | ipv6

3. Specify a RADIUS DAC. ipv6-address } [ key { cipher | By default, no RADIUS DACs are
simple } string | vpn-instance specified.
vpn-instance-name ] *
4. Specify the RADIUS DAS By default, the RADIUS DAS port is
port. port port-number
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 By default, the DSCP priority is 0
for RADIUS packets. radius [ ipv6 ] dscp dscp-value
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.

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

radius attribute extended By default, no user-defined

2. (Optional.) Define an attribute-name [ vendor vendor-id ] extended RADIUS attributes exist.
extended RADIUS code attribute-code type { binary | Repeat this command to define
attribute. date | integer | interface-id | ip | multiple extended RADIUS
ipv6 | ipv6-prefix | octets | string } attributes.
3. Enter RADIUS scheme radius scheme
view. N/A
radius-scheme-name
4. Enable the RADIUS
attribute translation attribute translate By default, this feature is disabled.
feature.
By default, no RADIUS attribute
attribute convert src-attr-name to conversion rules exist.
5. Configure a RADIUS dest-attr-name { { access-accept |
attribute conversion rule. access-request | accounting } * | Repeat this command to add
{ received | sent } * } multiple RADIUS attribute
conversion rules.
By default, no RADIUS attribute
attribute reject attr-name rejection rules exist.
6. Configure a RADIUS { { access-accept |
attribute rejection rule. access-request | accounting } * | Repeat this command to add
{ received | sent } * } 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

radius attribute extended By default, no user-defined

2. (Optional.) Define an attribute-name [ vendor vendor-id ] extended RADIUS attributes exist.
extended RADIUS code attribute-code type { binary | Repeat this command to define
attribute. date | integer | interface-id | ip | multiple extended RADIUS
ipv6 | ipv6-prefix | octets | string } attributes.
3. Enter RADIUS DAS view. radius dynamic-author server N/A
4. Enable the RADIUS
attribute translation attribute translate By default, this feature is disabled.
feature.
By default, no RADIUS attribute
attribute convert src-attr-name to conversion rules exist.
5. Configure a RADIUS dest-attr-name { { coa-ack |
attribute conversion rule. coa-request } * | { received | sent } Repeat this command to add
*} multiple RADIUS attribute
conversion rules.
By default, no RADIUS attribute
6. Configure a RADIUS attribute reject attr-name rejection rules exist.
attribute rejection rule. { { coa-ack | coa-request } * |
{ received | sent } * } Repeat this command to add
multiple RADIUS attribute rejection

64
 Step Command Remarks
rules.

Setting the maximum number of concurrent login

users
Perform this task to set the maximum number of concurrent users who 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
• In non-FIPS mode:
aaa session-limit { ftp | http
| https | ssh | telnet } By default, the maximum number
2. Set the maximum number of max-sessions
concurrent login users. of concurrent login users is 32 for
• In FIPS mode: each user type.
aaa session-limit { https |
ssh } max-sessions

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.
You can apply a NAS-ID profile to portal- or port security-enabled interfaces. For more information,
see "Configuring portal authentication" and "Configuring port security."
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 By default, no NAS-ID profiles
aaa nas-id profile profile-name
view. exist.

3. Configure a NAS-ID and

VLAN binding in the By default, no NAS-ID and VLAN
nas-id nas-identifier bind vlan vlan-id
profile. bindings exist.

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

Configuring the RADIUS server feature

Configuration restrictions and guidelines
When you configure the RADIUS server feature, follow these restrictions and guidelines:
• To use the RADIUS server feature, you must install the FreeRADIUS feature image that has the
same version as the current software images. The feature image is named in the format of
S7500E-CMW710-FREERADIUS-version.bin, for example,
S7500E-CMW710-FREERADIUS-R7523P01.bin.
For more information about how to install a feature image, see Fundamentals Configuration
Guide.
• To ensure correct operation of the RADIUS server feature, disable RADIUS session-control on
the device.

Configuration task list

To configure the RADIUS server feature, perform the following tasks:

Tasks at a glance Remarks

Configure network access users, which are

the basis of RADIUS user data.
(Required.) Configuring local users A RADIUS user has the following attributes:
user name, password, description,
authorization ACL, authorization VLAN, and
expiration time.
(Required.) Specifying RADIUS clients N/A
(Required.) Activating the RADIUS server configuration N/A

Specifying RADIUS clients

Perform this task to specify RADIUS clients and shared keys for centralized management. The
RADIUS server feature does not accept requests from RADIUS clients that are not managed by the
system.
When you specify RADIUS clients on the device, follow these restrictions and guidelines:

66
 • The IP address of a RADIUS client must be the same as the source IP address for outgoing
RADIUS packets specified on the RADIUS client.
• The shared key of a RADIUS client must be the same as the setting on the RADIUS client.
To specify a RADIUS client:

Step Command Remarks

1. Enter system view. system-view N/A

2. Specify a RADIUS client. radius-server client ip ipv4-address By default, no RADIUS clients

key { cipher | simple } string are specified.

Activating the RADIUS server configuration

At the device startup, the RADIUS server configuration is automatically activated, including RADIUS
users and RADIUS clients. You can immediately activate the most recent RADIUS server
configuration if you have added, modified, or deleted RADIUS clients and network access users from
which RADIUS user data is generated.
To activate the RADIUS server configuration:

Step Command Remarks

1. Enter system view. system-view N/A
Executing this command restarts
2. Activate the RADIUS the RADIUS server process and
server configuration. radius-server activate an authentication service
interruption will occur during the
restart.

Displaying and maintaining RADIUS users and clients

Execute display commands in any view.

Task Command

Display information about activated RADIUS users. display radius-server active-user [ user-name ]
Display information about activated RADIUS clients. display radius-server active-client

Configuring the connection recording policy

Overview
Use this feature on scenarios where the device acts as an FTP, SSH, SFTP, or Telnet login client to
establish a connection with a login server. This feature enables the device to provide an accounting
server with the connection start and termination information. When the login client establishes a
connection with the login server, the system sends a start-accounting request to the accounting
server. When the connection is terminated, the system sends a stop-accounting request to the
accounting server.

67
Configuration restrictions and guidelines
The device includes the username entered by a user in the accounting packets to be sent to the AAA
server for connection recording. The username format configured by using the user-name-format
command in the accounting scheme does not take effect.

Configuration procedure
To configure the connection recording policy:

Step Command Remarks

1. Enter system view. system-view N/A
2. Create a connection
recording policy and By default, the connection
aaa connection-recording policy
enter its view. recording policy does not exist.

3. Specify the accounting

method for the By default, no accounting
accounting hwtacacs-scheme
connection recording method is specified for the
hwtacacs-scheme-name
policy. connection recording policy.

Displaying and maintaining the connection recording policy

Execute display commands in any view.

Task Command

Display the connection recording policy

display aaa connection-recording policy
configuration.

AAA configuration examples

AAA for SSH users by an HWTACACS server
Network requirements
As shown in Figure 13, 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.

68
 Figure 13 Network diagram

Configuring the HWTACACS server

# Set the shared keys to expert for secure communication with the switch, add an account for the
SSH user, and specify the password. (Details not shown.)
Configuring 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.

69
 [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 14, 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 named hello for the SSH user. Configure the shared keys to expert for secure
communication with the HWTACACS server and RADIUS server.
Figure 14 Network diagram

Configuring the HWTACACS server

# Set the shared keys to expert for secure communication with the switch, add an account for the
SSH user, and specify the password. (Details not shown.)
Configuring the RADIUS server
# Set the shared keys to expert for secure communication with the switch, add an account for the
SSH user, and specify the password. (Details not shown.)
Configuring the switch
# Configure IP addresses for interfaces. (Details not shown.)
# Create local RSA and DSA key pairs.

70
 <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 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.)

71
Authentication and authorization for SSH users by a RADIUS
server
Network requirements
As shown in Figure 15, 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 PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101). Add an account
named 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.
Figure 15 Network diagram

Configuring the RADIUS server

1. 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 to expert for secure RADIUS communication.
b. Set the ports for authentication and accounting to 1812 and 1813, respectively.
c. Select Device Management Service from the Service Type list.
d. Select H3C from the Access Device Type list.
e. Select an access device from the device list or manually add an access device. In this
example, the device IP address is 10.1.1.2.
f. Use the default values 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 using the nas-ip command.
{ IP address specified by using the radius nas-ip command.
{ IP address of the outbound interface (the default).

72
 Figure 16 Adding the switch as an access device

2. 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 account name hello@bbb and specify the password.
b. Select SSH from the Service Type list.
c. Specify 10.1.1.0 to 10.1.1.255 as the IP address range of hosts to be managed.
d. Click OK.

NOTE:
The IP address range must contain the IP address of the switch.

73
 Figure 17 Adding an account for device management

Configuring 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

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

74
 [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 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 for SSH users by an LDAP server

Network requirements
As shown in Figure 18, the LDAP server uses domain ldap.com and runs Microsoft Windows 2003
Server Active Directory.
Configure the switch to meet the following requirements:
• Use the LDAP server to authenticate SSH users.
• Assign the default user role network-operator to SSH users after they pass authentication.
On the LDAP server, set the administrator password to admin!123456, add a user named aaa, and
set the user's password to ldap!123456.
Figure 18 Network diagram

Configuring the LDAP server

1. Add a user named aaa and set the password to ldap!123456:
a. On the LDAP server, select Start > Control Panel > Administrative Tools.
b. Double-click Active Directory Users and Computers.
The Active Directory Users and Computers window is displayed.
c. From the navigation tree, click Users under the ldap.com node.
d. Select Action > New > User from the menu to display the dialog box for adding a user.
e. Enter logon name aaa and click Next.

75
 Figure 19 Adding user aaa

f. In the dialog box, enter password ldap!123456, select options as needed, and click Next.
Figure 20 Setting the user's password

g. Click OK.
2. Add user aaa to group Users:
a. From the navigation tree, click Users under the ldap.com node.
b. In the right pane, right-click user aaa and select Properties.
c. In the dialog box, click the Member Of tab and click Add.

76
 Figure 21 Modifying user properties

d. In the Select Groups dialog box, enter Users in the Enter the object names to select field,
and click OK.
User aaa is added to group Users.
Figure 22 Adding user aaa to group Users

3. Set the administrator password to admin!123456:

a. In the right pane, right-click user Administrator and select Set Password.
b. In the dialog box, enter the administrator password. (Details not shown.)
Configuring the switch
# Configure IP addresses for interfaces. (Details not shown.)

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

# Configure an LDAP server.

[Switch] ldap server ldap1

# Specify the IP address of the LDAP authentication server.

[Switch-ldap-server-ldap1] ip 10.1.1.1

# Specify the administrator DN.

[Switch-ldap-server-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com

# Specify the administrator password.

[Switch-ldap-server-ldap1] login-password simple admin!123456

# Configure the base DN for user search.

[Switch-ldap-server-ldap1] search-base-dn dc=ldap,dc=com
[Switch-ldap-server-ldap1] quit

# Create an LDAP scheme.

[Switch] ldap scheme ldap-shm1

# Specify the LDAP authentication server.

[Switch-ldap-ldap-shm1] authentication-server ldap1
[Switch-ldap-ldap-shm1] 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 ldap-scheme ldap-shm1
[Switch-isp-bbb] authorization login none
[Switch-isp-bbb] accounting login none
[Switch-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the switch, and enter username aaa@bbb and password
ldap!123456. 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.)

78
AAA for 802.1X users by a RADIUS server
Network requirements
As shown in Figure 23, configure the switch to meet the following requirements:
• Use the RADIUS server for authentication, authorization, and accounting of 802.1X users.
• Use MAC-based access control on GigabitEthernet 1/0/1 to authenticate all 802.1X users on
the port separately.
• Include domain names in the usernames sent to the RADIUS server.
In this example, the RADIUS server runs on IMC PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101). On
the RADIUS server, perform the following tasks:
• Add a service that charges 120 dollars for up to 120 hours per month and assigns authenticated
users to VLAN 4.
• Configure a user account named dot1x@bbb and assign the service to the user.
Set the shared keys to expert for secure RADIUS communication. Set the ports for authentication
and accounting to 1812 and 1813, respectively.
Figure 23 Network diagram

Configuring the RADIUS server

1. 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 to expert for secure authentication and accounting communication.
b. Set the ports for authentication and accounting to 1812 and 1813, respectively.
c. Select LAN Access Service from the Service Type list.
d. Select H3C(General) from the Access Device Type list.
e. Select an access device from the device list or manually add an access device. In this
example, the device IP address is 10.1.1.2.
f. Use the default values 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 using the nas-ip command.
{ IP address specified by using the radius nas-ip command.
{ IP address of the outbound interface (the default).

79
 Figure 24 Adding the switch as an access device

2. Add a charging plan:

Click the Service tab, and select Accounting Manager > Charging Plans from the navigation
tree to enter the charging plan configuration page. Then, click Add to configure a charging plan
as follows:
a. Add a plan named UserAcct.
b. Select Flat rate from the Charging Template list.
c. Select time for Charge Based on, select Monthly for Billing Term, and enter 120 in the
Fixed Fee field.
d. Enter 120 in the Usage Threshold field and select hr (hours) for the in field. The
configuration allows the user to access the Internet for up to 120 hours per month.
e. Use the default values for other parameters and click OK.
Figure 25 Adding a charging plan

3. Add a service:
Click the Service tab, and select User Access Manager > Service Configuration from the
navigation tree. Then, click Add to configure a service as follows:
a. Add a service named Dot1x auth, and set the service suffix to bbb, the authentication
domain for the 802.1X user. With the service suffix configured, you must configure the
access device to send usernames that include domain names to the RADIUS server.
b. Select UserAcct from the Charging Plan list.

80
 c. Select Deploy VLAN and set the ID of the VLAN to be assigned to 4.
d. Configure other parameters as needed.
e. Click OK.
Figure 26 Adding a service

4. Add a user:
Click the User tab, and select Access User View > All Access Users from the navigation tree
to enter the All Access Users page. Then, click Add to configure a user as follows:
a. Select the user or add a user named hello.
b. Specify the account name as dot1x and configure the password.
c. Select Dot1x auth in the Access Service area.
d. Configure other parameters as needed and click OK.

81
 Figure 27 Adding an access user account

Configuring the switch

1. Configure a RADIUS scheme:
# Create a RADIUS scheme named rad and enter RADIUS scheme view.
<Switch> system-view
[Switch] radius scheme rad
# Specify the primary authentication server and primary accounting server, and configure the
keys for communication with the servers.
[Switch-radius-rad] primary authentication 10.1.1.1
[Switch-radius-rad] primary accounting 10.1.1.1
[Switch-radius-rad] key authentication simple expert
[Switch-radius-rad] key accounting 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
2. Configure an ISP domain:
# Create an ISP domain named bbb and enter ISP domain view.
[Switch] domain bbb
# Configure the ISP domain to use RADIUS scheme rad for authentication, authorization, and
accounting of LAN users.
[Switch-isp-bbb] authentication lan-access radius-scheme rad
[Switch-isp-bbb] authorization lan-access radius-scheme rad
[Switch-isp-bbb] accounting lan-access radius-scheme rad
[Switch-isp-bbb] quit
3. Configure 802.1X authentication:
# Enable 802.1X globally.
[Switch] dot1x
# Enable 802.1X for GigabitEthernet 1/0/1.
[Switch] interface gigabitethernet 1/0/1
[Switch-GigabitEthernet1/0/1] dot1x

82
 # Configure the access control method. By default, an 802.1X-enabled port uses the
MAC-based access control.
[Switch-GigabitEthernet1/0/1] dot1x port-method macbased

Verifying the configuration

1. On the host, use account dot1x@bbb to pass 802.1X authentication:
# If the host runs the Windows XP 802.1X client, configure the network connection properties
as follows:
a. Click the Authentication tab of the properties window.
b. Select the Enable IEEE 802.1X authentication for this network option.
c. Select MD5 challenge as the EAP type.
d. Click OK.
The user passes authentication after entering the correct username and password on the
authentication page.
# If the host runs the iNode client, no advanced authentication options are required. The user
can pass authentication after entering username dot1x@bbb and the correct password on the
client property page.

IMPORTANT:
Make sure the client can update its IP address to access the resources in the authorized VLAN
after passing authentication.

2. On the switch, verify that the server assigns the port connecting the client to VLAN 4 after the
user passes authentication. (Details not shown.)
3. Display 802.1X connection information on the switch.
[Switch] display dot1x connection

Local guest configuration and management example

Network requirements
As shown in Figure 28, create an 802.1X local guest named user1 for Jack. Configure local guest
attributes and manage the local guest on the switch as follows:
• Configure attributes for the local guest, including the password, user group, validity period, and
sponsor information.
• Enable the local user auto-delete feature.
• Specify an SMTP server and email sender address for the device to send local guest email
notifications.
• Configure email addresses for the local guest and guest sponsor.
• Configure the subject and body of the email notifications to be sent to the guest and guest
sponsor.
• Send email notifications of the local guest account information to the guest and guest sponsor.
Figure 28 Network diagram

Internet

Guest Switch

83
Configuration procedure
1. Configure 802.1X settings. Make sure the guest can pass 802.1X authentication to access the
network. (Details not shown.)
2. Manage local guests:
# Enable the local user auto-delete feature for expired local guests.
<Switch> system-view
[Switch] local-user auto-delete enable
# Specify an SMTP server to send local guest email notifications.
[Switch] local-guest email smtp-server smtp://192.168.0.112/smtp
# Specify the email sender address as [email protected] in the email notifications sent by the
device for local guests.
[Switch] local-guest email sender [email protected]
# Configure the subject and body of the email notifications to be sent to the local guest.
[Switch] local-guest email format to guest subject Guest account information
[Switch] local-guest email format to guest body A guest account has been created for
you. The username, password, and validity period of the account are given below.
# Configure the subject and body of the email notifications to be sent to the guest sponsor.
[Switch] local-guest email format to sponsor subject Guest account information
[Switch] local-guest email format to sponsor body A guest account has been created
for you. The username, password, and validity period of the account are given below.
3. Configure the local guest:
# Create a user group named guest1.
[Switch] user-group guest1
[Switch-ugroup-guest1] quit
# Create a local guest named user1 and enter local guest view.
[Switch] local-user user1 class network guest
# Set the guest password to 123456 in plain text.
[Switch-luser-network(guest)-user1] password simple 123456
# Assign the guest to user group guest1.
[Switch-luser-network(guest)-user1] group guest1
# Specify the name of the local guest.
[Switch-luser-network(guest)-user1] full-name Jack
# Specify the company of the local guest.
[Switch-luser-network(guest)-user1] company cc
# Configure the email address of the local guest.
[Switch-luser-network(guest)-user1] email [email protected]
# Configure the phone number of the local guest.
[Switch-luser-network(guest)-user1] phone 131129237
# Configure a description for the local guest.
[Switch-luser-network(guest)-user1] description A guest from company cc
# Configure the validity period of the local guest.
[Switch-luser-network(guest)-user1] validity-datetime from 2015/4/1 08:00:00 to
2015/4/3 18:00:00
# Specify the guest sponsor name as Sam.
[Switch-luser-network(guest)-user1] sponsor-full-name Sam
# Configure the email address of the guest sponsor.
[Switch-luser-network(guest)-user1] sponsor-email [email protected]

84
 # Configure the department of the guest sponsor as security.
[Switch-luser-network(guest)-user1] sponsor-department security
[Switch-luser-network(guest)-user1] quit
[Switch] quit
4. Configure the device to send guest email notifications:
# Send an email notification to the guest sponsor.
<Switch> local-guest send-email user-name user1 to sponsor
# Send an email notification to the guest.
<Switch> local-guest send-email user-name user1 to guest

Verifying the configuration

# Display local guest information.
<Switch> display local-user user-name user1 class network guest
Total 1 local users matched.

Network access guest user1:

State: Active
Service type: LAN-access/Portal
User group: guest1
Full name: Jack
Company: cc
Email: [email protected]
Phone: 131129237
Sponsor full name: Sam
Sponsor department: security
Sponsor email: [email protected]
Description: A guest from company cc
Validity period:
Start date and time: 2015/04/01-08:00:00
Expiration date and time:2015/04/03-18:00:00

# Verify that Jack can use username user1 and password 123456 to pass local authentication and
come online during the validity period. (Details not shown.)

Authentication and authorization of 802.1X users by the

device as a RADIUS server
Network requirements
As shown in Figure 29, Switch B acts as the RADIUS server for authentication and authorization of
802.1X users connected to the NAS (Switch A).
Configure the switches to meet the following requirements:
• Perform 802.1X authentication on GigabitEthernet 1/0/1 of the NAS.
• The shared key is expert and the authentication port is 1812.
• Exclude domain names from the usernames sent to the RADIUS server.
• The user name for 802.1X authentication is dot1x.
• After the user passes authentication, the RADIUS server authorizes VLAN 4 to the NAS port
that the user is connecting to.

85
 Figure 29 Network diagram

Configuration procedure
1. Configure the NAS:
a. Configure a RADIUS scheme:
# Configure a RADIUS scheme named rad and enter RADIUS scheme view.
<SwitchA> system-view
[SwitchA] radius scheme rad
# Specify the primary authentication server with IP address 10.1.1.1 and set the shared key
to expert in plaintext form.
[SwitchA-radius-rad] primary authentication 10.1.1.1 key simple expert
# Exclude domain names from the usernames sent to the RADIUS server.
[SwitchA-radius-rad] user-name-format without-domain
[SwitchA-radius-rad] quit
b. Configure an authentication domain:
# Create an ISP domain named bbb and enter ISP domain view.
[SwitchA] domain bbb
# Configure the ISP domain to use RADIUS scheme rad for authentication and
authorization of LAN users and not to perform accounting for LAN users.
[SwitchA-isp-bbb] authentication lan-access radius-scheme rad
[SwitchA-isp-bbb] authorization lan-access radius-scheme rad
[SwitchA-isp-bbb] accounting lan-access none
[SwitchA-isp-bbb] quit
c. Configure 802.1X authentication:
# Enable 802.1X for GigabitEthernet 1/0/1.
[SwitchA] interface gigabitethernet 1/0/1
[SwitchA-GigabitEthernet1/0/1] dot1x
# Specify bbb as the mandatory authentication domain for 802.1X users on the interface.
[SwitchA-GigabitEthernet1/0/1] dot1x mandatory-domain bbb
[SwitchA-GigabitEthernet1/0/1] quit
# Enable 802.1X globally.
[SwitchA] dot1x
2. Configure the RADIUS server:
# Create a network access user named dot1x.
<SwitchB> system-view
[SwitchB] local-user dot1x class network
# Configure the password as 123456 in plaintext form.

86
 [SwitchB-luser-network-dot1x] password simple 123456
# Configure VLAN 4 as the authorization VLAN.
[SwitchB-luser-network-dot1x] authorization-attribute vlan 4
[SwitchB-luser-network-dot1x] quit
# Configure the IP address of the RADIUS client as 10.1.1.2 and the shared key as expert in
plaintext form.
[SwitchB] radius-server client ip 10.1.1.2 key simple expert
# Activate the RADIUS server configuration.
[SwitchB] radius-server activate

Verifying the configuration

1. On the RADIUS server, display the activated RADIUS clients and users.
[SwitchB] display radius-server active-client
Total 1 RADIUS clients.
Client IP: 10.1.1.2
[SwitchB] display radius-server active-user dot1x
Total 1 RADIUS users matched.
Username: dot1x
Description: Not configured
Authorization attributes:
VLAN ID: 4
ACL number: Not configured
Validity period:
Expiration time: Not configured
2. On the host, use the dot1x user for 802.1X authentication.
If the user host runs the Windows built-in 802.1X client, configure the network connection
properties as follows:
a. Click the Authentication tab of the properties window.
b. Select the Enable IEEE 802.1X authentication for this network option.
c. Select MD5 challenge as the EAP type.
d. Click OK.
If the user host runs the iNode client, no advanced authentication options are required.
The user passes authentication after entering the correct user name and password on the
authentication page or the iNode client.

IMPORTANT:
Make sure the client can update its IP address to access the resources in the authorized VLAN
after passing authentication.

3. On the NAS, verify that the RADIUS server assigns the user access port to VLAN 4 after the
user passes authentication. (Details not shown.)
4. On the NAS, display online 802.1X user information.
[SwitchA] display dot1x connection

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

88
 { 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."

Troubleshooting LDAP
LDAP authentication failure
Symptom
User authentication fails.
Analysis
Possible reasons include:
• A communication failure exists between the NAS and the LDAP server.
• The LDAP server IP address or port number configured on the NAS is not correct.
• 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 LDAP server.
• The password entered by the user is incorrect.
• The administrator DN or password is not configured.
• Some user attributes (for example, the username attribute) configured on the NAS are not
consistent with those configured on the server.
• No user search base DN is specified for the LDAP scheme.

89
Solution
To resolve the problem:
1. Verify the following items:
{ The NAS and the LDAP server can ping each other.
{ The IP address and port number of the LDAP server configured on the NAS match those of
the server.
{ The username is in the correct format and the ISP domain for the user authentication is
correctly configured on the NAS.
{ The user is configured on the LDAP server.
{ The correct password is entered.
{ The administrator DN and the administrator password are correctly configured.
{ The user attributes (for example, the username attribute) configured on the NAS are
consistent with those configured on the LDAP server.
{ The user search base DN for authentication is specified.
2. If the problem persists, contact H3C Support.

90