< Home

Configuring User-defined Portal Authentication

This section describes how to configure user-defined portal authentication.

Context

By default, the FW uses port 8887 to provide the built-in local portal authentication page. Users can proactively access the page (https://interface IP address:8887) for local portal authentication, or the HTTP requests of users are redirected to the page for local portal authentication.

When an enterprise deploys an external portal server for user authentication, user-defined portal authentication needs to be configured.

Procedure

  1. Configure the portal authentication template.

    Except Emergency Channel, all portal authentication template-related configurations take effect for the two types of user-defined portal authentication.

    1. In the system view, create and access the portal authentication template view.

      user-manage portal-template template-name [ template-id ]

      A maximum of five portal authentication templates can be set.

    2. Configure the URL of the user-defined portal authentication page.

      portal-url url-address

    3. Optional: Enable the function for pushing information to the portal server.

      portal-url push information

      By default, the function is enabled.

      If the portal server needs to interwork with the FW to exchange data, enable the FW to push information to the portal server. After the function of pushing information to the portal server is enabled, the FW automatically adds the default parameters in the portal server URL before pushing the URL to the portal server for portal authentication. The portal server extracts information from the URL.

      For example, the portal server URL is https://example.com. When the FW adds the default parameters, the portal server URL is changed to https://example.com?fwname=TH-FW1&fwip=0.0.0.0&pagetype=login&esn=21023595120123456789&url=http://www.example0.com/&userip=1.1.1.1. The FW pushes the modified URL to the portal server.

      The default parameter in the URL is described as follows (the value of each parameter is automatically filled in by the FW):

      • fwname: indicates the name of the FW that a user accesses.
      • fwip: IP address of the FW for receiving messages from the portal server. The FW is identified by the IP address.
      • pagetype: indicates the Portal page type.
      • esn: indicates the ESN of the FW.
      • url: indicates the accessed URL before user authentication.
      • userip: indicates the user IP address.

    4. Optional: Set parameters in the portal server URL.

      portal-url parameter { receive-interface receive-interface | esn esn | user-ip user-ip | user-mac user-mac | redirect-url redirect-url } *

      By default, the portal server URL carries default parameters.

      If the portal server can interwork with the FW in case of default parameters in the portal server URL, you do not need to perform the step. Otherwise, set parameters in the portal server URL for the portal server to interwork with the FW.

      If the specified URL of the portal server carries a user MAC address, run the portal-url parameter mac-address format command to set the format of the MAC address in the portal server URL.

      As long as one or more parameters are set in the command, the FW adds configured parameters in the portal server URL, but no default parameter. For example, if the ESN is configured, the portal server URL carries only the ESN.

    5. Optional: Enable the NTLM authentication function and specify an AD server address.

      ntlm enable

      ntlm auth-server address ipv4-address port port-number

      Usually, the AD server uses TCP port 445. Therefore, set the port value to 445.

      In an AD domain authentication environment where NTLM authentication is enabled, if a user that already logs in to the AD domain accesses the Internet through the browser, the user no longer needs to enter the user name or password. FW serves as the NTLM authentication proxy, triggers NTLM authentication between the browser and AD server, transfers NTLM authentication messages, and obtains the user ID in the authentication process.

      In NTLM authentication, the FW does not prompt a portal authentication page for entering the user name and password. This process, however, involves redirection for authentication. Therefore, you must run the portal-url url-address command in the portal authentication template view to configure the URL of the portal authentication page, namely, https://interface IP address:8887.

      In a scenario where the user accesses the Internet through a proxy server, the FW does not support NTLM authentication.

      NTLM authentication applies only to HTTP (port 80) traffic.

      A prerequisite of NTLM authentication is that the browser must support NTLM authentication. Otherwise, the browser cannot automatically provide user login information. At present, IE and Chrome support NTLM authentication. However, you must enable automatic logon in Internet Options.

      1. In the Internet Options dialog box, click the Security tab and then Custom level.
      2. Click Automatic logon with current user name and password in User Authentication > Logon.

    6. Optional: Set a mode for processing HTTPS service requests.

      https { enable | disable action { bypass | block } }

      By default, the FW redirects HTTP service requests destined for port 80 to the portal authentication page and permits HTTPS service requests destined for port 443 without authentication. To redirect HTTPS service requests, run the https enable command.

    7. Configure the emergency channel function.

      server-detect { haca-template haca-template | web-auth-server web-auth-server }

      With the emergency channel function, the FW does not push the user-defined portal authentication page to users when it detects that the portal server is Down. To be specific, the FW does not authenticate users, and users can directly access network resources.

      The parameter takes effect for user-defined portal authentication for user authentication that the FW participates in.

      Before setting Emergency Channel, set Portal Server Probe.

  2. Configure Portal2.0 authentication.

    The step takes effect for method 2: user-defined Portal authentication for user authentication that the FW participates in.

    1. Configure a portal server template.

      1. Create a portal server template and access the portal server template view.

        web-auth-server server-name

      2. Configure an IP address towards the portal server.

        server-ip server-ip-address

        By default, no IP address towards the Portal server is set.

      3. Optional: Configure the source IP address used by the FW to communicate with the portal server.

        source-ip ip-address

        By default, the source IP address is not set.

      4. Configure the destination port number used by the FW to send packets to the portal server.

        port port-number [ all ]

        By default, the FW uses destination port 50100 to send packets to the portal server.

      5. Configure the shared key used by the FW to exchange information with the portal server.

        shared-key cipher key-string

        By default, the key is not configured.

    2. Configure parameters for the FW to communicate with the portal server.

      1. Set the number of the port on which the FW listens to Portal2.0 packets.

        web-auth-server listening-port port-number

        The default port number is 2000.

      2. Optional: Enable the function of transparently transmitting user authentication information provided by the authentication server to the portal server.

        web-auth-server reply-message

        By default, the function is enabled.

    3. Optional: Configure the portal server probe function in the portal server template view.

      server-detect [ interval interval-period | max-times times | action log ] *

      By default, the function is disabled.

      If the communication between the FW and portal server is interrupted due to a network fault or a fault in the portal server, users cannot go online.

      The server probe function enables the FW to report faults through logs in case of a network fault or portal server failure.

      When enabling the function, you are advised to set Emergency Channel so that users can properly access network resources even when the portal server is Down.

    4. Optional: Configure the user information synchronization function in the portal server template view.

      user-sync [ interval interval-period | max-times times ] *

      By default, the function is disabled.

      If the communication between the FW and portal server is interrupted due to a network fault or a fault in the portal server, online users on the FW cannot log out properly, causing user information on the FW to be inconsistent with that on the portal server.

      The user information synchronization function ensures that the user information on the FW is consistent with that on the portal server.

      During user information synchronization, if the FW detects that the portal server does not have information on a user but the FW has the information on the user, the FW does not immediately force the user to go offline. Instead, the FW forces the user to go offline only when the portal server does not have the information on the user even after Synchronization Counts after the number of times that the FW fails to synchronize user information reaches the maximum value.

    5. Configure the portal access template and authentication template and apply the authentication template to Loopback 0.

      1. Configure the portal access template.

        portal-access-profile name access-profile-name

        The device uses the Portal access template to manage the configurations of the access from users who use portal authentication.

      2. Reference the portal server template in the portal access template.

        web-auth-server server-name

        By default, the portal access template does not reference any portal server template.

      3. Configure an authentication template.

        authentication-profile name authentication-profile-name

      4. Reference the portal access template in the authentication template.

        portal-access-profile access-profile-name

        By default, the authentication template is not bound with any portal access template.

      5. Apply the authentication template to Loopback 0.

        authentication-profile authentication-profile-name

        By default, no authentication template is applied to Loopback 0. Currently, the authentication template can be applied only to Loopback 0.

  3. Configure MAC address-prioritized portal authentication.

    You need to perform this step only when you use Method 2: The FW participates in user-defined portal authentication combined with MAC address-prioritized portal authentication.

    1. Enable MAC address-prioritized portal authentication.

      user-manage mac-access enable

      By default, the MAC address-prioritized portal authentication function is disabled.

    2. Configure the MAC entry aging time.

      user-manage mac-access aging-time aging-time

      The default MAC entry aging time is 1 minute.

    3. Configure MAC authentication response failure time.

      user-manage mac-access no-ack-time no-ack-time

      The default MAC authentication response failure time is 2 seconds.

    4. Configure the MAC access template.

      mac-access-profile name access-profile-name

    5. Configure the authentication template

      authentication-profile name authentication-profile-name

    6. Reference the MAC access template in the authentication template.

      mac-access-profile access-profile-name

    7. Apply the authentication template to a Layer 2 physical interface or a Layer 2 Eth-Trunk interface.

      authentication-profile authentication-profile-name

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >