Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing network access management. It provides the following security functions:

· Authentication—Identifies users and determines whether a user is valid.

· Authorization—Grants user rights and controls user access to resources and services. For example, a user who has successfully logged in to the device can be granted read and print permissions to the files on the device.

· Accounting—Records all network service usage information, including service type, start time, and traffic. The accounting function provides information required for charging, and allows for network security surveillance.

AAA typically uses a client/server model, as shown in Figure 1. The client runs on the network access server (NAS), which is also called the access device. The server maintains user information centrally. In an AAA network, the NAS is a server for users but a client for AAA servers.

Figure 1 AAA application scenario

The NAS uses the authentication server to authenticate any user who tries to log in, use network resources, or access other networks. The NAS transparently transmits authentication, authorization, and accounting information between the user and the servers. The RADIUS and HWTACACS protocols define how a NAS and a remote server exchange user information.

The network shown in Figure 1 comprises a RADIUS server and an 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 the RADIUS server for accounting.

You can implement any of the three security functions provided by AAA as needed. For example, if your company wants employees to be authenticated before they access specific resources, configure an authentication server. If network usage information is needed, you must also configure an accounting server.

AAA can be implemented through multiple protocols. The device supports RADIUS and HWTACACS, of which RADIUS is most often used.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. It can protect networks against unauthorized access and is often used in network environments that require both high security and remote user access.

RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting.

RADIUS was originally designed for dial-in user access. With the addition of new access methods, RADIUS has been extended to support additional access methods, including Ethernet and ADSL. RADIUS provides access authentication, authorization, and accounting services. The accounting function collects and records network resource usage information.

Client/server model

RADIUS clients run on NASs located throughout the network. NASs pass user information to RADIUS servers, and determine to reject or accept user access requests depending on the responses from RADIUS servers.

The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network access. It receives connection requests, authenticates users, and returns access control information (for example, rejecting or accepting the user access request) to the clients.

The RADIUS server typically maintains the following databases: Users, Clients, and Dictionary. See Figure 2.

Figure 2 RADIUS server databases

· Users—Stores user information, such as 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.

Security and authentication mechanisms

The RADIUS client and the RADIUS server use a shared key to authenticate RADIUS packets and encrypt user passwords exchanged between them. For security, this key must be manually configured on the client and the server.

RADIUS servers support multiple authentication protocols, including PPP PAP and CHAP. A RADIUS server can also act as the client of another AAA server to provide authentication proxy services.

Basic RADIUS message exchange process

Figure 3 illustrates the interactions between the host, the RADIUS client, and the RADIUS server.

Figure 3 Basic RADIUS message exchange process

RADIUS operates in the following manner:

1. The host initiates a connection request that carries the user's username and password to the RADIUS client.

2. Having received the username and password, the RADIUS client sends an authentication request (Access-Request) to the RADIUS server, with the user password encrypted by using the MD5 algorithm and the shared key.

3. The RADIUS server authenticates the username and password. If the authentication succeeds, the server returns an Access-Accept message containing the user's authorization information. If the authentication fails, the server returns an Access-Reject message.

4. The RADIUS client permits or denies the user according to the returned authentication result. If it permits the user, it sends a start-accounting request (Accounting-Request) to the RADIUS server.

5. The RADIUS server returns an acknowledgement (Accounting-Response) and starts accounting.

6. The user accesses the network resources.

7. The host requests the RADIUS client to tear down the connection and the RADIUS client sends a stop-accounting request (Accounting-Request) to the RADIUS server.

8. The RADIUS server returns an acknowledgement (Accounting-Response) and stops accounting for the user.

RADIUS packet format

RADIUS uses UDP to transmit messages. To ensure smooth message exchange between the RADIUS server and the client, RADIUS uses a timer management mechanism, a retransmission mechanism, and a backup server mechanism. Figure 4 shows the RADIUS packet format.

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 Main values of the Code field

Code	Packet type	Description
1	Access-Request	From the client to the server. A packet of this type carries user information for the server to authenticate the user. It must contain the User-Name attribute and can optionally contain the attributes of NAS-IP-Address, User-Password, and NAS-Port.
2	Access-Accept	From the server to the client. If all attribute values carried in the Access-Request are acceptable, the authentication succeeds, and the server sends an Access-Accept response.
3	Access-Reject	From the server to the client. If any attribute value carried in the Access-Request is unacceptable, the authentication fails, and the server sends an Access-Reject response.
4	Accounting-Request	From the client to the server. A packet of this type carries user information for the server to start or stop accounting for the user. The Acct-Status-Type attribute in the packet indicates whether to start or stop accounting.
5	Accounting-Response	From the server to the client. The server sends a packet of this type to notify the client that it has received the Accounting-Request and has successfully recorded the accounting information.

· The Identifier field (1 byte long) is used to match request packets and response packets and to detect duplicate request packets. Request and response packets of the same type have the same identifier.

· The Length field (2 bytes long) indicates the length of the entire packet, including the Code, Identifier, Length, Authenticator, and Attributes fields. Bytes beyond this length are considered padding and are ignored at the receiver. If the length of a received packet is less than this length, the packet is dropped. The value of this field is in the range 20 to 4096.

· 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) carries the specific authentication, authorization, and accounting information that defines the configuration details of the request or response. This field may contain multiple attributes, each with three sub-fields:

¡ Type—(1 byte long) Type of the attribute. It is in the range of 1 to 255. Commonly used RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868. Table 2 shows a list of the attributes. For more information, see "Commonly used standard RADIUS attributes."

¡ Length—(1 byte long) Length of the attribute in bytes, including the Type, Length, and Value sub-fields.

¡ Value—(Up to 253 bytes) Value of the attribute. Its format and content depend on the Type and Length sub-fields.

Table 2 Commonly used RADIUS attributes

No.	Attribute	No.	Attribute
1	User-Name	45	Acct-Authentic
2	User-Password	46	Acct-Session-Time
3	CHAP-Password	47	Acct-Input-Packets
4	NAS-IP-Address	48	Acct-Output-Packets
5	NAS-Port	49	Acct-Terminate-Cause
6	Service-Type	50	Acct-Multi-Session-Id
7	Framed-Protocol	51	Acct-Link-Count
8	Framed-IP-Address	52	Acct-Input-Gigawords
9	Framed-IP-Netmask	53	Acct-Output-Gigawords
10	Framed-Routing	54	(unassigned)
11	Filter-ID	55	Event-Timestamp
12	Framed-MTU	56-59	(unassigned)
13	Framed-Compression	60	CHAP-Challenge
14	Login-IP-Host	61	NAS-Port-Type
15	Login-Service	62	Port-Limit
16	Login-TCP-Port	63	Login-LAT-Port
17	(unassigned)	64	Tunnel-Type
18	Reply-Message	65	Tunnel-Medium-Type
19	Callback-Number	66	Tunnel-Client-Endpoint
20	Callback-ID	67	Tunnel-Server-Endpoint
21	(unassigned)	68	Acct-Tunnel-Connection
22	Framed-Route	69	Tunnel-Password
23	Framed-IPX-Network	70	ARAP-Password
24	State	71	ARAP-Features
25	Class	72	ARAP-Zone-Access
26	Vendor-Specific	73	ARAP-Security
27	Session-Timeout	74	ARAP-Security-Data
28	Idle-Timeout	75	Password-Retry
29	Termination-Action	76	Prompt
30	Called-Station-Id	77	Connect-Info
31	Calling-Station-Id	78	Configuration-Token
32	NAS-Identifier	79	EAP-Message
33	Proxy-State	80	Message-Authenticator
34	Login-LAT-Service	81	Tunnel-Private-Group-id
35	Login-LAT-Node	82	Tunnel-Assignment-id
36	Login-LAT-Group	83	Tunnel-Preference
37	Framed-AppleTalk-Link	84	ARAP-Challenge-Response
38	Framed-AppleTalk-Network	85	Acct-Interim-Interval
39	Framed-AppleTalk-Zone	86	Acct-Tunnel-Packets-Lost
40	Acct-Status-Type	87	NAS-Port-Id
41	Acct-Delay-Time	88	Framed-Pool
42	Acct-Input-Octets	89	(unassigned)
43	Acct-Output-Octets	90	Tunnel-Client-Auth-id
44	Acct-Session-Id	91	Tunnel-Server-Auth-id

Extended RADIUS attributes

Attribute 26 (Vendor-Specific), an attribute defined in RFC 2865, allows a vendor to define extended attributes to implement functions that the standard RADIUS protocol does not provide.

A vendor can encapsulate multiple sub-attributes as TLVs in attribute 26 to provide extended functions. As shown in Figure 5, a sub-attribute encapsulated in attribute 26 consists of the following parts:

· Vendor-ID—ID of the vendor. Its most significant byte is 0. The other three bytes contains a code that is compliant to RFC 1700. The vendor ID of H3C is 25506. For more information about the proprietary RADIUS sub-attributes of H3C, see "H3C proprietary RADIUS sub-attributes."

· Vendor-Type—Type of the sub-attribute.

· Vendor-Length—Length of the sub-attribute.

· Vendor-Data—Contents of the sub-attribute.

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). Similar to RADIUS, it uses a client/server model for information exchange between the NAS and the HWTACACS server.

HWTACACS typically provides AAA services for PPP, VPDN, and terminal users. In a typical HWTACACS scenario, some terminal users need to log in to the NAS for operations. Working as the HWTACACS client, the NAS sends users' usernames and passwords to the HWTACACS sever for authentication. After passing authentication and getting 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 user information security, and providing flexibility and extensibility. Table 3 lists the primary differences.

Table 3 Primary differences between HWTACACS and RADIUS

HWTACACS	RADIUS
Uses TCP, providing more reliable network transmission.	Uses UDP, providing higher transport efficiency.
Encrypts the entire packet except for the HWTACACS header.	Encrypts only the user password field in an authentication packet.
Protocol packets are complicated and authorization is independent of authentication. Authentication and authorization can be deployed on different HWTACACS servers.	Protocol packets are simple and the authorization process is combined with the authentication process.
Supports authorization of configuration commands. Commands a user can access depend on both the user level and AAA authorization. A user can use only commands that are at, or lower than, the user level and authorized by the HWTACACS server.	Does not support authorization of configuration commands. Commands a user can access solely depend on the level of the user. A user can use all the commands at, or lower than, the user level.

Basic HWTACACS message exchange process

The following example describes how HWTACACS performs user authentication, authorization, and accounting for a Telnet user.

Figure 6 Basic HWTACACS message exchange process for a Telnet user

HWTACACS operates in the following manner:

1. A Telnet user sends an access request to the HWTACACS client.

2. Upon receiving the request, the HWTACACS client sends a start-authentication packet to the HWTACACS server.

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

7. The HWTACACS server sends back an authentication response, requesting the login password.

8. Upon receipt of the response, the HWTACACS client asks the user for the login password.

9. The user enters the password.

10. After receiving the login password, the HWTACACS client sends the HWTACACS server a continue-authentication packet that carries the login password.

11. The HWTACACS server sends back an authentication response to indicate that the user has passed authentication.

12. The HWTACACS client sends the user authorization request packet to the HWTACACS server.

13. The HWTACACS server sends back the 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.

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.

Domain-based user management

A NAS manages users based on ISP domains. On a NAS, each user belongs to one ISP domain. A NAS determines the ISP domain for a user by the username entered by the user at login, as shown in Figure 7.

Figure 7 Determining the ISP domain of a user by the username

Authentication, authorization, and accounting of a user depends on the AAA methods configured for the domain that the user belongs to. If no specific AAA methods are configured for the domain, the default methods are used. By default, a domain uses local authentication, local authorization, and local accounting.

AAA allows you to manage users based on their access types:

· LAN users—Users on a LAN who must pass 802.1X or MAC address authentication to access the network.

· Login users—Users who want to log in to the device, including SSH users, Telnet users, Web users, FTP users, and terminal users.

· Portal users—Users who must pass portal authentication to access the network.

· PPP users—Users who access through PPP.

In addition, AAA provides the following services for login users to enhance device security:

· Command authorization—Enables the NAS to defer to the authorization server to determine whether a command entered by a login user is permitted, and allows login users to execute only authorized commands. For more information about command authorization, see Fundamentals Configuration Guide.

· Command accounting—Allows the accounting server to record all commands executed on the device or all authorized commands successfully executed. For more information about command accounting, see Fundamentals Configuration Guide.

· Level switching authentication—Allows the authentication server to authenticate users who perform privilege level switching. As long as passing level switching authentication, users can switch their user privilege levels, without logging out and disconnecting current connections. For more information about user privilege level switching, see Fundamentals Configuration Guide.

You can configure different AAA methods for different types of users in a domain. See "Configuring AAA methods for ISP domains."

Protocols and standards

The following protocols and standards are related to AAA, RADIUS, and HWTACACS:

· 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 1492, An Access Control Protocol, Sometimes Called TACACS

RADIUS attributes

This section provides tables of commonly used standard RADIUS attributes and H3C proprietary RADIUS sub-attributes.

Commonly used standard RADIUS attributes

No.	Attribute	Description
1	User-Name	Name of the user to be authenticated.
2	User-Password	User password for PAP authentication, only present in Access-Request packets when PAP authentication is used.
3	CHAP-Password	Digest of the user password for CHAP authentication, only present in Access-Request packets when CHAP authentication is used.
4	NAS-IP-Address	IP address for the server to use to identify a client. Usually, a client is identified by the IP address of its access interface. This attribute is only present in Access-Request packets.
5	NAS-Port	Physical port of the NAS that the user accesses.
6	Service-Type	Type of service that the user has requested or type of service to be provided.
7	Framed-Protocol	Encapsulation protocol for framed access.
8	Framed-IP-Address	IP address assigned to the user.
11	Filter-ID	Name of the filter list.
12	Framed-MTU	MTU for the data link between the user and NAS. For example, with 802.1X EAP authentication, NAS uses this attribute to notify the server of the MTU for EAP packets, so as to avoid oversized EAP packets.
14	Login-IP-Host	IP address of the NAS interface that the user accesses.
15	Login-Service	Type of the service that the user uses for login.
18	Reply-Message	Text to be displayed to the user, which can be used by the server to indicate, for example, the reason of the authentication failure.
26	Vendor-Specific	Vendor specific attribute. A packet can contain one or more such proprietary attributes, each of which can contain one or more sub-attributes.
27	Session-Timeout	Maximum service duration for the user before termination of the session.
28	Idle-Timeout	Maximum idle time permitted for the user before termination of the session.
31	Calling-Station-Id	User identification that the NAS sends to the server. For the LAN access service provided by an H3C device, this attribute carries the MAC address of the user in the format HHHH-HHHH-HHHH.
32	NAS-Identifier	Identification that the NAS uses to identify itself to the RADIUS server.
40	Acct-Status-Type	Type of the Accounting-Request packet. Possible values include: · 1—Start. · 2—Stop. · 3—Interim-Update. · 4—Reset-Charge. · 7—Accounting-On. (Defined in the 3rd Generation Partnership Project.) · 8—Accounting-Off. (Defined in the 3rd Generation Partnership Project.) · 9 to 14—Reserved for tunnel accounting. · 15—Reserved for failed.
45	Acct-Authentic	Authentication method used by the user. Possible values include: · 1—RADIUS. · 2—Local. · 3—Remote.
60	CHAP-Challenge	CHAP challenge generated by the NAS for MD5 calculation during CHAP authentication.
61	NAS-Port-Type	Type of the physical port of the NAS that is authenticating the user. Possible values include: · 15—Ethernet. · 16—Any type of ADSL. · 17—Cable (with cable for cable TV). · 19—WLAN-IEEE 802.11. · 201—VLAN. · 202—ATM. If the port is an ATM or Ethernet one and VLANs are implemented on it, the value of this attribute is 201.
79	EAP-Message	Used to encapsulate EAP packets to allow RADIUS to support EAP authentication.
80	Message-Authenticator	Used for authentication and verification of authentication packets to prevent spoofing Access-Requests. This attribute is present when EAP authentication is used.
87	NAS-Port-Id	String for describing the port of the NAS that is authenticating the user.

H3C proprietary RADIUS sub-attributes

No.	Sub-attribute	Description
1	Input-Peak-Rate	Peak rate in the direction from the user to the NAS, in bps.
2	Input-Average-Rate	Average rate in the direction from the user to the NAS, in bps.
3	Input-Basic-Rate	Basic rate in the direction from the user to the NAS, in bps.
4	Output-Peak-Rate	Peak rate in the direction from the NAS to the user, in bps.
5	Output-Average-Rate	Average rate in the direction from the NAS to the user, in bps.
6	Output-Basic-Rate	Basic rate in the direction from the NAS to the user, in bps.
15	Remanent_Volume	Total remaining available traffic for the connection, in different units for different server types.
20	Command	Operation for the session, used for session control. Possible values include: · 1—Trigger-Request. · 2—Terminate-Request. · 3—SetPolicy. · 4—Result. · 5—PortalClear.
24	Control_Identifier	Identification for retransmitted packets. For retransmitted packets of the same session, this attribute must take the same value. For retransmitted packets of different sessions, this attribute may take the same value. The client response of a retransmitted packet must also carry this attribute and the value of this attribute must be the same. For Accounting-Request packets of the start, stop, and interim update types, the Control-Identifier attribute, if present, makes no sense.
25	Result_Code	Result of the Trigger-Request or SetPolicy operation, zero for success and any other value for failure.
26	Connect_ID	Index of the user connection.
28	Ftp_Directory	FTP user working directory. When the RADIUS client acts as the FTP server, this attribute is used to set the FTP directory for an FTP user on the RADIUS client.
29	Exec_Privilege	EXEC user priority.
59	NAS_Startup_Timestamp	Startup time of the NAS in seconds, which is represented by the time elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
60	Ip_Host_Addr	User IP address and MAC address carried in authentication and accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space is required between the IP address and the MAC address.
61	User_Notify	Information that must be sent from the server to the client transparently.
62	User_HeartBeat	Hash value assigned after an 802.1X user passes authentication, which is a 32-byte string. This attribute is stored in the user list on the NAS and is used for verifying the handshake messages from the 802.1X user. This attribute only exists in Access-Accept and Accounting-Request packets.
140	User_Group	User groups assigned after the SSL VPN user passes authentication. A user may belong to more than one user group. In this case, the user groups are delimited by semi-colons. This attribute is used for cooperation with the SSL VPN device.
141	Security_Level	Security level assigned after the SSL VPN user passes security authentication.
201	Input-Interval-Octets	Number of bytes input within a real-time accounting interval.
202	Output-Interval-Octets	Number of bytes output within a real-time accounting interval.
203	Input-Interval-Packets	Number of packets input within an accounting interval, in the unit set on the NAS.
204	Output-Interval-Packets	Number of packets output within an accounting interval, in the unit set on the NAS.
205	Input-Interval-Gigawords	Amount of bytes input within an accounting interval, in units of 4G bytes.
206	Output-Interval-Gigawords	Amount of bytes output within an accounting interval, in units of 4G bytes.
207	Backup-NAS-IP	Backup source IP address for sending RADIUS packets.
255	Product_ID	Product name.

AAA configuration considerations and task list

To configure AAA on the NAS:

1. Configure the required AAA schemes.

¡ Local authentication—Configure local users and the related attributes, including the usernames and passwords for the users to be authenticated.

¡ Remote authentication—Configure the required RADIUS and HWTACACS schemes. You must configure user attributes on the servers accordingly.

2. Configure AAA methods for the ISP domain.

¡ Authentication method—No authentication (none), local authentication (local), or remote authentication (scheme)

¡ Authorization method—No authorization (none), local authorization (local), or remote authorization (scheme)

¡ Accounting method—No accounting (none), local accounting (local), or remote accounting (scheme)

See Figure 8 for the configuration procedure.

Figure 8 AAA configuration procedure

Table 4 AAA configuration task list

Task		Remarks
Configuring AAA schemes	Configuring local users	Required. Complete at least one task.
	Configuring RADIUS schemes
	Configuring HWTACACS schemes
Configuring AAA methods for ISP domains	Creating an ISP domain	Required.
	Configuring ISP domain attributes	Optional.
	Configuring authentication methods for an ISP domain	Required. Complete at least one task.
	Configuring authorization methods for an ISP domain
	Configuring accounting methods for an ISP domain
Tearing down user connections		Optional.

NOTE:

To use AAA methods to control access of login users, you must configure the user interfaces to use AAA by using the authentication-mode command. For more information, see Fundamentals Configuration Guide.

Configuring AAA schemes

Configuring local users

To implement local AAA, you must 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 a username. Configurable local user attributes are as follows:

· 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, LAN access, portal, PPP, SSH, Telnet, terminal, and Web.

· User state.

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

· Maximum number of users using the same local user account.

Indicates how many users can use the same local user account for local authentication.

· Validity time and expiration time.

Indicates the validity time and expiration time of a local user account. A user must use a valid local user account to pass local authentication. When some users need to access the network temporarily, you can create a guest account and specify a validity time and an expiration time for the account to control the validity of the account.

· User group.

Each local user belongs to a local user group and bears the authorization attributes of the group. For more information about local user group, see "Configuring user group attributes."

· Binding attributes.

Binding attributes are used for controlling the scope of users. They 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 ISDN calling number, IP address, access port, MAC address, and native VLAN.

· Authorization attributes.

Authorization attributes indicate the rights that a user has after passing local authentication. Authorization attributes include the ACL, PPP callback number, idle cut function, user level, user role, VLAN, and FTP/SFTP work directory. For more information about authorization attributes, see "Configuring local user attributes."

Every configurable authorization attribute has its definite application environments and purposes. When you configure authorization attributes for a local user, consider which attributes are needed and which are not. For example, for PPP users, you do not need to configure the work directory attribute.

You can configure an authorization attribute in user group view or local user view to make the attribute effective for all local users in the group or for only the local user. The setting of an authorization attribute in local user view takes precedence over that in user group view.

Local user configuration task list

Task	Remarks
Configuring local user attributes	Required.
Configuring user group attributes	Optional.
Displaying and maintaining local users and local user groups	Optional.

Configuring local user attributes

Follow these guidelines when you configure local user attributes:

· If the user interface authentication mode set by the authentication-mode command in user interface view is AAA (scheme), which commands a login user can use after login depends on the privilege level authorized to the user. If the user interface authentication mode is password (password) or no authentication (none), which commands a login user can use after login depends on the level configured for the user interface by using the user privilege level command in user interface view. For an SSH user using public key authentication, which commands are available depends on the level configured for the user interface. For more information about user interface authentication mode and user interface command level, see Fundamentals Configuration Guide.

· You cannot delete a local user who is the only security log manager in the system, nor can you change or delete the security log manager role of the user. To do so, you must specify a new security log manager first.

To configure local user attributes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Add a local user and enter local user view.	local-user user-name	By default, a local user named admin exists on the device.
3. Configure a password for the local user.	password [ { hash simple \| cipher \| simple } password ]	Optional. A local user with no password configured directly passes authentication after providing the valid local username and attributes. To enhance security, configure a password for each local user.
4. Assign service types for the local user.	service-type { ftp \| lan-access \| { ssh \| telnet \| terminal } * \| portal \| ppp \| web }	By default, no service is authorized to a local user.
5. Place the local user to the active or blocked state.	state { active \| block }	Optional. By default, a created local user is in active state and can request network services.
6. Set the maximum number of concurrent users of the local user account.	access-limit max-user-number	Optional. By default, there is no limit to the maximum number of concurrent users of a local user account. The limit is effective only for local accounting, and is not effective for FTP users.
7. Configure binding attributes for the local user.	bind-attribute { call-number call-number [ : subcall-number ] \| ip ip-address \| location port slot-number subslot-number port-number \| mac mac-address \| vlan vlan-id } *	Optional. By default, no binding attribute is configured for a local user.
8. Configure authorization attributes for the local user.	authorization-attribute { acl acl-number \| callback-number callback-number \| idle-cut minute \| level level \| user-role { guest \| guest-manager \| security-audit } \| vlan vlan-id \| work-directory directory-name } *	Optional. By default, no authorization attribute is configured for a local user. For PPP users, only acl, callback-number, and idle-cut are supported. For LAN and portal users, only acl, idle-cut, and vlan are supported. For SSH, terminal, and Web users, only level is supported. For FTP users, only level and work-directory are supported. For Telnet users, only level and user-role is supported. For other types of local users, no authorization attribute is supported.
9. Set the validity time of the local user.	validity-date time	Optional. Not set by default.
10. Set the expiration time of the local user.	expiration-date time	Optional. Not set by default.
11. Assign the local user to a user group.	group group-name	Optional. By default, a local user belongs to the default user group system.

Configuring user group attributes

User groups simplify local user configuration and management. A user group comprises 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. Configurable user attributes include authorization attributes.

By default, every newly added local user belongs to the default user group system and bears all attributes of the group. To assign a local user to a different user group, use the user-group command in local user view.

To configure attributes for a user group:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a user group and enter user group view.	user-group group-name	N/A
3. Configure authorization attributes for the user group.	authorization-attribute { acl acl-number \| callback-number callback-number \| idle-cut minute \| level level \| vlan vlan-id \| work-directory directory-name } *	Optional. By default, no authorization attribute is configured for a user group.
4. Set the guest attribute for the user group.	group-attribute allow-guest	Optional. By default, the guest attribute is not set for a user group, and guest users created by a guest manager through the Web interface cannot join the group.

Displaying and maintaining local users and local user groups

Task	Command	Remarks
Display local user information.	display local-user [ idle-cut { disable \| enable } \| service-type { ftp \| lan-access \| portal \| ppp \| ssh \| telnet \| terminal \| web } \| state { active \| block } \| user-name user-name \| vlan vlan-id ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display the user group configuration.	display user-group [ group-name ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.

Configuring RADIUS schemes

A RADIUS scheme specifies the RADIUS servers that the device can cooperate with and defines a set of parameters that the device uses to exchange information with the RADIUS servers. There might be authentication/authorization servers and accounting servers, or primary servers and secondary servers. The parameters include the IP addresses of the servers, the shared keys, and the RADIUS server type.

RADIUS scheme configuration task list

Task	Remarks
Creating a RADIUS scheme	Required
Specifying the RADIUS authentication/authorization servers	Required
Specifying the RADIUS accounting servers and the relevant parameters	Optional
Specifying the shared keys for secure RADIUS communication	Optional
Setting the username format and traffic statistics units	Optional
Setting the supported RADIUS server type	Optional
Setting the maximum number of RADIUS request transmission attempts	Optional
Setting the status of RADIUS servers	Optional
Specifying the source IP address for outgoing RADIUS packets	Optional
Setting RADIUS timers	Optional
Configuring RADIUS accounting-on	Optional
Configuring the IP address of the security policy server	Optional
Enabling the trap function for RADIUS	Optional
Enabling the RADIUS client service	Optional
Displaying and maintaining RADIUS	Optional

Creating a RADIUS scheme

Before you perform other RADIUS configurations, first create a RADIUS scheme and enter RADIUS scheme view. A RADIUS scheme can be referenced by multiple ISP domains at the same time.

To create a RADIUS scheme and enter RADIUS scheme view:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a RADIUS scheme and enter RADIUS scheme view.	radius scheme radius-scheme-name	By default, no RADIUS scheme is created.

Specifying the RADIUS authentication/authorization servers

In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS clients. It is neither allowed nor needed to specify a separate RADIUS authorization server.

You can specify one primary authentication/authorization server and up to 16 secondary authentication/authorization servers for a RADIUS scheme. When the primary server is not available, a secondary server is used. If no redundancy is needed, specify only the primary server.

A RADIUS authentication/authorization server can function as the primary authentication/authorization server for one scheme and a secondary authentication/authorization server for another scheme at the same time.

You can enable the server status detection feature. With the feature, the device periodically sends an authentication request to check whether or not the target RADIUS authentication/authorization server is reachable. If the server can be reached, the device sets the status of the server to active. If the server cannot be reached, the device sets the status of the server to block. This feature can promptly notify authentication modules of latest server status information.

To specify RADIUS authentication/authorization servers for a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Specify RADIUS authentication/authorization servers.	· Specify the primary RADIUS authentication/authorization server: primary authentication { ip-address \| ipv6 ipv6-address } [ port-number \| key [ cipher \| simple ] key \| probe username name [ interval interval ] ] * · Specify a secondary RADIUS authentication/authorization server: secondary authentication { ip-address \| ipv6 ipv6-address } [ port-number \| key [ cipher \| simple ] key \| probe username name [ interval interval ] ] *	Configure at least one command. By default, no authentication/authorization server is specified. The IP addresses of the primary and secondary authentication/authorization servers for a scheme must be different. Otherwise, the configuration will fail. All servers for authentication/authorization and accounting, primary or secondary, must use IP addresses of the same IP version.

Specifying the RADIUS accounting servers and the relevant parameters

You can specify one primary accounting server and up to 16 secondary accounting servers for a RADIUS scheme. When the primary server is not available, a secondary server is used. When 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 the device receives a connection teardown request from a host or a connection teardown command from an administrator, it sends a stop-accounting request to the accounting server. When the maximum number of real-time accounting attempts is reached, the device disconnects users who have no accounting responses. You can enable buffering of non-responded stop-accounting requests to allow the device to buffer and resend a stop-accounting request until it receives a response. If the number of stop-accounting attempts reaches the upper limit, the device discards the buffered request.

If you delete an accounting server that is serving users, the device no longer sends real-time accounting requests or stop-accounting requests for the users to that server, or buffers the stop-accounting requests.

RADIUS does not support accounting for FTP users.

You can enable the server status detection feature. With the feature, the device periodically sends an accounting request to check whether or not the target RADIUS accounting server is reachable. If the server can be reached, the device sets the status of the server to active. If the server cannot be reached, the device sets the status of the server to block. This feature can promptly notify authentication modules of latest server status information.

To specify RADIUS accounting servers and set relevant parameters for a scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Specify RADIUS accounting servers.	· Specify the primary RADIUS accounting server: primary accounting { ip-address \| ipv6 ipv6-address } [ port-number \| key [ cipher \| simple ] key \| probe username name [ interval interval ] ] * · Specify a secondary RADIUS accounting server: secondary accounting { ip-address \| ipv6 ipv6-address } [ port-number \| key [ cipher \| simple ] key \| probe username name [ interval interval ] ] *	Configure at least one command. No accounting server is specified by default. The IP addresses of the primary and secondary accounting servers must be different from each other. Otherwise, the configuration fails. All servers for authentication/authorization and accounting, primary or secondary, must use IP addresses of the same IP version.
4. Set the maximum number of real-time accounting attempts.	retry realtime-accounting retry-times	Optional. The default setting is 5.
5. Enable buffering of stop-accounting requests to which no responses are received.	stop-accounting-buffer enable	Optional. Enabled by default.
6. Set the maximum number of stop-accounting attempts.	retry stop-accounting retry-times	Optional. The default setting is 500.

Specifying the shared keys for secure RADIUS communication

The RADIUS client and RADIUS server use the MD5 algorithm and a shared key pair for packet authentication and password encryption in a certain type of communication.

A shared key configured in RADIUS scheme view applies to all servers of the specified type (accounting or authentication) in that scheme, and has a lower priority than those configured for individual RADIUS servers.

To specify a shared key for secure RADIUS communication:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Specify a shared key for secure RADIUS authentication/authorization or accounting communication.	key { accounting \| authentication } [ cipher \| simple ] key	By default, no shared key is specified. The shared key configured on the device must be the same as that configured on the RADIUS server.

Setting the username format and traffic statistics units

A username is usually in the format userid@isp-name, where isp-name represents the user's ISP domain name. By default, the ISP domain name is included in a username; however, some earlier RADIUS servers do not recognize usernames that contain the ISP domain names. In this case, you can configure the device to remove the domain name from each username to be sent.

The device periodically sends accounting updates to RADIUS accounting servers to report the traffic statistics of online users. For normal and accurate traffic statistics, make sure that the unit for data flows and that for packets on the device are consistent with those on the RADIUS server.

To set the username format and the traffic statistics units for a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Set the format for usernames sent to the RADIUS servers.	user-name-format { keep-original \| with-domain \| without-domain }	Optional. By default, the ISP domain name is included in a username.
4. Specify the unit for data flows or packets sent to the RADIUS servers.	data-flow-format { data { byte \| giga-byte \| kilo-byte \| mega-byte } \| packet { giga-packet \| kilo-packet \| mega-packet \| one-packet } }*	Optional. The default unit is byte for data flows and one-packet for data packets.

Do not apply the RADIUS scheme to more than one ISP domain if you have configured the user-name-format without-domain command for that RADIUS scheme. Otherwise, users in different ISP domains are considered the same user if they use the same username.

For level switching authentication, user-name-format keep-original and user-name-format without-domain commands all produce the same results: they make sure that usernames sent to the RADIUS server carry no ISP domain name.

Setting the supported RADIUS server type

The supported RADIUS server type determines the type of the RADIUS protocol that the device uses to communicate with the RADIUS server. It can be standard or extended:

· Standard—Uses the standard RADIUS protocol, compliant to RFC 2865 and RFC 2866 or later.

· Extended—Uses the proprietary RADIUS protocol of H3C.

When the RADIUS server runs on IMC, you must set the RADIUS server type to extended. When the RADIUS server runs third-party RADIUS server software, either RADIUS server type applies.

To set the RADIUS server type:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Set the RADIUS server type.	server-type { extended \| standard }	Optional. The default RADIUS server type is standard.

NOTE:

Changing the RADIUS server type will restore the unit for data flows and that for packets that are sent to the RADIUS server to the defaults.

Setting the maximum number of RADIUS request transmission attempts

RADIUS uses UDP packets to transfer data. UDP communication is not reliable. To improve reliability, RADIUS uses a retransmission mechanism. If a NAS sends a RADIUS request to a RADIUS server but receives no response before the response timeout timer (defined by the timer response-timeout command) expires, it retransmits the request. If the number of transmission attempts exceeds the specified limit but it still receives no response, it tries to communicate with other RADIUS servers in active state. If no other servers are in active state at the time, it considers the authentication or accounting attempt a failure. For more information about RADIUS server states, see "Setting the status of RADIUS servers."

The maximum number of transmission attempts of RADIUS packets multiplied by the RADIUS server response timeout period cannot be greater than 75 seconds. For more information about the RADIUS server response timeout timer, see "Setting RADIUS timers."

To set the maximum number of RADIUS request transmission attempts for a scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Set the maximum number of RADIUS request transmission attempts.	retry retry-times	Optional. The default setting is 3.

Setting the status of RADIUS servers

By setting the status of RADIUS servers to blocked or active, you can control the AAA servers with which the device communicates when the current servers are no longer available. In practice, you can specify one primary RADIUS server and multiple secondary RADIUS servers, with the secondary servers functioning as the backup of the primary servers. Typically, the device chooses servers based on these rules:

· When the primary server is in active state, the device communicates with the primary server.

If the primary server fails, the device changes the server's status to blocked, starts a quiet timer for the server, and tries to communicate with a secondary server in active state (a secondary server configured earlier has a higher priority).

If the secondary server is unreachable, the device changes the server's status to blocked, starts a quiet timer for the server, and continues to check the next secondary server in active state. This search process continues until the device finds an available secondary server or has checked all secondary servers in active state.

If the quiet timer of a server expires or an authentication or accounting response is received from the server, the status of the server changes back to active automatically, but the device does not check the server again during the authentication or accounting process.

If no server is found reachable during one search process, the device considers the authentication or accounting attempt a failure.

· Once the accounting process of a user starts, the device keeps sending the user's real-time accounting requests and stop-accounting requests to the same accounting server.

· If you remove the accounting server, real-time accounting requests and stop-accounting requests for the user are no longer delivered to the server.

· If you remove an authentication or accounting server in use, the communication of the device with the server will soon time out, and the device will look for a server in active state by checking the primary server first and then the secondary servers in the order they are configured.

· When the primary server and secondary servers are all in blocked state, the device communicates with the primary server. If the primary server is available, its status changes to active. Otherwise, its status remains to be blocked.

· If one server is in active state and all the others are in blocked state, the device only tries to communicate with the server in active state, even if the server is unavailable.

· After receiving an authentication/accounting response from a server, the device changes the status of the server identified by the source IP address of the response to active if the current status of the server is blocked.

The device does not change the status of an unreachable authentication or accounting server if the server quiet timer is set to 0. Instead, the device keeps the server status as active and sends authentication or accounting packets to another server in active state, so subsequent authentication or accounting packets can still be sent to that server. For more information about the server quiet timer, see "Setting RADIUS timers."

By default, the device sets the status of all RADIUS servers to active. In some cases, however, you may need to 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.

To set the status of RADIUS servers in a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Set the RADIUS server status.	· Set the status of the primary RADIUS authentication/authorization server: state primary authentication { active \| block } · Set the status of the primary RADIUS accounting server: state primary accounting { active \| block } · Set the status of a secondary RADIUS authentication/authorization server: state secondary authentication [ ip ipv4-address \| ipv6 ipv6-address ] { active \| block } · Set the status of a secondary RADIUS accounting server: state secondary accounting [ ip ipv4-address \| ipv6 ipv6-address ] { active \| block }	Optional. By default, all servers in the RADIUS scheme are in active state.

The server status set by the state command cannot be saved to the configuration file. After the device restarts, the status of each server is restored to active.

To display the states of the servers, use the display radius scheme command.

Specifying the source IP address for outgoing RADIUS packets

The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon receiving a RADIUS packet, a RADIUS server checks whether the source IP address of the packet is the IP address of any managed NAS. If yes, the server processes the packet. If not, the server drops the packet.

The source address of outgoing RADIUS packets is typically the IP address of an egress interface on the NAS to communicate with the RADIUS server. In some cases, however, you must change the source IP address. For example, if a NAT device is present between the NAS and the RADIUS server, the source IP address of outgoing RADIUS packets must be a public IP address of the NAS.

You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view for a specific RADIUS scheme, or in system view for all RADIUS schemes. Before sending a RADIUS packet, the NAS selects a source IP address in the following order:

1. The source IP address specified for the RADIUS scheme.

2. The source IP address specified in system view.

3. The IP address of the outbound interface specified by the route.

To specify a source IP address for all RADIUS schemes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify a source IP address for outgoing RADIUS packets.	radius nas-ip { ip-address \| ipv6 ipv6-address }	By default, the IP address of the outbound interface is used as the source IP address.

To specify a source IP address for a specific RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Specify a source IP address for outgoing RADIUS packets.	nas-ip { ip-address \| ipv6 ipv6-address }	By default, the IP address of the outbound interface is used as the source IP address.

Setting RADIUS timers

The device uses the following types of timers to control the communication with a RADIUS server:

· Server response timeout timer (response-timeout)—Defines the RADIUS request retransmission interval. After sending a RADIUS request (authentication/authorization or accounting request), the device starts the server response timeout timer. If the device receives no 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's 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. To implement real-time accounting, the device must periodically send real-time accounting packets to the accounting server for online users.

Follow these guidelines when you set RADIUS timers:

· For the same type of users, the maximum number of transmission attempts multiplied by the RADIUS server response timeout period must be less than the client connection timeout time and cannot exceed 75 seconds. Otherwise, stop-accounting messages cannot be buffered, and the primary/secondary server switchover cannot take place. For example, the product of the two parameters must be less than 10 seconds for voice users and less than 30 seconds for Telnet users, because the client connection timeout period for voice users is 10 seconds and that for Telnet users is 30 seconds.

· When you configure the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout timer, consider the number of secondary servers. If the retransmission process takes too long, the client connection in the access module may time out while the device is trying to find an available server. For more information about the maximum number of RADIUS packet transmission attempts, see "Setting the maximum number of RADIUS request transmission attempts."

· When a number of secondary servers are configured, the client connections of access modules that have a short client connection timeout period may still be timed out during initial authentication or accounting, even if the packet transmission attempt limit and server response timeout period are configured with small values. In this case, the next authentication or accounting attempt can succeed because the device has set the status of the unreachable servers to blocked so time for finding a reachable server is shortened.

· Properly set the server quiet timer. Too short a quiet timer can result in frequent authentication or accounting failures because the device has to repeatedly attempt to communicate with an unreachable server that is in active state.

To set RADIUS timers:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Set the RADIUS server response timeout timer.	timer response-timeout seconds	Optional. The default RADIUS server response timeout timer is 3 seconds.
4. Set the server quiet timer.	timer quiet minutes	Optional. The default server quiet timer is 5 minutes.
5. Set the real-time accounting interval.	timer realtime-accounting minutes	Optional. The default real-time accounting interval is 12 minutes.

Configuring RADIUS accounting-on

The accounting-on feature enables the device to send an accounting-on packet to the RADIUS server after it reboots so the server can log out users who logged in through the device before the reboot. Without this feature, users who were online before the reboot could not re-log in after the reboot, because the RADIUS server would consider them already online.

If the device receives no response to the accounting-on packet, it re-sends the packet to the RADIUS server at a particular interval for a specified number of times.

The accounting-on feature requires the cooperation of the H3C IMC network management system.

To configure the accounting-on feature for a RADIUS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Enable accounting-on and configure parameters.	accounting-on enable [ interval seconds \| send send-times ] *	Disabled by default. The default interval is 3 seconds, and the default number of send-times is 5.

Configuring the IP address of the security policy server

The core of the H3C EAD solution is integration and cooperation. The security policy server is the management and control center for EAD. Using a collection of software, the security policy server provides functions such as user management, security policy management, security status assessment, security cooperation control, and security event audit.

The NAS checks the validity of received control packets and accepts only control packets from known servers. To use a security policy server that is independent of the AAA servers, you must configure the IP address of the security policy server on the NAS. To implement all EAD functions, configure both the IP address of the security policy server and the IP address of the IMC Platform on the NAS.

To configure the IP address of the security policy server for a scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Specify a security policy server.	security-policy-server ip-address	No security policy server is specified by default. You can specify up to eight security policy servers for a RADIUS scheme.

Enabling the trap function for RADIUS

With the trap function, the NAS sends a trap message when either of the following events occurs:

· The status of a RADIUS server changes. If the NAS receives no response to an accounting or authentication request before the specified maximum number of RADIUS request transmission attempts is exceeded, it considers the server unreachable, sets the status of the server to block and sends a trap message. If the NAS receives a response from a RADIUS server that it considers unreachable, the NAS considers that the RADIUS server is reachable again, sets the status of the server to active, and sends a trap message.

· The ratio of the number of failed transmission attempts to the total number of authentication request transmission attempts reaches the threshold. This threshold ranges from 1% to 100% and defaults to 30%. This threshold can only be configured through the MIB.

The failure ratio is typically small. If a trap message is triggered because the failure ratio is higher than the threshold, troubleshoot the configuration on and the communication between the NAS and the RADIUS server.

To enable the trap function for RADIUS:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the trap function for RADIUS.	radius trap { accounting-server-down \| authentication-error-threshold \| authentication-server-down }	Disabled by default.

Enabling the RADIUS client service

To receive and send RADIUS packets, enable the RADIUS client service on the device. If RADIUS is not required, disable the RADIUS client service to avoid attacks that exploit RADIUS packets.

To enable the RADIUS client service:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the RADIUS client service.	radius client enable	Optional. Enabled by default.

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Enable the RADIUS client service.

radius client enable

Optional.

Enabled by default.

Displaying and maintaining RADIUS

Task	Command	Remarks
Display the configuration of RADIUS schemes.	display radius scheme [ radius-scheme-name ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display the RADIUS packet statistics.	display radius statistics [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about buffered stop-accounting requests for which no responses have been received.	display stop-accounting-buffer { radius-scheme radius-scheme-name \| session-id session-id \| time-range start-time stop-time \| user-name user-name } [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Clear RADIUS statistics.	reset radius statistics	Available in user view.
Clear the buffered stop-accounting requests for which no responses have been received.	reset stop-accounting-buffer { radius-scheme radius-scheme-name \| session-id session-id \| time-range start-time stop-time \| user-name user-name }	Available in user view.

Configuring HWTACACS schemes

You cannot remove the HWTACACS schemes in use or change the IP addresses of the HWTACACS servers in use.

HWTACACS configuration task list

Task	Remarks
Creating an HWTACACS scheme	Required
Specifying the HWTACACS authentication servers	Required
Specifying the HWTACACS authorization servers	Optional
Specifying the HWTACACS accounting servers and the relevant parameters	Optional
Specifying the shared keys for secure HWTACACS communication	Required
Setting the username format and traffic statistics units	Optional
Specifying the source IP address for outgoing HWTACACS packets	Optional
Setting HWTACACS timers	Optional
Displaying and maintaining HWTACACS	Optional

Creating an HWTACACS scheme

The HWTACACS protocol is configured on a per scheme basis. Before you perform other HWTACACS configurations, create an HWTACACS scheme and enter HWTACACS scheme view. You can configure up to 16 HWTACACS schemes.

To create an HWTACACS scheme and enter HWTACACS scheme view:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an HWTACACS scheme and enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	Not defined by default.

You can delete an HWTACACS scheme only when it is not referenced.

Specifying the HWTACACS authentication servers

You can specify one primary authentication server and one secondary authentication server for an HWTACACS scheme. When the primary server is not available, the secondary server is used. If no redundancy is needed, specify only the primary server.

An HWTACACS server can function as the primary authentication server of one scheme and as the secondary authentication server of another scheme at the same time. You cannot specify the same IP address as both the primary and the secondary authentication servers in a scheme.

To specify HWTACACS authentication servers for an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Specify HWTACACS authentication servers.	· Specify the primary HWTACACS authentication server: primary authentication ip-address [ port-number ] · Specify a secondary HWTACACS authentication server: secondary authentication ip-address [ port-number ]	Configure at least one command. No authentication server is specified by default.

You can remove an authentication server only when no active TCP connection for sending authentication packets is using it.

Specifying the HWTACACS authorization servers

You can specify one primary authorization server and one secondary authorization server for an HWTACACS scheme. When the primary server is not available, the secondary server is used. If no redundancy is needed, 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. You cannot specify the same IP address as both the primary and the secondary authorization servers in a scheme.

To specify HWTACACS authorization servers for an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Specify HWTACACS authorization servers.	· Specify the primary HWTACACS authorization server: primary authorization ip-address [ port-number ] · Specify a secondary HWTACACS authorization server: secondary authorization ip-address [ port-number ]	Configure at least one command. No authorization server is specified by default.

You can remove an authorization server only when no active TCP connection for sending authorization packets is using it.

Specifying the HWTACACS accounting servers and the relevant parameters

You can specify one primary accounting server and one secondary accounting server for an HWTACACS scheme. When the primary server is not available, the secondary server is used. If no redundancy is needed, specify only the primary server.

When the device receives a connection teardown request from a host or a connection teardown command from an administrator, it sends a stop-accounting request to the accounting server. You can enable buffering of non-responded stop-accounting requests to allow the device to buffer and resend a stop-accounting request until it receives a response or the number of stop-accounting attempts reaches the configured limit. In the latter case, the device discards the packet.

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. You cannot specify the same IP address as both the primary and the secondary accounting servers in a scheme.

HWTACACS does not support accounting for FTP users.

To specify HWTACACS accounting servers and set relevant parameters for an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Specify HWTACACS accounting servers.	· Specify the primary HWTACACS accounting server: primary accounting ip-address [ port-number ] · Specify a secondary HWTACACS accounting server: secondary accounting ip-address [ port-number ]	Configure at least one command. No accounting server is specified by default.
4. Enable buffering of stop-accounting requests to which no responses are received.	stop-accounting-buffer enable	Optional. Enabled by default.
5. Set the maximum number of stop-accounting attempts.	retry stop-accounting retry-times	Optional. The default setting is 100.

You can remove an accounting server only when no active TCP connection for sending accounting packets is using it.

Specifying the shared keys for secure HWTACACS communication

The HWTACACS client and HWTACACS server use the MD5 algorithm and a shared key pair for password encryption.

To specify a shared key for secure HWTACACS communication:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Specify a shared key for secure HWTACACS authentication, authorization, or accounting communication.	key { accounting \| authentication \| authorization } [ cipher \| simple ] key	By default, no shared key is specified. The shared key configured on the device must be the same as that configured on the HWTACACS server.

Setting the username format and traffic statistics units

A username is usually in the format userid@isp-name, where isp-name represents the user's ISP domain name. By default, the ISP domain name is included in a username; however, some HWTACACS servers do not recognize usernames that contain the ISP domain names. In this case, you can configure the device to remove the domain name from each username to be sent.

The device periodically sends accounting updates to HWTACACS accounting servers to report the traffic statistics of online users. For normal and accurate traffic statistics, make sure that the unit for data flows and that for packets on the device are consistent with those configured on the HWTACACS servers.

To set the username format and the traffic statistics units for an HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Set the format of usernames sent to the HWTACACS servers.	user-name-format { keep-original \| with-domain \| without-domain }	Optional. By default, the ISP domain name is included in a username.
4. Specify the unit for data flows or packets sent to the HWTACACS servers.	data-flow-format { data { byte \| giga-byte \| kilo-byte \| mega-byte } \| packet { giga-packet \| kilo-packet \| mega-packet \| one-packet } }*	Optional. The default unit is byte for data flows and one-packet for data packets.

If an HWTACACS server does not support a username that carries the domain name, configure the device to remove the domain name before sending the username to the server.

Specifying the source IP address for outgoing HWTACACS packets

The source IP address of HWTACACS packets that a NAS sends must match the IP address of the NAS configured on the HWTACACS server. An HWTACACS server identifies a NAS by IP address. Upon receiving an HWTACACS packet, an HWTACACS server checks whether the source IP address of the packet is the IP address of any managed NAS. If yes, the server processes the packet. If not, the server drops the packet.

The source address of outgoing HWTACACS packets is typically the IP address of an egress interface on the NAS to communicate with the HWTACACS server. In some cases, however, you must change the source IP address. For example, if a NAT device is present between the NAS and the HWTACACS server, the source IP address of outgoing HWTACACS packets must be a public IP address of the NAS.

You can specify the source IP address for outgoing HWTACACS packets in HWTACACS scheme view for a specific HWTACACS scheme, or in system view for all HWTACACS schemes.

Before sending an HWTACACS packet, the NAS selects a source IP address in the following order:

1. The source IP address specified for the HWTACACS scheme.

2. The source IP address specified in system view.

3. The IP address of the outbound interface specified by the route.

To specify a source IP address for all HWTACACS schemes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify a source IP address for outgoing HWTACACS packets.	hwtacacs nas-ip ip-address	By default, the IP address of the outbound interface is used as the source IP address.

To specify a source IP address for a specific HWTACACS scheme:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Specify a source IP address for outgoing HWTACACS packets.	nas-ip ip-address	By default, the IP address of the outbound interface is used as the source IP address.

Setting HWTACACS timers

The device uses the following timers to control the communication with an HWTACACS server:

· Server response timeout timer (response-timeout)—Defines the HWTACACS request retransmission interval. After sending an HWTACACS request (authentication, authorization, or accounting request), the device starts the server response timeout timer. If the device receives no response from the server before the timer expires, it resends the request.

· Primary server quiet timer (quiet)—Defines the duration to keep an unreachable primary server in blocked state. If a primary server is not reachable, the device changes the server's status to blocked, starts this timer for the server, and tries to communicate with the secondary server if the secondary server is configured and in active state. After the primary server quiet timer expires, the device changes the status of the primary server back to active.

To set HWTACACS timers:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter HWTACACS scheme view.	hwtacacs scheme hwtacacs-scheme-name	N/A
3. Set the HWTACACS server response timeout timer.	timer response-timeout seconds	Optional. The default HWTACACS server response timeout timer is 5 seconds.
4. Set the quiet timer for the primary server.	timer quiet minutes	Optional. The default quiet timer for the primary server is 5 minutes.

Displaying and maintaining HWTACACS

Task	Command	Remarks
Display the configuration or statistics of HWTACACS schemes.	display hwtacacs [ hwtacacs-server-name [ statistics ] ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about buffered stop-accounting requests for which no responses have been received.	display stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Clear HWTACACS statistics.	reset hwtacacs statistics { accounting \| all \| authentication \| authorization }	Available in user view.
Clear buffered stop-accounting requests that get no responses.	reset stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name	Available in user view.

Configuring AAA methods for ISP domains

By default, the device uses local (default) AAA methods for users in an ISP domain. To use other AAA methods for them, configure the device to reference existing AAA schemes for the ISP domain. For information about configuring AAA schemes, see "Configuring RADIUS schemes" and "Configuring HWTACACS schemes."

To use local authentication for users in an ISP domain, first configure local user accounts on the device (see "Configuring local user attributes").

Creating an ISP domain

In a networking scenario with multiple ISPs, the device can connect users of different ISPs. Different ISP users can have different user attributes (such as username and password structures), different service types, and different rights. To manage these ISP users, you need to create ISP domains and then configure AAA methods and domain attributes for each ISP domain.

The device can accommodate up to 16 ISP domains, including the system-defined ISP domain system. You can specify one ISP domain as the default domain.

On the device, each user belongs to an ISP domain. If a user provides no 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:

· The authentication domain specified for the access module

· The ISP domain in the username

· The default ISP domain of the device

· The ISP domain specified for users with unknown domain names

If all the domains are unavailable, user authentication will fail.

NOTE:

Support for the authentication domain configuration depends on the access module. You can specify an authentication domain for 802.1X or MAC address authentication.

To create an ISP domain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an ISP domain and enter ISP domain view.	domain isp-name	N/A
3. Return to system view.	quit	N/A
4. Specify the default ISP domain.	domain default enable isp-name	Optional. By default, the default ISP domain is the system-defined ISP domain system.
5. Specify an ISP domain for users with unknown domain names.	domain if-unknown isp-name	Optional. By default, no ISP domain is specified for users with unknown domain names.

To delete the ISP domain that is functioning as the default ISP domain, you must change it to a non-default ISP domain by using the undo domain default enable command.

Configuring ISP domain attributes

In an ISP domain, you can configure the following attributes:

· Domain status—By placing the ISP domain to the active or blocked state, you allow or deny network service requests from users in the domain.

· Maximum number of online users—The device controls the number of online users in a domain to ensure the system performance and service reliability.

· Idle cut—Enables the device to check the traffic of each online user in the domain at the idle timeout interval, and to log out any user in the domain whose traffic during the idle timeout period is less than the specified minimum traffic.

· Self-service server location—Allows users to access the self-service server to manage their own accounts and passwords.

An ISP domain attribute applies to all users in the domain.

A self-service RADIUS server running on IMC is required for the self-service server location function to work.

To configure ISP domain attributes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter ISP domain view.	domain isp-name	N/A
3. Place the ISP domain to the active or blocked state.	state { active \| block }	Optional. By default, an ISP domain is in active state, and users in the domain can request network services.
4. Specify the maximum number of online users in the ISP domain.	access-limit enable max-user-number	Optional. No limit is specified by default.
5. Configure the idle cut function.	idle-cut enable minute [ flow ]	Optional. Disabled by default. This command is effective only for LAN, portal, and PPP users. In a portal stateful failover situation, set the idle cut interval to be longer than 5 minutes to ensure that online users' data can be backed up.
6. Enable the self-service server location function and specify the URL of the self-service server.	self-service-url enable url-string	Optional. Disabled by default.
7. Set the device to include the idle cut time in the user online time to be uploaded to the server.	session-time include-idle-time	Optional. By default, the user online time uploaded to the server excludes the idle cut time.

Configuring authentication methods for an ISP domain

In AAA, authentication, authorization, and accounting are separate processes. Authentication refers to the interactive authentication process of username/password/user information during an access or service request. The authentication process neither sends authorization information to a supplicant nor triggers any accounting.

AAA supports the following authentication methods:

· No authentication (none)—No authentication is performed. This method trusts all users and is not for general use.

· Local authentication (local)—Authentication is performed by the NAS, which is configured with the 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 (scheme)—The NAS cooperates with a RADIUS or HWTACACS server to authenticate users. Remote authentication provides centralized information management, high capacity, high reliability, and support for centralized authentication service for multiple NASs. You can configure local or no authentication as the backup method, which will be used when the remote server is not available. The no authentication method can only be configured for LAN users as the backup method of remote authentication.

You can configure AAA authentication to work alone without authorization and accounting.

By default, an ISP domain uses the local authentication method.

Configuration prerequisites

Before configuring authentication methods, complete the following tasks:

· For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme to be referenced first. Local and none authentication methods do not require a scheme.

· 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 to limit the authentication protocols that users can use for access.

· Determine whether to configure the default authentication method for all access types or service types.

Configuration guidelines

When configuring authentication methods, follow these guidelines:

· If you configure an authentication method that references a RADIUS scheme and an authorization method that does not reference a RADIUS scheme, AAA accepts only the authentication result from the RADIUS server. The Access-Accept message from the RADIUS server also carries the authorization information, but the device ignores the information.

· You can configure a default authentication method for an ISP domain. The default method will be used for all users who support the authentication method and have no specific authentication method configured.

· You can configure local authentication (local) or no authentication (none) as the backup for remote authentication that is used when the remote authentication server is unavailable.

· Local authentication (local) and no authentication (none) cannot have a backup method.

· If the method for level switching authentication references an HWTACACS scheme, by default the device uses the login username of the user for level switching authentication. If the method for level switching authentication references a RADIUS scheme, the system uses the username configured for the corresponding privilege level on the RADIUS server for level switching authentication, rather than the login username. A username configured on the RADIUS server is in the format $enablevel$, where level specifies the privilege level that the user wants to enter. For example, if user user1 of domain aaa wants to switch the privilege level to 3, the system uses $enab3@aaa$ for authentication when the domain name is required and uses $enab3$ for authentication when the domain name is not required.

Configuration procedure

To configure authentication methods for an ISP domain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter ISP domain view.	domain isp-name	N/A
3. Specify the default authentication method for all types of users.	authentication default { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default authentication method is local for all types of users.
4. Specify the authentication method for LAN users.	authentication lan-access { local \| none \| radius-scheme radius-scheme-name [ local \| none ] }	Optional. The default authentication method is used by default.
5. Specify the authentication method for login users.	authentication login { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default authentication method is used by default.
6. Specify the authentication method for portal users.	authentication portal { local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default authentication method is used by default.
7. Specify the authentication method for PPP users.	authentication ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default authentication method is used by default.
8. Specify the authentication method for privilege level switching.	authentication super { hwtacacs-scheme hwtacacs-scheme-name \| radius-scheme radius-scheme-name }	Optional. The default authentication method is used by default.

Configuring authorization methods for an ISP domain

In AAA, authorization is a separate process at the same level as authentication and accounting. Its responsibility is to send authorization requests to the specified authorization servers and to send authorization information to users after successful authorization. Authorization method configuration is optional in AAA configuration.

AAA supports the following authorization methods:

· No authorization (none)—The NAS performs no authorization exchange. After passing authentication, non-login users can access the network, FTP users can access the root directory of the NAS, and other login users have Level 0 (visiting) access.

· Local authorization (local)—The NAS performs authorization according to the user attributes configured for users.

· Remote authorization (scheme)—The NAS cooperates with a RADIUS or HWTACACS server to authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS authorization can work only after RADIUS authentication is successful, and the authorization information is carried in the Access-Accept message. HWTACACS authorization is separate from HWTACACS authentication, and the authorization information is carried in the authorization response after successful authentication. You can configure local authorization or no authorization as the backup method. The backup method will be used when the remote server is not available.

Configuration prerequisites

Before configuring authorization methods, complete the following tasks:

1. For HWTACACS authorization, configure the HWTACACS scheme to be referenced first. For RADIUS authorization, the RADIUS authorization scheme must be the same as the RADIUS authentication scheme. Otherwise, it does not take effect.

2. 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 to limit the authorization protocols that can be used for access.

3. Determine whether to configure an authorization method for all access types or service types.

Configuration guidelines

When configuring authorization methods, follow these guidelines:

· To configure RADIUS authorization, you must also configure RADIUS authentication, and reference the same RADIUS scheme for RADIUS authentication and authorization. If the RADIUS authorization configuration is invalid or RADIUS authorization fails, the RADIUS authentication also fails. If RADIUS authorization fails, the server sends an error message to the NAS, indicating that the server itself is not responding.

· You can configure a default authorization method for an ISP domain. This method will be used for all users who support the authentication method and have no specific authorization method configured.

· You can configure local authorization (local) or no authorization (none) as the backup for remote authorization that is used when the remote authorization server is unavailable.

· Local authorization (local) and no authorization (none) cannot have a backup method.

Configuration procedure

To configure authorization methods for an ISP domain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter ISP domain view.	domain isp-name	N/A
3. Specify the default authorization method for all types of users.	authorization default { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default authorization method is local for all types of users.
4. Specify the command authorization method.	authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local \| none ] \| local \| none }	Optional. The default authorization method is used by default.
5. Specify the authorization method for LAN users.	authorization lan-access { local \| none \| radius-scheme radius-scheme-name [ local \| none ] }	Optional. The default authorization method is used by default.
6. Specify the authorization method for login users.	authorization login { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default authorization method is used by default.
7. Specify the authorization method for portal users.	authorization portal { local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default authorization method is used by default.
8. Specify the authorization method for PPP users.	authorization ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default authorization method is used by default.

Configuring accounting methods for an ISP domain

In AAA, accounting is a separate process at the same level as authentication and authorization. This process sends accounting start/update/end requests to the specified accounting server. Accounting is optional.

AAA supports the following accounting methods:

· No accounting (none)—The NAS does not perform accounting for the users.

· Local accounting (local)—Local accounting is implemented on the NAS. It counts and controls the number of concurrent users who use the same local user account. It does not provide statistics for charging. The maximum number of concurrent users using the same local user account is set by the access-limit command in local user view.

· Remote accounting (scheme)—The NAS works with a RADIUS server or HWTACACS server for accounting. You can configure local or no accounting as the backup method, which will be used when the remote server is not available.

By default, an ISP domain uses the local accounting method.

Configuration prerequisites

Before configuring accounting methods, complete the following tasks:

1. For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be referenced first. The local and none accounting methods do not require a scheme.

2. 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 to limit the accounting protocols that can be used for access.

3. Determine whether to configure an accounting method for all access types or service types.

Configuration guidelines

When configuring accounting methods, follow these guidelines:

· You can configure a default accounting method for an ISP domain. This method will be used for all users who support the accounting method and have no specific accounting method configured.

· You can configure local accounting (local) or no accounting (none) as the backup for remote accounting that is used when the remote accounting server is unavailable.

· Local accounting (local) and no accounting (none) cannot have a backup method.

· Accounting is not supported for FTP services.

· If you enable the accounting optional feature, the limit on the number of local user connections does not take effective.

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. Enable the accounting optional feature.	accounting optional	Optional. Disabled by default. With the accounting optional feature, a device allows users to use network resources when no accounting server is available or communication with all accounting servers fails.
4. Specify the default accounting method for all types of users.	accounting default { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default accounting method is local for all types of users.
5. Specify the command accounting method.	accounting command hwtacacs-scheme hwtacacs-scheme-name	Optional. The default accounting method is used by default.
6. Specify the accounting method for LAN users.	accounting lan-access { local \| none \| radius-scheme radius-scheme-name [ local \| none ] }	Optional. The default accounting method is used by default.
7. Specify the accounting method for login users.	accounting login { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default accounting method is used by default.
8. Specify the accounting method for portal users.	accounting portal { local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default accounting method is used by default.
9. Specify the accounting method for PPP users.	accounting ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] \| local \| none \| radius-scheme radius-scheme-name [ local ] }	Optional. The default accounting method is used by default.

Tearing down user connections

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Tear down AAA user connections.	cut connection { access-type { dot1x \| mac-authentication \| portal } \| all \| domain isp-name \| interface interface-type interface-number \| ip ip-address \| mac mac-address \| ucibindex ucib-index \| user-name user-name \| vlan vlan-id }	The command applies to LAN, portal, and PPP user connections.

Displaying and maintaining AAA

Task	Command	Remarks
Display the configuration of ISP domains.	display domain [ isp-name ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about user connections.	display connection [ access-type { dot1x \| mac-authentication \| portal } \| domain isp-name \| interface interface-type interface-number \| ip ip-address \| mac mac-address \| ucibindex ucib-index \| user-name user-name \| vlan vlan-id ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.

AAA configuration examples

AAA for Telnet users by an HWTACACS server

Network requirements

As shown in Figure 9, configure the AP to use the HWTACACS server for Telnet user authentication, authorization, and accounting.

Set the shared keys for secure communication with the HWTACACS server to expert. Configure the AP to remove the domain name from a username sent to the HWTACACS server.

Figure 9 Network diagram

Configuration procedure

1. Configure the HWTACACS server:

# Specify the AP as an HWTACACS client. (Details not shown.)

# Set the shared keys for secure communication with the AP to expert. (Details not shown.)

# Add an account for the Telnet user, and specify the password. (Details not shown.)

2. Configure the AP:

# Assign IP addresses to the interfaces. (Details not shown.)

# Enable the Telnet server on the AP.

<AP> system-view

[AP] telnet server enable

# Configure the AP to use AAA for Telnet users.

[AP] user-interface vty 0 4

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

[AP-ui-vty0-4] quit

# Create an HWTACACS scheme named hwtac.

[AP] hwtacacs scheme hwtac

# Specify the primary authentication server.

[AP-hwtacacs-hwtac] primary authentication 10.1.1.1 49

# Specify the primary authorization server.

[AP-hwtacacs-hwtac] primary authorization 10.1.1.1 49

# Specify the primary accounting server.

[AP-hwtacacs-hwtac] primary accounting 10.1.1.1 49

# Set the shared keys for secure authentication, authorization, and accounting communication to expert.

[AP-hwtacacs-hwtac] key authentication expert

[AP-hwtacacs-hwtac] key authorization expert

[AP-hwtacacs-hwtac] key accounting expert

# Remove domain names from the usernames sent to the HWTACACS server.

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

[AP-hwtacacs-hwtac] quit

# Configure the AAA methods for the domain.

[AP] domain bbb

[AP-isp-bbb] authentication login hwtacacs-scheme hwtac

[AP-isp-bbb] authorization login hwtacacs-scheme hwtac

[AP-isp-bbb] accounting login hwtacacs-scheme hwtac

[AP-isp-bbb] quit

# Specify the domain bbb as the default domain.

[AP] domain default enable bbb

3. Verify the configuration:

# Telnet to the AP and enter the correct username and password. Verify that the user can pass authentication and log into the AP. (Details not shown.)

# Use the display connection command on the AP to display information about the user connection. (Details not shown.)

Local authentication and authorization for Telnet users

Network requirements

As shown in Figure 10, configure the AP to perform local authentication and authorization for Telnet users.

Figure 10 Network diagram

Configuration procedure

1. Configure the AP:

# Assign IP addresses to interfaces. (Details not shown.)

# Enable the Telnet server on the AP.

<AP> system-view

[AP] telnet server enable

# Configure the AP to use AAA for Telnet users.

[AP] user-interface vty 0 4

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

[AP-ui-vty0-4] quit

# Create a local user named hello.

[AP] local-user hello

[AP-luser-hello] service-type telnet

[AP-luser-hello] password simple hello

[AP-luser-hello] quit

# Configure authentication and authorization methods for the ISP domain.

[AP] domain bbb

[AP-isp-bbb] authentication login local

[AP-isp-bbb] authorization login local

[AP-isp-bbb] quit

# Specify the domain bbb as the default domain.

[AP] domain default enable bbb

2. Verify the configuration:

# Telnet to the AP and enter the username hello@bbb and the correct password. Verify that the user can pass authentication and log into the AP. (Details not shown.)

# Use the display connection command on the AP to display information about the user connection. (Details not shown.)

AAA for Telnet users by a RADIUS server

The configuration of authentication, authorization, and accounting for SSH users is similar to that for Telnet users. This example describes the configuration of Telnet users.

Network requirements

As shown in Figure 11, configure the AP to perform the following operations:

· Use the RADIUS server for Telnet user authentication, authorization, and accounting.

· Remove the domain name from a username sent to the RADIUS server.

Set the shared keys to expert for secure RADIUS communication between the AP and the RADIUS server.

Figure 11 Network diagram

Configuration procedure

1. Configure the RADIUS server. Make sure the RADIUS server can provide authentication, authorization, and accounting services for the users who access the AP. (Details not shown.)

2. Configure the AP:

# Configure IP addresses for interfaces, as shown in Figure 11. (Details not shown.)

# Enable the Telnet server on the AP.

<AP> system-view

[AP] telnet server enable

# Configure the AP to use AAA for Telnet users.

[AP] user-interface vty 0 4

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

[AP-ui-vty0-4] quit

# Create a RADIUS scheme named radius1.

[AP] radius scheme radius1

# Specify the primary authentication server.

[AP-radius-radius1] primary authentication 10.1.1.1 1812

# Specify the primary accounting server.

[AP-radius-radius1] primary accounting 10.1.1.1 1813

# Set the shared key for secure authentication communication to expert.

[AP-radius-radius1] key authentication expert

# Set the shared key for secure accounting communication to expert.

[AP-radius-radius1] key accounting expert

# Remove domain names from the usernames sent to the RADIUS server.

[AP-radius-radius1] user-name-format without-domain

[AP-radius-radius1] quit

# Use one of the following methods to configure AAA methods for the Telnet user in the domain.

¡ Method 1:

[AP] domain bbb

[AP-isp-bbb] authentication login radius-scheme radius1

[AP-isp-bbb] authorization login radius-scheme radius1

[AP-isp-bbb] accounting login radius-scheme radius1

[AP-isp-bbb] quit

¡ Method 2:

[AP] domain bbb

[AP-isp-bbb] authentication default radius-scheme radius1

[AP-isp-bbb] accounting default radius-scheme radius1

[AP-isp-bbb] authorization default radius-scheme radius1

[AP-isp-bbb] quit

# Specify the domain bbb as the default domain.

[AP] domain default enable bbb

3. Verify the configuration.

Telnet to the AP, and enter the correct username and password. The user can log into the AP. (Details not shown.)

Local authentication, local authorization, and RADIUS accounting for Telnet users

Network requirements

As shown in Figure 12, configure the AP to provide local authentication, local authorization, and RADIUS accounting services to Telnet users. The username and the password for Telnet users are both hello.

The RADIUS server is used for accounting. On the AP, set the shared keys for packets exchanged with the RADIUS server to expert. Configure the AP to remove the domain name from a username before sending the username to the RADIUS server.

NOTE:

Configuration for other types of users is similar to that given in this example. The only difference lies in the access type.

Figure 12 Network diagram

Configuration procedure

1. Configure the RADIUS server. Make sure the RADIUS server can provide accounting services for the users who access the AP. (Details not shown.)

2. Configure the AP:

# Assign IP addresses to interfaces. (Details not shown.)

# Enable the Telnet server on the AP.

<AP> system-view

[AP] telnet server enable

# Configure the AP to use AAA for Telnet users.

[AP] user-interface vty 0 4

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

[AP-ui-vty0-4] quit

# Configure the RADIUS scheme.

[AP] radius scheme rd

[AP-radius-rd] primary accounting 10.1.1.1 1813

[AP-radius-rd] key accounting expert

[AP-radius-rd] server-type extended

[AP-radius-rd] user-name-format without-domain

[AP-radius-rd] quit

# Create a local user named hello.

[AP] local-user hello

[AP-luser-hello] service-type telnet

[AP-luser-hello] password simple hello

[AP-luser-hello] quit

# Use one of the following methods to configure AAA methods for the Telnet user in the domain.

¡ Method 1:

[AP] domain bbb

[AP-isp-bbb] authentication login local

[AP-isp-bbb] authorization login local

[AP-isp-bbb] accounting login radius-scheme rd

[AP-isp-bbb] quit

¡ Method 2:

[AP] domain bbb

[AP-isp-bbb] authentication default local

[AP-isp-bbb] authorization default local

[AP-isp-bbb] accounting default radius-scheme rd

[AP-isp-bbb] quit

# Specify the default ISP domain.

[AP] domain default enable bbb

3. Verify the configuration.

Telnet to the AP, and enter the username hello@bbb and the password. The user logs into the AP. (Details not shown.)

AAA for 802.1X users by a RADIUS server

Network requirements

As shown in Figure 13, configure the AP as follows:

· Use the RADIUS server to perform authentication, authorization, and accounting for 802.1X users.

· Set the shared keys for authentication and authorization packets exchanged between the AP and the RADIUS server to expert.

· Specify the ports for authentication/authorization and accounting as 1812 and 1813, respectively.

· Include the domain names in usernames to be sent to the RADIUS server.

· Configure MAC-based access control on WLAN-BSS 1 to authenticate all 802.1X users on the port separately.

Configure an account for the user, with the username dot1x@bbb. Configure the authentication server to assign the host to VLAN 4 after the host passes authentication. Register a monthly service that charges 120 dollars for up to 120 hours per month for the user.

Figure 13 Network diagram

Configuration procedure

NOTE:

Configure the interfaces and VLANs as shown in Figure 13. Make sure that the host can get a new IP address manually or automatically and can access resources in the authorized VLAN after passing authentication.

1. Configure the RADIUS server:

This example uses the RADIUS server that runs IMC PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101).

# Add the AP to IMC 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:

¡ Set the shared key for authentication and accounting to expert.

¡ Set the ports for authentication and accounting to 1812 and 1813, respectively.

¡ Select LAN Access Service as the service type.

¡ Select H3C(General) as the access device type.

¡ Select the access device from the device list or manually add the device with the IP address 10.18.1.1.

¡ Use the default values for other parameters and click OK.

NOTE:

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 device, which is chosen in this order:

· The IP address specified with the nas-ip command on the device

· The IP address specified with the radius nas-ip command on the device

· The IP address of the outbound interface (the default)

Figure 14 Adding an access device

# Add a charging plan.

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:

¡ Add a plan named UserAcct.

¡ Select Flat rate as the charging template.

¡ Select time for Charge Based on, select Monthly for Billing Term, and type 120 in the Fixed Fee field.

¡ Type 120 in the Usage Threshold field and select hr for the in field to allow the user to access the Internet for up to 120 hours per month.

¡ Use the default values for other parameters and click OK.

Figure 15 Adding a charging plan

# Add a service.

Select User Access Manager > Service Configuration from the navigation tree. Then, click Add to configure a service as follows:

¡ 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 carry domain names to the RADIUS server.

¡ Select UserAcct as the charging plan.

¡ Select Deploy VLAN and set the ID of the VLAN to be assigned to 4.

¡ Configure other parameters as needed and click OK.

Figure 16 Adding a service

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

¡ Select the user or add a user named hello.

¡ Specify the account name as dot1x and configure the password.

¡ Select the access service Dot1x auth.

¡ Configure other parameters as needed and click OK.

Figure 17 Adding an access user account

2. Configure the AP:

# Create a RADIUS scheme named rad and enter its view.

<AP> system-view

[AP] radius scheme rad

# Set the server type for the RADIUS scheme. To work with IMC, set the server type to extended.

[AP-radius-rad] server-type extended

# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.

[AP-radius-rad] primary authentication 10.1.1.1 1812

[AP-radius-rad] primary accounting 10.1.1.1 1813

[AP-radius-rad] key authentication simple expert

[AP-radius-rad] key accounting simple expert

# Configure the scheme to include the domain names in usernames to be sent to the RADIUS server.

[AP-radius-rad] user-name-format with-domain

[AP-radius-rad] quit

# Create an ISP domain named bbb and enter its view.

[AP] domain bbb

# Configure the ISP domain to use RADIUS scheme rad.

[AP-isp-bbb] authentication lan-access radius-scheme rad

[AP-isp-bbb] authorization lan-access radius-scheme rad

[AP-isp-bbb] accounting lan-access radius-scheme rad

[AP-isp-bbb] quit

# Configure bbb as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at login, the authentication and accounting methods of the default domain will be used for the user.

[AP] domain default enable bbb

# Create VLAN 4.

[AP] vlan 4

[AP-vlan4] quit

# Configure port security and enable key negotiation of the 11key type on interface WLAN-BSS 1.

[AP] interface wlan-bss 1

[AP-WLAN-BSS1] port-security port-mode userlogin-secure-ext

[AP-WLAN-BSS1] port-security tx-key-type 11key

# Disable the 802.1X multicast trigger function and the online user handshake function.

[AP-WLAN-BSS1] undo dot1x multicast-trigger

[AP-WLAN-BSS1] undo dot1x handshake

# Configure WLAN-BSS 1 to forward packets for VLAN 1 and VLAN 4 after removing VLAN tags. Enable the MAC-based VLAN feature on the port.

[AP-WLAN-BSS1] port link-type hybrid

[AP-WLAN-BSS1] port hybrid vlan 1 4 untagged

[AP-WLAN-BSS1] mac-vlan enable

[AP-WLAN-BSS1] quit

# Configure the RSN service template.

[AP] wlan service-template 1 crypto

[AP-wlan-st-1] ssid dot1xtest

[AP-wlan-st-1] authentication-method open-system

[AP-wlan-st-1] cipher-suite ccmp

[AP-wlan-st-1] security-ie rsn

[AP-wlan-st-1] service-template enable

[AP-wlan-st-1] quit

# Bind the service template with WLAN-Radio 1/0/1.

[AP] interface wlan-radio 1/0/1

[AP-WLAN-Radio1/0/1] radio-type dot11g

[AP-WLAN-Radio1/0/1] service-template 1 interface wlan-bss 1

[AP-WLAN-Radio1/0/1] quit

# Configure the uplink port of the AP to forward packets with VLAN tags of VLAN 1 and VLAN 4.

[AP] interface gigabitethernet 1/0/1

[AP-GigabitEthernet1/0/1] port link-type hybrid

[AP-GigabitEthernet1/0/1] port hybrid vlan 1 4 tagged

[AP-GigabitEthernet1/0/1] quit

3. Verify the configuration:

NOTE:

If the 802.1X client of Windows XP is used, the properties of the 802.1X connection should be specifically configured in the Authentication tab on the Properties page, where you must select the Enable IEEE 802.1X authentication for this network option and specify the EAP type as PEAP.

When using the Windows XP 802.1X client, the user can pass authentication after entering the correct username and password in the pop-up authentication page. After the user passes authentication, the server assigns the port connecting the client to VLAN 4.

# Use the display connect command to view the connection information on the AP.

[AP] display connection

Index=1 ,Username=dot1x@bbb

MAC=00-21-27-08-B5-0F

IP=10.18.1.5

IPv6=N/A

Total 1 connection(s) matched.

# View the information of the specified connection on the AP.

[AP] display connection ucibindex 1

Index=1 , Username=dot1x@bbb

MAC=00-21-27-08-B5-0F

IP=10.18.1.5

IPv6=N/A

Access=8021X ,AuthMethod=EAP

Port Type=Wireless-802.11,Port Name=WLAN-BSS1

Initial VLAN=1, Authorization VLAN=4

ACL Group=Disable

User Profile=N/A

CAR=Disable

Priority=Disable

Accounting Username=dot1x@bbb

Start=2011-06-30 17:58:44 ,Current=2011-06-30 18:00:19 ,Online=00h01m35s

Total 1 connection matched.

The Authorization VLAN field in the output shows that VLAN 4 has been assigned to the user.

Level switching authentication for Telnet users by an HWTACACS server

Network requirements

As shown in Figure 18, configure the AP to use local authentication for the Telnet user and assign the privilege level of 0 to the user after the user passes authentication.

Configure the AP to use the HWTACACS server for level switching authentication of the Telnet user, and to use local authentication as the backup method.

Figure 18 Network diagram

Configuration considerations

1. Configure the AP to use AAA, particularly, local authentication for Telnet users.

¡ Create ISP domain bbb and configure it to use local authentication for Telnet users.

¡ Create a local user account, configure the password, and assign the privilege level for the user to enjoy after login.

2. On the AP, configure the authentication method for user privilege level switching.

¡ Specify to use HWTACACS authentication and, if HWTACACS authentication is not available, use local authentication for user level switching authentication.

¡ Configure HWTACACS scheme hwtac and assign an IP address to the HWTACACS server. Set the shared keys for message exchange and specify that usernames sent to the HWTACACS server carry no domain name. Configure the domain to use the HWTACACS scheme hwtac for user privilege level switching authentication.

¡ Configure the password for local privilege level switching authentication.

3. On the HWTACACS server, add the username and password for user privilege level switching authentication.

Configuration procedure

1. Configure the AP:

# Assign an IP address to VLAN-interface 1, the interface through which the Telnet user accesses the AP.

<AP> system-view

[AP] interface vlan-interface 1

[AP-Vlan-interface1] ip address 10.1.1.254 255.255.255.0

[AP-Vlan-interface1] quit

# Enable the AP to provide Telnet service.

[AP] telnet server enable

# Configure the AP to use AAA for Telnet users.

[AP] user-interface vty 0 4

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

[AP-ui-vty0-4] quit

# Use HWTACACS authentication for user level switching authentication and, if HWTACACS authentication is not available, use local authentication.

[AP] super authentication-mode scheme local

# Create an HWTACACS scheme named hwtac.

[AP] hwtacacs scheme hwtac

# Specify the IP address for the primary authentication server as 10.1.1.1 and the port for authentication as 49.

[AP-hwtacacs-hwtac] primary authentication 10.1.1.1 49

# Set the shared key for authentication packets to expert.

[AP-hwtacacs-hwtac] key authentication expert

# Configure the scheme to remove the domain name from a username before sending the username to the HWTACACS server.

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

[AP-hwtacacs-hwtac] quit

# Create an ISP domain named bbb.

[AP] domain bbb

# Configure the ISP domain to use local authentication for Telnet users.

[AP-isp-bbb] authentication login local

# Configure to use HWTACACS scheme hwtac for privilege level switching authentication.

[AP-isp-bbb] authentication super hwtacacs-scheme hwtac

[AP-isp-bbb] quit

# Create a local Telnet user named hello.

[AP] local-user hello

[AP-luser-hello] service-type telnet

[AP-luser-hello] password simple hello

# Configure the user level of the Telnet user to 0 after user login.

[AP-luser-hello] authorization-attribute level 0

[AP-luser-hello] quit

# Configure the password for local privilege level switching authentication to 654321.

[AP] super password simple 654321

# Specify the default authentication domain.

[AP]domain default enable bbb

2. Configure the HWTACACS server:

The HWTACACS server in this example runs ACSv4.0.

# Add a user named hello on the HWTACACS server and configure advanced attributes for the user as shown in Figure 19:

¡ Select Max Privilege for any AAA Client and set the privilege level to level 3. After these configurations, the user must use the password enabpass when switching to level 1, level 2, or level 3.

¡ Select Use separate password and specify the password as enabpass.

Figure 19 Configuring advanced attributes for the Telnet user

3. Verify the configuration:

# Telnet to the AP, and enter the username hello@bbb and the password hello to access the user interface of the AP. Verify that the user can access all level 0 commands.

<AP> telnet 10.1.1.254

Trying 10.1.1.254 ...

Press CTRL+K to abort

Connected to 10.1.1.254 ...

******************************************************************************

* Without the owner's prior written consent, *

* no decompiling or reverse-engineering shall be allowed. *

******************************************************************************

Username:hello

Password:

<AP> ?

User view commands:

display Display current system information

ping Ping function

quit Exit from current command view

ssh2 Establish a secure shell client connection

super Set the current user priority level

telnet Establish one TELNET connection

tracert Trace route function

# Request for user privilege level 3 by entering password enabpass.

<AP> super 3

Password:

User privilege level is 3, and only those commands can be used

whose level is equal or less than this.

Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE

If the HWTACACS server is not available, the Telnet user must enter the password 654321 for local authentication.

<AP> super 3

Password:

Error: Invalid configuration or no response from the authentication server.

Info: Change authentication mode to local.

Password:

User privilege level is 3, and only those commands can be used

whose level is equal or less than this.

Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE

Troubleshooting AAA

Troubleshooting RADIUS

Symptom 1

User authentication/authorization always fails.

Analysis

Possible reasons include:

· A communication failure exists between the NAS and the RADIUS server.

· The username is not in the format userid@isp-name 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

Check that:

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

Symptom 2

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/authorization and accounting UDP ports configured on the NAS are incorrect.

· The RADIUS server's authentication/authorization and accounting port numbers are being used by other applications.

Solution

Check that:

· The link between the NAS and the RADIUS server work well at both the physical and data link layers.

· The IP address of the RADIUS server is correctly configured on the NAS.

· The authentication/authorization and accounting UDP ports configured on the NAS are the same as those of the RADIUS server.

· The RADIUS server's authentication/authorization and accounting port numbers are available.

Symptom 3

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

Check that:

· The accounting port number is correctly configured.

· The accounting server IP address is correctly configured on the NAS.

Troubleshooting HWTACACS

Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS."

07-Security Configuration Guide

RADIUS

Client/server model

Security and authentication mechanisms

Basic RADIUS message exchange process

RADIUS packet format

Extended RADIUS attributes

HWTACACS

Differences between HWTACACS and RADIUS

Basic HWTACACS message exchange process

H3C proprietary RADIUS sub-attributes

Specifying the RADIUS authentication/authorization servers

Enabling the RADIUS client service

HWTACACS configuration task list

Configuring ISP domain attributes

Configuring authentication methods for an ISP domain

Configuration prerequisites

Configuration procedure

Configuration prerequisites

Configuration procedure

Configuration prerequisites

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Configuration procedure

Configuration considerations

Configuration procedure

Troubleshooting RADIUS

Symptom 1

Analysis

Solution

Symptom 2

Analysis

Solution

Symptom 3

Analysis

Solution

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us