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

CLI-based Configuration Guide - Security

AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R010

This document provides the basic concepts, configuration procedures, and configuration examples in different application scenarios of the network management feature supported by the device.
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 an Access Profile

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 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 device supports a maximum of 8 configurable 802.1X access profiles.The compatibility profile converted after an upgrade is not counted in the configuration specification. 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 Packet Types That Can Trigger 802.1X Authentication

Context

After 802.1X authentication is enabled, the device can trigger 802.1X authentication on users by default when receiving DHCP or ARP packets. Based on user information on the actual network, the administrator can adjust the packet types that can trigger 802.1X authentication. For example, if all users on a network dynamically obtain IPv4 addresses, the device can be configured to trigger 802.1X authentication only through DHCP packets. This prevents the device from continuously sending ARP packets to trigger 802.1X authentication when static IPv4 addresses are configured for unauthorized users on the network, and reduces device CPU occupation.

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 trigger-condition { dhcp | arp } *

    The packet types that can trigger 802.1X authentication are configured.

    By default, DHCP/ARP packets can trigger 802.1X authentication.

(Optional) Configuring the Authorization State of an Interface

Context

You can configure the authorization state of an interface to control whether an access user must be authenticated before accessing network resources. The interface supports the following authentication states:
  • Auto mode: The interface is initially in Unauthorized state and sends and receives EAPoL packets only. Users cannot access network resources. After a user passes the authentication, the interface turns to Authorized state. Users are allowed to access network resources in this state.
  • Authorized-force mode: The interface is always in Authorized state and allows users to access network resources without authentication.
  • Unauthorized-force mode: The interface is always in Unauthorized state and does not allow users to access 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 dot1x port-control { auto | authorized-force | unauthorized-force }

    The authorization state of the interface is configured.

    By default, the authorization state of an interface is auto.

(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 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 periodic 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.

      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 Online User Handshake Function

Context

When a user goes offline due to causes such as network interruption, the device still reserves the user's online information. This may result in incorrect accounting, and brings security threats if a bogus user accesses the network.

To ensure that user online information is normal, you can configure handshake with online 802.1X authentication users on the device. The device then periodically sends handshake request packets to online 802.1X users. If a user does not respond to the handshake request packets when the retransmission count is reached, the device sets the user status to offline.

NOTE:

If the 802.1X client cannot exchange handshake packets with the device, the device will not receive the handshake response packets within the handshake period. Therefore, to prevent the device from disconnecting users incorrectly, disable the online user handshake function.

This function takes effect only for the wired users.

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 handshake

    Handshake with online 802.1X authentication users is enabled.

    By default, handshake with online 802.1X authentication users is disabled on the device.

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

    The interval at which the device handshakes with 802.1X online users on non-Eth-Trunk interfaces is set.

    By default, the interval for sending handshake packets is 15 seconds.

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

    The number of times for resending a handshake packet is configured.

    By default, a handshake packet can be resent 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. Configure authorization parameters.

    • VLAN

      Configure a VLAN and network resources in the VLAN on the device.

    • Service scheme

      Configure a service scheme on the device. For configuration details, see (Optional) Configuring a Service Scheme.

    • User group

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

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

      2. Run acl-id acl-number

        An ACL is bound to the user group.

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

        NOTE:
        • Before running this command, ensure that an ACL has been created using the acl (system view) or acl name command and ACL rules have been configured using the rule command.

        • If a user group contains online users, the ACL bound to the user group cannot be modified or deleted in the system view.
      3. Run user-vlan vlan-id

        A user group VLAN is configured.

        By default, no user group VLAN is configured.

        NOTE:

        Before running this command, ensure that a VLAN has been created using the vlan command.

      4. Run remark { 8021p 8021p-value | dscp dscp-value | exp exp-value | lp lp-value } *

        The user group priority is configured.

        By default, no user group priority is configured.

      5. Run quit

        Return to the system view.

  3. Run dot1x-access-profile name access-profile-name

    The 802.1X access profile view is displayed.

  4. Run authentication event client-no-response action authorize { service-scheme service-scheme-name | user-group user-group-name | 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.

(Optional) Configuring the Device to Automatically Generate the DHCP Snooping Binding Table for Static IP Users

Context

There are unauthorized users who modify their MAC addresses to those of authorized users. After authorized users are connected through 802.1X authentication, the unauthorized users can obtain the same identities as the authorized users and connect to the network without authentication. This results in security risks of authentication and accounting. After accessing the network, unauthorized users can also initiate ARP spoofing attacks by sending bogus ARP packets. In this case, the device records incorrect ARP entries, greatly affecting normal communication between authorized users. To prevent the previous attacks, configure IPSG and DAI. These two functions are implemented based on binding tables. For static IP users, you can run the user-bind static command to configure the static binding table. However, if there are many static IP users, it takes more time to configure static binding entries one by one.

To reduce the workload, you can configure the device to automatically generate the DHCP snooping binding table for static IP users. After the static IP users who pass 802.1X authentication or are at the pre-authentication phase send EAP packets to trigger generation of the user information table, the device automatically generates the DHCP snooping binding table based on the MAC address, IP address, and interface recorded in the table.

To make this function take effect, you must run the dhcp snooping enable command on the interface to which the 802.1X access profile is bound to enable the DHCP snooping function on the interface and globally.

NOTE:
  • The EAP protocol does not specify a standard attribute to carry IP address information. Therefore, if the EAP request packet sent by a static IP user does not contain an IP address, the IP address information in the DHCP snooping binding table is obtained from the user' first ARP request packet with the same MAC address as the user information table after the user passes authentication. On a network, unauthorized users may forge authorized users' MAC addresses to initiate ARP snooping attacks to devices, and the DHCP snooping binding table generated accordingly may be unreliable. Therefore, the dot1x trigger dhcp-binding command is not recommended and you are advised to run the user-bind static command to configure the static binding table.

  • For users who are assigned IP addresses using DHCP, you do not need to run the dot1x trigger dhcp-binding command on the device. The DHCP snooping binding table is generated through the DHCP snooping function.

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 trigger dhcp-binding

    The device is configured to automatically generate the DHCP snooping binding table after static IP users pass 802.1X authentication or when the users are at the pre-authentication phase.

    By default, the device does not automatically generate the DHCP snooping binding table after static IP users pass 802.1X authentication or when the users are at the pre-authentication phase.

Verifying the Configuration

You can run the display dhcp snooping user-bind command to check the DHCP snooping binding table that is generated by the device for static IP users who pass 802.1X authentication or are at the pre-authentication phase. The DHCP snooping binding table generated using this function will be deleted after the users are disconnected.

Follow-up Procedure

Configure IPSG and DAI after the DHCP snooping binding table is generated, prevent attacks from unauthorized users.
  • In the interface view, run the ip source check user-bind enable command to enable IPSG.

  • In the interface view, run the arp anti-attack check user-bind enable command to enable DAI.

For detailed configurations of IPSG and DAI, see IPSG Configuration and ARP Security Configuration in the Huawei AR Series V200R010 Configuration Guide - Security.
(Optional) Configuring the Number of Times an Authentication Request or Handshake Packet 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 or handshake packet to the user, the device sends the authentication request or handshake packet again. If the authentication request or handshake packet has been sent for the maximum retransmission times and no response is received, the user authentication or handshake fails. In this process, the total number of authentication requests or handshake packets 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 or handshake packet is retransmitted to an 802.1X client is configured.

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

(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 the Function of Triggering 802.1X Authentication Through Multicast Packets

Context

If clients such as the built-in 802.1X client on the Windows operating system cannot send EAPoL-Start packets for 802.1X authentication, you can configure the function of triggering 802.1X authentication through multicast packets on the device. The device then periodically multicasts EAP-Request/Identity packets to clients to trigger 802.1X authentication for the clients.

If the device interface connecting to a client changes from Down to Up, the client needs to send EAPoL-Start packets again for 802.1X authentication, which takes a long time. You can enable the function of triggering 802.1X authentication through multicast packets immediately after the device interface goes Up, shortening the re-authentication time.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run dot1x mc-trigger

    The function of triggering 802.1X authentication through multicast packets is enabled.

    By default, the function of triggering 802.1X authentication through multicast packets is enabled.

  3. (Optional) Run dot1x mc-trigger port-up-send enable

    The function of triggering 802.1X authentication through multicast packets immediately after an interface goes Up is enabled.

    By default, the function of triggering 802.1X authentication through multicast packets immediately after an interface goes Up is disabled.

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 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 device supports a maximum of 8 configurable MAC access profiles.The compatibility profile converted after an upgrade is not counted in the configuration specification. The built-in MAC 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.

(Optional) Configuring the Authentication Mode for MAC Address Authentication

Context

In MAC address authentication, the access device exchanges RADIUS packets with the authentication server. Differences between authentication modes PAP and CHAP are as follows:

  • 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 high security is required, CHAP is recommended.

By default, the authentication mode for MAC address authentication is set to PAP. The authentication mode can be changed to CHAP for higher security.

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 authentication-method { chap | pap }

    The authentication mode for MAC address authentication is configured.

    By default, the authentication mode is set to PAP.

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 ] [ colon ] | without-hyphen } [ uppercase ] [ password cipher password ] ] }

    The user name format is configured for MAC address authentication.

    By default, a MAC address without hyphens (-) or colons (:) 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.

    • If MAC address authentication is enabled on a WLAN-ESS interface, passwords must be configured.

(Optional) Configuring Packet Types That Can Trigger MAC Address Authentication

Context

After MAC address authentication is enabled, the device can trigger MAC address authentication on users by default when receiving DHCP/ARP packets. Based on user information on the actual network, the administrator can adjust the packet types that can trigger MAC address authentication. For example, if all users on a network dynamically obtain IPv4 addresses, the device can be configured to trigger MAC address authentication only through DHCP packets. This prevents the device from continuously sending ARP packets to trigger MAC address authentication when static IPv4 addresses are configured for unauthorized users on the network, and reduces device CPU occupation.

When the function of triggering MAC address authentication through DHCP packets is supported, the device can use the DHCP packets to re-authenticate users, clear the MAC address authentication user entries in time, and send user terminal information to the authentication server.

NOTE:
  • After the VLANIF interface is enabled with the MAC address authentication function, MAC address authentication cannot be triggered for users when the interface receives DHCP packets.

  • This function takes effect only for users who go online after this function is successfully configured.

  • Only wired users support MAC address authentication triggered by DHCP/ARP packets. For wireless users, MAC address authentication is triggered by association packets.

  • The function does not take effect when multiple authentication modes are used together.
  • When MAC address authentication and 802.1X authentication are both enabled on an interface, packets that can trigger authentication include all the packet types that can trigger authentication in the MAC access profile and 802.1X access profile. For example, assume that ARP packets in the MAC access profile are unable to trigger authentication and ARP packets in the 802.1X access profile can trigger authentication. If MAC address authentication and 802.1X authentication are both enabled on an interface, ARP packets can trigger MAC address authentication.

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 authentication trigger-condition { dhcp | arp } *

    The packet types that can trigger MAC address authentication are configured.

    By default, DHCP/ARP packets can trigger MAC address authentication.

(Optional) Configuring a Source MAC Address Segment Allowed by MAC Address Authentication

Context

After MAC address authentication is enabled, MAC address authentication will be performed for every new MAC address entry generated on the device. To restrict the users for whom MAC address authentication can be performed on interfaces, you can configure a source MAC address segment allowed by MAC address authentication.

NOTE:

Only MAC address authentication users who go online through VLANIF interfaces support this function.

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 permit mac-address mac-address mask { mask | mask-length }

    The source MAC address segment allowed by MAC address authentication is configured.

    By default, no source MAC address segment is configured for MAC address authentication.

(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 re-authenticates MAC address authentication users when receiving DHCP lease renewal packets from the users. This mode takes effect only after the device is configured to trigger MAC address authentication through DHCP packets.
  • The device is manually configured to re-authenticate a user with a specified MAC address once.

Procedure

  • Configuring periodic 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.

      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 protocol { haca | portal }

      The protocol used in Portal authentication is set.

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

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

    5. (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.

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

    6. (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.

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

    8. Run vpn-instance vpn-instance-name

      A VPN instance is configured for the device to communicate with the Portal server.

      By default, no VPN instance is configured for the device to communicate with the Portal server.

    9. (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.

    10. 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 { ac-ip ac-ip-value | ac-mac ac-mac-value | 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 | user-vlan user-vlan-value | esn esn-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. (Optional) Run url-parameter set { ac-ip { ip-address | interface interface-type interface-number } | ap-ip { ip-address | interface interface-type interface-number } } *

            Redirection parameter values are set.

            By default, the device automatically obtains redirection parameter values.

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

  • 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 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 https-redirect enable

      HTTPS redirection of Portal authentication is enabled.

      By default, HTTPS redirection of Portal authentication is disabled.

      NOTE:
      • If Portal authentication is triggered when a user visits a website using HTTPS, the browser displays a security prompt. The user needs to click Continue to complete Portal authentication.
      • Redirection cannot be performed for browsers or websites using HTTP Strict Transport Security (HSTS).
      • If the destination port in HTTPS request packets sent by users is an unknown port (443), redirection cannot be performed.
      • This function takes effect only for new Portal authentication users.
      • This function takes effect only after the Portal server template is created or the IP address of the built-in Portal server is configured.
    • 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.

  • Enable the Nginx server.

    1. (Optional) Run nginx load { default | file-name }

      The device is configured to load the Nginx configuration file to the Nginx server when the Nginx server is enabled.

    2. Run nginx enable

      The Nginx server is enabled.

      By default, the Nginx server is disabled.

    3. Run nginx proxy port { default | port-number }

      The port number of the Nginx proxy server is configured.

      By default, the port number is 81.

    NOTE:

    Only the AR161EW, AR161EW-M1, AR169EGW-L, and AR169EW support the Nginx server.

(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.
NOTE:

For Layer 3 Portal authentication, the device currently can synchronize user information with the Huawei Symantec TSM Portal server. If the device connects to other Portal servers, user information may fail to be synchronized and users cannot go offline in real time. You can run the cut access-user command or use the NMS or RADIUS DM to force users to go offline.

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 device supports a maximum of 8 configurable portal access profiles.The compatibility profile converted after an upgrade is not counted in the configuration specification. 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 ] { direct | 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.

    The following Portal authentication modes are available:
    • direct: When there is no Layer 3 forwarding device between the device and a user, the device can learn the user's MAC address. You can configure the Layer 2 authentication mode so that the device can identify the user using the IP address and MAC address.
    • layer3: When there is a Layer 3 forwarding device between the device and a user, the device cannot learn the user's MAC address and can only identify the user using the IP address. You need to configure the Layer 3 authentication mode.

  4. Run portal auth-network network-address { mask-length | mask-address }

    The source subnet is set for Portal authentication.

    By default, the source authentication subnet is 0.0.0.0/0, indicating that users in all subnets must pass Portal authentication.

    The command takes effect only for Layer 3 Portal authentication. In Layer 2 Portal authentication, users on all subnets must be authenticated.

(Optional) Configuring the User Offline Detection Interval

Context

If a Portal authentication user goes offline due to power failure or network interruption, the device and Portal server may still store user information, which leads to incorrect accounting. In addition, a limit number of users can access the device. If a user goes offline improperly but the device still stores user information, other users cannot access the network.

After the offline detection interval is set for Portal authentication users, if a user does not respond within the interval, the device considers the user offline. The device and Portal server then delete the user information and release the occupied resources to ensure efficient resource use.

NOTE:

This function applies only to Layer 2 Portal authentication.

The heartbeat detection function of the authentication server can be used to ensure the normal online status of PC users for whom Layer 3 Portal authentication is used. If the authentication server detects that a user goes offline, it instructs the device to disconnect the user.

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 timer offline-detect time-length

    The interval for detecting Portal authentication user logout is set.

    By default, the interval for detecting Portal authentication user logout is 300s. The value 0 indicates that offline detection is not performed.

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

If the device functions as an AC, the Portal escape function for wireless users takes effect only when Fit APs running V200R007C00 and later versions are used.

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

An authorized VLAN cannot be delivered to online Portal users.

The Portal escape function does not take effect when wired users perform Layer 3 Portal authentication.

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.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Configure a user group.

    1. Run user-group group-name

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

    2. Run acl-id acl-number

      An ACL is bound to the user group.

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

      NOTE:
      • Before running this command, ensure that an ACL has been created using the acl (system view) or acl name command and ACL rules have been configured using the rule command.

      • If a user group contains online users, the ACL bound to the user group cannot be modified or deleted in the system view.
    3. Run remark { 8021p 8021p-value | dscp dscp-value | exp exp-value | lp lp-value } *

      The user group priority is configured.

      By default, no user group priority is configured.

    4. Run quit

      Return to the system view.

  3. Run portal-access-profile name access-profile-name

    The Portal access profile view is displayed.

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

  5. (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.
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 [ vpn-instance vpn-instance-name ] ] 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 { ac-ip ac-ip-value | ac-mac ac-mac-value | 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 | user-vlan user-vlan-value | esn esn-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. (Optional) Run url-parameter set { ac-ip { ip-address | interface interface-type interface-number } | ap-ip { ip-address | interface interface-type interface-number } } *

          Redirection parameter values are set.

          By default, the device automatically obtains redirection parameter values.

        8. 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 device supports a maximum of 8 configurable portal access profiles.The compatibility profile converted after an upgrade is not counted in the configuration specification. 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 ] { direct | 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.

    The following Portal authentication modes are available:
    • direct: When there is no Layer 3 forwarding device between the device and a user, the device can learn the user's MAC address. You can configure the Layer 2 authentication mode so that the device can identify the user using the IP address and MAC address.
    • layer3: When there is a Layer 3 forwarding device between the device and a user, the device cannot learn the user's MAC address and can only identify the user using the IP address. You need to configure the Layer 3 authentication mode.

  4. Run portal auth-network network-address { mask-length | mask-address }

    The source subnet is set for Portal authentication.

    By default, the source authentication subnet is 0.0.0.0/0, indicating that users in all subnets must pass Portal authentication.

    The command takes effect only for Layer 3 Portal authentication. In Layer 2 Portal authentication, users on all subnets must be authenticated.

(Optional) Configuring the User Offline Detection Interval

Context

If a Portal authentication user goes offline due to power failure or network interruption, the device and Portal server may still store user information, which leads to incorrect accounting. In addition, a limit number of users can access the device. If a user goes offline improperly but the device still stores user information, other users cannot access the network.

After the offline detection interval is set for Portal authentication users, if a user does not respond within the interval, the device considers the user offline. The device and Portal server then delete the user information and release the occupied resources to ensure efficient resource use.

NOTE:

This function applies only to Layer 2 Portal authentication.

The heartbeat detection function of the authentication server can be used to ensure the normal online status of PC users for whom Layer 3 Portal authentication is used. If the authentication server detects that a user goes offline, it instructs the device to disconnect the user.

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 timer offline-detect time-length

    The interval for detecting Portal authentication user logout is set.

    By default, the interval for detecting Portal authentication user logout is 300s. The value 0 indicates that offline detection is not performed.

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 [ vpn-instance vpn-instance-name ] ] 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. Run portal local-server https ssl-policy policy-name [ 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.

  4. (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.

  5. (Optional) Many well-known websites such as Google and Baidu use Hypertext Transfer Protocol Secure (HTTPS). When users visit these websites, it is required that users should be redirected to the Portal authentication page so that Portal authentication can be performed and the users can normally access the network. If unauthenticated Portal users visit websites using HTTPS after HTTPS redirection of Portal authentication is enabled, the device can redirect the users to the Portal authentication page.

    Run portal https-redirect enable

    HTTPS redirection of Portal authentication is enabled.

    By default, HTTPS redirection of Portal authentication is disabled.

    NOTE:
    • If Portal authentication is triggered when a user visits a website using HTTPS, the browser displays a security prompt. The user needs to click Continue to complete Portal authentication.
    • Redirection cannot be performed for browsers or websites using HTTP Strict Transport Security (HSTS).
    • If the destination port in HTTPS request packets sent by users is an unknown port (443), redirection cannot be performed.
    • This function takes effect only for new Portal authentication users.
    • This function takes effect only after the Portal server template is created or the IP address of the built-in Portal server is configured.

(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 the login page to users. The users can enter the user name and password on the login page for authentication.

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. Customize the login page of the built-in Portal server.

    • Run portal local-server 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 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 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 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 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.

(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 device supports a maximum of 8 configurable portal access profiles.The compatibility profile converted after an upgrade is not counted in the configuration specification. 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.

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 [ layer3 ]

    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.

    Portal authentication can work either in Layer 2 or Layer 3 mode.
    • In Layer 2 mode, there is no Layer 3 forwarding device between a device and a user. The device can learn the user's MAC address and identify the user using both the user's IP and MAC addresses.
    • In Layer 3 mode, there is a Layer 3 forwarding device between a device and a user. The device cannot learn the user's MAC address and has to identify the user using the user's IP address.

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.
Translation
Download
Updated: 2019-05-20

Document ID: EDOC1100034077

Views: 112852

Downloads: 208

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