No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Fat AP and Cloud AP V200R008C00 CLI-based Configuration Guide

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Configuring NAC

Configuring NAC

Configuration Procedure for NAC

Configuration Procedure
Figure 25-82  NAC Configuration Procedure
NAC Configuration Tasks
Authentication Mode

Scenario

Task

802.1X authentication

Users are densely distributed and high information security is required.

MAC Address authentication

Dumb terminals such as printers and fax machines need to connect to the network.

Portal authentication

Users are sparsely distributed and move frequently.

Portal servers are classified into built-in and external Portal servers. A built-in Portal server is integrated in an access device, whereas an external Portal server has independent hardware. Compared with the external Portal server, the built-in Portal server supports more flexible deployment, but provides only basic functions of the external Portal server.

When using a built-in Portal server for authentication, perform the following configurations in sequence:
  1. Configuring a Portal Access Profile (for a Built-in Portal Server)
  2. Configuring an Authentication Profile
  3. Application

WeChat authentication (Central AP)

Users can connect to a Wi-Fi network using WeChat. After being authenticated, they can follow a WeChat public account to obtain access to the Internet.
When using an external Portal server for WeChat authentication, perform the following configurations in sequence:
  1. Configuring a Portal Access Profile (for an External Portal Server-Portal Protocol)
  2. Configuring an Authentication Profile
  3. Application
When using a built-in Portal server for WeChat authentication, perform the following configurations in sequence:
  1. Configuring a Portal Access Profile (for a Built-in Portal Server)
  2. Configuring an Authentication Profile
  3. Application

Combined authentication

The device allows multiple authentication modes to be deployed simultaneously to meet various authentication requirements on the network.

The device supports only one combined authentication mode: MAC address-prioritized Portal authentication.

To configure combined authentication of several authentication modes, you only need to bind corresponding access profiles to an authentication profile. For example, to configure MAC address-prioritized Portal authentication, you only need to bind the MAC access profile and Portal access profile to the authentication profile. By default, MAC address authentication takes precedence over Portal authentication.

Perform the following configurations in sequence:
  1. Configuring an Access Profile
  2. Configuring an Authentication Profile
  3. Application

Configuring an Access Profile

Configuring an 802.1X Access Profile
Creating an 802.1X Access Profile

Context

The device uses 802.1X access profiles to uniformly manage all 802.1X access configurations. Before configuring 802.1X authentication, you need to create an 802.1X access profile.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dot1x-access-profile name access-profile-name

    An 802.1X access profile is created and the 802.1X access profile view is displayed.

    By default, the device has a built-in 802.1X access profile named dot1x_access_profile.

    NOTE:
    • The maximum number of 802.1X access profiles supported by different device models is as follows:
      • FAT AD9430DN-24 and FAT AD9431DN-24X: 32
      • FAT AD9430DN-12: 16
      • Other models: 8

      The built-in 802.1X access profile dot1x_access_profile can be modified and applied, but cannot be deleted.

    • Before deleting an 802.1X access profile, ensure that this profile is not bound to any authentication profile.

(Optional) Configuring an Authentication Mode for 802.1X Users

Context

During 802.1X authentication, users exchange authentication information with the device using EAP packets. The device uses two modes to exchange authentication information with the RADIUS server.
  • EAP termination: The device directly parses EAP packets, encapsulates user authentication information into a RADIUS packet, and sends the packet to the RADIUS server for authentication. EAP termination is classified into PAP or CHAP authentication.

    • PAP is a two-way handshake authentication protocol. It transmits passwords in plain text format in RADIUS packets.
    • CHAP is a three-way handshake authentication protocol. It transmits only user names but not passwords in RADIUS packets. CHAP is more secure and reliable than PAP. If higher security is required, CHAP is recommended.
  • EAP relay (specified by eap): The device encapsulates EAP packets into RADIUS packets and sends the RADIUS packets to the RADIUS server. The device does not parse the received EAP packets but encapsulates them into RADIUS packets. This mechanism is called EAP over Radius (EAPoR).

The processing capability of the RADIUS server determines whether EAP termination or EAP relay is used. If the RADIUS server has a higher processing capability and can parse a large number of EAP packets before authentication, the EAP relay mode is recommended. If the RADIUS server has a processing capability not good enough to parse a large number of EAP packets and complete authentication, the EAP termination mode is recommended and the device parses EAP packets for the RADIUS server. When the authentication packet processing method is configured, ensure that the client and server both support this method; otherwise, the users cannot pass authentication.
NOTE:
  • The EAP relay can be configured for 802.1X users only when RADIUS authentication is used.

  • If AAA local authentication is used, the authentication mode for 802.1X users can only be set to EAP termination.

  • Because mobile phones do not support EAP termination mode (PAP and CHAP), the 802.1X authentication + local authentication mode cannot be configured for mobile phones. Terminals such as laptop computers support EAP termination mode only after having third-party clients installed.

  • If the 802.1X client uses the MD5 encryption mode, the user authentication mode on the device can be set to EAP or CHAP; if the 802.1X client uses the PEAP authentication mode, the authentication mode on the device can be set to EAP.

  • In a wireless access scenario, if WPA or WPA2 authentication mode is configured in the security policy profile, 802.1X authentication does not support pre-authentication domain-based authorization.
  • If 802.1X users on an interface have gone online, changing the user authentication mode in the 802.1X access profile bound to the interface will make the online 802.1X users go offline.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dot1x-access-profile name access-profile-name

    The 802.1X access profile view is displayed.

  3. Run dot1x authentication-method { chap | pap | eap }

    An authentication mode is configured for 802.1X users.

    The default 802.1X authentication mode is eap, which indicates Extensible Authentication Protocol (EAP) relay authentication.

(Optional) Configuring the Device to Send EAP Packets with a Code Number to 802.1X Users

Context

When a non-Huawei device used as the RADIUS server sends RADIUS packets with attribute 61, EAP packet code number 0xa (hexadecimal notation, 10 in decimal notation), and data type being 0x19 (hexadecimal notation, 25 in decimal notation) to the device, run the dot1x eap-notify-packet command on the device so that the device can send EAP packets with code number 0xa and data type 0x19 to users. If the dot1x eap-notify-packet command is not executed, the device does not process EAP packets of this type and users are disconnected.

Perform this configuration if the device connects to an H3C iMC RADIUS server.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dot1x-access-profile name access-profile-name

    The 802.1X access profile view is displayed.

  3. Run dot1x eap-notify-packet eap-code code-number data-type type-number

    The device is configured to send EAP packets with a code number to 802.1X users.

    By default, the device does not send EAP packets with a code number to 802.1X users.

    NOTE:

    If an H3C iMC functions as the RADIUS server, run the dot1x eap-notify-packet eap-code 10 data-type 25 command on the device.

(Optional) Configuring the Number of Times an Authentication Request Is Retransmitted to an 802.1X User

Context

If the device does not receive any response from a user within a specified time after sending an authentication request to the user, the device sends the authentication request again. If the authentication request has been sent for the maximum retransmission times and no response is received, the user authentication fails. In this process, the total number of authentication requests sent by the device is max-retry-value plus 1.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dot1x-access-profile name access-profile-name

    The 802.1X access profile view is displayed.

  3. Run dot1x retry max-retry-value

    The number of times an authentication request is retransmitted to an 802.1X client is configured.

    By default, the device can retransmit an authentication request to an 802.1X user twice.

(Optional) Configuring Re-authentication for Online 802.1X Authentication Users

Context

If the administrator modifies parameters such as access rights and authorization attributes of an online user on the authentication server, the user must be re-authenticated to ensure user validity.

If re-authentication is configured for online 802.1X authentication users, the device sends saved authentication parameters of an online user to the authentication server for re-authentication. The device saves user authentication information after users go online. If the user authentication information on the authentication server remains unchanged, the user keeps online. If the information has been modified, the user is disconnected and needs to be re-authenticated.

The device re-authenticates 802.1X authentication users in the following modes:
  • The device periodically re-authenticates users using a specified 802.1X access profile.
    NOTE:

    After this function is configured, many 802.1X authentication logs will be generated.

  • The device is manually configured to re-authenticate a user with a specified MAC address once.

If the device is connected to a server for re-authentication and the server replies with a re-authentication deny message that makes an online user go offline, it is recommended that you locate the cause of the re-authentication failure on the server or disable the re-authentication function on the device.

Procedure

  • Configuring periodical re-authentication
    1. Run system-view

      The system view is displayed.

    2. Run dot1x-access-profile name access-profile-name

      The 802.1X access profile view is displayed.

    3. Run dot1x reauthenticate

      Re-authentication is configured for online 802.1X authentication users.

      By default, re-authentication is not configured for online 802.1X authentication users.

    4. (Optional) Run dot1x timer reauthenticate-period reauthenticate-period-value

      The re-authentication interval is configured for online 802.1X authentication users.

      By default, the re-authentication interval is 3600 seconds for online 802.1X authentication users.

      NOTE:

      It is recommended that the re-authentication interval be set to the default value. If multiple ACLs need to be delivered during user authorization, you are advised to disable the re-authentication function or set a longer re-authentication interval to improve the device's processing performance.

      In remote authentication and authorization, if the re-authentication interval is set to a shorter time, the CPU usage may be higher.

      This handshake function takes effect only for the wired users.

      To reduce the impact on the device performance when many users exist, the user re-authentication interval may be longer than the configured re-authentication interval.

  • Configuring single-time re-authentication
    1. Run system-view

      The system view is displayed.

    2. Run dot1x reauthenticate mac-address mac-address

      The device is manually configured to re-authenticate a user with a specified MAC address once.

(Optional) Configuring the Authentication Timeout Timer for 802.1X Clients

Context

The device starts the authentication timeout timer for 802.1X clients after sending an EAP-Request/MD5-Challenge packet to a client. If the client does not respond within the period set by this timer, the device sends the packet again. If the packet has been sent for the maximum number of times (configured using the dot1x retry max-retry-value command) and no response is received, the device stops sending the packet. This prevents repeated retransmission of authentication requests, which occupies lots of resources.

Generally, if the client fails to be authenticated, the device starts a backup mechanism (MAC address authentication, Portal authentication, or granting specified access permission), so that the client can continue to access the network. The value of the timeout timer for EAP-Request/MD5 Challenge packets is calculated as follows:

Timer value = (max-retry-value + 1) x client-timeout-value

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dot1x-access-profile name access-profile-name

    The 802.1X access profile view is displayed.

  3. Run dot1x timer client-timeout client-timeout-value

    The authentication timeout timer for 802.1X clients is configured.

    By default, the authentication timeout timer for 802.1X clients is enabled and its value is 5 seconds.

  4. (Optional) Run dot1x retry max-retry-value

    The number of times an authentication request is retransmitted to an 802.1X client is configured.

    By default, the device can retransmit an authentication request to an 802.1X user twice.

(Optional) Configuring Network Access Rights for Users When the 802.1X Client Does Not Respond

Context

If the 802.1X client does not respond, users cannot pass authentication and thereby have no network access right. Before being successfully authenticated, some users may need certain basic network access rights to download client software and update the antivirus database. The network access rights can be configured for the users when the 802.1X client does not respond, so that the users can access specified network resources.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dot1x-access-profile name access-profile-name

    The 802.1X access profile view is displayed.

  3. Run authentication event client-no-response action authorize vlan vlan-id

    Network access rights are configured for users when the 802.1X client does not respond.

    By default, no network access right is configured for users when the 802.1X client does not respond.

Verifying the 802.1X Access Profile Configuration

Context

After configuring an 802.1X access profile, run the following command to check the configuration.

Procedure

  • Run the display dot1x-access-profile configuration [ name access-profile-name ] command to check the configuration of the 802.1X access profile.
Configuring a MAC Access Profile
Creating a MAC Access Profile

Context

The device uses MAC access profiles to uniformly manage all MAC users access configurations. Before configuring MAC address authentication, you need to create a MAC access profile.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mac-access-profile name access-profile-name

    A MAC access profile is created and the MAC access profile view is displayed.

    By default, the device has the built-in MAC access profile mac_access_profile.

    NOTE:
    • The maximum number of MAC access profiles supported by different device models is as follows:
      • FAT AD9430DN-24 and FAT AD9431DN-24X: 32
      • FAT AD9430DN-12: 16
      • Other models: 8

      The built-in MACx access profile mac_access_profile can be modified and applied, but cannot be deleted.

    • Before deleting a MAC access profile, ensure that this profile is not bound to any authentication profile.

Configuring the User Name Format for MAC Address Authentication

Context

The following user name formats are available for MAC address authentication:
  • MAC address: A user uses the MAC address as the user name for authentication, and uses the MAC address or a user-defined character string as the password.
  • Fixed user name: All users use a fixed name and password configured on the device for authentication, regardless of their MAC addresses. Only one user account needs to be configured on the authentication server. This method can be used on a network where access clients are reliable.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run mac-access-profile name access-profile-name

    The MAC access profile view is displayed.

  3. Run mac-authen username { fixed username [ password cipher password ] | macaddress [ format { with-hyphen [ normal ] | without-hyphen } [ uppercase ] [ password cipher password ] ] }

    The user name format is configured for MAC address authentication.

    By default, a MAC address without hyphens (-) is used as the user name and password for MAC address authentication.

    NOTE:
    • When configuring the user name format for MAC address authentication, ensure that the authentication server supports the user name format.

(Optional) Configuring Re-authentication for Online MAC Address Authentication Users

Context

If the administrator modifies parameters such as access rights and authorization attributes of an online user on the authentication server, the user must be re-authenticated to ensure user validity.

If re-authentication is configured for online MAC address authentication users, the device sends saved authentication parameters of an online user to the authentication server for re-authentication. The device saves user authentication information after users go online. If the user authentication information on the authentication server remains unchanged, the user keeps online. If the information has been modified, the user is disconnected and needs to be re-authenticated.

The device re-authenticates MAC address authentication users in the following modes:
  • The device periodically re-authenticates users using a specified MAC access profile.
    NOTE:
    After this function is configured, many MAC address authentication logs will be generated.
  • The device is manually configured to re-authenticate a user with a specified MAC address once.

Procedure

  • Configuring periodical re-authentication
    1. Run system-view

      The system view is displayed.

    2. Run mac-access-profile name access-profile-name

      The MAC access profile view is displayed.

    3. Run mac-authen reauthenticate

      Re-authentication is enabled for online MAC address authentication users.

      By default, re-authentication for online MAC address authentication users is disabled.

    4. (Optional) Run mac-authen timer reauthenticate-period reauthenticate-period-value

      The re-authentication interval is configured for online MAC address authentication users.

      By default, the re-authentication interval is 1800 seconds for online MAC address authentication users.

      NOTE:

      It is recommended that the re-authentication interval be set to the default value. If multiple ACLs need to be delivered during user authorization, you are advised to disable the re-authentication function or set a longer re-authentication interval to improve the device's processing performance.

      In remote authentication and authorization, if the re-authentication interval is set to a shorter time, the CPU usage may be higher.

      This handshake function takes effect only for the wired users.

      To reduce the impact on the device performance when many users exist, the user re-authentication interval may be longer than the configured re-authentication interval.

  • Configuring single-time re-authentication
    1. Run system-view

      The system view is displayed.

    2. Run mac-authen reauthenticate mac-address mac-address

      The device is manually configured to re-authenticate a user with a specified MAC address once.

Verifying the MAC Access Profile Configuration

Context

After configuring a MAC access profile, run the following command to check the configuration.

Procedure

  • Run the display mac-access-profile configuration [ name access-profile-name ] command to check the configuration of the MAC access profile.
Configuring a Portal Access Profile (for an External Portal Server-Portal Protocol)

The device supports external and built-in Portal servers. An external Portal server has independent hardware. A built-in Portal server is an embedded entity on an access device, that is, the access device functions as the Portal server.

After configuring the Portal server, you must bind the Portal server profile to a Portal access profile. When users who use the Portal access profile attempt to access charged network resources, they are forcibly redirected to the authentication page of the Portal server for Portal authentication.

This section describes how to configure the Portal server and Portal access profile when using an external Portal server.

Configuring an External Portal Server

Context

To ensure proper communication between the device and an External Portal server for authentication, configure the following information:
  • Portal server template: manages parameters of the Portal server, such as the IP address.
  • Parameters for information exchange with the Portal server: When the device connects to the Portal server, you need to configure information such as the Portal protocol version, to ensure proper communication and security.

Procedure

  • Configure a Portal server template.

    1. Run system-view

      The system view is displayed.

    2. Run web-auth-server server-name

      A Portal server template is created and the Portal server template view is displayed.

      By default, no Portal server template is created.

    3. Run server-ip server-ip-address &<1-10>

      An IP address is configured for the Portal server.

      By default, no IP address is configured for the Portal server.

    4. (Optional) Configure a source IP address for the device to communicate with the Portal server.

      • Run source-ip ip-address

        A source IP address is configured for the device to communicate with the Portal server.

        By default, no source IP address is configured for the device.

      • Run source-interface interface-type interface-number

        An IP address of the specified interface is configured for the device to communicate with the Portal server.

        By default, no source IP address is configured for the device.

    5. (Optional) Run port port-number [ all ]

      A destination port number is configured for the device to send packets to the Portal server.

      By default, the device uses the destination port number 50100 to send packets to the Portal server.

    6. Run shared-key cipher key-string

      A shared key is configured for the device to exchange information with the Portal server.

      By default, no shared key is configured.

    7. (Optional) Run web-redirection disable

      The Portal authentication redirection function is disabled.

      By default, the Portal authentication redirection function is enabled.

      The device redirects all unauthenticated users to the Portal authentication page when the users send access requests to external networks. For example, when the user needs to enter the URL of the authentication page manually, the web-redirection disable command can be executed so that unauthorized users are not forcibly redirected to the Portal authentication page.

    8. Configure the URL of the Portal server.

      You can bind a URL or a URL template to a Portal server template. Compared with URL binding, URL template binding allows you to configure the redirection URL of the Portal server and configure the URL to carry parameters related to users or the access device. The Portal server then can obtain user terminal information based on parameters carried in the URL and provide different Portal authentication pages for different users. You can choose URL binding mode or URL template binding mode based on actual requirements.

      • URL binding mode

        Run url url-string

        A URL is configured for the Portal server.

        By default, no URL is configured for the Portal server.

      • URL template binding mode

        1. Create and configure a URL template.

          1. Run quit

            Return to the system view.

          2. Run url-template name template-name

            A URL template is created and the URL template view is displayed.

            By default, no URL template is created on the device.

          3. Run url [ redirect-only ] url-string [ ssid ssid ]

            A redirection URL is configured for the Portal server.

            By default, no redirection URL is configured for the Portal server.

          4. Run url-parameter { ap-ip ap-ip-value | ap-mac ap-mac-value | redirect-url redirect-url-value | ssid ssid-value | sysname sysname-value | user-ipaddress user-ipaddress-value | user-mac user-mac-value } *

            Parameters carried in the URL are configured.

            By default, a URL does not carry parameters.

          5. Run url-parameter mac-address format delimiter delimiter { normal | compact }

            The MAC address format in the URL is configured.

            By default, the MAC address format in a URL is XXXXXXXXXXXX.

          6. Run parameter { start-mark parameter-value | assignment-mark parameter-value | isolate-mark parameter-value } *

            Characters in the URL are configured.

            By default, the start character in a URL is a question mark (?), the assignment character is an equal sign (=), and the delimiter between parameters is an ampersand (&).

          7. Run quit

            Return to the system view.

        2. Run web-auth-server server-name

          The Portal server template view is displayed.

        3. Run url-template url-template [ ciphered-parameter-name ciphered-parameter-name iv-parameter-name iv-parameter-name key cipher key-string ]

          The URL template is bound to the Portal server template.

          By default, no URL template is bound to a Portal server template.

          NOTE:

          The device support encryption of parameter information in the URL template only when it connects to the Huawei Agile Controller-Campus.

  • Configure parameters for information exchange with the Portal server.

    • Run system-view

      The system view is displayed.

    • Run web-auth-server version v2 [ v1 ]

      Portal protocol versions supported by the device are configured.

      By default, the device supports Portal protocol v1 and v2.

      NOTE:

      The default setting is recommended to ensure proper communication, that is, the device supports both versions.

    • Run web-auth-server source-ip ip-address

      The source IP address is configured for the device to communicate with the Portal server in the system view.

      By default, no source IP address is configured for the device to communicate with the Portal server in the system view.

    • Run web-auth-server listening-port port-number

      The number of the port through which the device listens to Portal packets is configured.

      By default, the device listens to Portal packets through port 2000.

    • Run web-auth-server reply-message

      The device is enabled to transparently transmit user authentication information received from the authentication server to the Portal server.

      By default, the device transparently transmits users' authentication responses sent by the authentication server to the Portal server.

    • Run portal redirect-http-port port-number

      A user-defined destination port number of HTTP packets that trigger Portal redirection is configured.

      By default, the device redirects users to the Portal authentication page only when their browsers send HTTP packets with the destination port number 80.

    • Run portal logout resend times timeout period

      The number of times that the device retransmits offline packets of Portal authentication users and the retransmission interval are configured.

      By default, the device retransmits offline packets of Portal authentication users for three times at an interval of five seconds.

    • Run portal logout different-server enable

      The device is enabled to process user logout requests sent by a Portal server other than the one from which users log in.

      By default, a device does not process user logout requests sent by Portal servers other than the one from which users log in.

    • Run portal user-roam-out reply enable

      A device is enabled to send the Portal server the IP address of the central AP to which a user roams.

      By default, when a user roams, the device sends the Portal server the IP address of the central AP to which the user roams.

(Optional) Configuring the Portal Server Detection Function

Context

In Portal authentication application, if communication between the device and Portal server is interrupted due to a network failure or Portal server failure, new Portal authentication users cannot go online, and online Portal users cannot go offline normally.

The Portal server detection function enables the device to generate logs and alarms for network faults and Portal server faults.

When two Portal servers work in active/standby mode or the Portal escape function is configured, enable the Portal server detection function on the device.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run web-auth-server server-name

    The Portal server profile view is displayed.

  3. Run server-detect [ interval interval-period | max-times times | critical-num critical-num | action { log | trap } * ] *

    The Portal server detection function is enabled.

    By default, the Portal server detection function is disabled.

(Optional) Configuring Synchronization of Portal Authentication User Information

Context

In Portal authentication application, if communication between the device and Portal server is interrupted due to a network failure or Portal server failure, online Portal users cannot go offline normally. As a result, user information on the device may be different from that on the Portal server, causing inaccurate accounting.

The user information synchronization mechanism ensures user information consistency between the Portal server and the device, so that accounting can be performed accurately.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run web-auth-server server-name

    The Portal server profile view is displayed.

  3. Run user-sync [ interval interval-period | max-times times ] *

    User information synchronization is enabled.

    By default, user information synchronization is disabled.

Creating a Portal Access Profile

Context

The device uses Portal access profiles to uniformly manage all Portal users access configurations. Before configuring Portal authentication, you need to create a Portal access profile.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal-access-profile name access-profile-name

    A Portal access profile is created and the Portal access profile view is displayed.

    By default, the device has the built-in Portal access profile portal_access_profile.

    NOTE:
    • The maximum number of portal access profiles supported by different device models is as follows:
      • FAT AD9430DN-24 and FAT AD9431DN-24X: 32
      • FAT AD9430DN-12: 16
      • Other models: 8

      The built-in portal access profile portal_access_profile can be modified and applied, but cannot be deleted.

    • Before deleting a portal access profile, ensure that this profile is not bound to any authentication profile.

Configuring an External Portal Server for a Portal Access Profile

Context

To use Portal authentication, you must configure Portal server parameters on the device. The device supports external and built-in Portal servers. To use an external Portal server for authentication, you need to configure an external Portal server, and configure a Portal access profile to use the external Portal server. When users who use the Portal access profile attempt to access charged network resources, they are forcibly redirected to the authentication page of the Portal server for Portal authentication.

A Portal server profile defines parameters of the Portal server. You need to configure an external Portal server for the Portal access profile, that is, bind a Portal server profile to the Portal access profile.

To improve Portal authentication reliability, the backup Portal server profile can also be bound to the Portal access profile. When the primary Portal server is disconnected, the users are redirected to the backup Portal server for authentication. This function can take effect only when the Portal server detection function is enabled using the server-detect command and heartbeat detection is enabled on the Portal server.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal-access-profile name access-profile-name

    A Portal access profile is created and the Portal access profile view is displayed.

  3. Run web-auth-server server-name [ bak-server-name ] layer3

    A Portal server profile is bound to the Portal access profile.

    By default, no Portal server profile is bound to a Portal access profile.

    Wireless users are authenticated using Layer 2 Portal authentication. The layer3 parameter is set for upgrade compatibility of the portal auth-network command that configures a source subnet for Portal authentication.

  4. (Optional) Run portal http-proxy-redirect enable [ port port-number ]

    The HTTP proxy function is enabled.

    By default, the HTTP proxy function is disabled.

    Only an external Portal server that uses the Portal protocol supports the HTTP proxy function. An external Portal server that uses the HTTP or HTTPS protocol does not support the HTTP proxy function.

(Optional) Configuring the Portal Escape Function

Context

If the Portal server is Down, users cannot pass the authentication and thereby have no network access right. The Portal escape function allows the access device to grant specified network access rights to users when it detects that the Portal server is Down, meeting basic network access requirements.

NOTE:

Only HTTP messages-triggered Portal authentication users support this function.

If a terminal uses Portal authentication or combined authentication (including Portal authentication), the device cannot authorize a VLAN to the terminal.

Pre-configuration Tasks
Before configuring the Portal escape function, complete the following tasks:
  1. Enable the heartbeat detection function on the Portal server.
  2. Enable the Portal server detection function on the access device. For details about the configuration, see (Optional) Configuring the Portal Server Detection Function.
  3. Create a user group and configure network resources for the user group. For details about the configuration, see Configuring Authorization Parameters.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal-access-profile name access-profile-name

    The Portal access profile view is displayed.

  3. Run authentication event portal-server-down action authorize user-group user-group-name

    Network access rights are configured for users to use when the Portal server is Down.

    By default, no network access right is configured for users to use when the Portal server is Down.

  4. (Optional) Run authentication event portal-server-up action re-authen

    The device is enabled to re-authenticate users when the Portal server changes from Down to Up.

    By default, the device does not re-authenticate users when the Portal server changes from Down to Up.

    If you perform this step, the access device re-authenticates users when it detects that the Portal server changes from Down to Up. The access device sets the status of users who display web-server-down to pre-connection. The re-authentication process starts when the users visit any web page. If the authentication is successful, the access device grants normal network access rights to the users.

Verifying the Configuration
  • Run the display portal-access-profile configuration [ name access-profile-name ] command to check authorization information configured for the Portal escape function.
(Optional) Configuring CNA Bypass for iOS Terminals

Context

The iOS operating system provides the Captive Network Assistant (CNA) function. With the CNA function, the iOS terminals (including iPhone, iPad, and iMAC) automatically detects wireless network connectivity after associating with a wireless network. If the network connection cannot be set up, the iOS terminals ask users to enter user names and passwords. If users do not enter the user names and passwords, the iOS terminals automatically disconnect from the wireless network.

However, Portal authentication allows users to access certain resources before authentication is successful. If the iOS terminals are disconnected, users cannot access the specified resources. The CNA bypass function addresses this problem. If the users do not enter user names and passwords immediately, the CNA bypass function keeps the iOS terminals online before the Portal authentication is successful. Therefore, the iOS users are allowed to access authentication-free resources.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal captive-bypass enable

    The CNA bypass function is enabled for iOS terminals.

    By default, the CNA bypass function is disabled for iOS terminals.

(Optional) Configuring the Maximum Number of Portal Authentication Users Allowed on the Device

Context

You can perform the following configurations to restrict the maximum number of Portal authentication users allowed on the device.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal max-user user-number

    The maximum number of Portal authentication users allowed on the device is configured.

    By default, the maximum number of Portal authentication users allowed on the device is not restricted within the device's capacity.

  3. (Optional) Run portal user-alarm percentage percent-lower-value percent-upper-value

    The alarm thresholds for the Portal authentication user count percentage are configured.

    By default, the lower alarm threshold for the Portal authentication user count percentage is 50, and the upper alarm threshold for the Portal authentication user count percentage is 100.

    When the percentage of online Portal authentication users against the maximum number of users allowed on the device exceeds the upper alarm threshold, the device generates an alarm. When the percentage reaches or falls below the lower alarm threshold, the device clears the alarm.

(Optional) Enabling URL Encoding and Decoding

Context

To improve web application security, data from untrustworthy sources must be encoded before being sent to clients. URL encoding is most commonly used in web applications. After URL encoding and decoding are enabled, some special characters in redirected URLs are converted to secure formats, preventing clients from mistaking them for syntax signs or instructions and unexpectedly modifying the original syntax. In this way, cross-site scripting attacks and injection attacks are prevented.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal url-encode enable

    URL encoding and decoding are enabled.

    By default, URL encoding and decoding are enabled.

Check the Configuration

Run the display portal url-encode configuration command to check the configuration of URL encoding and decoding.

Verifying the Portal Server Profile and Portal Access Profile Configuration

Context

After configuring a Portal server profile and a Portal access profile, run the following commands to check the configuration.

Procedure

  • Run the display portal-access-profile configuration [ name access-profile-name ] command to check the configuration of the Portal access profile.
  • Run the display portal [ interface interface-type interface-number ] command to view information about Portal authentication.
  • Run the display portal user-logout [ ip-address ip-address ] command to check the temporary logout entries of Portal authentication users.
  • Run the display web-auth-server configuration command to check the configuration of the Portal server profile.
  • Run the display url-template { all | name template-name } command to check the configuration of the URL profile.
  • Run the display server-detect state [ web-auth-server server-name ] command to view the status of a Portal server.
Configuring a Portal Access Profile (for an External Portal Server-HTTP/HTTPS Protocol)

After configuring the Portal server, you must bind the Portal server profile to a Portal access profile. When users who use the Portal access profile attempt to access charged network resources, they are forcibly redirected to the authentication page of the Portal server for Portal authentication.

This section describes how to configure the Portal server and Portal access profile.

Configuring Portal Server

Context

If Portal server is used for authentication, you need to configure related parameters in the Portal server template, for example, the authentication protocol, to ensure that the device and Portal server can communicate.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal web-authen-server { http | https ssl-policy policy-name } [ port port-number ]

    The Portal interconnection function of the HTTP or HTTPS protocol is enabled.

    By default, the Portal interconnection function of the HTTP or HTTPS protocol is disabled.

  3. Run web-auth-server server-name

    A Portal server template is created and the Portal server template view is displayed.

    By default, no Portal server template is created.

  4. Run protocol http [ password-encrypt { none | uam } ]

    The protocol used in Portal authentication is set to HTTP or HTTPS.

    By default, the Portal protocol is used in Portal authentication.

  5. (Optional) Run http get-method enable

    The device is configured to allow users to submit user name and password information to the device in GET mode during Portal authentication.

    By default, the device does not allow users to submit user name and password information to the device in GET mode during Portal authentication.

  6. Run http-method post { cmd-key cmd-key [ login login-key | logout logout-key ] * | init-url-key init-url-key | login-fail response { err-msg { authenserve-reply-message | msg msg } | redirect-login-url | redirect-url redirect-url [ append-reply-message msgkey ] } | login-success response { msg msg | redirect-init-url | redirect-url redirect-url } | logout-fail response { msg msg | redirect-url redirect-url } | logout-success response { msg msg | redirect-url redirect-url } | password-key password-key | user-mac-key user-mac-key | userip-key userip-key | username-key username-key } *

    Parameters for parsing and replying to POST or GET request packets of the HTTP or HTTPS protocol are configured.

    By default, the system has configured parameters for parsing and replying to POST or GET request packets of the HTTP or HTTPS protocol. For details, see the "Parameters" table in the http-method post command.

  7. Configure a URL for the Portal server.

    You can bind a URL or a URL template to a Portal server template. Compared with URL binding, URL template binding allows you to configure the redirection URL of the Portal server and configure the URL to carry parameters related to users or the access device. The Portal server then can obtain user terminal information based on parameters carried in the URL and provide different Portal authentication pages for different users. You can choose URL binding mode or URL template binding mode based on actual requirements.

    • URL binding mode

      Run url url-string

      A URL is configured for the Portal server.

      By default, no URL is configured for the Portal server.

    • URL template binding mode

      1. Create and configure a URL template.

        1. Run quit

          Return to the system view.

        2. Run url-template name template-name

          A URL template is created and the URL template view is displayed.

          By default, no URL template is created on the device.

        3. Run url [ redirect-only ] url-string [ ssid ssid ]

          A redirection URL is configured for the Portal server.

          By default, no redirection URL is configured for the Portal server.

        4. Run url-parameter { | login-url url-key url | redirect-url redirect-url-value | sysname sysname-value | user-ipaddress user-ipaddress-value | user-mac user-mac-value } *

          Parameters carried in the URL are configured.

          By default, a URL does not carry parameters.

        5. Run url-parameter mac-address format delimiter delimiter { normal | compact }

          The MAC address format in the URL is configured.

          By default, the MAC address format in a URL is XXXXXXXXXXXX.

        6. Run parameter { start-mark parameter-value | assignment-mark parameter-value | isolate-mark parameter-value } *

          Characters in the URL are configured.

          By default, the start character in a URL is a question mark (?), the assignment character is an equal sign (=), and the delimiter between parameters is an ampersand (&).

        7. Run quit

          Return to the system view.

      2. Run web-auth-server server-name

        The Portal server template view is displayed.

      3. Run url-template url-template

        The URL template is bound to the Portal server template.

        By default, no URL template is bound to a Portal server template.

      4. Run quit

        Return to the system view.

Creating a Portal Access Profile

Context

The device uses Portal access profiles to uniformly manage all Portal users access configurations. Before configuring Portal authentication, you need to create a Portal access profile.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal-access-profile name access-profile-name

    A Portal access profile is created and the Portal access profile view is displayed.

    By default, the device has the built-in Portal access profile portal_access_profile.

    NOTE:
    • The maximum number of portal access profiles supported by different device models is as follows:
      • FAT AD9430DN-24 and FAT AD9431DN-24X: 32
      • FAT AD9430DN-12: 16
      • Other models: 8

      The built-in portal access profile portal_access_profile can be modified and applied, but cannot be deleted.

    • Before deleting a portal access profile, ensure that this profile is not bound to any authentication profile.

Configuring an External Portal Server for a Portal Access Profile

Context

To use Portal authentication, you must configure Portal server parameters on the device. The device supports external and built-in Portal servers. To use an external Portal server for authentication, you need to configure an external Portal server, and configure a Portal access profile to use the external Portal server. When users who use the Portal access profile attempt to access charged network resources, they are forcibly redirected to the authentication page of the Portal server for Portal authentication.

A Portal server profile defines parameters of the Portal server. You need to configure an external Portal server for the Portal access profile, that is, bind a Portal server profile to the Portal access profile.

To improve Portal authentication reliability, the backup Portal server profile can also be bound to the Portal access profile. When the primary Portal server is disconnected, the users are redirected to the backup Portal server for authentication. This function can take effect only when the Portal server detection function is enabled using the server-detect command and heartbeat detection is enabled on the Portal server.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal-access-profile name access-profile-name

    A Portal access profile is created and the Portal access profile view is displayed.

  3. Run web-auth-server server-name [ bak-server-name ] layer3

    A Portal server profile is bound to the Portal access profile.

    By default, no Portal server profile is bound to a Portal access profile.

    Wireless users are authenticated using Layer 2 Portal authentication. The layer3 parameter is set for upgrade compatibility of the portal auth-network command that configures a source subnet for Portal authentication.

  4. (Optional) Run portal http-proxy-redirect enable [ port port-number ]

    The HTTP proxy function is enabled.

    By default, the HTTP proxy function is disabled.

    Only an external Portal server that uses the Portal protocol supports the HTTP proxy function. An external Portal server that uses the HTTP or HTTPS protocol does not support the HTTP proxy function.

Verifying the Portal Server Profile and Portal Access Profile Configuration

Context

After configuring a Portal server profile and a Portal access profile, run the following commands to check the configuration.

Procedure

  • Run the display portal-access-profile configuration [ name access-profile-name ] command to check the configuration of the Portal access profile.
  • Run the display portal [ interface interface-type interface-number ] command to view information about Portal authentication.
  • Run the display portal user-logout [ ip-address ip-address ] command to check the temporary logout entries of Portal authentication users.
  • Run the display web-auth-server configuration command to check the configuration of the Portal server profile.
  • Run the display url-template { all | name template-name } command to check the configuration of the URL profile.
  • Run the display server-detect state [ web-auth-server server-name ] command to view the status of a Portal server.
Configuring a Portal Access Profile (for a Built-in Portal Server)

The device supports external and built-in Portal servers. An external Portal server has independent hardware. A built-in Portal server is an embedded entity on an access device, that is, the access device functions as the Portal server.

After configuring the Portal server, you must bind the Portal server profile to a Portal access profile. When users who use the Portal access profile attempt to access charged network resources, they are forcibly redirected to the authentication page of the Portal server for Portal authentication.

This section describes how to configure the Portal server and Portal access profile when using a built-in Portal server.

Configuring a Built-in Portal Server

Context

Compared with an external Portal server, a built-in Portal server is easy to use, cost-effective, and easy to maintain. When configuring the built-in Portal server function, you need to specify the IP address of the built-in Portal server and enable the built-in Portal server function globally.

NOTE:

If the time on a client differs from that on the built-in Portal server, the client cannot pass authentication or cannot go offline after passing authentication. Therefore, ensure that the time zone and time on the device are correct when configuring the built-in Portal server function.

VPN users do not support the built-in Portal server function.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal local-server ip ip-address

    An IP address is configured for the built-in Portal server.

    By default, no IP address is configured for the built-in Portal server.

    NOTE:

    The IP address of the built-in Portal server is the IP address of a Layer 3 interface that has a reachable route to the user.

  3. (Optional) Run portal local-server url url-string

    A URL is configured for the built-in Portal server.

    By default, no URL is configured for the built-in Portal server.

    To facilitate memorization, you can run this command to configure a URL for the built-in Portal server. The URL identifies the built-in Portal server's website that can be visited by Portal authentication users.

  4. Run portal local-server { https ssl-policy policy-name | http } [ port port-num ]

    The built-in Portal server function is enabled globally.

    By default, the built-in Portal server function is disabled globally.

    NOTE:

    Ensure that an SSL policy exists and the digital certificate has been successfully loaded.

    In the WeChat authentication scenario, the https parameter cannot be configured.

  5. (Optional) Run portal local-server authentication-method { chap | pap }

    The authentication mode of the built-in Portal server is configured.

    By default, the CHAP authentication mode is used.

  6. (Optional) Run portal local-server redirect-url enable

    The device is configured to display the requested web page after users are successfully authenticated by the built-in Portal server.

    By default, the device does not display the requested web page after users are successfully authenticated by the built-in Portal server.

    If the URL entered by the user contains more than 200 characters, clicking Redirect to the old page can only redirect the user to the webpage corresponding to the server address in the URL. For example, if the URL entered by the user is http://career.huawei.com/campus/pages/job/job.aspx?recruittype=School=%E8%... which contains more than 200 characters, the user will be directed to career.huawei.com.

(Optional) Customizing the Page of the Built-in Portal Server

Context

When a built-in Portal server is used for authentication, the device as the built-in Portal server forcibly pushes authentication pages to users. Authentication pages include the login page, authentication success page, online page, and logout success page. Users can customize authentication pages.

The device supports login page customization to meet various user requirements. For example, you can load a logo on the login page, change the background image or color of the login page, and push an advertisement page.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal local-server load string

    A page file package to the built-in Portal server is loaded.

    By default, the built-in Portal server loads the default page file package portalpage.zip.

    Users need to customize HTML files in the page file package according to certain specifications. Otherwise, the built-in Portal server cannot work properly. For details about the specifications, see Built-in Portal Server Page Customization Specifications.

  3. Customize the login page of the built-in Portal server.

    • Run portal local-server [ terminal-type { pc | phone } ] logo load logo-file or portal local-server page-name wechat-authen terminal-type phone logo load logo-file

      A logo is loaded on the login page of the built-in Portal server.

      By default, no logo is loaded on the login page of the built-in Portal server.

    • Run portal local-server [ terminal-type { pc | phone } ] ad-image load ad-image-file or portal local-server page-name wechat-authen terminal-type phone ad-image load ad-image-file

      An advertisement page file is loaded on the login page of the built-in Portal server.

      By default, no advertisement page file is loaded on the login page of the built-in Portal server.

    • Run portal local-server [ terminal-type { pc | phone } ] page-text load string or portal local-server page-name wechat-authen terminal-type phone page-text load string

      The use instruction page file of the built-in Portal server is loaded.

      By default, no use instruction page file of the built-in Portal server is loaded.

    • Run portal local-server [ terminal-type { pc | phone } ] policy-text load string or portal local-server page-name wechat-authen terminal-type phone policy-text load string

      A disclaimer page file is loaded on the login page of the built-in Portal server.

      By default, no disclaimer page file is loaded on the login page of the built-in Portal server.

    • Run portal local-server [ terminal-type { pc | phone } ] background-image load { background-image-file | default-image1 } or portal local-server page-name wechat-authen terminal-type phone background-image load { background-image-file | default-image1 }

      A background image is loaded on the login page of the built-in Portal server.

      By default, two background images default-image0 and default-image1 exist on the device, and the built-in Portal server uses the background image default-image0.

    • Run portal local-server background-color background-color-value

      The background color is configured for the login page of the built-in Portal server.

      By default, no background color is configured for the login page of the built-in Portal server.

    • Run portal local-server default-language { chinese | english }

      The default language on the login page of the built-in Portal server is set.

      By default, the default language on the login page of the built-in Portal server is English.

Built-in Portal Server Page Customization Specifications

File-Naming Specifications

The file names of primary index pages cannot be customized and must be the file name listed in Table 25-52. Users can customize other file names and ensure that the file name length does not exceed 127 characters.

Table 25-52  Primary index page file name

Primary Index Page

File Name

Description

Login page

index.html

login.html

Before being authenticated, a user can access device to connect to the network. The device redirects the user to the index.html page, and the login page is displayed.

The user needs to request the login.html page on the index.html page. login.html is a Post request used to submit a user's user name and password.

Authentication success page

auth_success.html

If the submitted user name and password pass server authentication, the device displays the authentication success page. To help the user know the online duration, the authentication success page displays time.

Authentication failure page

auth_failure.html

If the submitted user name and password fail server authentication, the device displays the authentication failure page. To help the user log in again, the authentication failure page must provide the Login button.

Online page

hasonline.html

If the user has passed authentication and goes online again for authentication, the device displays the online page. To help the user log out easily, the online page must provide the Logout button.

Connection page

hasconnect.html

If the user initiates an online request again while waiting to be authenticated, the device displays a connection page, indicating that the system is processing an authentication request.

Logout success page

logout_success.html

When the user logs out successfully, the device displays the logout success page. To help the user log in again, the logout success page must provide the Login button.

Logout failure page

logout_failure.html

When the user fails to log out, the device displays the logout failure page. To help the user log out again, the logout failure page must provide the Logout button.

Secondary address allocation wait page

pnprealloc.html

If secondary address allocation is not complete for a Plug and Play (PNP) user during authentication, the device displays the PNP wait page, indicating that the user needs to wait for secondary address allocation.

Page Request Specifications

  • The built-in Portal server accepts only Get and Post requests.

    • Get requests are used to obtain static files in authentication pages, including .png and .css files.

    • Post requests are used to submit user names and passwords and to log in and log out.

  • A PC's background image, advertisement image, and logo image must be named background-1.jpg, ad.png, and logo.png respectively. A phone's background image, advertisement image, and logo image must be named bg_phone.jpg, ad_phone.png, and logo_phone.png respectively. A WeChat's background image, advertisement image, and logo image must be named bg_wechat.jpg, ad_wechat.png, and logo_wechat.png respectively. Additionally, these images must be stored in the /custom directory. Otherwise, the device does not support customization of these images.

Attribute Specifications in Post Requests

  • Forms in authentication pages must be edited according to the following rules:

    • The path address must contain the protocol type, gateway address, and port number, such as "<%=HuaWei_GetProtocol()%>://<%=HuaWei_GetUserGateWayIP()%>:<%=HuaWei_GetPort()%>/login". Otherwise, user information cannot be sent to the Portal server.

    • The user name attribute is fixed as username, and the password attribute is fixed as password.

    • There must be an attribute that indicates the user login or logout: type = submit. The value Login indicates a login, and the value Logout indicates a logout.

    • A login Post request must contain three attributes username, password, and Login.

    • A logout Post request must contain the Logout attribute.

  • The page that must contain a login Post request is login.html.

    The following example lists some scripts of the login.html page.

    <form id="LoginForm" name="LoginForm" method="post" action="<%=HuaWei_GetProtocol()%>://<%=HuaWei_GetUserGateWayIP()%>:<%=HuaWei_GetPort()%>/login" onSubmit ='return CheckSubmit()' style="height:310px; margin-left:0px; margin-top:0px;" target="_top">
    <INPUT type="submit" id="sub1" name="Login" style="height:100px; margin-top:3px; margin-bottom:3px;" />
    
    <div id="lab_Username" style="display:none">Username:</div>
    <input type="text" name="username" maxlength="66" class="loginTxt" autocomplete="off" disableautocomplete placeholder="Username"  style="background-image:url(./image/user.jpg);background-repeat:no-repeat;padding-left:30px;height:45px;width:300px;background-position:left center;background-color:white;border:1px solid gray;display:inline" />
    
    <div id="lab_PassWord" style="display:none">Password:</div>
    <input name="password" type="password" id="password" maxlength="128" class="loginTxt" autocomplete="off" disableautocomplete placeholder="Password" style="background-image:url(./image/passcode.jpg);background-repeat:no-repeat;padding-left:30px;height:45px;width:300px;background-position:left center;background-color:white;border:1px solid gray;" /> 
    <INPUT type="hidden" name="RedirectUrl" value="">
    <INPUT type="hidden" name="anonymous" value="<%=HuaWei_GetAnonymous()%>">
    <INPUT type="hidden" name="anonymousurl" value="<%=HuaWei_GetAnonymousUrl()%>">
    </form>
  • The pages that must contain a logout Post request are hasonline.html, auth_success.html, and logout_failure.html.

    The following example lists some scripts of the hasonline.html page.

    <form name=LogoutForm method=post action="<%=HuaWei_GetProtocol()%>://<%=HuaWei_GetUserGateWayIP()%>:<%=HuaWei_GetPort()%>/logout">
    <input onClick="logout()" name="submit" type=submit value="Logout" class="none">
    </form>

Page Content Modification Specifications

Currently, the default page file package (portalpage.zip) only provides HTML files in Chinese and English. If a user needs to change the language, the user can only modify the descriptive content displayed on the page.

  1. Visit Huawei enterprise technical support website, download the product software package, and decompress the product software package to obtain the portalpage.zip file.

  2. Decompress the portalpage.zip file. You can modify the descriptive content displayed on the page in the HTML file, but cannot modify names and directory structure of the primary index pages in the folder. For example, you can modify the Login Time displayed on the auth_success.html page.

    <tr bgcolor="#B0DFFF"><td width="35%" align="center">Login Time:</td>
     <td >
     <INPUT type="hidden"  name="HiddenLoginTime" size=25 value="<%=HuaWei_GetLoginTime()%>">
     <INPUT name="LoginTime" size=20 maxlength="80" style="HEIGHT: 20Px; BACKGROUND-COLOR: #B0DFFF; BORDER-BOTTOM: #B0DFFF 1px double; BORDER-LEFT: #B0DFFF 1px double; BORDER-RIGHT: #B0DFFF 1px double; BORDER-TOP: #B0DFFF 1px double; COLOR: #000000" readonly >
     </td>
    </tr>
    
  3. After modifying the content, perform operations based on the page file compression and storage specifications.

Page File Compression and Storage Specifications

  • After all authentication pages have been edited, these pages must be compressed into a ZIP file. The ZIP file name cannot contain spaces.

  • The ZIP file can be uploaded to the device using FTP and stored in the root directory of the device.

The following example shows the storage directory of a ZIP file.

<Huawei> dir *.zip
Directory of sdcard:/
  Idx  Attr     Size(Byte)  Date        Time(LMT)  FileName
    0  -rw-        146,825  Aug 30 2016 04:19:19   portalpage-normal.zip
    1  -rw-        251,704  Aug 25 2016 18:07:28   portalpage.zip
    2  -rw-        251,711  Aug 25 2016 19:01:37   portalpage1.zip
    3  -rw-        251,709  Aug 25 2016 19:07:44   portalpage2.zip
1,969,388 KB total (1,681,124 KB free)

Script Functions in Pages

Table 25-53 lists script functions in pages. Select these script functions according to requirements.

Table 25-53  Script functions in pages

Script Function

Description

HuaWei_GetUserGateWayIP

Obtains a user gateway address to construct a URL so as to request pages from the built-in Portal server.

HuaWei_GetUserOnlineTime

Obtains the user online duration. This function is not used in authentication pages.

HuaWei_GetUserIp

Obtains a user IP address, which is displayed on the authentication success page and online page to notify the user of the obtained IP address.

HuaWei_GetUserName

Obtains user name information, which is displayed on the authentication success page and online page to notify the user of the login user name.

HuaWei_GetChallenge

Obtains challenge and converts challenge into displayable characters. This function is not used in authentication pages.

HuaWei_GetLoginTime

Obtains the user login time. The time is the device time and displayed on the authentication success page and online page to notify the user of the login time.

HuaWei_GetAuthMode

Obtains the user authentication mode, PAP or CHAP, which is used for exchange with the built-in Portal server. This function is not used in authentication pages.

HuaWei_GetAccessPageName

Obtains the requested page name. This function is not used in authentication pages.

HuaWei_GetUserMAC

Obtains the user MAC address, which carries user's MAC information in the secondary address allocation page address bar.

HuaWei_GetHeartBeatInterval

Obtains the client's packet detection time, which is set to one third of the heartbeat packet interval. This function is not used in authentication pages.

HuaWei_GetProtocol

Obtains the protocol type to construct a URL so as to request pages from the built-in Portal server.

HuaWei_GetPort

Obtains the port number of HTTP packets that trigger Portal redirection to construct a URL so as to request pages from the built-in Portal server.

HuaWei_GetAnonymous

Obtains information about whether the anonymous login function is enabled on the device. It is carried in a request initiated on the authentication page for exchange with the built-in Portal server.

When the anonymous login function is enabled, the value of this function is set to ENABLE.

HuaWei_GetAnonymousUrl

Obtains the configured anonymous pushed URL. A URL is pushed to users to enable them to access the specified web page only when the anonymous login function is enabled

(Optional) Configuring the Heartbeat Detection Function for the Built-in Portal Server

Context

When a user closes the browser or an exception occurs, the device can detect the user's online state to determine whether to make the user go offline. The administrator can configure the heartbeat detection function of the built-in Portal server. If the device does not receive a heartbeat packet from the client within a specified period, the user is specified to go offline. The heartbeat detection mode of the built-in Portal server can be either of the following modes:
  • Forcible detection mode: This mode is valid for all users. If the device does not receive a heartbeat packet from a user within a specified period, the device specifies the user to go offline.
  • Automatic detection mode: The device checks whether the client browser supports the heartbeat program. If yes, the forcible detection mode is used for the user; if no, the device does not detect the user. You are advised to configure this mode to prevent users from going offline because the browser does not support the heartbeat program.
    NOTE:

    Currently, the heartbeat program is supported by Internet Explorer 8, FireFox 3.5.2, Chrome 28.0.1500.72, and Opera 12.00 on Windows 7. A Java program must be installed and configured on the operating system.

    Browsers using Java1.7 and later versions do not support the heartbeat program.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal local-server keep-alive interval interval-value [ auto ]

    The heartbeat detection function is enabled for the built-in Portal server.

    By default, the heartbeat detection function is disabled for the built-in Portal server.

(Optional) Configuring the Session Timeout Interval for Users Authenticated Through the Built-in Portal Server

Context

When built-in Portal authentication is used for users and the device functions as a built-in Portal server, you can configure the session timeout interval for the users. The users are disconnected after the specified session timeout interval. To connect to the network again, the users need to be re-authenticated.

The session timeout interval for built-in Portal authentication users is calculated based on the device time. For example, if the session timeout interval is 6 hours and the device time is 2014-09-01 02:00:00 when a user was connected, the user should be disconnected at 2014-09-01 08:00:00. Therefore, ensure that the device time and time zone are correct after the session timeout interval is configured for users. If the device time is incorrect, users may fail to be connected or disconnected properly. You can run the display clock command to check the device time and the time zone.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal local-server timer session-timeout interval

    The session timeout interval is configured for users authenticated through the built-in Portal server.

    By default, the session timeout interval is 8 hours for users authenticated through the built-in Portal server.

(Optional) Configuring the Log Suppression Function for Users Authenticated Through the Built-in Portal Server

Context

The device generates logs when users authenticated through the built-in Portal server fail to go online or offline. If a user fails to go online or offline, the user attempts to go online or offline repeatedly, and the device generates a large number of logs within a short time. This results in a high failure rate in the statistics and degrades the system performance. You can enable the log suppression function for users authenticated through the built-in Portal server. The device then only generates one log if a user fails to go online or offline within a suppression period.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal local-server syslog-limit enable

    The log suppression function is enabled for users authenticated through the built-in Portal server.

    By default, the log suppression function is enabled for users authenticated through the built-in Portal server.

  3. (Optional) Run portal local-server syslog-limit period value

    The log suppression period is configured for users authenticated through the built-in Portal server.

    By default, the log suppression period is 300 seconds for users authenticated through the built-in Portal server.

Creating a Portal Access Profile

Context

The device uses Portal access profiles to uniformly manage all Portal users access configurations. Before configuring Portal authentication, you need to create a Portal access profile.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal-access-profile name access-profile-name

    A Portal access profile is created and the Portal access profile view is displayed.

    By default, the device has the built-in Portal access profile portal_access_profile.

    NOTE:
    • The maximum number of portal access profiles supported by different device models is as follows:
      • FAT AD9430DN-24 and FAT AD9431DN-24X: 32
      • FAT AD9430DN-12: 16
      • Other models: 8

      The built-in portal access profile portal_access_profile can be modified and applied, but cannot be deleted.

    • Before deleting a portal access profile, ensure that this profile is not bound to any authentication profile.

Configuring a Built-in Portal Server for a Portal Access Profile

Context

To use Portal authentication, you must configure Portal server parameters on the device. The device supports external and built-in Portal servers. To use a built-in Portal server for authentication, you need to enable the built-in Portal server function globally, and then enable the built-in Portal server function in a Portal access profile. When users who use the Portal access profile attempt to access charged network resources, they are forcibly redirected to the authentication page of the Portal server for Portal authentication.

NOTE:

If WeChat authentication and anonymous login functions are both configured on the device, the function that configured earlier takes effect.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal-access-profile name access-profile-name

    The Portal access profile view is displayed.

  3. Run portal local-server enable

    The built-in Portal server function is enabled in the Portal access profile.

    By default, the built-in Portal server function is disabled in a Portal access profile.

  4. (Optional) Run portal local-server anonymous [ redirect-url url ]

    The anonymous login function is enabled for users authenticated through the built-in Portal server.

    By default, the anonymous login function is disabled for users authenticated through the built-in Portal server.

    In places such as airports, hotels, cafes, and public recreation places, the anonymous login function allows users to access the network without entering the user name and password, facilitating network service provisioning.

    If the redirect-url url parameter is specified, the web page corresponding to the specified URL will be automatically displayed when anonymous login users access web pages for the first time. This function can be used for advertisement push and users are unaware of the anonymous login process, improving user experience.

    When anonymous login is configured, it is recommended that you set AAA authentication mode to none authentication.

  5. (Optional) Run portal local-server wechat

    WeChat authentication is enabled on the built-in Portal server.

    By default, WeChat authentication is disabled on the built-in Portal server.

(Optional) Configuring WeChat Authentication (Central AP)

Context

To enable users to be authenticated using WeChat, you need to configure related parameters, such as the WeChat public account and shop information, on the device.

NOTE:

For WeChat users, set the authentication mode to non-authentication. Otherwise, WeChat users cannot go online.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal local-server wechat-authen

    A built-in Portal server WeChat authentication profile is created and the profile view is displayed.

    By default, no built-in Portal server WeChat authentication profile is configured in the system.

  3. Run public-account appid appid appsecret appsecret

    A WeChat public account ID and its key are configured.

    By default, no WeChat public account ID or key is configured.

  4. Manually configure shop information or configure the device to automatically obtain shop information. When WeChat authentication is required in a large number of shops, the automatic mode is recommended for convenient management and maintenance.

    • Manually configure shop information.

      Run shop-id shop-id secretkey secretkey ssid ssid

      Shop information is configured.

      By default, no shop information is configured in the system.

    • Configure the device to obtain shop information automatically.

      1. Run wechat-server-ip [ url url-string ] ssl-policy policy-name [ port port-number ]

        The domain name, SSL policy, and port number of the WeChat server are specified.

        By default:
        • The domain name of the WeChat server is api.weixin.qq.com.
        • No SSL policy is configured in the system.
        • The port number of the WeChat server is 443.

        After you configure the WeChat server information, the device will automatically obtain shop information from the WeChat server.

      2. Run polling-time time

        The interval for obtaining shop information from the WeChat server is set.

        By default, the interval for obtaining shop information from the WeChat server is 3600 seconds.

    If both two commands are configured, the configuration of the shop-id command does not take effect.

  5. Run quit

    Return to the system view.

  6. Run portal local-server timer pre-auth time time-out

    The pre-authentication period of users on the built-in Portal server is set.

    By default, the pre-authentication period of users on the built-in Portal server is 120 seconds.

  7. Run portal local-server pre-auth-suppression { quiet-times quiet-times | quiet-period quiet-period } *

    The maximum number of network accesses and quiet period are set for WeChat users in pre-authentication state.

    By default, the maximum number of network accesses for WeChat users in pre-authentication state is 3, and the quiet period is 10 minutes.

(Optional) Configuring CNA Bypass for iOS Terminals

Context

The iOS operating system provides the Captive Network Assistant (CNA) function. With the CNA function, the iOS terminals (including iPhone, iPad, and iMAC) automatically detects wireless network connectivity after associating with a wireless network. If the network connection cannot be set up, the iOS terminals ask users to enter user names and passwords. If users do not enter the user names and passwords, the iOS terminals automatically disconnect from the wireless network.

However, Portal authentication allows users to access certain resources before authentication is successful. If the iOS terminals are disconnected, users cannot access the specified resources. The CNA bypass function addresses this problem. If the users do not enter user names and passwords immediately, the CNA bypass function keeps the iOS terminals online before the Portal authentication is successful. Therefore, the iOS users are allowed to access authentication-free resources.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal captive-bypass enable

    The CNA bypass function is enabled for iOS terminals.

    By default, the CNA bypass function is disabled for iOS terminals.

(Optional) Configuring the Maximum Number of Portal Authentication Users Allowed on the Device

Context

You can perform the following configurations to restrict the maximum number of Portal authentication users allowed on the device.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run portal max-user user-number

    The maximum number of Portal authentication users allowed on the device is configured.

    By default, the maximum number of Portal authentication users allowed on the device is not restricted within the device's capacity.

  3. (Optional) Run portal user-alarm percentage percent-lower-value percent-upper-value

    The alarm thresholds for the Portal authentication user count percentage are configured.

    By default, the lower alarm threshold for the Portal authentication user count percentage is 50, and the upper alarm threshold for the Portal authentication user count percentage is 100.

    When the percentage of online Portal authentication users against the maximum number of users allowed on the device exceeds the upper alarm threshold, the device generates an alarm. When the percentage reaches or falls below the lower alarm threshold, the device clears the alarm.

Verifying the Built-in Portal Server and Portal Access Profile Configuration

Context

After configuring a built-in Portal server and a Portal access profile, run the following commands to check the configuration.

Procedure

  • Run the display portal-access-profile configuration [ name access-profile-name ] command to check the configuration of the Portal access profile.
  • Run the display portal local-server command to check the configuration of the built-in Portal server.
  • Run the display portal local-server page-information command to check the page files loaded to the memory of a built-in Portal server.

Configuring an Authentication Profile

Creating an Authentication Profile

Context

NAC implements access control on users. To facilitate NAC function configuration, the device uses authentication profiles to uniformly manage NAC configuration. You can configure parameters in an authentication profile to provide different access control modes for users. For example, you can configure the access profile bound to the authentication profile to determine the authentication mode for the authentication profile. The device then uses the authentication mode to authenticate users on the VAP profile to which the authentication profile is applied.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run authentication-profile name authentication-profile-name

    An authentication profile is created and the authentication profile view is displayed.

    By default, the device has five built-in authentication profiles: default_authen_profile, dot1x_authen_profile, mac_authen_profile, portal_authen_profile, and macportal_authen_profile.

    NOTE:
    • The maximum number of authentication profiles is as follows:
      • FAT AD9430DN-24 and FAT AD9431DN-24X: 32
      • FAT AD9430DN-12: 16
      • Other models: 8

      The five built-in authentication profiles (default_authen_profile, dot1x_authen_profile, mac_authen_profile, portal_authen_profile, and macportal_authen_profile) can be modified and applied, but cannot be deleted. The built-in authentication profile default_authen_profile is not counted in the configuration specification.

    • Before deleting an authentication profile, ensure that this profile is not bound to any VAP profile. You can run the display authentication-profile configuration command to check whether the authentication profile is bound to VAP profile

Configuring a User Authentication Mode

Context

The device supports 802.1X, MAC address, and Portal authentication modes in NAC deployment. The access profile bound to the authentication profile determines the user authentication mode in a VAP profile. For example, if you want to use MAC address authentication to control and manage users who go online using a VAP profile, bind a MAC access profile to the authentication profile applied to the VAP profile.

The device allows multiple authentication modes (combined authentication) to be deployed simultaneously in a VAP profile to meet various authentication requirements on the network. In this case, you need to bind multiple access profiles to an authentication profile.

Prerequisites
Access profiles have been configured.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run authentication-profile name authentication-profile-name

    The authentication profile view is displayed.

  3. Configure the user authentication mode.

    • 802.1X authentication

      Run dot1x-access-profile access-profile-name

      An 802.1X access profile is bound to the authentication profile.

      By default, no 802.1X access profile is bound to an authentication profile.

    • MAC address authentication

      Run mac-access-profile access-profile-name

      A MAC access profile is bound to the authentication profile.

      By default, no MAC access profile is bound to an authentication profile.

    • Portal authentication

      Run portal-access-profile access-profile-name

      A Portal access profile is bound to the authentication profile.

      By default, no Portal access profile is bound to an authentication profile.

    • Combined authentication

      The device supports one combined authentication mode: MAC address-prioritized Portal authentication. If a MAC access profile and a Portal access profile are bound to an authentication profile, MAC address authentication takes precedence over Portal authentication by default.

      The procedure of configuring MAC address-prioritized Portal authentication is as follows:
      • Run mac-access-profile access-profile-name

        A MAC access profile is bound to the authentication profile.

        By default, no MAC access profile is bound to an authentication profile.

      • Run portal-access-profile access-profile-name

        A Portal access profile is bound to the authentication profile.

        By default, no Portal access profile is bound to an authentication profile.

    NOTE:

    When configuring combined authentication, pay attention to the following points:

    • If a MAC access profile and a Portal access profile are bound to an authentication profile, MAC address authentication takes precedence over Portal authentication by default.
    • An authentication profile can be bounded to a MAC access profile and a Portal access profile at most.

    • After combined authentication is configured, the device by default allows users to use multiple authentication modes. For example, if a user passes MAC address authentication, the user will not be redirected to the Portal authentication page when accessing a web page. However, if the user directly enters the Portal authentication website in the browser, Portal authentication can be performed. After the authentication succeeds, the users can obtain network access rights for Portal authentication users. To authenticate users using only one authentication mode, run the authentication single-access command to configure the device to allow users to pass only one access authentication.

  4. (Optional) Run authentication ip-address in-accounting-start [ arp-delay ]

    The function of carrying users' IP addresses in Accounting-Start packets is enabled.

    By default, the function of carrying users' IP addresses in Accounting-Start packets is disabled.

    This command takes effect only for 802.1X authentication and MAC address authentication users. By default, Accounting-Start packets for Portal authentication carry users' IP addresses.

    The arp-delay parameter is supported only in wireless scenarios. By default, ARP packets are permitted after authentication succeeds. After this parameter is configured, the device permits ARP packets after receiving Accounting-Start Response packets.

    In the wireless scenario where MAC-preferred Portal authentication is enabled, after users pass authentication, you can configure the arp-delay parameter to enable the device to deny ARP packets before it receives Accounting-Start Response packets.

  5. (Optional) Run authentication portal-ip-trigger

    The fast Portal authentication function is enabled.

    By default, the fast Portal authentication function is disabled.

    Only external Portal servers supporting fast authentication support this function.

Configuring an AAA Scheme

Context

To use NAC to control user access, you need to configure an Authentication, Authorization, and Accounting (AAA) scheme.

The device manages users in domains. For details about how to configure a user authentication domain, see (Optional) Configuring a User Authentication Domain. You can use an AAA scheme applied to a user authentication domain. For details about the configuration, see AAA Configuration.

The device uses authentication profiles to uniformly manage NAC configuration. However, users using the same authentication profile may be in different authentication domains, and AAA schemes applied to the domains are difficult to manage and maintain. To solve this problem, you can configure an AAA scheme in the authentication profile.

NOTE:

If AAA schemes are configured in both the authentication domain and authentication profile, the AAA scheme in the authentication profile takes effect.

Prerequisites
The device supports local, RADIUS, and HWTACACS authentication modes. Before binding an AAA scheme to an authentication profile, complete the following tasks based on the authentication mode:

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run authentication-profile name authentication-profile-name

    The authentication profile view is displayed.

  3. Configure an AAA scheme.

    • local authentication
      1. Run authentication-scheme authentication-scheme-name

        An authentication scheme is bound to the authentication profile.

      2. Run authorization-scheme authorization-scheme-name

        An authorization scheme is bound to the authentication profile.

    • RADIUS authentication
      1. Run authentication-scheme authentication-scheme-name

        An authentication scheme is bound to the authentication profile.

      2. Run accounting-scheme accounting-scheme-name

        An accounting scheme is bound to the authentication profile.

      3. Run radius-server template-name

        A RADIUS server template is bound to the authentication profile.

    • HWTACACS authentication
      1. Run authentication-scheme authentication-scheme-name

        An authentication scheme is bound to the authentication profile.

      2. Run authorization-scheme authorization-scheme-name

        An authorization scheme is bound to the authentication profile.

      3. Run accounting-scheme accounting-scheme-name

        An accounting scheme is bound to the authentication profile.

      4. Run hwtacacs-server template-name

        An HWTACACS server template is bound to the authentication profile.

Follow-up Procedure

After binding an AAA scheme to the authentication profile, complete the following tasks based on the authentication mode:

  • If local authentication is used, configure the user name and password on the device.
  • If RADIUS authentication is used, configure the user name and password on the RADIUS server.
  • If HWTACACS authentication is used, configure the user name and password on the HWTACACS server.
Configuring Authorization Information
Configuring Authorization Parameters

Context

In user authorization, the device controls network access rights based on the user role during each phase of user authentication. Two authorization modes are available:
  • Local authorization: The device authorizes users based on attributes configured for users.
  • Remote authorization: The device authorizes users based on information delivered by the server (for example, a RADIUS server or an HWTACACS server).

As described in Table 25-54, local authorization and remote authorization support flexible deployment of multiple authorization parameters.

Table 25-54  Authorization parameters

Authorization Parameter

Supported Authorization Mode

Application Scenario

VLAN

Local authorization and remote authorization

VLAN-based authorization is easy to deploy and maintenance costs are low. It applies to scenarios where employees in an office or a department have the same access rights.

ACL number

Remote authorization

ACL number-based authorization can better control user rights. It allows employees within the same department to have different access rights, for example, the department manager has more rights than common employees.

Service scheme

Local authorization

You need to configure a service scheme and corresponding network resources on the device.

User group

Local authorization and remote authorization

A user group consists of users (terminals) with the same attributes such as the role and rights. For example, you can divide users on a campus network into the R&D group, finance group, marketing group, and guest group based on the enterprise department structure, and grant different security policies to different departments.

NOTE:

Only authenticated users support remote authorization. If both local authorization and remote authorization are configured, remote authorization takes effect.

If a user uses Portal authentication or combined authentication (including Portal authentication), the device cannot authorize a VLAN to the user. After the user is authorized with a VLAN, DHCP needs to be manually triggered to apply for an IP address.

Procedure

  • VLAN

    In remote authorization, the server delivers VLAN IDs and VLAN descriptions to the device. You need to configure VLANs and network resources in the VLANs on the device.

    In local authorization, you only need to configure VLANs and corresponding network resources on the device.

    NOTE:

    You are not advised to set the VLAN description to a string of only digits when configuring an authorization VLAN.

    If the VLAN description of an authorization VLAN is set to an integer that ranges from 1 to 4094, the device will consider the VLAN description as the ID of the authorization VLAN to be delivered by the RADIUS server.

    If the VLAN description of an authorization VLAN contains invalid characters but is not an integer that ranges from 1 to 4094, the device will search for the corresponding VLAN based on the VLAN description and uses the VLAN as the authorization VLAN to be delivered by the RADIUS server. If the device has multiple VLANs with the same VLAN description, it selects the VLAN with the smallest ID as the authorization VLAN.

  • ACL number

    The server delivers ACL numbers to the device. You need to configure ACLs and corresponding network resources on the device.

    If a user has obtained the access rights defined by the ACL, the ACL cannot be deleted from the device.

    Configure an ACL for authorization. If the ACL is modified after a user obtains the access rights defined by the ACL, the modification does not take effect immediately, and access rights of the user change after the user is re-authenticated.

  • Service scheme

    You need to configure a service scheme and corresponding network resources on the device.

    For details about the configuration, see (Optional) Configuring a Service Scheme in AAA Configuration.

  • User group

    In remote authorization, the server delivers user group names to the device. You need to configure user groups and corresponding network resources on the device.

    In local authorization, you only need to configure user groups and corresponding network resources on the device.

    The procedure for configuring a user group is as follows:

    1. Run system-view

      The system view is displayed.

    2. Configure a QoS profile.

      1. Run qos-profile name profile-name

        A QoS profile is created and the QoS profile view is displayed.

      2. Run remark { inbound | outbound } 8021p 8021p-value

        The action of re-marking 802.1p priorities of VLAN-tagged packets is configured in the QoS profile.

        By default, the action of re-marking 802.1p priorities of VLAN-tagged packets is not configured in a QoS profile.

      3. Run remark { inbound | outbound } dscp 8021p-value

        The action of re-marking DSCP priorities of IP packets is configured in the QoS profile.

        By default, the action of re-marking DSCP priorities of IP packets is not configured in a QoS profile.

      4. Run remark local-precedence { local-precedence-name | local-precedence-value }

        The action of re-marking internal priorities of packets is configured in the QoS profile.

        By default, the action of re-marking internal priorities of packets is not configured in a QoS profile.

      5. Run car { inbound | outbound } cir cir-value [ pir pir-value [ cbs cbs-value pbs pbs-value ] ]

        Traffic policing parameters are configured in the QoS profile.

        By default, no traffic policing parameter is configured in a QoS profile.

      6. Run quit

        Return to the system view.

    3. Run user-group group-name [ group-index group-index ]

      A user group is created and the user group view is displayed.

    4. Run qos-profile name

      The QoS profile is bound to the user group.

      By default, no QoS profile is bound to a user group.

    5. Run acl-id acl-number

      An ACL is bound to the user group.

      By default, no ACL is bound to a user group.

      NOTE:
      • The ACL to be bound to a user group must have been created using the acl (system view) command.

      • The bound ACL applies only to packets sent from an AP to an upstream device, but not to packets sent from the AP to downstream STAs.

    6. Run user-vlan vlan-id

      A VLAN is bound to the user group.

      By default, no VLAN is bound to a user group.

      NOTE:

      The VLAN to be bound to a user group has been created using the vlan command.

    7. Run user-isolated { inter-group | inner-group } *

      Intra-group isolation and inter-group isolation are configured in the user group.

      By default, intra-group or inter-group isolation is not configured in a user group.

Configuring Authorization Information for Authenticated Users

Context

An authenticated user is in the post-authentication domain and can obtain network access rights through local or remote authorization. Remote authorization parameters supported by the device include the VLAN, ACL number, and user group. Local authorization parameters supported by the device include the service scheme and user group.

In remote authorization, the authorization server delivers authorization parameters to the device. For example, if the authorization server uses a user group for remote authorization, you need to specify the user group to which users are added on the authorization server, and configure the user group and network resources for the user group on the device. An authenticated user can obtain network access rights in the user group.

In local authorization, you need to bind authorization parameters to the user authentication domain or authentication profile on the device. For details about how to configure authorization information in an authentication domain, see AAA Configuration. This section describes how to configure authorization information in an authentication profile. The device uses authentication profiles to uniformly manage NAC configuration. Therefore, the administrator manages authorization information in an authentication profile more easily than authorization information in an authentication domain.

NOTE:
  • If both local authorization and remote authorization are configured, remote authorization takes effect.

  • If authorization information is configured both in the authentication domain and authentication profile, the authorization information in the authentication profile takes effect.

Prerequisites

A service scheme and a user group have been configured. For details about the configuration, see Configuring Authorization Parameters.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run authentication-profile name authentication-profile-name

    The authentication profile view is displayed.

  3. Run authorize { service-scheme service-scheme-name | user-group group-name }

    A service scheme or a user group is bound to the authentication profile.

    By default, no service scheme or user group is bound to an authentication profile.

Configuring Authentication Event Authorization Information

Context

To meet these users' basic network access requirements such as updating the antivirus database and downloading the client, configure authentication event authorization information. The device will assign network access rights to these users based on the authentication phase.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run authentication-profile name authentication-profile-name

    The authentication profile view is displayed.

  3. Configure authorization information.

    • Run authentication event authen-server-down action authorize user-group user-group-name

      Network access rights are configured for users when the authentication server is Down.

    By default, no authentication event authorization information is configured.

    NOTE:

    If authorization upon an authentication server Down event is configured and the device detects that the authentication server is Down, the device grants corresponding network access rights to users who fail to be authenticated, and add the users to entries of users who fail to be authenticated upon an authentication server Down event. If authorization upon an authentication server Down event is not configured and the device detects that the authentication server is Down, the device grants corresponding network access rights to users who fail to be authenticated, and add the users to entries of users who fail to be authenticated.

    The device assigns network access rights based on the priorities of the configured rights in a network status as follows:

    • If the authentication server is Down: network access right upon an authentication server Down event > network access right for users who fail authentication > network access right for users in the pre-connection state > user authorization based on whether the function of keeping users who fail to be authenticated and do not have any network access rights in the pre-connection state is enabled
    • If users fail authentication: network access right for users who fail authentication > network access right for users in the pre-connection state > user authorization based on whether the function of keeping users who fail to be authenticated and do not have any network access rights in the pre-connection state is enabled
    • If users are in the pre-connection state: network access right for users in the pre-connection state > user authorization based on whether the function of keeping users who fail to be authenticated and do not have any network access rights in the pre-connection state is enabled
    • If an 802.1X client does not respond: network access right if an 802.1X client does not respond > network access right for users in the pre-connection state > user authorization based on whether the function of keeping users who fail to be authenticated and do not have any network access rights in the pre-connection state is enabled

Configuring Authorization Information for Authentication-free Users

Context

Before being authenticated, users need to obtain some network access rights to meet basic network access requirements such as downloading the 802.1X client and updating antivirus database. The device uses an authentication-free rule profile to uniformly manage authorization information for authentication-free users. You can define some network access rules in the profile to determine network access rights that can be obtained by authentication-free users. You need to bind a configured authentication-free rule profile to an authentication profile. Users using the authentication profile then can obtain authentication-free authorization information.

NOTE:

Pay attention to the following when you use a common authentication-free rule:

  • Authentication-free authorization information takes effect only for Portal authentication users.
  • When multiple rules are configured at the same time, the system matches the rules one by one.
Pay attention to the following when you define the authentication-free rule by ACL:
  • Authentication-free authorization information takes effect only for Portal authentication users.
  • When multiple authentication-free rules are configured at the same time, only the last one takes effect.
  • The device does not support ACL rules that contain the deny action.
  • If multiple domain names correspond to the same IP address and one matches the authentication-free rule, other domain names also match the authentication-free rule.

During Portal authentication configuration, you need to configure the device to allow packets to the DNS server to pass through before Portal authentication succeeds. Assume that the IP address of the DNS server is 10.1.1.1. Configure the free-rule 1 destination ip 10.1.1.1 mask 32 command in the authentication-free rule profile.

Procedure

  1. Configure an authentication-free rule profile.

    1. Run system-view

      The system view is displayed.

    2. Run free-rule-template name free-rule-template-name

      An authentication-free rule profile is created and the authentication-free rule profile view is displayed.

      By default, the device has a built-in authentication-free rule profile named default_free_rule.

      NOTE:

      Currently, the device supports only one authentication-free rule profile, that is, the built-in profile default_free_rule.

    3. Configure an authentication-free rule.

      • Run free-rule rule-id { destination { any | ip { ip-address mask { mask-length | ip-mask } [ tcp destination-port port | udp destination-port port ] | any } } | source { any | ip { ip-address mask { mask-length | ip-mask } | any } } } *

        An authentication-free rule is configured.

      • Run free-rule acl acl-id

        An authentication-free rule defined by ACL is configured.

      An authentication-free rule defined by ACL is configured.

    4. Run quit

      Return to the system view.

  2. Bind the authentication-free rule profile to the authentication profile.

    1. Run authentication-profile name authentication-profile-name

      The authentication profile view is displayed.

    2. Run free-rule-template free-rule-template-name

      Bind the authentication-free rule profile to the authentication profile.

      By default, no authentication-free rule profile is bound to an authentication profile.

(Optional) Configuring Re-authentication for Users

Context

The device records entries for pre-connection users and users who fail to be authenticated, and grants corresponding network access rights to the users. For details, see Configuring Authentication Event Authorization Information. To ensure that users are successfully authenticated in a timely manner and obtain normal network access rights, you can configure the device to re-authenticate users who fail to be authenticated based on user entries.

If a user fails to be re-authenticated before the aging time expires, the device deletes the corresponding user entry and reclaims the granted network access rights. If a user is successfully re-authenticated, the device adds the user to entries of authenticated users and grants corresponding network access rights to the user.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run authentication-profile name authentication-profile-name

    The authentication profile view is displayed.

  3. Run authentication event authen-server-up action re-authen

    The device is enabled to re-authenticate users in the survival state when the authentication server changes from Down to Up.

    By default, the device does not re-authenticate users in the survival state when the authentication server changes from Down to UP.

    NOTE:
    • The radius-server testuser command has been configured in the RADIUS server template so that the device can detect that the authentication server changes from Down to Up.

      If the radius-server testuser command is not configured and the device sets the status of the authentication server to Down, the device will automatically set the status of the authentication server to Up after the interval (configured using the radius-server retransmit timeout dead-time command) for the server to restore to the active state. The device will not re-authenticate users.

    • The device adds users with the authen-server-down authorization to entries of users who fail to be authenticated upon an authentication server Down event. The device will re-authenticate users in the entries when it detects that the authentication server is Up.

(Optional) Configuring a User Authentication Domain

Context

The device manages users in domains. For example, AAA schemes and authorization information are bound to domains. During user authentication, the device assigns users to specified domains based on the domain names contained in user names. However, user names entered by many users on actual networks do not contain domain names. In this case, you can configure a default domain in an authentication profile. If users using this profile enter user names that do not contain domain names, the device manages the users in the default domain.

On actual networks, user names entered by some users contain domain names and those entered by other users do not. The device uses different domains to manage the users. Because authentication, authorization and accounting (AAA) information in the domains are different, users use different AAA information. To ensure that users using the same authentication profile use the same AAA information, you can configure a forcible domain in the authentication profile for the users. The device then manages the users in the forcible domain regardless of whether entered user names contain domain names or not.

NOTE:

After the NAC configuration model supports modular configuration, AAA configuration information used by users can be directly bound to the authentication profile. If AAA configuration information exists both in the user authentication domain and authentication profile, the AAA configuration information in the authentication profile is used preferentially.

Prerequisites

A domain has been configured using the domain (AAA view) command in the AAA view.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run authentication-profile name authentication-profile-name

    The authentication profile view is displayed.

  3. Run access-domain domain-name [ dot1x | mac-authen | portal ] * [ force ]

    A default or forcible domain is configured for users.

    By default, no default or forcible domain is configured in an authentication profile, and the global default domain default is used.

    NOTE:
    • If force is not specified, a default domain is configured. If force is specified, a forcible domain is configured. If both a default domain and a forcible domain are configured, the device authenticates users in the forcible domain.

    • If dot1x, mac-authen, or portal is not specified, the configured domain takes effect for all access authentication users using the authentication profile. If dot1x, mac-authen, or portal is specified, the configured domain takes effect only for specified users using the authentication profile.

Verifying the Authentication Profile Configuration

Context

After configuring an authentication profile, run the following commands to verify the configuration.

Procedure

  • Run the display authentication-profile configuration [ name authentication-profile-name ] command to check the configuration of the authentication profile.
  • Run the display free-rule-template configuration [ name free-rule-name ] command to check the configuration of the authentication-free rule profile.
  • Run the display user-group [ group-name ] command to view the configuration of a user group.

Application

Context

After an authentication profile is bound to the VAP profile, NAC is enabled in the VAP profile. The device implements access control on users who go online through the VAP profile.

An authentication profile uniformly manages NAC configuration. The authentication profile is bound to the VAP profile view to enable NAC, implementing access control on the users in the VAP profile. The authentication type of the users in the VAP profile is determined by the access profile bound to the authentication profile. For details about how to configure an access profile, see Configuring an Access Profile.

Prerequisites

An authentication profile has been configured. For details about how to configure an authentication profile, see Configuring an Authentication Profile.

Procedure

  • Enable in a VAP profile.
    1. Run system-view

      The system view is displayed.

    2. Run wlan

      The WLAN view is displayed.

    3. Run vap-profile name profile-name

      The VAP profile view is displayed.

    4. Run authentication-profile authentication-profile-name

      The authentication profile is applied to the VAP profile.

      By default, no authentication profile is applied to a VAP profile.

(Optional) Configuring the Quiet Function

Context

If a user frequently fails NAC authentication within a short period, system performance will be affected, and brute force attacks on the user name and password may occur.

After the quiet function is enabled, if the number of times that a user fails to be authenticated within 60s exceeds the upper limit, the device discards the user's authentication request packets for a period to avoid frequent authentication failures.

NOTE:

When the number of quiet entries reaches the maximum number, the device does not allow new users who are not in the quiet table to access the network.

Procedure

  • Configure the quiet function for 802.1X authentication users.

    1. Run system-view

      The system view is displayed.

    2. Run dot1x quiet-period

      The quiet function is enabled for 802.1X authentication users.

      By default, the quiet function is enabled for 802.1X authentication users.

    3. (Optional) Run dot1x quiet-times fail-times

      The maximum number of authentication failures within 60 seconds before the device quiets an 802.1X authentication user is configured.

      By default, the maximum number of authentication failures is 10.

    4. (Optional) Run dot1x timer quiet-period quiet-period-value

      The quiet period is configured for 802.1X authentication users who fail to be authenticated.

      By default, the quiet period is 60 seconds for 802.1X authentication users who fail to be authenticated.

  • Configure the quiet function for MAC address authentication users.

    NOTE:

    The quiet function for MAC address authentication users takes effect only after the device is disabled from assigning network access rights to users in each phase before authentication succeeds using the undo authentication event action authorize command. In hybrid authentication of MAC address authentication users, the quiet function for MAC address authentication users does not take effect.

    1. Run system-view

      The system view is displayed.

    2. (Optional) Run mac-authen quiet-times fail-times

      The maximum number of authentication failures within 60 seconds before the device quiets a MAC address authentication user is configured.

      By default, the maximum number of authentication failures is 10.

    3. Run mac-authen timer quiet-period quiet-period-value

      The quiet period is configured for MAC address authentication users who fail to be authenticated.

      By default, the quiet period is 60 seconds for MAC address authentication users who fail to be authenticated. If the value of quiet-period-value is 0, the quiet function is disabled for MAC address authentication users.

  • Configure the quiet function for Portal authentication users.

    1. Run system-view

      The system view is displayed.

    2. Run portal quiet-period

      The quiet function is enabled.

      By default, the quiet function is enabled for Portal authentication users.

    3. (Optional) Run portal quiet-times fail-times

      The maximum number of authentication failures within 60 seconds before the device quiets a Portal authentication user is configured.

      By default, the maximum number of authentication failures is 10.

    4. (Optional) Run portal timer quiet-period quiet-period-value

      The quiet period is configured for Portal authentication users who fail to be authenticated.

      By default, the quiet period is 60 seconds for Portal authentication users who fail to be authenticated.

(Optional) Configuring the Web Push Function

Context

After a user is successfully authenticated, the device forcibly redirect the user to a web page when receiving the HTTP packet from the user who accesses web pages for the first time. In addition to pushing advertisement pages, the device can obtain user terminal information through the HTTP packets sent by the users, and apply the information to other services. There are two ways to push web pages:
  1. URL: pushes the URL corresponding to the web page.
  2. URL template: pushes the URL template. A URL template must be created. The URL template contains the URL of the pushed web page and URL parameters.

If an application program that actively sends HTTP packets is installed on the user terminal, the terminal has sent the HTTP packet before the user accesses a web page. Therefore, the user is unaware of the web page push process.

Users who go online without authentication through an authentication-free rule cannot receive the pushed web page configured using the force-push command.

NOTE:
Built-in Portal authentication does not support the web page push function.

Procedure

  • URL mode

    1. Run system-view

      The system view is displayed.

    2. Run aaa

      The AAA view is displayed.

    3. Run domain domain-name

      An AAA domain is created and the AAA domain view is displayed.

      The device has two default domains: default and default_admin. Common access users use the default domain and the administrator uses the default_admin domain.

    4. Run force-push url url-address

      The URL push function is enabled.

      By default, the URL push function is disabled.

  • URL template mode

    1. Create and configure a URL template.
      1. Run system-view

        The system view is displayed.

      2. Run url-template name template-name

        A URL template is created and the URL template view is displayed.

        By default, no URL template is created on the device.

      3. Run url [ push-only ] url-string [ ssid ssid ]

        A pushed URL is configured.

        By default, no pushed URL is configured.

        The SSID that users associate with must be the same as that configured on the device; otherwise, the device cannot push URLs to users.

      4. Run url-parameter { ap-ip ap-ip-value | ap-mac ap-mac-value | redirect-url redirect-url-value | ssid ssid-value | sysname sysname-value | user-ipaddress user-ipaddress-value | user-mac user-mac-value } *

        Parameters carried in the URL are configured.

        By default, a URL does not carry parameters.

      5. Run url-parameter mac-address format delimiter delimiter { normal | compact }

        The MAC address format in the URL is configured.

        By default, the MAC address format in a URL is XXXXXXXXXXXX.

      6. Run parameter { start-mark parameter-value | assignment-mark parameter-value | isolate-mark parameter-value } *

        Characters in the URL are configured.

        By default, the start character in a URL is a question mark (?), the assignment character is an equal sign (=), and the delimiter between parameters is an ampersand (&).

      7. Run quit

        Return to the system view.

    2. Run aaa

      The AAA view is displayed.

    3. Run domain domain-name

      An AAA domain is created and the AAA domain view is displayed.

      The device has two default domains: default and default_admin. Common access users use the default domain and the administrator uses the default_admin domain.

    4. Run force-push url-template template-name

      The URL template push function is enabled.

      By default, the URL template push function is disabled.

(Optional) Enabling the Device to Dynamically Adjust the Rate at Which It Processes Packets from NAC Users

Context

When a lot of NAC users send authentication or log off requests to the device, the CPU usage may be overloaded especially when the CPU or memory usage is already high (for example, above 80%). After the device is enabled to dynamically adjust the rate of packets from NAC users, the device limits the number of NAC packets received per second if the CPU or memory usage is high. This function reduces loads on the device CPU.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run authentication speed-limit auto

    The device is enabled to dynamically adjust the rate at which it processes packets from NAC users.

(Optional) Enabling User Management Based on HTTP or HTTPS

Context

After enabling user management based on HTTP or HTTPS, you can manage access users through HTTP or HTTPS on a remote host or server, including forcibly logging out users, authorizing user groups, and deregistering users (by modifying the user status to pre-connection). You can also configure an ACL rule in the command to specify which remote hosts or servers can be used to manage users.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run remote-access-user manage { http | https ssl-policy policy-name } port port-num [ acl acl-number ]

    User management based on HTTP or HTTPS is enabled.

Translation
Download
Updated: 2019-01-11

Document ID: EDOC1000176006

Views: 118078

Downloads: 309

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next