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 V200R013C00 Configuration Guide - User Access and Authentication

This document describes the configurations of User Access and Authentication Configuration, including 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).
Logical Process of NAC Authentication

Logical Process of NAC Authentication

Logical Process of 802.1X Authentication

Figure 2-41 shows the processing logic of an access device during 802.1X authentication. The RADIUS authentication mode is used as an example.

  1. When the device sends a request to the client for the user name and the client does not respond, the user obtains the corresponding network access rights if authorization upon no 802.1X client response is configured. If authorization upon no 802.1X client response is not configured, the device checks whether authorization for pre-connection users is configured and authorizes the user accordingly.
  2. When the client initiates authentication or responds to the authentication request sent from the access device, the user is authenticated successfully and obtains complete access rights if the RADIUS server is in Up state. If the user fails the authentication, the access device checks the authorization configuration upon authentication failures and the authorization configuration for pre-connection users in sequence, and authorizes the user accordingly.
  3. If the RADIUS server is in Down state, the access device checks the authorization configuration when the authentication server is Down, authorization configuration upon authentication failures, and authorization configuration for pre-connection users in sequence, and authorizes the user accordingly.
  4. If re-authentication is configured, re-authentication is performed for the user in the corresponding state according to the re-authentication trigger mechanism.
Figure 2-41  Processing logic of the 802.1X authentication device

Logical Process of MAC Address Authentication

Figure 2-42 shows the processing logic of the access device during MAC address authentication for a user. The RADIUS authentication mode is used as an example.

  1. After detecting a new MAC address, the access device triggers MAC address authentication for the user.
  2. The access device sends a RADIUS Access-Request packet to the RADIUS server, requesting the RADIUS server to perform MAC address authentication for the user (for details, see RADIUS Server Selection Mechanism and MAC Address Authentication Process).
    1. If the MAC address authentication succeeds, the user goes online.
    2. If the MAC address authentication fails and the RADIUS server is in Down state (for details, see RADIUS Server Status Detection), the access device checks whether it is configured to authorize users when the RADIUS server is in Down state, to authorize users who fail to be authenticated, and to authorize pre-connection users (for details, see NAC Escape Mechanism). If yes, the user obtains the corresponding network access rights; if not, the user does not have any network access rights.
    3. If the MAC address authentication fails and the RADIUS server is in Up state, the access device checks whether it is configured to authorize users who fail to be authenticated and to authorize pre-connection users. If yes, the user obtains the corresponding network access rights; if not, the user does not have any network access rights.
  3. For users in abnormal authentication state, the access device can be configured to re-authenticate the users so that they can obtain network access rights as soon as possible. For users who have passed MAC address authentication, re-authentication can ensure the validity of user identities (for details, see MAC Address Re-authentication).
Figure 2-42  Processing logic of the access device

Processing Logic of Portal Authentication

Figure 2-43 shows the processing logic of the access device during Portal authentication. RADIUS authentication is used as an example.

  1. When a user accesses a network, if pre-connection authorization is configured, the client obtains the corresponding permission. When the user accesses resources beyond the permissions, the user is redirected to the Portal authentication website. If pre-connection authorization is not configured, the user is redirected to the Portal authentication website.
  2. If a user needs to access the Portal authentication website and the Portal server is working properly, the access device and RADIUS server perform Portal authentication. If the Portal server is Down, the access device checks network access permissions of the user. When the Portal server changes from Down to Up, the user is reauthenticated in accordance with the reauthentication triggering mechanism.
  3. During Portal authentication, if the RADIUS server works properly, the user is authenticated successfully and granted complete permissions. If the user fails to be authenticated, the access device checks authentication failure and pre-connection authorization. The user obtains corresponding permissions. If the RADIUS server is Down, the access device checks network access permissions when the authentication server is Down, authentication fails, and the user is in the pre-connection phase.
Figure 2-43  Processing logic

Pre-Connection

After the pre-connection function is enabled, users enter the pre-connection state before the authentication succeeds and after the authentication fails. You can configure network access permissions granted to users in pre-connection state. Otherwise, these users have no network access permission.

Pre-connection is triggered in either of the following conditions:
  • After being started, the client sends any packet to the access device and the user enters the pre-connection state.
  • After a user fails the authentication, the user enters the pre-connection state.

The access device deletes an existing user entry if ARP probe detects that the user is offline or the physical link is Down for more than T seconds. If the access device has a user entry that is not aged out when the client is connected, no pre-connection log is generated. If a user fails to be authenticated for the first time, the user stays in the pre-connection state until the user goes offline. The following assumes that no user entry exists on the access device before the client is connected and describes the pre-connection mechanism state upon a re-authentication failure.

When a client is directly connected to an access device, the interfaces of the client and the access device go Down after the client is shut down. When a client is connected to the access device through an IP phone, the interface of the access device connected to the IP phone does not go Down after the client is shut down. The following describes pre-connection log generation in those scenarios. Assume that an interface link is faulty, the user logout delay is T seconds, and user's ARP probe ends within T seconds.

Direct Connection Between the Client and the Access Device
Figure 2-44  Direct connection between the client and the access device
  1. After being started, the client sends any packet to and establishes a pre-connection with the access device. The access device then generates a pre-connection log.
  2. The access device performs 802.1X authentication for the user. After the user passes the authentication, the access device generates an authentication success log.
  3. The access device periodically re-authenticates the user and generates an authentication success log each time the user passes re-authentication.
  4. After the client is shut down, the interface of the client goes Down, and the interface of the access device goes Down after T seconds. If the (N+1)th re-authentication is performed for the user within the T-second delay, user authentication fails and the access device generates a pre-connection log. Otherwise, the (N+1)th re-authentication is not performed after the interface goes Down.
  5. After ARP probe fails, the user goes offline.
Non-direct Connection Between the Client and the Access Device
Figure 2-45  Non-direct connection between the client and the access device
  1. After being started, the client sends any packet to and establishes a pre-connection with the access device. The access device then generates a pre-connection log.
  2. The access device performs 802.1X authentication for the user. After the user passes the authentication, the access device generates an authentication success log.
  3. The access device periodically re-authenticates the user and generates an authentication success log each time the user passes re-authentication.
  4. After the client is shut down, the interface of the access device sends packets normally because the interface is connected to an IP phone. If the (N+1)th re-authentication is performed for the user before ARP probe fails, user authentication fails and the device generates a pre-connection log. Otherwise, the user goes offline after ARP probe fails and the (N+1)th re-authentication is not performed.
  5. After ARP probe fails, the user goes offline.
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100066170

Views: 23319

Downloads: 6

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