No relevant resource is found in the selected language.

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

Reminder

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

upgrade

Fat AP and Cloud AP V200R008C00 CLI-based Configuration Guide

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

Understanding NAC

NAC Fundamentals

Process

Figure 25-66 shows the basic NAC process.

Figure 25-66  Basic NAC process
  1. The access device works with a security policy server (for example, an AAA server) to authenticate the user when an NAC terminal connects to the network.
  2. The security policy server delivers the authorization information to the access device if the user is authenticated. If the authentication fails, the access device isolates the user.
  3. Based on the authorization information from the security policy server, the access device controls the terminal user's network access rights and establishes a communication channel between the terminal and security policy server.
  4. The NAC terminal directly exchanges information with the security policy server. The terminal reports its status information, including the antivirus database, operating system, and patch versions.
  5. The security policy server checks the terminal status, and redelivers the authorization information to the access device if the NAC terminal does not comply with enterprise security standards.
  6. The access device modifies the terminal user's network access rights according to the authorization information delivered by the security policy server.
  7. Based on the status check result, the NAC terminal connects to the software server to download client software, repair the system, or upgrade the patch or antivirus database until the terminal complies with the enterprise security standards.
Comparison Between Three Authentication Modes

NAC provides three authentication modes: 802.1X authentication, MAC address authentication, and Portal authentication. Table 25-46 compares the three authentication modes.

Table 25-46  Authentication mode comparisons

Item

802.1X Authentication

MAC Address Authentication

Portal Authentication

Client

Required

Not required

Not required

Advantage

High security

No client required

Flexible deployment

Disadvantage

Inflexible deployment

Complex management and MAC address registration required

Low security

Scenario

New network with concentrated users and high requirements for security

Authentication of dumb terminals such as printers and fax machines

Scenario with flexible authentication modes and scattered users

The device allows multiple authentication modes to be deployed simultaneously to meet various authentication requirements on the network. The device supports one combined authentication mode: MAC address-prioritized Portal authentication.

802.1X Authentication

Overview

To resolve wireless local area network (LAN) security issues, the Institute of Electrical and Electronics Engineers (IEEE) 802 LAN/wide area network (WAN) committee developed the 802.1X protocol. Later, the 802.1X protocol was widely applied as a common access control mechanism on LAN interfaces for authentication and security on Ethernet networks.

The 802.1X protocol is an interface-based network access control protocol. It controls users' access to network resources by authenticating the users on access interfaces.

As shown in Figure 25-67, an 802.1X system uses a standard client/server architecture with three components: client, access device, and authentication server.

Figure 25-67  Diagram of the 802.1X authentication system
  • Client: an entity on the LAN segment, which is authenticated by the access device on the same LAN segment. The client is usually a user terminal. The user triggers 802.1X authentication using client software. The client must support Extensible Authentication Protocol over LAN (EAPOL).
  • Access device: an entity on the LAN segment, which authenticates the connected client. The access device is usually a network device that supports the 802.1X protocol. The device provides an interface for the client to access the LAN.
  • Authentication server: an entity that provides the authentication service for the access device. The authentication server, which is usually a RADIUS server, carries out authentication, authorization, and accounting on users.
Authentication Triggering Modes
802.1X authentication can be initiated by either the client or access device. The device supports the following authentication triggering modes:
  1. Triggered by the client: A user starts the client and enters the user name and password. The client then sends an EAP packet to the access device to trigger authentication.
  2. Triggered by the access device: When receiving a DHCP/ARP packet from a user terminal, the access device proactively enables the user terminal to display the client page and prompt the user to enter the user name and password. After the user name and password are entered, the authentication is started.
Authentication Modes
In an 802.1X authentication system, the client, access device, and authentication server exchange authentication information using the Extensible Authentication Protocol (EAP). The EAP packet exchange process is described as follows:
  1. The EAP packets transmitted between the client and access device are encapsulated in EAPOL format and transmitted across the LAN.
  2. The access device and authentication server (for example, a RADIUS server) exchange EAP packets in the following modes:
    • EAP relay: The access device relays EAP packets. The device encapsulates EAP packets in EAP over RADIUS (EAPoR) format and sends the packets to the RADIUS server for authentication. This authentication mode simplifies device processing and supports various EAP authentication methods, such as MD5-Challenge, EAP-TLS, and PEAP. However, the RADIUS server is required to support corresponding authentication methods.
    • EAP termination: The access device terminates EAP packets. The device encapsulates client authentication information into standard RADIUS packets, which are then authenticated by the server using the Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP). This authentication mode is applicable since mainstream RADIUS servers support PAP and CHAP authentication and server update is unnecessary. However, device processing is complex, and the device supports only the MD5-Challenge EAP authentication method.
NOTE:

The device supports the following EAP protocols: EAP-TLS, EAP-TTLS, EAP-PAP, EAP-CHAP (EAP-MD5), EAP-PEAP, EAP-SIM, and EAP-AKA.

Authentication Process

Figure 25-68 shows the 802.1X authentication process in EAP relay mode.

Figure 25-68  Service process in EAP relay mode
  1. Before authentication, a pre-connection is established between the client and device.

  2. When a user needs to access an external network, the user starts the 802.1X client program, enters the applied and registered user name and password, and initiates a connection request. At this time, the client sends an authentication request packet to the device to start the authentication process.

  3. After receiving the authentication request packet, the device sends a user name request packet, requesting the client to send the previously entered user name.

  4. In response to the request sent by the device, the client sends the user name to the device.

  5. The device sends the user name to the authentication server for processing.

  6. After receiving the user name forwarded by the device, the authentication server verifies the user password.

    1. The authentication server uses the user name to search the user name list in the database to find the corresponding user password.
    2. The authentication server encrypts the password with a randomly generated MD5 challenge, and sends the MD5 challenge to the client through the access device.
    3. After receiving the MD5 challenge from the device, the client encrypts the password with the MD5 challenge and sends the encrypted password to the authentication server through the access device.
    4. The authentication server compares the encrypted password received and the locally encrypted password. If the two passwords are the same, the user is considered authorized; if they are different, the user is considered unauthorized.
  7. After the password verification succeeds, the authentication server sends an authentication success packet to the access device.

  8. After receiving the authentication success packet, the device sends a packet indicating that the authentication is successful to the client, changes the interface status to authorized, and allows the user to access the network through the interface.

  9. If the user wants to go offline, the client sends a logoff packet to the device.

  10. The access device changes the interface status from authorized to unauthorized. It sends an authentication failure packet to the client and concurrently deletes the user login information.

Steps 5 and 6 are different in the authentication processes in EAP termination and relay modes. In EAP termination mode, when sending the user name from the client to the authentication server, the access device randomly generates an MD5 challenge to the client. (In this mode, the MD5 challenge is not generated by the authentication server.) The access device then sends the user name, MD5 challenge, and encrypted password to the authentication server for processing.

MAC Address Authentication

Overview

MAC address authentication controls a user's network access rights based on the user's interface and MAC address. The user does not need to install any client software. The device starts authenticating a user when detecting the user's MAC address for the first time on the interface where MAC address authentication has been enabled. During the authentication process, the user does not need to enter a user name or password.

User Name Format
Based on different user name formats and content that the access device uses to authenticate users, user name formats used in MAC authentication can be classified into the following types:
  • MAC address: The device uses a user's MAC address as the user name for authentication. The device can also use the MAC address or a user-defined character string as the user password.
  • Fixed user name: Regardless of users' MAC addresses, all users use a fixed name and password designated on the access device for authentication. As multiple users can be authenticated on the same interface, all users requiring MAC address authentication on the interface use the same fixed user name. The server only needs to configure one user account to meet the authentication demands of all users. This applies to a network environment with reliable clients.
Authentication Process

Figure 25-69 shows the MAC authentication process.

Figure 25-69  MAC address authentication process
  1. The device triggers MAC address authentication for a user when detecting an association packet sent by the user.
  2. Based on the configuration, the device sends the user name and password to the authentication server for authentication.
  3. The authentication server verifies the received user name and password. If the verification succeeds, the server sends an authentication success packet to the device. After receiving the authentication success packet, the device allows the user to access the network through the AP.

Portal Authentication

Overview

Portal authentication is also called web authentication. Generally, Portal authentication websites are also called Portal websites. When users go online, they must be authenticated on Portal websites. The users can use network resources only after they pass the authentication.

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.

System Architecture

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

The access device with a built-in Portal server implements basic Portal server functions, including web-based login and logout. It cannot replace an independent Portal server or support extended functions of an external Portal server, for example, it does not support MAC address-prioritized Portal authentication.

The built-in Portal server enhances the flexibility of Portal authentication because it does not require an additional Portal server to be installed. However, due to limited storage space, functions, and performance of access devices, the built-in Portal server applies to scenarios with simple functions and a smaller number of access users, for example, small restaurants that provide Internet access services.

  • Using an external Portal server

As shown in Figure 25-70, typical networking of a Portal authentication system using an external Portal server consists of four entities: client, access device, Portal server, and authentication server.

Figure 25-70  Portal authentication system using an external Portal server
  1. Client: has a browser running HTTP installed.
  2. Access device: includes switches and routers, and 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 authentication server to implement identity authentication, authorization, and accounting during authentication.
    • Allows the users to access authorized Internet resources after the authentication succeeds.
  3. Portal server: receives authentication requests from clients, provides free Portal services and authentication pages, and exchanges the client authentication information with the access device.
  4. Authentication server: interacts with the access device to implement user authentication, authorization, and accounting.
  • Using a built-in Portal server

The access device with the built-in Portal server implements the Portal server functions. In this scenario, the Portal authentication system only includes three entities: client, access device, and authentication server, as shown in Figure 25-71.

Figure 25-71  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 device with a built-in Portal server implements basic Portal server functions and only provides web-based login and logout functions for users. It cannot completely replace an independent Portal server or support any extended functions of an external server.

Authentication Protocol

If a Portal authentication system using an external Portal server is used, the device can connect to the Portal server using the following protocols:

  • Portal protocol: uses the UDP mode to transmit parameters such as the user name and password.
  • HTTP or HTTPS protocol: uses the HTTP or HTTPS mode to transmit parameters such as the user name and password.

It is recommended that you use the Portal protocol to connect the device to the Portal server. If the Portal server does not support the Portal protocol, it is recommended that you use the HTTPS protocol on the device.

If a Portal authentication system using a built-in Portal server is used, the device only supports the Portal protocol.

Authentication Modes

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

  • Layer 2 authentication

The client and access device are either directly connected or have only Layer 2 devices between them. The device can learn users' MAC addresses and identify the users using their MAC addresses and IP addresses. On a network of this configuration, Layer 2 authentication should be used.

If a wireless terminal is used to access the network, the user and service VLAN are in the same network segment, so the access device can learn the user's MAC address. In this scenario, Layer 2 Portal authentication is applied.

Figure 25-72 shows the packet interaction process in Layer 2 authentication.

Figure 25-72  Layer 2 authentication process of the Portal protocol
  1. Before authentication, a pre-connection is established between the client and device.
  2. The 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 on which the user must enter the user name and password for authentication.
  3. The Portal server exchanges information with the access device to implement Challenge Handshake Authentication Protocol (CHAP) authentication. If Password Authentication Protocol (PAP) authentication is used, the Portal server directly performs step 4 without exchanging information with the access device.
  4. The Portal server sends the user name and password entered by the user to the access device through an authentication request packet.
  5. The access device exchanges authentication packets with the authentication server.
  6. The access device sends an authentication reply packet to the Portal server.
  7. The Portal server sends an authentication success packet to the client, notifying the client that the authentication succeeded.
  8. The Portal server sends an authentication reply ACK packet to the access device.
For an external Portal server, authentication processes of different authentication protocols are different. Figure 25-72 shows the authentication process of the Portal protocol. Figure 25-73 shows the authentication process of the HTTP or HTTPS protocol.
Figure 25-73  Layer 2 authentication process of the HTTP or HTTPS protocol
  1. Before authentication, a pre-connection is established between the client and device.
  2. The client initiates an authentication request using HTTP or HTTPS. The access device allows an HTTP or HTTPS packet destined for the Portal server or an HTTP or HTTPS packet destined for the configured authentication-free network resources to pass through. The access device redirects HTTP or HTTPS packets accessing other addresses to the Portal server. The Portal server provides a web page on which the user must enter the user name and password for authentication, and instructs the client to send a POST authentication request packet to the access device.
  3. The client encapsulates the user name and password into a POST authentication request packet and sends the packet to the access device.
  4. The access device and authentication server exchange authentication packets.
  5. The access device sends an authentication reply packet to the client.
  • Layer 3 authentication

When the device is deployed at the aggregation or core layer, Layer 3 forwarding devices exist between the client and device. In this scenario, the device may not obtain the MAC address of the client. Therefore, the device only uses the IP address to identify the user. On a network of this configuration, Layer 3 authentication should be used.

The Layer 3 authentication process is similar to the Layer 2 authentication process, except that a pre-connection is established between the client and access device in Layer 3 authentication. Networking of the 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.

WeChat Authentication (Central AP)

Overview

WeChat is a real-time public platform developed by Tencent. This public platform provides shops with public accounts for advertising and marketing to promote profitability. On an open network, users can access the Internet by simply following WeChat public accounts of shops, without the need to enter a user name or password. Users can browse the pages of shops and access the Internet for free.

WeChat authentication is a special Portal authentication and has two modes: WeChat authentication using an external Portal server and WeChat authentication using a built-in Portal server.

System Architecture

WeChat Authentication Using an External Portal Server

Figure 25-74 shows the system architecture of WeChat authentication using an external Portal server. The architecture includes four components: client, access device, Portal server, and WeChat server.
Figure 25-74  System architecture of WeChat authentication using an external Portal server
  • Client: is a terminal with WeChat installed.

  • Access device: a switch or router, which provides the following functions:

    • Before authentication, it redirects all HTTP requests of users on the authentication network segment to the Portal server. This operation can also be performed by an AP to reduce the load on the access device.

    • During authentication, it exchanges information with the Portal server to complete user identity authentication.

    • After authentication, it permits users to access Internet resources authorized by the administrator.

  • Portal server: is a server system that receives authentication requests from clients, provides the WeChat authentication page, and exchanges clients' authentication information with the access device.

  • WeChat server: is the WeChat public platform that exchanges information with clients to complete user identity authentication.

WeChat Authentication Using a Built-in Portal Server

Figure 25-75 shows the system architecture of WeChat authentication using a built-in Portal server. The architecture includes three components: client, access device, and WeChat server.
Figure 25-75  System architecture of WeChat authentication using a built-in Portal server
  • Client: is a terminal with WeChat installed.

  • Access device: a switch or router, which provides the following functions:

    • Before authentication, it redirects all HTTP requests of users on the authentication network segment to the Portal server. This operation can also be performed by an AP to reduce the load on the access device.

    • During authentication, it functions as a Portal server to exchange information with a client, provide the client with the WeChat authentication page, and authenticate users.

    • After authentication, it permits users to access Internet resources authorized by the administrator.

  • WeChat server: is the WeChat public platform, which exchanges information with clients and authenticates users.

Authentication Process

WeChat Authentication Using an External Portal Server

Figure 25-76 illustrates the process of WeChat authentication using an external Portal server.
Figure 25-76  Process of WeChat authentication using an external Portal server
  1. A client connects to a Wi-Fi network and establishes a pre-connection with an AP.
  2. The client initiates an authentication request using HTTP.
  3. The AP permits HTTP packets for accessing the Portal server or configured authentication-free network resources and redirects HTTP packets for accessing other addresses to the Portal server.
  4. The client automatically accesses the redirected URL.
  5. The Portal server pushes the WeChat authentication page to the client.
  6. After the user clicks the WeChat Authentication button on the WeChat authentication page, the client initiates an authentication request to the Portal server.
  7. The Portal server creates a temporary user to request network access rights (same as WeChat users' network access rights configured in the authorization rule by the administrator) for the temporary user.

    The purpose of creating a temporary user and requesting network access rights for the user is to ensure that the terminal can access WeChat server resources before passing authentication. The administrator needs to configure the Session-Timeout attribute on the Portal server to specify the validity period (for example, 60 seconds) for the created temporary user. After the validity period expires, the temporary user automatically becomes invalid. If the user completes WeChat authentication before the validity period expires, the temporary user automatically goes offline after the user goes online using the WeChat account.

  8. The Portal server and the access device exchange information to complete the Portal authentication and login process of the temporary user.

  9. After the client is authenticated successfully, the access device sends an authentication response to the client.
  10. The client sends a ticket request (carrying parameters such as the extend parameter, authentication URL, shop information, and WeChat public account) to the WeChat server to initiate the local WeChat app program.
  11. The WeChat server authenticates the parameters carried in the received ticket request packet. If the authentication succeeds, it returns a ticket response to the client.
  12. The client initiates the local WeChat app program based on the received ticket response and sends a user WeChat identity information request carrying parameters, such as shop information and WeChat public accounts, to the WeChat server.
  13. After the client is authenticated successfully, the WeChat server sends a user WeChat identity information response carrying parameters, such as openId, to the client.
  14. The client sends an authentication URL request carrying extend and openId parameters to the Portal server.
  15. The Portal server authenticates parameters carried in the received authentication URL request. After the authentication succeeds, the Portal server returns an authentication URL response and a Wi-Fi connection page to the client.
  16. The user clicks Connect immediately. After the client connects to the Wi-Fi network successfully, it automatically sends a Portal authentication request to the Portal server.
  17. The Portal server and the access device exchange information to complete the Portal authentication and login process of the WeChat user.

    After the user passes authentication, the Portal server uses the twice-authentication mode to grant the user network access rights, and deletes the temporary user account.

    NOTE:

    If the device is connected to a non-Huawei Portal server, it is recommended that you use the CoA mode to change the Session-timeout attribute value to the MAC address buffer time configured in MAC address-prioritized Portal authentication or do not grant the Session-timeout attribute after the user goes offline in DM mode and passes re-authentication.

  18. The Portal server makes the user's WeChat account go online and the temporary user account go offline, and returns the authentication result to the user.
  19. The user can access the network.

WeChat Authentication Using a Built-in Portal Server

Figure 25-77 illustrates the process of WeChat authentication using a built-in Portal server.
Figure 25-77  Process of WeChat authentication using a built-in Portal server
  1. A client connects to a Wi-Fi network and establishes a pre-connection with an AP.
  2. The client initiates an authentication request using HTTP.
  3. The AP permits HTTP packets for accessing the Portal server or configured authentication-free network resources and redirects HTTP packets for accessing other addresses to the built-in Portal server.
  4. The client automatically accesses the redirected URL.
  5. The access device pushes the WeChat authentication page to the client.
  6. After a user clicks the Open WeChat for Wi-Fi Access button on the WeChat authentication page, the client initiates an authentication request to the access device.
  7. After the client is authenticated successfully, the access device sends an authentication response to the client.
  8. The client requests parameter information such as WeChat public accounts and shop information from the access device.
  9. The access device sends the required parameter information including shop information, WeChat public accounts, extend, and authentication URL to the client.
  10. The client sends a ticket request carrying parameters such as shop information and WeChat public account to the WeChat server to initiate the local WeChat app program.
  11. The WeChat server authenticates the parameters carried in the received ticket request. If the authentication succeeds, it returns a ticket response to the client.
  12. The client initiates the local WeChat app program based on the received ticket response and sends a user WeChat identity information request carrying parameters, such as shop information and WeChat public accounts, to the WeChat server.
  13. After the client is authenticated successfully, the WeChat server sends a user WeChat identity information response carrying parameters, such as openId, to the client.
  14. The client sends an authentication URL request carrying extend and openId parameters to the access device.

    The default format of an authentication URL is http://ip:port/login, in which ip and port indicate the IP address and TCP port number of the Portal server.

  15. The access device authenticates parameters carried in the received authentication URL request. After the authentication succeeds, the access device returns an authentication URL response to the client.
  16. The user can access the Internet without the need to follow WeChat public accounts.
NOTE:

extend: a set of user-defined parameters, which can be used to verify data.

openId: unique identifier of a WeChat public account

Translation
Download
Updated: 2019-01-11

Document ID: EDOC1000176006

Views: 117490

Downloads: 309

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