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

S12700 V200R011C10 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, DAA, NAC, PPPoE, Policy Association, and IP session.
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 802.1X 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 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.

If a static IPv4 address is configured for a client, 802.1X authentication cannot be triggered because they do not exchange DHCP or ARP packets. You can run the authentication trigger-condition any-l2-packet command to trigger 802.1X authentication through any packets. To prevent unauthorized users from occupying user entries on the device maliciously, you are advised to configure the function of triggering 802.1X authentication through any packets on the access device, and run the authentication mode max-user max-user-number command in the authentication profile view to configure the maximum number of access users allowed on an interface. The recommended value is 10.

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 | any-l2-packet } *

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

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

(Optional) Enabling 802.1X Authentication Triggered by Unicast Packets

Context

On a network where 802.1X authentication is used, if a user uses a built-in 802.1X client of a PC operating system (such as Windows XP), the user cannot enter the user name and password to trigger authentication.

To solve the problem, enable 802.1X authentication triggered by unicast packets. This function enables the device to send a unicast packet to respond to the received ARP or DHCP Request packet. After the user PC receives the unicast packet from the device, the built-in 802.1X authentication page is displayed. The user then can enter the user name and password for authentication.

After 802.1X authentication triggered by unicast packets is enabled, users can use built-in 802.1X clients for authentication, which facilitates fast network deployment.

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 unicast-trigger

    802.1X authentication triggered by unicast packets is enabled.

    By default, 802.1X authentication triggered by unicast packets is disabled.

(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. For other precautions about interoperability between the device and H3C iMC RADIUS server, see What Should I Be Aware of When Connecting the Device 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 handshake packet-type { request-identity | srp-sha1-part2 }

    The type of 802.1X authentication handshake packets is configured.

    By default, the type of 802.1X authentication handshake packets is request-identity.

    To ensure interoperability with devices of other vendors, you can configure the handshake packet type based on the actual requirements.

  5. (Optional) Configure the interval at which the device handshakes with 802.1X online users.

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

    • Run dot1x timer eth-trunk-access handshake-period handshake-period-value

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

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

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

    • UCL group

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

        A UCL group is created.

        By default, no UCL group is created.

      2. (Optional) Run ucl-group ip ip-address { mask-length | ip-mask } { group-index | name group-name }

        A static UCL group is created.

        By default, no static UCL group is configured.

      3. Configure a user ACL to filter packets based on the UCL group. For details, see "Configuring a User ACL" in "ACL Configuration" in the S12700 V200R011C10 Configuration Guide - Security.
      4. Use the following methods to process packets:

        • Run traffic-filter inbound acl { acl-number | name acl-name }

          ACL-based packet filtering is configured.

          By default, ACL-based packet filtering is not configured.

        • Run traffic-redirect inbound acl { acl-number | name acl-name } [ vpn-instance vpn-instance-name ] ip-nexthop nexthop-address

          ACL-based packet redirection is configured.

          By default, ACL-based packet redirection is not configured.

    • Service scheme

      1. Run aaa

        The AAA view is displayed.

      2. Run service-scheme service-scheme-name

        A service scheme is created and the service scheme view is displayed.

        By default, no service scheme is configured on the device.

      3. Run ucl-group { group-index | name group-name }

        A UCL group is bound to the service scheme.

        By default, no UCL group is bound to a service scheme.

        Before running this command, ensure that a UCL group that identifies the user category has been created and configured.

      4. Run user-vlan vlan-id

        A user VLAN is configured in the service scheme.

        By default, no user VLAN is configured in a service scheme.

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

      5. Run voice-vlan

        The voice VLAN function is enabled in the service scheme.

        By default, the voice VLAN function is disabled in a service scheme.

        For this configuration to take effect, ensure that a VLAN has been specified as the voice VLAN using the voice-vlan enable command and the voice VLAN function has been enabled on the interface.

      6. Run qos-profile profile-name

        A QoS profile is bound to the service scheme.

        NOTE:

        The user-queue command is supported only by the X1E series cards.

        By default, no QoS profile is bound to a service scheme.

        Before running this command, ensure that a QoS profile has been configured. The procedure for configuring a QoS profile is as follows:
        1. In the system view, run qos-profile name profile-name

          A QoS profile is created and the QoS profile view is displayed.

        2. Configure traffic policing, packet processing priority, and user queue in the QoS profile view. (Of all parameters in the QoS profile bound to the service scheme, only those configured using the following commands take effect.)
          • Run car cir cir-value [ pir pir-value ] [ cbs cbs-value pbs pbs-value ] { inbound | outbound }

            Traffic policing is configured in the QoS profile.

            By default, traffic policing is not configured in a QoS profile.

          • Run remark dscp dscp-value { inbound | outbound }

            The action of re-marking DSCP priorities of IP packets is configured in the QoS profile.

            By default, the action of re-marking DSCP priorities of IP packets is not configured in a QoS profile.

          • Run remark 8021p 8021p-value

            The action of re-marking 802.1p priorities of VLAN packets is configured in the QoS profile.

            By default, the action of re-marking 802.1p priorities of VLAN packets is not configured in a QoS profile.

          • Run user-queue pir pir-value [ flow-queue-profile flow-queue-profile-name ] [ flow-mapping-profile flow-mapping-profile-name ]

            A user queue is created in the QoS profile to implement HQoS scheduling.

            By default, no user queue is configured in a QoS profile.

      7. Run quit

        The AAA view is displayed.

      8. Run quit

        The system view is displayed.

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

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

In Figure 4-14, the device sends an authentication failure packet to the client after the EAP-Request/MD5 Challenge packet times out. 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

Figure 4-14  802.1X authentication timeout process

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

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.
Translation
Download
Updated: 2019-10-21

Document ID: EDOC1000178117

Views: 117820

Downloads: 55

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