Contents

Configuring 802.1X· 1

Overview·· 1

802.1X architecture· 1

Access control methods· 1

802.1X timers· 2

Configuration prerequisites· 2

Configuration procedure· 2

Configuring 802.1X globally· 3

Configuring 802.1X on a port 4

Configuring an 802.1X guest VLAN·· 6

Configuring an Auth-Fail VLAN·· 7

Configuring portal authentication· 8

Overview·· 8

Configuration prerequisites· 9

Configuration procedure· 9

Configuring the portal service· 10

Configuring advanced parameters for portal authentication· 14

Configuring a portal-free rule· 15

Customizing authentication pages· 16

File name rules· 16

Page request rules· 17

Post request attribute rules· 17

Page file compression and saving rules· 18

File size and content rules· 18

Logging off a user who closes the logon success or online page· 18

Redirecting authenticated users to a specific webpage· 19

Portal authentication configuration example· 19

Configuring AAA· 29

Overview·· 29

Configuration prerequisites· 30

Configuration procedure· 30

Configuring an ISP domain· 31

Configuring authentication methods for the ISP domain· 32

Configuring authorization methods for the ISP domain· 34

Configuring accounting methods for the ISP domain· 36

AAA configuration example· 37

Network requirements· 37

Configuration procedure· 38

Configuring RADIUS· 41

Configuration guidelines· 41

Configuring a RADIUS scheme· 42

RADIUS configuration example· 48

Configuring the local EAP service· 56

Configuration procedure· 56

Local EAP service configuration example· 57

Configuring users· 63

Overview·· 63

Configuring a local user 63

Configuring a user group· 66

Configuring a guest 67

Configuring a guest by a management level administrator 67

Configuring a guest by a guest administrator 68

Configuring a user profile· 69

Configuration guidelines· 69

Configuration procedure· 70

Managing certificates· 73

Overview·· 73

Configuration guidelines· 73

Configuration procedures· 74

Configuration procedure for manual request 74

Configuration procedure for automatic request 75

Creating a PKI entity· 76

Creating a PKI domain· 77

Generating an RSA key pair 80

Destroying the RSA key pair 80

Retrieving and displaying a certificate· 81

Requesting a local certificate· 82

Retrieving and displaying a CRL· 83

Certificate management configuration example· 84

 

Configuring 802.1X

802.1X is a port-based network access control protocol initially proposed by the IEEE 802 LAN/WAN committee for the security of wireless LANs (WLANs). It has been widely used on Ethernet networks for access control.

802.1X controls network access by authenticating the devices connected to 802.1X-enabled LAN ports.

You can also configure the port security feature to perform 802.1X. Port security combines and extends 802.1X and MAC authentication. It applies to a network, a WLAN, for example, that requires different authentication methods for different users on a port. For more information about port security, see H3C Access Controllers Security Configuration Guide.

Overview

802.1X architecture

802.1X operates in the client/server model. It has three entities: the client (supplicant), the network access device (authenticator), and the authentication server, as shown in Figure 1.

Figure 1 802.1X architecture

 

·     Client—A user terminal seeking access to the LAN. It must have 802.1X software to authenticate to the network access device.

·     Network access device—Authenticates the client to control access to the LAN. In a typical 802.1X environment, the network access device uses an authentication server to perform authentication.

·     Authentication server—Provides authentication services for the network access device. The authentication server authenticates 802.1X clients by using the data sent from the network access device, and returns the authentication results for the network access device to make access decisions. The authentication server typically is a RADIUS server. In a small LAN, you can also use the network access device as the authentication server.

For more information about the 802.1X protocol, see H3C Access Controllers Security Configuration Guide.

Access control methods

H3C implements port-based access control as defined in the 802.1X protocol, and extends the protocol to support MAC-based access control.

·     Port-based access control—Once an 802.1X user passes authentication on a port, any subsequent user can access the network through the port without authentication. When the authenticated user logs off, all other users are logged off.

·     MAC-based access control—Each user is authenticated separately on a port. When a user logs off, no other online users are affected.

802.1X timers

This section describes the timers used on an 802.1X device to guarantee that the client, the device, and the RADIUS server can interact with each other correctly.

·     Username request timeout timer—Starts when the device sends an EAP-Request/Identity packet to a client in response to an authentication request. If the device receives no response before this timer expires, it retransmits the request. The timer also sets the interval at which the network device sends multicast EAP-Request/Identity packets to detect clients that cannot actively request authentication.

·     Client timeout timer—Starts when the access device sends an EAP-Request/MD5 Challenge packet to a client. If no response is received when this timer expires, the access device retransmits the request to the client.

·     Server timeout timer—Starts when the access device sends a RADIUS Access-Request packet to the authentication server. If no response is received when this timer expires, the access device retransmits the request to the server.

·     Handshake timer—Sets the interval at which the access device sends client handshake requests to check the online status of a client that has passed authentication. If the device receives no response after sending the maximum number of handshake requests, it considers that the client has logged off. For information about how to enable the online user handshake function, see "Configuring 802.1X on a port."

·     Quiet timer—Starts when the access device sends a RADIUS Access-Request packet to the authentication server. If no response is received when this timer expires, the access device retransmits the request to the server.

·     Periodic online user re-authentication timer—Sets the interval at which the network device periodically re-authenticates online 802.1X users. For information about how to enable periodic online user re-authentication on a port, see "Configuring 802.1X on a port."

Configuration prerequisites

·     Configure an ISP domain and AAA scheme (local or RADIUS authentication) for 802.1X users. For more information, see "Configuring AAA" and "Configuring RADIUS."

·     If you use local authentication, create user accounts on the device and assign the LAN access service to the users. For more information, see "Configuring users."

·     If you use RADIUS authentication, create user accounts on the RADIUS server.

·     Configure a special local EAP server on the device to use EAP relay if the RADIUS server does not support any EAP authentication method or when local authentication is used. For more information, see "Configuring the local EAP service."

Configuration procedure

Task	Description
1.     Configuring 802.1X globally	Required. Enable 802.1X authentication globally and configure the authentication method and advanced parameters. By default, 802.1X authentication is disabled globally.
2.     Configuring 802.1X on a port	Required. Enable 802.1X authentication on specified ports and configure 802.1X parameters for the ports. By default, 802.1X authentication is disabled on a port.

 

Configuring 802.1X globally

1.     From the navigation tree, select Authentication > 802.1X.

Figure 2 802.1X global configuration

 

2.     In the 802.1X Configuration area, select the Enable 802.1X option.

3.     Select an authentication method for 802.1X users. Options include CHAP, PAP, and EAP.

¡     CHAP—Sets the access device to perform EAP termination and use the CHAP to communicate with the RADIUS server.

¡     PAP—Sets the access device to perform EAP termination and use the PAP to communicate with the RADIUS server.

¡     EAP—Sets the access device to relay EAP packets, and supports any of the EAP authentication methods to communicate with the RADIUS server.

When you configure EAP relay or EAP termination, consider the following factors:

·     Whether the RADIUS server supports EAP packets.

·     The authentication methods supported by the 802.1X client and the RADIUS server.

If the client is using only MD5-Challenge EAP authentication or the "username + password" EAP authentication initiated by an H3C iNode 802.1X client, you can use both EAP termination and EAP relay. To use EAP-TL, PEAP, or any other EAP authentication methods, you must use EAP relay.

4.     Click Advanced to expand the advanced 802.1X configuration area.

Figure 3 Advanced configuration

 

5.     Configure advanced 802.1X settings as described in Table 1.

6.     Click Apply.

Table 1 Configuration items

Item	Description
Quiet	Specify whether to enable the quiet timer. The quiet timer enables the network access device to wait a period of time before it can process any authentication request from a client that has failed an 802.1X authentication.
Quiet Period	Set the value of the quiet timer.
Retry Times	Set the maximum number of authentication request attempts. The network access device retransmits an authentication request if it receives no response to the request it has sent to the client within a period of time (specified by using the TX-Period option or the Supplicant Timeout Time option). The network access device stops retransmitting the request, if it has made the maximum number of request transmission attempts but still received no response.
TX-Period	Set the username request timeout timer.
Handshake Period	Set the handshake timer.
Re-Authentication Period	Set the periodic online user re-authentication timer.
Supplicant Timeout Time Server Timeout Time	Set the client and server timeout timers.  TIP: You can set the client timeout timer to a high value in a low-performance network, and adjust the server timeout timer to adapt to the performance of different authentication servers. In most cases, the default settings are sufficient.

 

For more information about 802.1X timers, see "802.1X timers."

 

	IMPORTANT: Do not change the timer parameters of global 802.1X from their default values unless you have determined that the changes would better the interaction process.

 

Configuring 802.1X on a port

1.     From the navigation tree, select Authentication > 802.1X to enter the page, as shown in Figure 2.

The Ports With 802.1X Enabled area shows the 802.1X configuration on ports.

2.     Click Add.

Figure 4 802.1X configuration on a port

 

3.     Configure 802.1X features on a port, as described in Table 2.

4.     Click Apply.

Table 2 Configuration items

Item	Description
Port	Select the port to be enabled with 802.1X authentication. Only 802.1X-disabled ports are available. 802.1X configuration takes effect on ports only when 802.1X is enabled both globally and on the ports. NOTE: 802.1X is mutually exclusive with the link aggregation group or service loopback group configuration on a port.
Port Control	Set the access control method for the port: MAC Based or Port Based. NOTE: To use both 802.1X and portal authentication on a port, you must select MAC Based.
Port Authorization	Select the port authorization state for 802.1X. Options include: ·     Auto—Places the port initially in unauthorized state to allow only EAPOL packets to pass, and after a user passes authentication, sets the port in authorized state to allow access to the network. You can use this option in most scenarios. ·     Force-Authorized—Places the port in authorized state, enabling users on the port to access the network without authentication. ·     Force-Unauthorized—Places the port in unauthorized state, denying any access requests from users on the port.
Max Number of Users	Set the maximum number of concurrent 802.1X users on the port. The maximum number varies by device model. For more information, see "About the H3C Access Controllers Web-Based Configuration Guide."
Enable Handshake	Specify whether to enable the online user handshake function. The online user handshake function checks the connectivity status of online 802.1X users. The network access device sends handshake messages to online users at the interval specified by the Handshake Period setting. If no response is received from an online user after the maximum number of handshake attempts (set by the Retry Times setting) has been made, the network access device sets the user in offline state. For information about the timers, see "802.1X timers." NOTE: If the network has 802.1X clients that cannot exchange handshake packets with the network access device, disable the online user handshake function to prevent their connections from being inappropriately torn down.
Enable Re-Authentication	Specify whether to enable periodic online user re-authentication on the port. Periodic online user re-authentication tracks the connection status of online users and updates the authorization attributes assigned by the server, such as the ACL, and VLAN. The re-authentication interval is specified by the Re-Authentication Period setting in Table 1. NOTE: ·     The periodic online user re-authentication timer can also be set by the authentication server in the session-timeout attribute. The server-assigned timer overrides the timer setting on the access device, and enables periodic online user re-authentication, even if the function is not configured. Support for the server assignment of re-authentication timer and the re-authentication timer configuration on the server vary with servers. ·     The VLAN assignment status must be consistent before and after re-authentication. If the authentication server has assigned a VLAN before re-authentication, it must also assign a VLAN at re-authentication. If the authentication server has assigned no VLAN before re-authentication, it must not assign one at re-authentication. Violation of either rule can cause the user to be logged off. The VLANs assigned to an online user before and after re-authentication can be the same or different.
Guest VLAN	Specify an existing VLAN as the guest VLAN. For more information, see "Configuring an 802.1X guest VLAN."
Enable MAC VLAN	Select the option to enable MAC-based VLAN. NOTE: Only hybrid ports support the feature.
Auth-Fail VLAN	Specify an existing VLAN as the Auth-Fail VLAN to accommodate users that have failed 802.1X authentication. For more information, see "Configuring an Auth-Fail VLAN."

 

Configuring an 802.1X guest VLAN

Configuration guidelines

·     You can configure only one 802.1X guest VLAN on a port. The 802.1X guest VLANs on different ports can be different.

·     Assign different IDs to the default VLAN and 802.1X guest VLAN on a port, so the port can correctly process incoming VLAN tagged traffic.

·     With 802.1X authentication, a hybrid port is always assigned to a VLAN as an untagged member. After the assignment, do not re-configure the port as a tagged member in the VLAN.

·     Use Table 3 when you configure multiple security features on a port.

Table 3 Relationships of the 802.1X guest VLAN and other security features

Feature	Relationship description
MAC authentication guest VLAN on a port that performs MAC-based access control	Only the 802.1X guest VLAN take effect. A user that fails MAC authentication will not be assigned to the MAC authentication guest VLAN.
802.1X Auth-Fail VLAN on a port that performs MAC-based access control	The 802.1X Auth-Fail VLAN has a higher priority.
Port intrusion protection on a port that performs MAC-based access control	The 802.1X guest VLAN function has higher priority than the block MAC action, but lower priority than the shutdown port action of the port intrusion protection feature.

 

Configuration prerequisites

·     Create the VLAN to be specified as the 802.1X guest VLAN.

·     If the 802.1X-enabled port performs port-based access control, enable 802.1X multicast trigger at the CLI. (802.1X multicast trigger is enabled by default.)

·     If the 802.1X-enabled port performs MAC-based access control, configure the port as a hybrid port, enable MAC-based VLAN on the port, and assign the port to the 802.1X guest VLAN as an untagged member.

Configuring an Auth-Fail VLAN

Configuration guidelines

·     You can configure only one 802.1X Auth-Fail VLAN on a port. The 802.1X Auth-Fail VLANs on different ports can be different.

·     Assign different IDs to the default VLAN and 802.1X Auth-Fail VLAN on a port, so the port can correctly process VLAN tagged incoming traffic.

·     Use Table 4 when you configure multiple security features on a port.

Table 4 Relationships of the 802.1X Auth-Fail VLAN with other features

Feature	Relationship description
MAC authentication guest VLAN on a port that performs MAC-based access control	The 802.1X Auth-Fail VLAN has a high priority.
Port intrusion protection on a port that performs MAC-based access control	The 802.1X Auth-Fail VLAN function has higher priority than the block MAC action, but lower priority than the shutdown port action of the port intrusion protection feature.

 

Configuration prerequisites

·     Create the VLAN to be specified as the 802.1X Auth-Fail VLAN.

·     If the 802.1X-enabled port performs port-based access control, enable 802.1X multicast trigger. (802.1X multicast trigger is enabled by default.)

·     If the 802.1X-enabled port performs MAC-based access control, configure the port as a hybrid port, enable MAC-based VLAN on the port, and assign the port to the Auth-Fail VLAN as an untagged member.

 

Configuring portal authentication

Overview

Portal authentication helps control access to the Internet. It is also called Web authentication. A website implementing portal authentication is called a portal website.

With portal authentication, an access device redirects all users to the portal authentication page. All users can access the free services provided on the portal website. However, to access the Internet, a user must pass portal authentication.

A user can access a known portal website and enter username and password for authentication. This authentication mode is called active authentication. There is also another authentication mode, forced authentication, in which the access device forces a user who is trying to access the Internet through HTTP to log on to a portal website for authentication.

The portal feature provides the flexibility for ISPs to manage services. A portal website can, for example, present advertisements and deliver community and personalized services. In this way, broadband network providers, equipment vendors, and content service providers form an industrial ecological system.

A typical portal system comprises these basic components: authentication client, access device, portal server, authentication/accounting server, and security policy server.

Figure 5 Portal system components

 

The components of a portal system interact in the following procedure:

1.     When an unauthenticated user enters a website address in the browser's address bar to access the Internet, an HTTP request is created and sent to the access device. The access device then redirects the HTTP request to the portal server's Web authentication homepage. For extended portal functions, authentication clients must run the portal client software.

2.     On the authentication homepage/authentication dialog box, the user enters and submits the authentication information, which the portal server then transfers to the access device.

3.     Upon receipt of the authentication information, the access device communicates with the authentication/accounting server for authentication and accounting.

4.     After successful authentication, the access device checks whether there is a corresponding security policy for the user. If not, it allows the user to access the Internet. Otherwise, the client communicates with the access device and the security policy server for security check. If the client passes security check, the security policy server authorizes the user to access the Internet resources.

 

	NOTE: The Web interface of the device supports configuring portal authentication only on Layer 3 interfaces. For more information about portal authentication, see H3C Access Controllers Security Configuration Guide.

 

Configuration prerequisites

Although the portal feature provides a solution for user identity authentication and security checking, the portal feature cannot implement this solution by itself. RADIUS authentication needs to be configured on the access device to cooperate with the portal feature to complete user authentication.

The prerequisites for portal authentication configuration are as follows:

·     The portal server and the RADIUS server have been installed and configured correctly. Local portal authentication requires no independent portal server.

·     With re-DHCP authentication, the IP address check function of DHCP relay is enabled on the access device, and the DHCP server is installed and configured correctly.

·     The portal client, access device, and servers can reach each other.

·     With RADIUS authentication, usernames and passwords of the users are configured on the RADIUS server, and the RADIUS client configurations are performed on the access device. For information about RADIUS client configuration, see "Configuring RADIUS."

·     To implement extended portal functions, install and configure IMC EAD. Make sure the ACLs configured on the access device correspond to those specified for the resources in the quarantined area and for the restricted resources on the security policy server. For information about security policy server configuration on the access device, see "Configuring RADIUS."

Configuration procedure

Step	Remarks
1.     Configuring the portal service	Required. Configure a portal server, apply the portal server to a Layer 3 interface, and configure the portal authentication parameters. By default, no portal server is configured.
2.     Configuring advanced parameters for portal authentication	Optional. Specify an auto redirection URL, set the time that the device must wait before redirecting an authenticated user to the auto redirection URL, and add Web proxy server port numbers.
3.     Configuring a portal-free rule	Optional. Configure a portal-free rule, specifying the source and destination information for packet filtering. A portal-free rule allows specified users to access specified external websites without portal authentication. Packets matching a portal-free rule will not trigger portal authentication and the users can directly access the specified external websites. By default, no portal-free policy is configured.

 

Configuring the portal service

1.     From the navigation tree, select Authentication > Portal.

The portal server configuration page appears.

The portal service on a Layer 3 interface can be in either of the following states:

¡     Running—Portal authentication has taken effect on the interface.

¡     Enabled—Portal authentication is enabled on the interface, but it does not take effect.

Figure 6 Portal server configuration

 

2.     Click Add to enter the portal service application page.

Figure 7 Portal service application

 

3.     Configure the portal application settings as described in Table 5.

4.     Click Apply.

Table 5 Configuration items

Item	Description
Interface	Specify the Layer 3 interface to be enabled with portal authentication.
Portal Server	Specify the portal server to be applied on the specified interface. Options include: ·     Select Server—Select an existing portal server from the Portal Server list. ·     New Server—If you select Add under this option from the list, the portal server configuration area, as shown in Figure 8, will be displayed at the lower part of the page. You can add a remote portal server and apply the portal server to the interface. For detailed configuration, see Table 6. ·     Enable Local Server—If you select this option from the list, the local portal service configuration area, as shown in Figure 9, will be displayed at the lower part of the page. You can configure the parameters for local portal service. For detailed configuration, see Table 7.
Method	Specify the portal authentication mode: ·     Direct—Direct portal authentication. ·     Layer3—Cross-subnet portal authentication. ·     Re DHCP—Re-DHCP portal authentication.  IMPORTANT: ·     In cross-subnet portal authentication mode, Layer 3 forwarding devices are not required to be present between the authentication client and the access device. However, if they are present, you must select the cross-subnet portal authentication mode. ·     In re-DHCP portal authentication mode, a client is allowed to send out packets using a public IP address before it passes portal authentication. However, responses of the packets are restricted. ·     If the local portal server is used, you can configure the re-DHCP mode but it does not take effect.
Auth Network IP Network Mask	Specify the IP address and mask of the authentication subnet. This field is configurable when you select the Layer3 mode (cross-subnet portal authentication). By configuring an authentication subnet, you specify that only HTTP packets from users on the authentication subnet can trigger portal authentication. If an unauthenticated user is not on any authentication subnet, the access device discards all the user's HTTP packets that do not match any portal-free rule.  IMPORTANT: The authentication subnet in direct mode is any source IP address, and that in re-DHCP mode is the private subnet to which the interface's private IP address belongs.
Authentication Domain	Specify the authentication domain for Layer 3 portal users. After you specify an authentication domain on a Layer 3 interface, the device will use the authentication domain for authentication, authorization, and accounting (AAA) of the portal users on the interface, ignoring the domain names carried in the usernames. You can specify different authentication domains for different interfaces as needed. The available authentication domains are those specified on the page you enter by selecting Authentication > AAA from the navigation tree. For more information, see "Configuring AAA."

 

Figure 8 Adding a portal server

 

Table 6 Configuration items

Item	Description
Server Name	Enter a name for the remote portal server.
IP	Enter the IP address of the remote portal server.
Key	Enter the shared key to be used for communication between the device and the remote portal server.
Port	Enter the port number of the remote portal server.
URL	Specify the URL for HTTP packets redirection, in the format http://ip-address. By default, the IP address of the portal server is used in the URL.  IMPORTANT: Redirection URL supports domain name resolution. However, you must configure a portal-free rule and add the DNS server address into the portal-free address range.

 

Figure 9 Local portal service configuration

 

Table 7 Configuration items

Item	Description
Server Name	Specify the local portal server name.
IP	Specify the IP address of the local portal server. You need to specify the IP address of the interface where the local portal server is applied.
URL	Specify the URL for HTTP packets redirection, in the format http://ip-address/portal/logon.htm or https://ip-address/portal/logon.htm (depending on the protocol type). By default, the IP address of the local portal server is used in the URL.  IMPORTANT: ·     To use the local portal server for stateful failover in a wireless environment, you must specify the redirection URL, and the IP address of the URL must be the virtual IP address of the VRRP group where the VRRP downlink resides. ·     URL redirection supports domain name resolution, but you need to configure a portal-free rule and add the DNS server address into the portal-free address range.
Protocol	Specify the protocol to be used for authentication information exchange between the local portal server and the client. It can be HTTP or HTTPS.
PKI Domain	Specify the PKI domain for HTTPS. This field is configurable when you select HTTPS. The available PKI domains are those specified on the page you enter by selecting Authentication > Certificate Management from the navigation tree. For more information, see "Managing certificates."  IMPORTANT: The service management, local portal authentication, and local EAP service modules always reference the same PKI domain. Changing the referenced PKI domain in any of the three modules will also change that referenced in the other two modules.
Page Customization SSID Page File	Specify the authentication page files to be bound with SSIDs as required. After you bind SSIDs with authentication page files, when a user access the portal page, the local portal server pushes the authentication pages according to the SSID of the user login interface and the bound authentication page file. By default, an SSID is not bound with any authentication page file. In this case, the system pushes the default authentication pages. You can edit an authentication page file as required and save it in the root directory or the portal directory under the root directory of the access device. For rules of customizing authentication pages, see "Customizing authentication pages."

 

Configuring advanced parameters for portal authentication

1.     From the navigation tree, select Authentication > Portal.

2.     Expand the Advanced area to show the advanced parameters for portal authentication.

Figure 10 Advanced configuration

 

3.     Configure the advanced parameters as described in Table 8.

4.     Click Apply.

Table 8 Advanced portal parameters

Item	Description
Web Proxy Server Ports	Add the Web proxy server ports to allow HTTP requests proxied by the specified proxy servers to trigger portal authentication. By default, only HTTP requests that are not proxied can trigger portal authentication. Different clients may have different Web proxy configurations. To make sure that clients using a Web proxy can trigger portal authentication, you must first complete some other relevant configurations. When the IMC portal server is used, you must first complete the following configurations: ·     If the client does not specify the portal server's IP address as a proxy exception, ensure the IP connectivity between the portal server and the Web proxy server and perform the following configurations on the IMC portal server: ¡     Select NAT as the type of the IP group associated with the portal device. ¡     Specify the proxy server's IP address as the IP address after NAT. ¡     Configure the port group to support NAT. ·     If the client specifies the portal server's IP address as an exception of the Web proxy server, configure the IP group and port group to not support NAT.  IMPORTANT: ·     If a user's browser uses the Web Proxy Auto-Discovery (WPAD) protocol to discover Web proxy servers, add the port numbers of the Web proxy servers on the device, and configure portal-free rules to allow user packets destined for the IP address of the WPAD server to pass without authentication. ·     If the Web proxy server port 80 is added on the device, clients that do not use a proxy server can trigger portal authentication only when they access a reachable host enabled with the HTTP service. ·     Authorized ACLs to be assigned to users who have passed portal authentication must contain a rule that permits the Web proxy server's IP address. Otherwise, the user cannot receive heartbeat packets from the remote portal server.
Redirection URL	Specify the auto redirection URL to which users will be automatically redirected after they pass portal authentication. To access the network, an unauthenticated user either goes to or is automatically forced to the portal authentication page for authentication. If the user passes portal authentication and the access device is configured with an auto redirection URL, the access device will redirect the user to the URL after a specified period of time.
Wait-Time	Period of time that the device must wait before redirecting an authenticated portal user to the auto redirection URL.

 

Configuring a portal-free rule

1.     From the navigation tree, select Authentication > Portal.

2.     Click the Free Rule tab.

Figure 11 Portal-free rule configuration

 

3.     Click Add.

The page for adding a new portal-free rule appears.

Figure 12 Adding a portal-free rule

 

4.     Configure the portal-free rule as described in Table 9.

5.     Click Apply.

Table 9 Configuration items

Item	Description
Number	Specify the sequence number of the portal-free rule. The maximum number of portal-free rules varies by device model. For more information, see "About the H3C Access Controllers Web-Based Configuration Guide."
Source-interface	Specify the source interface of the portal-free rule. The SSIDs in the list are the corresponding SSIDs of the wireless ESS interfaces.
Source IP Address Mask	Specify the source IP address and mask of the portal-free rule.
Source-MAC	Specify the source MAC address of the portal-free rule.  IMPORTANT: If you configure both the source IP address and the source MAC address, make sure that the mask of the specified source IP address is 255.255.255.255. Otherwise, the specified source MAC address will not take effect.
Source-VLAN	Specify the source VLAN of the portal-free rule.  IMPORTANT: If you configure both a source interface and a source VLAN for a portal-free rule, make sure that the source interface is in the source VLAN. Otherwise, the portal-free rule will not take effect.
Destination IP Address Mask	Specify the destination IP address and mask of the portal-free rule.

 

Customizing authentication pages

When the local portal server is used for portal authentication, the local portal server pushes authentication pages. You can define the authentication pages for users. Otherwise, the local portal server pushes the default authentication pages.

Customized authentication pages exist in the form of HTML files. You can compress them, and then save them in the storage medium of the access device.

A set of authentication pages include six main pages and their page elements.

The six main pages are the logon page, the logon success page, the logon failure page, the online page, the system busy page, and the logoff success page.

The page elements are the files that the authentication pages reference. For example, back.jpg is for page Logon.htm. Each main authentication page can reference multiple page elements. If you define only some of the main pages, the local portal server pushes the default authentication pages for the undefined ones.

For the local portal server to operate normally and steadily, use the following rules in this section when customizing authentication pages.

File name rules

The names of the main authentication page files cannot be changed. You can define the names of the files other than the main authentication page files. File names and directory names are case-insensitive.

Table 10 Main authentication page file names

Main authentication page	File name
Logon page.	logon.htm
Logon success page.	logonSuccess.htm
Logon failure page.	logonFail.htm
Online page. Pushed after the user gets online for online notification.	online.htm
System busy page. Pushed when the system is busy or the user is in the logon process.	busy.htm
Logoff success page.	logoffSuccess.htm

 

Page request rules

The local portal server supports only Post and Get requests.

·     Get requests—Used to get the static files in the authentication pages, and allow no recursion. For example, if file logon.htm includes contents that perform Get action on file ca.htm, file ca.htm cannot include any reference to file logon.htm.

·     Post requests—Used when users submit usernames and passwords, log on to the system, and log off the system.

Post request attribute rules

1.     Observe the following requirements when editing a form of an authentication page:

¡     An authentication page can have multiple forms, but there must be one and only one form whose action is logon.cgi. Otherwise, user information cannot be sent to the local portal server.

¡     The username attribute is fixed as PtUser. The password attribute is fixed as PtPwd.

¡     Attribute PtButton is required to indicate the action that the user requests, either Logon or Logoff.

¡     A logon Post request must contain PtUser, PtPwd, and PtButton attributes.

¡     A logoff Post request must contain the PtButton attribute.

2.     Authentication pages logon.htm and logonFail.htm must contain the logon Post request.

The following example shows part of the script in page logon.htm.

<form action=logon.cgi method = post >

<p>User name:<input type="text" name = "PtUser" style="width:160px;height:22px" maxlength=64>

<p>Password :<input type="password" name = "PtPwd" style="width:160px;height:22px" maxlength=32>

<p><input type=SUBMIT value="Logon" name = "PtButton" style="width:60px;" onclick="form.action=form.action+location.search;>

</form>

3.     Authentication pages logonSuccess.htm and online.htm must contain the logoff Post request.

The following example shows part of the script in page online.htm.

<form action=logon.cgi method = post >

<p><input type=SUBMIT value="Logoff" name="PtButton" style="width:60px;">

</form>

Page file compression and saving rules

·     A set of authentication page files must be compressed into a standard .zip file. The name of a .zip file can contain only letters, numbers, and underscores. The .zip file of the default authentication pages must be saved with name defaultfile.zip.

·     The set of authentication pages must be located in the root directory of the .zip file.

·     Zip files can be transferred to the device through FTP or TFTP. The default authentication pages file must be saved in the root directory of the device, and other authentication files can be saved in the root directory or in the portal directory under the root directory of the device.

File size and content rules   

The following size and content requirements for authentication pages allows the system to push customized authentication pages smoothly:

·     The size of the zip file of each set of authentication pages, including the main authentication pages and the page elements, must be no more than 500 KB.

·     The size of an uncompressed page, including the main authentication page and its page elements, must be no more than 50 KB.

·     Page elements can contain only static contents such as HTML, JS, CSS, and pictures.

Logging off a user who closes the logon success or online page

After a user passes authentication, the system pushes the logon success page named logonSuccess.htm. If the user initiates another authentication through the logon page, the system pushes the online page named online.htm. You can configure the device to forcibly log off the user when the user closes either of these two pages. To do so, add the following contents in logonSuccess.htm and online.htm:

1.     Reference to file pt_private.js.

2.     Function pt_unload(), which is for triggering page unloading.

3.     Function pt_submit(), the event handler function for Form.

4.     Function pt_init(), which is for triggering page loading.

The following is a script example with the added contents highlighted in gray:

    <html>

    <head>

    <script type="text/javascript" language="javascript" src="pt_private.js"></script>

    </head>

    <body onload="pt_init();" onbeforeunload="return pt_unload();">

    ... ...

<form action=logon.cgi method = post onsubmit="pt_submit()">

    ... ...

    </body>

    </html>

If a user refreshes the logon success or online page, or jumps to another website from either of the pages, the device also logs off the user.

Google Chrome browsers do not support this function.

Make sure that the browser of an authentication client permits pop-ups or permits pop-ups from the access device. Otherwise, the user cannot log off by closing the logon success or online page, and can only click Cancel to return back to the logon success or online page

Redirecting authenticated users to a specific webpage

To make the device automatically redirect authenticated users to a specified webpage, do the following in logon.htm and logonSuccess.htm:

1.     In logon.htm, set the target attribute of Form to blank.

See the contents in gray:

    <form method=post action=logon.cgi target="blank">

2.     Add the function for page loading pt_init() to logonSucceess.htm.

See the contents in gray:

    <html>

    <head>

    <title>LogonSuccessed</title>

    <script type="text/javascript" language="javascript" src="pt_private.js"></script>

    </head>

    <body onload="pt_init();" onbeforeunload="return pt_unload();">

    ... ...

    </body>

    </html>

H3C recommends using browser IE 6.0 or later on the authentication clients.

Portal authentication configuration example

Network requirements

As shown in Figure 13, the wireless client belongs to VLAN 2 and accesses the network through the AP, which belongs to VLAN 3. The model and serial ID of the AP is WA3628i-AGN and 210235A29G007C00002, respectively.

AC supports the local portal server, which runs HTTPS. The local portal server can push the corresponding customized pages according to the SSID of the user logon interface.

A RADIUS server runs on IMC to provide authentication and accounting services.

The client must pass direct portal authentication to access Internet resources. Before authentication, the client can access only the local portal server.

Figure 13 Network diagram

 

Configuration prerequisites

Complete the follow tasks before you perform the portal configuration:

·     Configure IP addresses for the devices, as shown in Figure 13, and make sure they can reach each other.

·     Configure PKI domain test, and make sure that a local certificate and a CA certificate are obtained successfully. For more information, see "Managing certificates."

·     Complete the editing of the authentication page files to be bound with the client SSID.

·     Configure the RADIUS server correctly to provide authentication and accounting functions for users.

Configuring the AC

1.     Configure the RADIUS scheme system:

a.     From the navigation tree, select Authentication > RADIUS.

b.     Click Add.

c.     On the page that appears, enter the scheme name system, select the server type Extended, and select Without domain name for Username Format.

d.     In the RADIUS Server Configuration area, click Add.

e.     On the page that appears, select Primary Authentication as the server type, enter the IP address 1.1.1.2, the port number 1812, and the key expert, enter expert again in the Confirm Key field, and click Apply.

The RADIUS server configuration page closes, and the RADIUS Server Configuration area on the RADIUS scheme configuration page displays the authentication server you have just configured.

f.     In the RADIUS Server Configuration area, click Add.

g.     On the page that appears, select Primary Accounting as the server type, enter the IP address 1.1.1.2, the port number 1813, and the key expert, enter expert again in the Confirm Key field, and click Apply.

The RADIUS server configuration page closes, and the RADIUS Server Configuration area on the RADIUS scheme configuration page displays the accounting server you have just configured.

h.     Click Apply.

Figure 14 Configuring the RADIUS scheme

 

2.     Configure ISP domain test as the default domain:

a.     From the navigation tree, select Authentication > AAA.

The Domain Setup tab appears.

b.     Enter the domain name test, and select Enable from the Default Domain list.

c.     Click Apply.

Figure 15 Creating an ISP domain

 

3.     Configure an authentication method for the ISP domain:

a.     Click the Authentication tab.

b.     Select the domain name test.

c.     Select the Default AuthN option, and then select RADIUS as the authentication mode.

d.     From the Name list, select system to use it as the authentication scheme

e.     Click Apply.

A configuration progress dialog box appears.

f.     After the configuration process is complete, click Close.

Figure 16 Configuring the authentication method for the ISP domain

 

4.     Configure an authorization method for the ISP domain:

a.     Click the Authorization tab.

b.     Select the Default AuthZ option, and then select RADIUS as the authorization mode.

c.     From the Name list, select system to use it as the authorization scheme

d.     Click Apply.

A configuration progress dialog box appears

e.     After the configuration process is complete, click Close.

Figure 17 Configuring the authorization method for the ISP domain

 

5.     Configure an accounting method for the ISP domain:

a.     Click the Accounting tab.

b.     Select the domain name test.

c.     Select the Accounting Optional option, and then select Enable from the list.

d.     Select the Default Accounting option, and then select RADIUS as the accounting mode.

e.     From the Name list, select system to use it as the accounting scheme

f.     Click Apply.

The configuration progress dialog box appears

g.     After the configuration process is complete, click Close.

Figure 18 Configuring the accounting method for the ISP domain

 

6.     Create an AP:

a.     From the navigation tree, select AP > AP Setup.

b.     Click Create.

c.     Enter the AP name ap1.

d.     Select model WA3628i-AGN.

e.     Select the manual mode for serial ID, and then enter the serial ID 210235A29G007C00002.

f.     Click Apply.

Figure 19 Creating an AP

 

7.     Create a wireless service:

a.     From the navigation tree, select Wireless Service > Access Service.

b.     Click New.

c.     On the page as shown in Figure 20, enter the wireless service name abc, select clear as the wireless service type, and click Apply.

The wireless service configuration page appears.

Figure 20 Creating a wireless service

 

d.     On the page as shown in Figure 21, enter 2 in the VLAN (Untagged) field, enter 2 in the Default VLAN field, and click Apply.

A configuration progress dialog box appears.

Figure 21 Configuring parameters for the wireless service

 

e.     After the configuration process is complete, click Close.

8.     Enable the wireless service:

a.     On wireless service list as shown in Figure 22, select the wireless service abc.

b.     Click Enable.

A configuration progress dialog box appears.

c.     After the configuration process is complete, click Close.

Figure 22 Enabling the wireless service

 

9.     Bind an AP radio with the wireless service:

a.     On the wireless service list, click the  icon in the Operation column of wireless service abc.

b.     On the page that appears, select ap1 with the radio mode of 802.11n(2.4GHz).

c.     Click Bind.

A configuration progress dialog box appears.

d.     After the configuration process is complete, click Close.

Figure 23 Binding an AP radio

 

10.     Enable radio:

a.     From the navigation tree, select Radio > Radio.

b.     Select ap1 with the radio mode of 802.11n(2.4GHz).

c.     Click Enable.

Figure 24 Enabling 802.11n(2.4GHz) radio

 

11.     Configure portal authentication:

a.     From the navigation tree, select Authentication > Portal.

b.     Click Add.

c.     Configure a local portal server:

-     Select interface Vlan-interface2.

-     Select Enable Local Server for Portal Server.

-     Select Direct as the authentication method.

-     Select the authentication domain test.

-     Enter 192.168.1.1 as the server IP address.

-     Select HTTPS as the protocol type.

-     Select test as the PKI domain.

-     Select Page Customization.

-     Select the authentication page file ssid1.zip for SSID abc.

d.     Click Apply.

Figure 25 Portal service application

 

12.     Configure a portal-free rule for port GigabitEthernet 1/0/1:

a.     Click the Free Rule tab.

b.     Click Add.

c.     On the page that appears, enter the rule number 0, and select the source interface GigabitEthernet 1/0/1.

d.     Click Apply.

Figure 26 Configuring a portal-free rule for port GigabitEthernet 1/0/1

 

Verifying the configuration

When a user accesses subnet 1.1.1.0/24 by using a Web browser, the user is redirected to page https://192.168.1.1/portal/logon.htm. After entering the correct username and password on the webpage, the user passes the authentication.

Configuring AAA

Overview

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 the service type, start time, and traffic. The accounting function provides information required for charging and allows for network security surveillance.

AAA can be implemented through multiple protocols. The device supports RADIUS. For more information, see "Configuring RADIUS."

AAA typically uses a client/server model. The client runs on the network access server (NAS) and the server maintains user information centrally. In an AAA network, the NAS is a server for users, but a client for AAA servers.

Figure 27 AAA application scenario

 

AAA manages users based on their ISP domains and access types.

On a NAS, each user belongs to one ISP domain. Typically, a NAS determines the ISP domain a user belongs to by the username entered by the user at login.

Figure 28 Determining the ISP domain for a user by the username

 

You can configure different authentication, authorization, and accounting methods for users in an ISP domain. Or you can configure a set of default methods for an ISP domain. These default methods are used for users for whom no specific AAA methods are configured.

AAA manages users in the same ISP domain based on their access types. The device supports the following user 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, FTP users, and terminal users.

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

·     PPP users—Users who access through PPP.

To improve device security, AAA provides command authorization for login users. Command authorization enables the NAS to defer to the authorization server to determine whether a command entered by a login user is permitted for the user, and allows login users to execute only authorized commands.

For more information about AAA and ISP, see H3C Access Controllers Security Configuration Guide.

Configuration prerequisites

·     To deploy local authentication, first configure local users on the access device. See "Configuring users."

·     To perform RADIUS authentication, first create the RADIUS schemes. See "Configuring RADIUS."

Configuration procedure

Step	Remarks
1.     Configuring an ISP domain	Optional. Create ISP domains and specify one of them as the default ISP domain. By default, there is an ISP domain named system, which is the default ISP domain.
2.     Configuring authentication methods for the ISP domain	Optional. Configure authentication methods for various types of users. By default, all types of users use local authentication.
3.     Configuring authorization methods for the ISP domain	Optional. Specify the authorization methods for various types of users. By default, all types of users use local authorization.
4.     Configuring accounting methods for the ISP domain	Required. Specify the accounting methods for various types of users. By default, all types of users use local accounting.

 

Configuring an ISP domain

1.     From the navigation tree, select Authentication > AAA.

The Domain Setup page appears.

Figure 29 Domain Setup page

 

2.     Configure an ISP domain as described in Table 11.

3.     Click Apply.

Table 11 Configuration items

Item	Description
Domain Name	Enter an ISP domain name for uniquely identifying the domain. You can enter a new domain name to create a domain, or specify an existing domain to change its status (whether it is the default domain).
Default Domain	Specify whether to use the ISP domain as the default domain. Options include: ·     Enable—Uses the domain as the default domain. ·     Disable—Uses the domain as a non-default domain. There can only be one default domain at a time. If you specify a second domain as the default domain, the original default domain will become a non-default domain.

 

Configuring authentication methods for the ISP domain

1.     From the navigation tree, select Authentication > AAA.

2.     Click the Authentication tab to enter the authentication method configuration page.

Figure 30 Authentication method configuration page

 

3.     Configure authentication methods for different types of users in the domain, as described in Table 12.

4.     Click Apply.

A configuration progress dialog box appears.

5.     After the configuration progress is complete, click Close.

Table 12 Configuration items

Item	Description
Select an ISP domain	Select the ISP domain for which you want to specify authentication methods.
Default AuthN Name Secondary Method	Configure the default authentication method and secondary authentication method for all types of users. Options include: ·     HWTACACS—HWTACACS authentication. You must specify the HWTACACS scheme to be used. ·     Local—Local authentication. ·     None—No authentication. This method trusts all users and is not for general use. ·     RADIUS—RADIUS authentication. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the default authentication setting, which is local authentication.  IMPORTANT: Use the default authentication method if the AC performs authentication on the connecting APs.
LAN-access AuthN Name Secondary Method	Configure the authentication method and secondary authentication method for LAN users. Options include: ·     Local—Local authentication. ·     None—No authentication. This method trusts all users and is not for general use. ·     RADIUS—RADIUS authentication. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default AuthN area for LAN users.
Login AuthN Name Secondary Method	Configure the authentication method and secondary authentication method for login users. Options include: ·     HWTACACS—HWTACACS authentication. You must specify the HWTACACS scheme to be used. ·     Local—Local authentication. ·     None—No authentication. This method trusts all users and is not for general use. ·     RADIUS—RADIUS authentication. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default AuthN area for login users.
PPP AuthN Name Secondary Method	Configure the authentication method and secondary authentication method for PPP users. Options include: ·     HWTACACS—HWTACACS authentication. You must specify the HWTACACS scheme to be used. ·     Local—Local authentication. ·     None—No authentication. This method trusts all users and is not for general use. ·     RADIUS—RADIUS authentication. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default AuthN area for PPP users.
Portal AuthN Name Secondary Method	Configure the authentication method and secondary authentication method for portal users. Options include: ·     Local—Local authentication. ·     None—No authentication. This method trusts all users and is not for general use. ·     RADIUS—RADIUS authentication. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default AuthN area for portal users.

 

Configuring authorization methods for the ISP domain

1.     From the navigation tree, select Authentication > AAA.

2.     Click the Authorization tab to enter the authorization method configuration page.

Figure 31 Authorization method configuration page

 

3.     Configure authorization methods for different types of users in the domain, as described in Table 13.

4.     Click Apply.

A configuration progress dialog box appears.

5.     After the configuration progress is complete, click Close.

Table 13 Configuration items

Item	Description
Select an ISP domain	Select the ISP domain for which you want to specify authorization methods.
Default AuthZ Name Secondary Method	Configure the default authorization method and secondary authorization method for all types of users. Options include: ·     HWTACACS—HWTACACS authorization. You must specify the HWTACACS scheme to be used. ·     Local—Local authorization. ·     None—This method trusts all users and assigns default rights to them. ·     RADIUS—RADIUS authorization. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the default authorization setting, which is local authorization.
LAN-access AuthZ Name Secondary Method	Configure the authorization method and secondary authorization method for LAN users. Options include: ·     Local—Local authorization. ·     None—This method trusts all users and assigns default rights to them. ·     RADIUS—RADIUS authorization. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default AuthZ area for LAN users.
Login AuthZ Name Secondary Method	Configure the authorization method and secondary authorization method for login users. Options include: ·     HWTACACS—HWTACACS authorization. You must specify the HWTACACS scheme to be used. ·     Local—Local authorization. ·     None—This method trusts all users and assigns default rights to them. ·     RADIUS—RADIUS authorization. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default AuthZ area for login users.
PPP AuthZ Name Secondary Method	Configure the authorization method and secondary authorization method for PPP users. Options include: ·     HWTACACS—HWTACACS authorization. You must specify the HWTACACS scheme to be used. ·     Local—Local authorization. ·     None—This method trusts all users and assigns default rights to them. ·     RADIUS—RADIUS authorization. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default AuthZ area for PPP users.
Portal AuthZ Name Secondary Method	Configure the authorization method and secondary authorization method for portal users. Options include: ·     Local—Local authorization. ·     None—This method trusts all users and assigns default rights to them. ·     RADIUS—RADIUS authorization. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default AuthZ area for portal users.
Command AuthZ Name	Configure the command authorization method. Options include: ·     HWTACACS—HWTACACS authorization. You must specify the HWTACACS scheme to be used. ·     Not Set—The device uses the settings in the Default AuthZ area for command users.

 

Configuring accounting methods for the ISP domain

1.     From the navigation tree, select Authentication > AAA.

2.     Click the Accounting tab to enter the accounting method configuration page.

Figure 32 Accounting method configuration page

 

3.     Configure accounting methods for different types of users in the domain, as described in Table 14.

4.     Click Apply.

A configuration progress dialog box appears.

5.     After the configuration progress is complete, click Close.

Table 14 Configuration items

Item	Description
Select an ISP domain	Select the ISP domain for which you want to specify accounting methods.
Accounting Optional	Specify whether to enable the accounting optional feature. With the feature enabled, a user that will be disconnected otherwise can use the network resources even when there is no accounting server available or communication with the current accounting server fails. If accounting for such a user fails, the device will not send real-time accounting updates for the user anymore.
Default Accounting Name Secondary Method	Configure the default accounting method and secondary accounting method for all types of users. Options include: ·     HWTACACS—HWTACACS accounting. You must specify the HWTACACS scheme to be used. ·     Local—Local accounting. ·     None—No accounting. ·     RADIUS—RADIUS accounting. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the default accounting setting, which is local accounting.
LAN-access Accounting Name Secondary Method	Configure the accounting method and secondary accounting method for LAN users. Options include: ·     Local—Local accounting. ·     None—No accounting. ·     RADIUS—RADIUS accounting. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default Accounting area for LAN users.
Login Accounting Name Secondary Method	Configure the accounting method and secondary accounting method for login users. Options include: ·     HWTACACS—HWTACACS accounting. You must specify the HWTACACS scheme to be used. ·     Local—Local accounting. ·     None—No accounting. ·     RADIUS—RADIUS accounting. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default Accounting area for login users.
PPP Accounting Name Secondary Method	Configure the accounting method and secondary accounting method for PPP users. Options include: ·     HWTACACS—HWTACACS accounting. You must specify the HWTACACS scheme to be used. ·     Local—Local accounting. ·     None—No accounting. ·     RADIUS—RADIUS accounting. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default Accounting area for PPP users.
Portal Accounting Name Secondary Method	Configure the accounting method and secondary accounting method for portal users. Options include: ·     Local—Local accounting. ·     None—No accounting. ·     RADIUS—RADIUS accounting. You must specify the RADIUS scheme to be used. ·     Not Set—The device uses the settings in the Default Accounting area for portal users.

 

AAA configuration example

Network requirements

As shown in Figure 33, configure the AC to perform local authentication, authorization, and accounting for Telnet users.

Figure 33 Network diagram

 

Configuration procedure

1.     Configure a local user:

a.     From the navigation tree, select Authentication > Users.

The local user management page appears.

b.     Click Add.

c.     Enter telnet as the username.

d.     Enter abcd as the password.

e.     Enter abcd again to confirm the password.

f.     Select Reversible for password encryption.

g.     Select Common User as the user type.

h.     Select Configure as the level.

i.     Select Telnet as the service type.

j.     Click Apply.

Figure 34 Configuring the local user

 

2.     Configure ISP domain test:

a.     From the navigation tree, select Authentication > AAA.

The Domain Setup page appears, as shown in Figure 35.

b.     Enter test as the domain name.

c.     Click Apply.

Figure 35 Configuring ISP domain test

 

3.     Configure the ISP domain to use local authentication for login users:

a.     From the navigation tree, select Authentication > AAA.

b.     Click the Authentication tab.

c.     Select the domain test.

d.     Select the Login AuthN option, and then select the authentication method Local.

e.     Click Apply.

A configuration progress dialog box appears.

f.     After the configuration progress is complete, click Close.

Figure 36 Configuring the ISP domain to use local authentication for login users

 

4.     Configure the ISP domain to use local authorization for login users:

a.     From the navigation tree, select Authentication > AAA.

b.     Click the Authorization tab.

c.     Select the domain test.

d.     Select the Login AuthZ option, and then select the authorization method Local.

e.     Click Apply.

A configuration progress dialog box appears.

f.     After the configuration progress is complete, click Close.

Figure 37 Configuring the ISP domain to use local authorization for login users

 

5.     At the CLI, enable the Telnet service and configure the AC to use AAA for Telnet users.

<AC> system-view

[AC] telnet server enable

[AC] user-interface vty 0 4

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

[AC-ui-vty0-4] quit

Verifying the configuration

Telnet to the AC and enter the username telnet@test and password abcd. You are serviced as a user in domain test.

Configuring RADIUS

The Remote Authentication Dial-In User Service (RADIUS) protocol implements Authentication, Authorization, and Accounting (AAA). RADIUS uses the client/server model. It can protect networks against unauthorized access, and is often used in network environments where both high security and remote user access are required. RADIUS defines the packet format and message transfer mechanism, and uses UDP as the transport layer protocol for encapsulating RADIUS packets. It 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, for example, Ethernet and ADSL. RADIUS provides access authentication and authorization services. Its accounting function collects and records network resource usage information.

For more information about AAA and RADIUS, see H3C Access Controllers Security Configuration Guide.

Configuration guidelines

When you configure RADIUS, use the following guidelines:

·     Accounting for FTP users is not supported.

·     If you remove the accounting server used for online users, the device cannot send real-time accounting requests and stop-accounting messages for the users to the server, and the stop-accounting messages are not buffered locally.

·     The status of RADIUS servers (blocked or active) determines which servers the device will communicate with or turn to when the current servers are not available. In practice, you can specify one primary RADIUS server and multiple secondary RADIUS servers, with the secondary servers that function as the backup of the primary servers. Generally, 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 state of the primary server to blocked, starts a quiet timer for the server, and turns to 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 state of the secondary server 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 cannot be delivered to the server any more.

¡     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 from scratch: it checks the primary server (if any) 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 statues changes to active. Otherwise, its status remains to be blocked.

¡     If one server is in active state, but 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.

·     It is a good practice to use the recommended real-time accounting intervals listed in Table 15.

Table 15 Recommended real-time accounting intervals

Number of users	Real-time accounting interval (in minutes)
1 to 99	3
100 to 499	6
500 to 999	12
≥1000	≥15

 

Configuring a RADIUS scheme

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

To configure a RADIUS scheme:

1.     From the navigation tree, select Authentication > RADIUS.

Figure 38 RADIUS scheme list

 

2.     Click Add.

Figure 39 RADIUS scheme configuration page

 

3.     Enter a scheme name.

4.     Select a server type and a username format.

Table 16 Configuration items

Item	Description
Server Type	Select the type of the RADIUS servers supported by the device: ·     Standard—Standard RADIUS servers. The RADIUS client and server communicate by using the standard RADIUS protocol and packet format defined in RFC 2865/2866 or later. ·     Extended—Extended RADIUS servers, usually running on IMC. The RADIUS client and server communicate by using the proprietary RADIUS protocol and packet format.
Username Format	Select the format of usernames to be sent to the RADIUS server. Typically, a username is in the format of userid@isp-name, of which isp-name is used by the device to determine the ISP domain to for the user. If a RADIUS server does not accept a username that contains an ISP domain name, configure the device to remove the domain name of a username before sending it to the RADIUS server. ·     Original format—Configure the device to send the username of a user on an "as is" basis. ·     With domain name—Configure the device to include the domain name in a username. ·     Without domain name—Configure the device to remove the domain name from a username.

 

5.     In the Common Configuration area, expand the Advanced area.

Figure 40 Advanced configuration area

 

6.     Configure the advanced parameters.

Table 17 Configuration items

Item	Description
Authentication Key Confirm Authentication Key Accounting Key Confirm Accounting Key	Set the shared key for RADIUS authentication packets and that for RADIUS accounting packets. The RADIUS client and the RADIUS authentication/accounting server use MD5 to encrypt RADIUS packets. They verify the validity of packets through the specified shared key. The client and the server can receive and respond to packets from each other only when they use the same shared key.  IMPORTANT: ·     The shared keys configured on the device must be consistent with those configured on the RADIUS servers. ·     The shared keys configured in the Common Configuration area are used only when no corresponding shared keys are configured in the RADIUS server configuration area.
Quiet Time	Set the time the device keeps an unreachable RADIUS server in blocked state. If you set the quiet time to 0, when the device needs to send an authentication or accounting request but finds that the current server is unreachable, it does not change the server's status that it maintains. It simply sends the request to the next server in active state. As a result, when the device needs to send a request of the same type for another user, it still tries to send the request to the server because the server is in active state. You can use this parameter to control whether the device changes the status of an unreachable server. For example, if you determine that the primary server is unreachable because the device's port for connecting the server is out of service temporarily or the server is busy, you can set the time to 0 so that the device uses the primary server as much.
Server Response Timeout Time Request Transmission Attempts	Set the RADIUS server response timeout time and the maximum number of attempts for transmitting a RADIUS packet to a single RADIUS server. If the device does not receive a response to its request from the RADIUS server within the response timeout period, it retransmits the RADIUS request. If the number of transmission attempts exceeds the limit but the device still receives no response from the RADIUS server, the device considers the request a failure.  IMPORTANT: The server response timeout time multiplied by the maximum number of RADIUS packet transmission attempts must not exceed 75.
Realtime Accounting Interval	Set the interval for sending real-time accounting information. The interval must be a multiple of 3. To implement real-time accounting, the device must send real-time accounting packets to the accounting server for online users periodically. Different real-time accounting intervals impose different performance requirements on the NAS and the RADIUS server. A shorter interval helps achieve higher accounting precision but requires higher performance. Use a longer interval when 1000 or more users exist. For information about the recommended real-time accounting intervals, see "Configuration guidelines."
Realtime Accounting Attempts	Set the maximum number of attempts for sending a real-time accounting request.
Unit for Data Flows	Specify the unit for data flows sent to the RADIUS server: ·     Byte. ·     Kilo-byte. ·     Mega-byte. ·     Giga-byte. The traffic measurement units on the device must be the same as the units configured on the RADIUS servers.
Unit for Packets	Specify the unit for data packets sent to the RADIUS server: ·     One-packet. ·     Kilo-packet. ·     Mega-packet. ·     Giga-packet. The traffic measurement units on the device must be the same as the units configured on the RADIUS servers.
Enable EAP offload	Enable or disable the EAP offload function. RADIUS servers that do not support EAP authentication cannot process EAP packets. To cooperate with these servers, the device must process EAP packets it receives from EAP clients before forwarding them to the servers. After receiving an EAP packet from an EAP client, the device operates as a local EAP authentication server to interact with the client, encapsulate the authentication information of the client into the RADIUS MS-CHAPv2 attribute, and send the attribute in a RADIUS authentication request to the RADIUS server. When the RADIUS server receives the request, it resolves the authentication information in the request, performs authentication, and then encapsulates and sends the authentication result in a RADIUS packet to the local EAP authentication server.
Security Policy Server	Specify the IP address of the security policy server.
RADIUS Packet Source IP	Specify the source IP address for the device to use in RADIUS packets sent to the RADIUS server. The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon receiving a RADIUS packet, a RADIUS server checks whether the source IP address of the packet is the IP address of a managed NAS. If it is, the server processes the packet. If it is 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. However, in some situations, you must change the source IP address. For example, if the NAS is configured with VRRP for stateful failover, the source IP address of outgoing RADIUS packets can be the virtual IP address of the uplink VRRP group.  IMPORTANT: ·     If you do not specify this parameter, the IP address of the outbound interface is used. ·     Make sure this source address has the same IP version of the RADIUS server address that is specified in the scheme. Otherwise, the configuration does not take effect.
RADIUS Packet Backup Source IP	Specify the backup source IP address for the device to use in RADIUS packets sent to the RADIUS server. In a stateful failover environment, the backup source IP address must be the source IP address for the remote device to use in RADIUS packets sent to the RADIUS server. Configuring the backup source IP address in a stateful failover environment makes sure that the backup server can receive the RADIUS packets sent from the RADIUS server when the master device fails.
Buffer stop-accounting packets	Enable or disable buffering of stop-accounting requests for which no responses are received.
Stop-Accounting Attempts	Set the maximum number of stop-accounting attempts. The NAS disconnects from a user according to the maximum number of stop-accounting attempts and specific parameters. For example, the RADIUS server response timeout period is 3 seconds, the maximum number of transmission attempts is five, and the maximum number of stop-accounting attempts is 20. For each stop-accounting request, if the device receives no response within 3 seconds, it retransmits the request. If it receives no responses after retransmitting the request five times, it considers the stop-accounting attempt a failure, buffers the request, and makes another stop-accounting attempt. If 20 consecutive attempts fail, the device discards the request.
Send accounting-on packets	Enable or disable the accounting-on feature. The accounting-on feature enables a device to send accounting-on packets to RADIUS servers after it reboots, making the servers forcedly log out users who logged in through the device before the reboot.  IMPORTANT: When enabling the accounting-on feature on a device for the first time, you must save the configuration so that the feature takes effect after the device reboots.
Accounting-On Interval	Set the interval for sending accounting-on packets. This field is configurable only when the Send accounting-on packets option is selected.
Accounting-On Attempts	Set the maximum number of accounting-on packets transmission attempts. This field is configurable only when the Send accounting-on packets option is selected.
Attribute Interpretation	Enable or disable the device to interpret the RADIUS class attribute as CAR parameters.

 

7.     In the RADIUS Server Configuration area, click Add.

Figure 41 RADIUS server configuration page

 

8.     Configure a RADIUS server for the RADIUS scheme.

Table 18 Configuration items

Item	Description
Server Type	Select the type of the RADIUS server to be configured. Possible values include primary authentication server, primary accounting server, secondary authentication server, and secondary accounting server.
IP Address	Specify the IPv4 or IPv6 address of the RADIUS server. You cannot specify the same server to serve as both the primary and the secondary authentication server in the scheme. The same rule applies to the primary and secondary accounting servers. Make sure all RADIUS server addresses in the scheme use the same IP version.
Port	Specify the UDP port of the RADIUS server.
Key Confirm Key	Specify the shared key for communication with the RADIUS server. If no shared key is specified here, the shared key specified in the common configuration area is used.

 

9.     Click Apply to add the server to the RADIUS scheme.

10.     Repeat step 7 through step 9 to add more RADIUS servers to the RADIUS scheme.

11.     On the RADIUS scheme configuration page, click Apply.

RADIUS configuration example

Network requirements

As shown in Figure 42, a RADIUS server running on IMC uses UDP ports 1812 and 1813 to provide authentication and accounting services, respectively.

Configure the AC to use the RADIUS server for Telnet user authentication and accounting, and to include domain names in the usernames sent to the server.

On the RADIUS server, configure a Telnet user account with the username hello@bbb and the password abc, and set the EXEC privilege level to 3 for the user.

Set the shared keys for packet exchange between the AC and the RADIUS server to expert.

Figure 42 Network diagram

 

Configure the RADIUS server

In this example, the RADIUS server runs on IMC PLAT 3.20-R2606 and IMC UAM 3.60-E6206.

1.     Add the AC to the IMC Platform as an access device:

a.     Click the Service tab.

b.     From the navigation tree, select Access Service > Access Device.

c.     Click Add.

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

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

f.     Select Device Management Service as the service type.

g.     Select H3C as the access device type.

h.     Select the access device from the device list or manually add the device with the IP address 10.1.1.2.

The IP address of the access device must be the same as the source IP address that the AC uses for outgoing RADIUS packets. By default, the AC uses the IP address of the outbound interface as the source IP address for outgoing RADIUS packets.

i.     Click OK.

Figure 43 Adding an access device

 

2.     Add a user account for device management:

a.     Click the User tab.

b.     From the navigation tree, select Access User View > Device Mgmt User.

c.     Click Add.

d.     Enter hello@bbb as the username.

e.     Enter abc as the password, and confirm the password.

f.     Select Telnet as the service type.

g.     Enter 3 as the EXEC privilege level.

This value identifies the privilege level of the Telnet user after login, which is 0 by default.

h.     In the IP Address List of Managed Devices area, click Add to specify 10.1.1.0 to 10.1.1.255 as the range of host IP addresses to be managed. The address range must contain the IP address of the access device.

i.     Click OK.

Figure 44 Adding a user account for device management

 

Configuring the AC

1.     Configure RADIUS scheme system:

a.     From the navigation tree, select Authentication > RADIUS.

b.     Click Add.

c.     Enter the scheme name system, select the server type Extended, and select the username format With domain name.

d.     In the RADIUS Server Configuration area, click Add to enter the RADIUS server configuration page.

e.     Select the server type Primary Authentication, enter 10.1.1.1 as the IP address of the primary authentication server, 1812 as the port number, and expert as the key, and click Apply to add the primary authentication server to the scheme.

Figure 45 RADIUS authentication server configuration page

 

f.     In the RADIUS Server Configuration area, click Add to enter the RADIUS server configuration page again.

g.     Select Primary Accounting as the server type, enter 10.1.1.1 as the IP address of the primary accounting server, port number 1813, and the key expert, and click Apply.

Figure 46 RADIUS accounting server configuration page

 

The RADIUS scheme configuration page refreshes and the added servers appear in the server list, as shown in Figure 47.

h.     Click Apply.

Figure 47 RADIUS scheme configuration

 

2.     Create an ISP domain named bbb:

a.     From the navigation tree, select Authentication > AAA.

The domain setup page appears.

b.     Enter bbb in the Domain Name field.

c.     Click Apply.

Figure 48 Creating an ISP domain

 

3.     Configure an authentication method for the ISP domain:

a.     Click the Authentication tab.

b.     Select the domain name bbb.

c.     Select the Default AuthN option, and then select the authentication mode RADIUS.

d.     From the Name list, select the RADIUS scheme system to use it as the authentication scheme.

e.     Click Apply.

A configuration progress dialog box appears.

f.     After the configuration progress is complete, click Close.

Figure 49 Configuring an authentication method for the ISP domain

 

4.     Configure an authorization method for the ISP domain:

a.     Click the Authorization tab.

b.     Select the domain name bbb.

c.     Select the Default AuthZ option, and then select the authorization mode RADIUS.

d.     From the Name list, select the RADIUS scheme system to use it as the authorization scheme.

e.     Click Apply.

A configuration progress dialog box appears.

f.     After the configuration progress is complete, click Close.

Figure 50 Configuring an authorization method for the ISP domain

 

5.     Configure an accounting method for the ISP domain and enable accounting optional:

a.     Click the Accounting tab.

b.     Select the domain name bbb.

c.     Select the Accounting Optional option, and then select Enable from the list.

d.     Select the Default Accounting option, and then select accounting mode RADIUS.

e.     From the Name list, select the RADIUS scheme system to use it as the accounting scheme.

f.     Click Apply.

A configuration progress dialog box appears.

g.     After the configuration progress is complete, click Close.

Figure 51 Configuring an accounting method for the ISP domain

 

6.     Enable the Telnet service:

a.     From the navigation tree, select Network > Service.

b.     Select Enable Telnet service.

c.     Click Apply.

Figure 52 Enabling the Telnet service

 

7.     At the CLI, configure the VTY user interfaces to use AAA for user access control.

<AC> system-view

[AC] user-interface vty 0 4

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

[AC-ui-vty0-4] quit

Verifying the configuration

Telnet to the AC and enter the username hello@bbb and password abc. You can log in and access commands of level 0 through level 3.

Configuring the local EAP service

In some simple application environments, you may want to use a NAS to authenticate users locally, instead of deploying AAA servers for user authentication. When the Extensible Authentication Protocol (EAP) is used for user authentication, configure the local EAP authentication server to cooperate with local authentication method of AAA for local EAP authentication. For more information about AAA, see "Configuring AAA."

Configuration procedure

1.     From the navigation tree, select Authentication > Local EAP Server.

The local EAP service configuration page appears.

Figure 53 Local EAP service configuration page

 

2.     Configure the local EAP service as described in Table 19.

3.     Click Apply.

Table 19 Configuration items

Item	Description
Status	Enable or disable the EAP server. If the EAP server is enabled, the EAP authentication method and PKI domain configurations are required.
Method	Specify the EAP authentication methods: ·     MD5—Uses Message Digest 5 (MD5) for authentication. ·     TLS—Uses the Transport Layer Security (TLS) protocol for authentication. ·     PEAP-MSCHAPV2—Uses the Protected Extensible Authentication Protocol (PEAP) for authentication and uses the Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2) for authentication in the established TLS tunnel. ·     PEAP-GTC—Uses the Protected Extensible Authentication Protocol (PEAP) for authentication and uses the Microsoft Generic Token Card (GTC) for authentication in the established TLS tunnel. ·     TTLS—Uses the Tunneled Transport Layer Security (TTLS) protocol for authentication. When an EAP client and the local server communicate for EAP authentication, they first negotiate the EAP authentication method to be used. During negotiation, the local server prefers the authentication method with the highest priority from the EAP authentication method list. If the client supports the authentication method, the negotiation succeeds and they proceed with the authentication process. Otherwise, the local server tries the one with the next highest priority until a supported one is found, or if none of the authentication methods are found supported, the local server sends an EAP-Failure packet to the client for notification of the authentication failure.  IMPORTANT: ·     You can select more than one authentication method. An authentication method selected earlier has a higher priority. ·     PEAP-MSCHAPv2 and PEAP-GTC methods are mutually exclusive.
PKI domain	Specify the PKI domain for EAP authentication. The available PKI domains are those configured on the page you enter by selecting Authentication > Certificate Management. For more information, see "Managing certificates."  IMPORTANT: The service management, local portal authentication, and local EAP service modules always reference the same PKI domain. Changing the referenced PKI domain in any of the three modules will also change that referenced in the other two modules.

 

Local EAP service configuration example

Network requirements

As shown in Figure 54, configure the AC to perform local EAP authentication and authorization for 802.1X users by using the authentication method EAP-TLS.

Figure 54 Network diagram

 

Configuration guidelines

To implement local EAP authentication and authorization for 802.1X users, make sure port security is enabled and 802.1X authentication uses the EAP authentication mode.

To use the authentication method of EAP-TLS, configure the network properties of the connection and the client certificate correctly on the client.

For information about configuring PKI domain test, requesting a local certificate, and retrieving a CA certificate, see "Managing certificates."

Configuration procedure

1.     Configure local user usera:

a.     From the navigation tree, select Authentication > Users.

b.     Click Add.

c.     Enter the username usera and password 1234, and select the service type LAN-access.

d.     Click Apply.

Figure 55 Local user configuration page

 

2.     Configure the default ISP domain named system to use local authentication and local authorization.

The ISP domain system uses local authentication and local authorization by default. For the configuration procedure, see "Configuring AAA."

3.     Enable the EAP server, configure the authentication method as TLS, and the PKI domain as test:

a.     From the navigation tree, select Authentication > Local EAP Server.

b.     Select Enabled for Status.

c.     Select TLS from the Available methods list and click << to add TLS to the Selected methods list.

d.     Select test from the PKI domain list.

e.     Click Apply.

Figure 56 Configuring a local EAP server

 

4.     Configure the AP:

a.     From the navigation tree, select AP > AP Setup.

b.     Click Add.

c.     Enter the AP name ap1.

d.     Select the device model WA3628i-AGN.

e.     Select Manual and enter the serial number in the field below the list.

f.     Click Apply.

Figure 57 Configuring the AP

 

5.     Create the wireless service:

a.     From the navigation tree, select Wireless Service > Access Service.

b.     Click Add.

c.     Enter the wireless service name 802.1x-auth.

d.     Select the service type crypto.

e.     Click Apply.

The wireless service configuration page appears.

Figure 58 Creating a wireless service

 

6.     Configure the wireless service:

a.     Expand the Security Setup area.

b.     Select the authentication type Open-System.

c.     Select the Cipher Suite option, and then select a cipher suite from the list as needed. This example uses AES and TKIP.

d.     Select WPA and WPA2 as the security IE.

e.     Expand the Port Security area.

f.     Select the Port Set option, and then select the port mode userlogin-secure-ext.

g.     Select the Mandatory Domain option, and then select system from the list.

h.     Select the authentication method EAP.

i.     Disable the handshake, multicast trigger, and stateful failover functions.

j.     Click Apply.

A configuration progress dialog box appears.

k.     Click OK in the confirmation dialog box to enable the EAP service.

l.     After the configuration process is complete, click Close.

Figure 59 Wireless service configuration page

 

7.     Enable the wireless service:

a.     On the access service list page, select the wireless service named 802.1x-auth.

b.     Click Enable.

A progress dialog box appears.

c.     After the configuration process is complete, click Close.

Figure 60 Enabling the wireless service

 

8.     Bind the AP's radio mode with the wireless service:

a.     In the wireless service list, click the  icon for wireless service 802.1x-auth.

b.     Select the AP named ap1 with the radio mode 802.11n(2.4GHz).

c.     Click Bind.

A progress dialog box appears.

d.     After the configuration process is complete, click Close.

Figure 61 Binding the radio mode with the wireless service

 

9.     Enable 802.11n (2.4GHz):

a.     From the navigation tree, select Radio > Radio.

b.     Select the AP named ap1 with the radio mode 802.11n(2.4GHz).

c.     Click Enable.

Figure 62 Enabling 802.11n(2.4GHz)

 

Verifying the configuration

When a client passes EAP authentication to access the wireless network, you can successfully ping the client from the AC.

Configuring users

Overview

This module allows you to configure local users, user groups, guests, and user profiles.

Local user

A local user represents a set of user attributes configured on a device (such as the user password, user type, service type, and authorization attribute). It is uniquely identified by the username. For a user requesting a network service to pass local authentication, you must add an entry as required in the local user database of the device. For more information about local authentication, see "Configuring AAA."

User group

A user group consists of 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 management of user attributes for the local users in the group. All local users in a user group inherit the user attributes of the group, but if you configure user attributes for a local user, the settings of the local user take precedence over the settings for the user group.

By default, every newly added local user belongs to a user group named system, which is automatically created by the system.

Guest

A guest is a local user for specific applications. You can create a guest account for portal and LAN users to temporarily access the network.

User profile

A user profile is a configuration template for saving predefined configurations. You can configure different items such as Quality of Service (QoS) policy, rate limit, wireless service, and AP group for different user profiles to accommodate to different application scenarios.

During the authentication process for a user, the authentication server sends the user profile name to the device, which then enables the configurations in the user profile. After the user passes the authentication and accesses the device, the device restricts the user's access based on the configurations in the user profile. When the user logs out, the device automatically disables the configurations in the user profile, removing the restrictions on the user as a result. As the mechanism indicates, user profiles are for restricting online users' access. If no user is online (no user is accessing the network, no user has passed authentication, or all users have logged out), user profiles do not take effect.

With user profiles, you can:

·     Make use of system resources more granularly. For example, you can apply a QoS policy on a per-user basis.

·     Restrict users' access rate more flexibly. For example, you can deploy traffic policing on a per-user basis by defining a rate limit in user profiles.

·     Restrict users' access more specifically. For example, you can deploy user access control on a per-wireless service basis by defining an SSID in user profiles. Or you can deploy user access control on a per-AP basis by defining APs in the user profiles.

Configuring a local user

1.     From the navigation tree, select Authentication > Users.

The local user management page appears, displaying information about all local users including common users, guest administrator, and guests.

 

	NOTE: On the Local User tab, you can modify a guest user, but the user type changes to another one after your modification.

 

Figure 63 Local user list

 

2.     Click Add.

The local user configuration page appears. On this page, you can create a local user of any type except guest.

Figure 64 Local user configuration page

 

3.     Configure a local user as described in Table 20.

4.     Click Apply.

Table 20 Configuration items

Item	Description
User-name	Specify a name for the local user.
Password Confirm	Enter and confirm the password of the local user.  IMPORTANT: Make sure the password does not include leading spaces, because they will be ignored.
Password Encryption	Select a password encryption method: Reversible or Irreversible.
Group	Select a user group for the local user. For information about user group configuration, see "Configuring a user group."
User-type	Specify the user type for the local user: Common User or Guest Admin. A guest administrator manages guest accounts through the Authentication > User > Guest page.
Level	Select an authorization level for the local user: Visitor, Monitor, Configure, or Management, in ascending order of priority. A local user has the rights of the specified level and all levels lower than the specified level (if any). ·     Visitor—A user of this level can perform ping and trace route operations but cannot read any data from the device or configure the device. ·     Monitor—A user of this level can read data from the device but cannot configure the device. ·     Configure—A user of this level can read data from the device and configure the device, but it cannot upgrade the device software, configure users, or back up or restore configuration files. ·     Management—A user of this level can perform all operations.  IMPORTANT: This option is effective only for Web, FTP, Telnet, and SSH users of the Common User type.
Service-type	Select the service types for the local user to use: Web, FTP, Telnet, PPP, Portal, LAN-access (accessing through the Ethernet, such as 802.1X users), SSH, or Terminal.  IMPORTANT: ·     If you do not specify any service type for a local user who uses local authentication, the user cannot pass authentication and cannot log in. ·     Guest administrators can use the Web service. ·     Guests can use portal and LAN access services.
Expire-time	Specify an expiration time for the local user. When authenticating a local user with the expiration time configured, the access device checks whether the expiration time has elapsed. If not, the device permits the user to log in.
VLAN	Specify the VLAN to be authorized to the local user after the user passes authentication.  IMPORTANT: This option is effective only on portal and LAN users of the Common User type.
ACL	Specify the ACL to be used by the access device to restrict the access of the local user after the user passes authentication.  IMPORTANT: This option is effective only on PPP, portal, and LAN users of the Common User type.
User-profile	Specify the user profile for the local user.  IMPORTANT: This option is effective only on PPP, portal, and LAN users of the Common User type.

 

Configuring a user group

1.     From the navigation tree, select Authentication > Users.

2.     Click the User Group tab to display the existing user groups.

Figure 65 User group list

 

3.     Click Add to enter the user group configuration page.

Figure 66 User group configuration page

 

4.     Add a user group as described in Table 21.

5.     Click Apply.

Table 21 Configuration items

Item	Description
Group-name	Specify a name for the user group.
Level	Select an authorization level for the user group: Visitor, Monitor, Configure, or Management, in ascending order of priority.
VLAN	Specify the VLAN to be authorized to a user in the user group after the user passes authentication.
ACL	Specify the ACL to be used by the access device to restrict the access of a user in the user group after the user passes authentication.
User-profile	Specify the user profile for the user group.
Allow Guest Accounts	Specify whether to allow a guest to join the user group.  IMPORTANT: By default, the system provides a group named system for guest accounts. The group cannot be modified.

 

Configuring a guest

Two categories of administrators can configure guests: guest administrators and administrators of the management level. A guest administrator manages guests through the Web interface. For information about the user type and authorization level, see Table 20.

Configuring a guest by a management level administrator

1.     From the navigation tree, select Authentication > Users.

2.     Click the Guest tab to display the guest information.

Figure 67 Guest list

 

3.     Click Add to enter the guest configuration page.

Figure 68 Guest configuration page

 

4.     Configure a single guest or a batch of guests as described in Table 22.

5.     Click Apply.

Table 22 Configuration items

Item	Description
Create Users in a Batch	Specify whether to create guests in a batch.
Username	Specify a name for the guest when users are not created in a batch.
User-name(prefix)	Specify the username prefix and number for guests to be created in a batch. For example, if you specify the username prefix as abc and number as 50, 50 guests will be created, with the usernames abc0 through abc49.
Password Confirm	Enter and confirm the password of the guest.  IMPORTANT: Leading spaces in the password are ignored.
Same as the Username	Select this option if you want to set the password the same as the guest account name instead of configuring a password in the Password and Confirm fields.
Password Encryption	Select a password encryption method: Reversible or Irreversible.
Group	Select a user group for the guest. For information about user group configuration, see "Configuring a user group."
ValidTime	Specify a valid time range for the guest, including the start time and end time. When authenticating a local user with the valid time configured, the access device checks whether the valid time has elapsed. If it is not, the device permits the user to log in.

 

Configuring a guest by a guest administrator

1.     Log in to the AC as a guest administrator, and then select Authentication > User from the navigation tree.

The guest management page appears.

Figure 69 Guest management page

 

2.     Click Add to enter the guest configuration page.

Figure 70 Guest configuration page

 

3.     Configure the guest as described in Table 22.

4.     Click Apply.

 

	NOTE: The guest accounts are also displayed in the local user list. You can click the icon  of a guest in the list to edit the guest information and authorization attributes.

 

Configuring a user profile

Configuration guidelines

When you configure a user profile, use the following configuration guidelines:

·     By default, a newly added user profile is disabled.

·     A user profile takes effect and the authentication server notifies users of authentication results only after the user profile is enabled. Therefore, if you do not enable the user profile, users using the user profile will not be able to get online.

·     Only enabled user profiles can be referenced by users. Disabling a user profile logs out all users using the user profile.

·     Enabled user profiles cannot be modified or removed. To modify or remove an enabled user profile, you must disable it first.

Configuration procedure

1.     From the navigation tree, select Authentication > Users.

2.     Click the User Profile tab to display the existing user profiles

Figure 71 User profile list

 

3.     Click Add to enter the user profile name configuration page.

Figure 72 User profile name configuration item

 

4.     Enter a profile name profile.

5.     Click Apply.

The user profile configuration page appears.

Figure 73 User profile configuration page

 

6.     Configure the profile as described in Table 23.

7.     Click Apply.

8.     From the page displaying the existing user profiles, select the user profile to be enabled.

9.     Click Enable.

Table 23 Configuration items

Item	Description
Userprofile name	This field displays the user profile name.
Qos-out policy	Select a QoS policy in the outbound direction.
Qos-in policy	Select a QoS policy in the inbound direction.
limited-out rate	Specify the rate limit in the outbound direction.
limited-in rate	Specify the rate limit in the inbound direction.
Bonjour Policy	Specify the bonjour policy in the user profile.
Services permitted	Specify the wireless services permitted in the user profile: Select services in the Services list and click << to add them to the Selected services list. The available wireless services are those configured on the page you enter by selecting Wireless Service > Access Service. For more information, see "Configuring access services."
AP Group list permitted	Specify the AP group permitted in the user profile: Select the AP group in the AP group list and click << to add them to the Selected AP group list. The available APs are those you configured on the page you enter by selecting AP > AP Group. For more information, see "Configuring APs."