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

S600-E V200R010C00 Configuration Guide - User Access and Authentication

This document describes the working mechanisms, configuration procedures, and configuration examples of User Access and Authentication features, such as AAA, NAC, and Policy Association.
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).
Portal Authentication

Portal Authentication

Introduction to Portal Authentication

Portal authentication is also called web authentication. Generally, Portal authentication websites are also called Portal websites.

When an unauthenticated user accesses the Internet, the device forcibly redirects the user to a specific site. The user then can access resources in the specific site for free. When the user needs to access resources outside the specific site, the user must pass authentication on the Portal authentication website first.

A user can access a known Portal authentication website and enter a user name and password for authentication. This mode is called active authentication. If a user attempts to access other external networks through HTTP, the device forcibly redirects the user to the Portal authentication website for Portal authentication. This mode is called forcible authentication.

NOTE:

The device uses Huawei proprietary Portal protocol to perform Portal authentication. Huawei proprietary Portal protocol is compatible with the Portal 2.0 protocol of China Mobile Communications Corporation (CMCC), and supports basic functions of the Portal 2.0 protocol.

System Architecture

A Portal server can be an external Portal server, or a built-in Portal server.

  • Using an external Portal server

As shown in Figure 3-7, typical networking of a Portal authentication system consists of four entities: authentication client, access device, Portal server, and authentication/accounting server.

Figure 3-7  Portal authentication system using an external Portal server
  1. Authentication client: is a client system installed on a user terminal. The user terminal can be a browser running HTTP/HTTPS or a host running Portal client software.
  2. Access device: is a broadband access device such as switch or router. It provides the following functions:
    • Redirects all HTTP requests from users on authentication subnets to the Portal server before authentication.
    • Interacts with the Portal server and the authentication/accounting server to implement identity authentication/accounting during authentication.
    • Allows the users to access authorized Internet resources after the authentication succeeds.
  3. Portal server: receives authentication requests from the Portal client. It provides free Portal services and an interface based on web authentication, and exchanges authentication information of the authentication client with the access device.
  4. Authentication/accounting server: interacts with the access device to implement user authentication and accounting.
  • Portal authentication system using a built-in Portal server

The access device with the built-in Portal server implements all Portal server functions. In this case, the Portal authentication system only includes three entities: authentication client, access device, and authentication/accounting server, as shown in Figure 3-8.

Figure 3-8  Portal authentication system using a built-in Portal server

The built-in Portal server provides Portal authentication, without the need to deploy an extra Portal server.

The built-in Portal server implements basic functions of the Portal server, including web-based login and logout. It cannot replace the independent Portal server or extensions.

Authentication Modes

Different Portal authentication modes can be used in different networking modes. Portal authentication is classified into Layer 2 and Layer 3 authentication according to the network layer on which it is implemented.

  • Layer 2 authentication

The authentication client and access device are directly connected (or only Layer 2 devices exist between the authentication client and an access device). The device can learn a user's MAC address, and uses an IP address and a MAC address to identify the user. Portal authentication is configured as Layer 2 authentication.

Layer 2 authentication is simple and highly secure. However, it requires that the user reside on the same subnet as the access device, which makes the networking inflexible.

Figure 3-9 illustrates the packet interaction process when the user goes online and Layer 2 authentication is used.

Figure 3-9  Layer 2 authentication flowchart
  1. A Portal user initiates an authentication request through HTTP. The access device allows an HTTP packet destined for the Portal server or an HTTP packet destined for the configured authentication-free network resources to pass. The access device redirects HTTP packets accessing other addresses to the Portal server. The Portal server provides a web page where the user can enter a user name and password for authentication.
  2. The Portal server exchanges information with the access device to implement CHAP authentication. If PAP authentication is used, the Portal service directly performs step 3 without exchanging information with the access device to implement PAP authentication.
  3. The Portal server sends the user name and password entered by the user to the access device through an authentication request packet, and starts a timer to wait for an authentication reply packet.
  4. The access device exchanges a RADIUS protocol packet with the RADIUS server.
  5. The access device sends an authentication reply packet to the Portal server.
  6. The Portal server sends a packet to the client indicating that the authentication succeeded and notifying the client that the authentication succeeded.
  7. The Portal server sends an authentication reply acknowledgment to the access server.
  • Layer 3 authentication

When the device is deployed at the aggregation or core layer, Layer 3 forwarding devices exist between the authentication client and device. In this case, the device may not obtain the MAC address of the authentication client. Therefore, only the IP address identifies the user. Portal authentication is configured as Layer 3 authentication.

The Layer 3 authentication process is the same as the Layer 2 authentication process. Networking of Layer 3 authentication is flexible, which facilitates remote control. However, only an IP address can be used to identify a user, so Layer 3 authentication has low security.

NOTE:

The device does not support Layer 3 authentication of the built-in Portal server.

Detection and Survival

If the Portal server fails or communication is interrupted due to a network failure between the device and Portal server, new Portal authentication users cannot go online, and online Portal users cannot go offline normally. User information on the Portal server and the device may be different, resulting in accounting errors.

With the Portal detection and survival function, even if the network fails or the Portal server cannot function properly, the device still allows users with certain access rights to use the network normally, and reports failures using logs and traps. Meanwhile, the user information synchronization mechanism ensures that user information on the Portal server matches that on the device, preventing accounting errors.

User Group Authorization

The device can authorize users based on the user group. After users are authenticated, the authentication server groups users together. Each user group is bound to an ACL so that users in the same user group share an ACL.

Translation
Download
Updated: 2019-08-21

Document ID: EDOC1000141885

Views: 54033

Downloads: 10

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