Login
- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 01-WLAN access authentication commands | 204.60 KB |
WLAN access authentication commands
client-security accounting-delay time
client-security accounting-restart trigger ipv4
client-security accounting-start trigger
client-security accounting-update trigger
client-security accounting dual-stack separate enable
client-security authentication critical-vlan
client-security authentication fail-vlan
client-security authentication-location
client-security authentication-mode
client-security authorization-fail offline
client-security authorization trigger byod
client-security ignore-authentication
client-security ignore-authorization
dot1x eap-termination authentication-method
dot1x eap-termination eap-profile
wlan authentication optimization
wlan client-security authentication clear-previous-connection
WLAN access authentication commands
client url-redirect acl
Use client url-redirect acl to specify an ACL to match traffic that triggers URL redirection.
Use undo client url-redirect acl to restore the default.
Syntax
client url-redirect acl acl-number
undo client url-redirect acl
Default
No ACL is specified to match traffic that triggers URL redirection.
Views
Service template view
Predefined user roles
network-admin
Parameters
acl-number: Specifies an ACL by its number, in the range of 2000 to 3999.
Usage guidelines
By default, the device uses the authorization ACL deployed by the RADIUS server to match traffic that triggers URL redirection. Rule conflicts might exist if the authorization ACL is used by multiple features. To avoid undesirable redirection results, specify an ACL that is configured only for matching traffic that triggers URL redirection.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# In service template service1, specify ACL 3111 to match traffic that triggers URL redirection.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client url-redirect acl 3111
Related commands
client url-redirect enable
client url-redirect enable
Use client url-redirect enable to enable URL redirection for WLAN clients.
Use undo client url-redirect enable to disable URL redirection for WLAN clients.
Syntax
client url-redirect enable
undo client url-redirect enable
Default
URL redirection is disabled for WLAN clients
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
This command takes effect only on clients that use RADIUS-based MAC authentication.
In RADIUS-based MAC authentication, a client can pass authentication only if the RADIUS server has its credential information (username and password) and MAC address.
URL redirection enables a client to authenticate to the RADIUS server after it has failed a MAC authentication because the server does not have its credential information and MAC address. This feature redirects the client to the specified authentication webpage URL for portal authentication. After the client passes portal authentication, the RADIUS server records the client's credential information and MAC address, and sends DM requests to log off the client. When the client reconnects to the the network, the client can pass MAC authentication. For information about DMs, see AAA configuration in User Access and Authentication Configuration Guide.
Examples
# Enable native URL redirection for WLAN clients in service template service1.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client url-redirect enable
Related commands
client url-redirect acl
client-security accounting-delay time
Use client-security accounting-delay time to configure the accounting delay.
Use undo client-security accounting-delay time to restore the default.
Syntax
client-security accounting-delay time time [ no-ip-logoff ]
undo client-security accounting-delay time
Default
The device sends a start-accounting request for a client only when the device learns the IP address of that client.
Views
Service template view
Predefined user roles
network-admin
Parameters
time: Sets the accounting delay timer. The value range for the time argument is 1 to 600 seconds.
no-ip-logoff: Logs off a client if the device has failed to learn the client's IP address before the delay timer expires. If you do not specify this keyword, the device sends a start-accounting request immediately after the accounting delay timer expires.
Usage guidelines
The accounting delay timer operates in conjunction with an IP-based accounting-start trigger.
· The IP-based accounting-start trigger specifies that the IP address of an 802.1X or MAC authenticated client triggers an accounting-start request.
· The accounting delay timer specifies the maximum interval for the device to learn the IP address of an 802.1X or MAC authenticated client before it takes the specified action.
The accounting delay timer starts when a client passes 802.1X or MAC authentication. If the device has failed to learn the client's IP address before the timer expires, the device takes either of the following actions:
· Sends a start-accounting request immediately if the no-ip-logoff action is not specified.
· Logs off the client if the no-ip-logoff action is specified.
Configure the accounting delay timer depending on the typical amount of time for the device to learn the IP address of a client. As a best practice, increase the delay timer on a low-performance network.
The timer takes effect only on clients that come online after the timer is configured.
Examples
# Set the accounting delay timer to 15 seconds in service template service1. Configure the device to log off a client if it has failed to learn the client's matching IP address before the delay timer expires.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security accounting-delay time 15 no-ip-logoff
Related commands
client-security accounting-start trigger
client-security accounting-restart trigger ipv4
Use client-security accounting-restart trigger ipv4 to enable the IPv4 address-based accounting-restart trigger for clients.
Use undo client-security accounting-restart trigger ipv4 to disable the IPv4 address-based accounting-restart trigger for clients.
Syntax
client-security accounting-restart trigger ipv4 [ delay interval ]
undo client-security accounting-restart trigger ipv4
Default
The IPv4 address-based accounting-restart trigger is disabled.
Views
Service template view
Predefined user roles
network-admin
Parameters
delay interval: Sets the delay for the device to send a start-accounting request for a new accounting cycle after it sends a stop-accounting request. The value range for the interval argument is 0 to 20 seconds. The default delay time is 15 seconds.
Usage guidelines
The IPv4 address-based accounting-restart trigger applies to 802.1X and MAC authentication clients.
This trigger restarts accounting for a client by sending a stop-accounting request and then a start-accounting request to the accounting server when the IPv4 address of the client changes.
This trigger has higher priority than the accounting-update trigger configured for IPv4 by using the client-security accounting-update trigger command.
This trigger is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Enable the IPv4 address-based accounting-restart trigger in service template service1.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security accounting-restart trigger ipv4 delay 10
client-security accounting-start trigger
Use client-security accounting-start trigger to configure an accounting-start trigger for clients.
Use undo client-security accounting-start trigger to restore the default.
Syntax
client-security accounting-start trigger { ipv4 | ipv4-ipv6 | ipv6 | none }
undo client-security accounting-start trigger
Default
The accounting-start trigger is based on IPv4 address type.
Views
Service template view
Predefined user roles
network-admin
Parameters
ipv4: Specifies an IPv4-based accounting-start trigger. The device sends a start-accounting request when the device learns the IPv4 address of an authenticated client.
ipv4-ipv6: Specifies IPv4-based and IPv6-based accounting-start triggers. The device sends a start-accounting request when the device learns the IPv4 or IPv6 address of an authenticated client.
ipv6: Specifies an IPv6-based accounting-start trigger. The device sends a start-accounting request when the device learns the IPv6 address of an authenticated client.
none: Specifies a non-IP-based accounting-start trigger. The device sends a start-accounting request when a client passes authentication without examining its IP address type.
Usage guidelines
This command takes effect only on clients that have passed 802.1X or MAC authentication.
If the trigger is IP address type based, you must enable learning IP addresses of that type. For information about wireless client IP address learning, see WLAN IP snooping configuration in User Access and Authentication Configuration Guide.
When you configure an IP-based accounting-start trigger, make sure the specified IP address version is the same as the version required by the accounting server.
The trigger takes effect only on clients that come online after the trigger is configured.
Examples
# Configure an IPv4 address-based accounting-start trigger in service template service1.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security accounting-start trigger ipv4
Related commands
client ipv4-snooping arp-learning enable
client ipv4-snooping dhcp-learning enable
client ipv6-snooping dhcpv6-learning enable
client ipv6-snooping nd-learning enable
client-security accounting-delay time
client-security accounting-update trigger
client-security accounting-update trigger
Use client-security accounting-update trigger to specify an event-based accounting-update trigger.
Use undo client-security accounting-update trigger to restore the default.
Syntax
client-security accounting-update trigger { ipv4 | ipv4-ipv6 | ipv6 }
undo client-security accounting-update trigger
Default
No event-based accounting-update trigger is configured. The device sends update-accounting requests to the accounting server only regularly at server-assigned or user-defined real-time accounting intervals.
Views
Service template view
Predefined user roles
network-admin
Parameters
ipv4: Sends an update-accounting request when the IPv4 address of an online 802.1X or MAC authenticated client changes.
ipv4-ipv6: Sends an update-accounting request when the IPv4 or IPv6 address of an online 802.1X or MAC authenticated client changes.
ipv6: Sends an update-accounting request when the IPv6 address of an online 802.1X or MAC authenticated client changes.
Usage guidelines
Use the accounting-update trigger in conjunction with the IP-based accounting-start trigger. The accounting-update trigger takes effect only if the IP-based accounting-start trigger setting takes effect.
In addition to the event-based accounting-update trigger, you can set a regular accounting-update interval by using the timer realtime-accounting command.
The accounting-update trigger takes effect only on clients that come online after the trigger is configured.
Examples
# Configure an IPv4 address change-based accounting-update trigger in service template service1.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security accounting-update trigger ipv4
Related commands
client-security accounting-start trigger
timer realtime-accounting
client-security accounting dual-stack separate enable
Use client-security accounting dual-stack separate enable to enable traffic accounting for 802.1X dual-stack clients by IP protocol version.
Use undo client-security accounting dual-stack separate enable to merge IPv4 and IPv6 data for accounting of 802.1X dual-stack clients.
Syntax
client-security accounting dual-stack separate enable
undo client-security accounting dual-stack separate enable
Default
The device merges IPv4 and IPv6 data for accounting of 802.1X dual-stack clients.
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
To measure the IPv4 and IPv6 traffic of 802.1X dual-stack clients separately, use this feature. With this feature, traffic data sent to the AAA accounting server about 802.1X dual-stack clients is separate by IP protocol version.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Separate IPv4 and IPv6 data for the accounting of 802.1X dual-stack clients in service template service1.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security accounting dual-stack separate enable
client-security authentication critical-vlan
Use client-security authentication critical-vlan to configure a critical VLAN for a service template.
Use undo client-security authentication critical-vlan to restore the default.
Syntax
client-security authentication critical-vlan vlan-id
undo client-security authentication critical-vlan
Default
No critical VLAN exists for a service template.
Views
Service template view
Predefined user roles
Parameters
vlan-id: Specifies the ID of the critical VLAN, in the range of 1 to 4094.
Usage guidelines
The WLAN critical VLAN accommodates clients that have failed WLAN access authentication because all RADIUS servers in their ISP domains are unreachable. Clients in the critical VLAN can access a limited set of network resources depending on the configuration.
The authenticator reauthenticates a client in the critical VLAN at intervals of 30 seconds.
· If the client passes the reauthentication, the authenticator assigns the client to the authorization VLAN. If no authorization VLAN is configured, the client is assigned to the initial VLAN.
· If the client fails the reauthentication because all the RADIUS servers are unreachable, the client stays in the critical VLAN.
· If the client fails the reauthentication for any reason other than unreachable servers, the device assigns the client to the Auth-Fail VLAN. If no Auth-Fail VLAN is configured, the device logs off the client.
The critical VLAN feature does not take effect on clients that use RSNA. When these clients fail authentication because all the RADIUS servers are unreachable, the authenticator directly logs off the clients.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Configure VLAN 10 as the critical VLAN in service template 1.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security authentication critical-vlan 10
client-security authentication fail-vlan
Use client-security authentication fail-vlan to configure an Auth-Fail VLAN for a service template.
Use undo client-security authentication fail-vlan to restore the default.
Syntax
client-security authentication fail-vlan vlan-id
undo client-security authentication fail-vlan
Default
No Auth-Fail VLAN exists for a service template.
Views
Service template view
Predefined user roles
network-admin
Parameters
vlan-id: Specifies the ID of the Auth-Fail VLAN, in the range of 1 to 4094. Make sure the VLAN has been created.
Usage guidelines
The WLAN Auth-Fail VLAN accommodates clients that have failed WLAN access authentication because of the failure to comply with the applicable security policy. For example, the VLAN accommodates clients that have entered invalid passwords. The Auth-Fail VLAN does not accommodate WLAN clients that have failed authentication because of authentication timeouts or network connection issues.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Configure VLAN 10 as the Auth-Fail VLAN in service template 1.
[Sysname] wlan service-template 1
[Sysname-wlan-st-1] client-security authentication fail-vlan 10
client-security authentication-location
Use client-security authentication-location to specify the authenticator for WLAN clients.
Use undo client-security authentication-location to restore the default.
Syntax
client-security authentication-location { ac | ap }
undo client-security authentication-location
Default
The AC acts as the authenticator to authenticate WLAN clients.
Views
Service template view
Predefined user roles
network-admin
Parameters
ac: Specifies the AC as the authenticator.
ap: Specifies the AP as the authenticator.
Usage guidelines
You cannot specify the AP as the authenticator if the AC is configured to forward client data traffic (by using the client forwarding-location command). For information about the client forwarding-location command, see WLAN access commands in WLAN Access Command Reference.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Configure the AC as the authenticator for WLAN clients in service template s1.
[Sysname] wlan service-template s1
[Sysname-wlan-st-s1] client-security authentication-location ac
Related commands
client forwarding-location
client-security authentication-mode
Use client-security authentication-mode to set the authentication mode for WLAN clients.
Use undo client-security authentication-mode to restore the default.
Syntax
client-security authentication-mode { dot1x | mac | mac-and-dot1x }
undo client-security authentication-mode
Default
The WLAN access authentication mode is Bypass. The device does not perform authentication for WLAN clients.
Views
Service template view
Predefined user roles
network-admin
Parameters
dot1x: Performs only 802.1X authentication for the attached clients. A client cannot access the network if it fails 802.1X authentication.
mac: Performs only MAC authentication for the attached clients. A client cannot access the network if it fails MAC authentication.
mac-and-dot1x: Performs MAC authentication and then 802.1X authentication for the attached clients. The attached clients must pass both MAC authentication and 802.1X authentication before they can access the network. A client cannot access the network if it fails MAC authentication or 802.1X authentication.
Usage guidelines
A service template allows access of multiple authenticated clients in any authentication mode. To set the maximum number of 802.1X clients, use the dot1x max-user command.
The WLAN access authentication mode is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Set the authentication mode to dot1x for WLAN clients in service template service1.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security authentication-mode dot1x
client-security authorization-fail offline
Use client-security authorization-fail offline to enable the authorization-fail-offline feature.
Use undo client-security authorization-fail offline to disable the authorization-fail-offline feature.
Syntax
client-security authorization-fail offline
undo client-security authorization-fail offline
Default
The authorization-fail-offline feature is disabled.
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
The authorization-fail-offline feature logs off WLAN clients that fail ACL or user profile authorization.
A WLAN client fails ACL or user profile authorization in the following situations:
· The device or server fails to authorize the specified ACL or user profile to the client.
· The authorized ACL or user profile does not exist.
If this feature is disabled, the device generates a log message to record the authentication failure without logging off the WLAN client.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Enable the authorization-fail-offline feature for service template service1.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security authorization-fail offline
client-security authorization trigger byod
Use client-security authorization trigger byod to enable the BYOD authorization trigger.
Use undo client-security authorization trigger byod to disable the BYOD authorization trigger.
Syntax
client-security authorization trigger byod
undo client-security authorization trigger byod
Default
The BYOD authorization trigger is disabled.
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
This command enables the access device to trigger BYOD authorization for an authenticated client after the device obtains that client's BYOD information, including its IP address. When BYOD authorization is triggered, the session-timeout timer assigned to the client restarts, extending the amount of time that the client can stay online before a reauthentication is required. On a low performance network, it might take so much time for the device to obtain the IP address of a client that the client's extended amount of online time becomes undesirable.
As a best practice to avoid this undesirable issue, use this command only if BYOD authorization is required and make sure the network performance is good. For more information about BYOD authorization, see AAA configuration in User Access and Authentication Configuration Guide.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Enable the BYOD authorization trigger in service template service1.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security authorization trigger byod
client-security ignore-authentication
Use client-security ignore-authentication to configure the device to ignore 802.1X and MAC authentication failures.
Use undo client-security ignore-authentication to restore the default.
Syntax
client-security ignore-authentication
undo client-security ignore-authentication
Default
The device does not ignore authentication failures for wireless clients that use 802.1X authentication or RADIUS-based MAC authentication.
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
|
|
IMPORTANT: For 802.1X clients that use RSN to roam to a new AP, do not use this command. |
This command allows a client to come online or continue with its authentication process despite an 802.1X or MAC authentication failure.
This command applies to the following clients:
· Clients that use 802.1X authentication.
This command enables the device to ignore 802.1X authentication failures and allow clients that have failed 802.1X authentication to come online.
· Clients that use both RADIUS-based MAC authentication and portal authentication.
Typically, a client must pass MAC authentication and portal authentication in turn to access network resources. The client provides username and password when it performs portal authentication.
This command simplifies the authentication process for such a client, as follows:
¡ If the RADIUS server already records the client's MAC authentication information, the client passes MAC authentication. The device allows the client to access network resources without performing portal authentication.
¡ If the RADIUS server does not record the client's MAC authentication information, the client fails MAC authentication. The device ignores the MAC authentication failure and performs portal authentication for the client. If the client passes portal authentication, it can access network resources. The MAC address of the portal authenticated client will be recorded as MAC authentication information on the RADIUS server.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Configure the device to ignore 802.1X and MAC authentication failures in service template service1.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security ignore-authentication
client-security ignore-authorization
Use client-security ignore-authorization to configure the device to ignore the authorization information received from the authentication server (a RADIUS server or the local device).
Use undo client-security ignore-authorization to restore the default.
Syntax
client-security ignore-authorization
undo client-security ignore-authorization
Default
The device uses the authorization information from the server.
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
After a client passes RADIUS or local authentication, the server performs authorization based on the authorization attributes configured for the user account. For example, the server might assign a VLAN to the client. If you do not want to apply server-assigned authorization attributes to clients, configure the device to ignore the authorization information from the server.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
Examples
# Configure the device to ignore the authorization information from the authentication server for service template service1.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] client-security ignore-authorization
dot1x domain
Use dot1x domain to specify an authentication domain for 802.1X clients in a service template.
Use undo dot1x domain to restore the default.
Syntax
dot1x domain domain-name
Default
No authentication domain is specified for 802.1X clients in a service template.
Views
Service template view
Predefined user roles
network-admin
Parameters
domain-name: Specifies an ISP domain by its name, a case-insensitive string of 1 to 255 characters.
Usage guidelines
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
802.1X chooses an authentication domain for WLAN clients in the following order:
1. The authentication domain specified by using this command in service template view.
2. The domain included in the username.
3. The default authentication domain specified by using the domain default enable command.
Examples
# Specify ISP domain my-domain as the authentication domain for 802.1X clients in service template service1.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] dot1x domain my-domain
dot1x eap
Use dot1x eap to specify the EAP mode for 802.1X authentication.
Use undo dot1x eap to restore the default.
Syntax
dot1x eap { extended | standard }
undo dot1x eap
Default
The EAP mode is standard for 802.1X authentication.
Views
Service template view
Predefined user roles
network-admin
Parameters
extended: Specifies the extended EAP mode. This mode requires the device to interact with clients according to the provisions and packet format defined by the proprietary EAP protocol.
standard: Specifies the standard EAP mode. This mode requires the device to interact with clients according to the provisions and packet format defined by the standard EAP protocol.
Usage guidelines
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
When you use this command, specify the extended keyword for iNode clients and the standard keyword for other clients.
This command is required only when an IMC server is used as the RADIUS server.
Examples
# Set the EAP mode to extended for service template 1.
<Sysname> system-view
[Sysname] wlan service-template 1
[Sysname-wlan-st-1] dot1x eap extended
dot1x eap-termination authentication-method
Use dot1x eap-termination authentication-method to enable EAP termination in a service template and specify the authentication method between the device and the authentication server.
Use undo dot1x eap-termination authentication-method to restore the default.
Syntax
dot1x eap-termination authentication-method { chap | pap }
undo dot1x eap-termination authentication-method
Default
CHAP is used.
Views
Service template view
Predefined user roles
network-admin
Parameters
chap: Specifies the CHAP authentication method.
pap: Specifies the PAP authentication method.
Usage guidelines
A client will fail authentication in EAP relay mode if the authentication server does not support the authentication method used by the client. To avoid authentication failure, use this command to enable EAP termination in the service template for that client and specify an authentication method for the device to communicate with the authentication server.
Use this command in a service template if that service template has clients that use the PEAP-GTC authentication method. With this feature, the device performs EAP termination for all clients in the service template.
Examples
# Enable EAP termination in service template service1 and specify PAP as the authentication method between the device and the authentication server.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] dot1x eap-termination authentication-method pap
dot1x eap-termination eap-profile
Use dot1x eap-termination eap-profile to specify an EAP profile for 802.1X EAP termination.
Use undo dot1x eap-termination eap-profile to restore the default.
Syntax
dot1x eap-termination eap-profile eap-profile-name
undo dot1x eap-termination eap-profile
Default
No EAP profile is specified for EAP termination.
Views
Service template view
Predefined user roles
network-admin
Parameters
eap-profile-name: Specifies an EAP profile by its name, a case-insensitive string of 1 to 32 characters. The EAP profile must already exist.
Usage guidelines
A client will fail authentication in EAP relay mode if the RADIUS server does not support the authentication method used by the client. To avoid authentication failure, use this command to enable the device to terminate the EAP packets received from the client and encapsulate the client authentication information in standard RADIUS packets.
Set the EAP authentication method to PEAP-GTC in the specified EAP profile.
As a best practice, use this command in a service template only if all clients of that service template use the PEAP-GTC authentication method. Clients that use other authentication method in the service template will fail authentication.
Examples
# Specify EAP profile gtcprofile for EAP termination in service template srvtmp1.
<Sysname> system-view
[Sysname] wlan service-template srvtmp1
[Sysname-wlan-st-srvtmp1] dot1x eap-termination eap-profile gtcprofile
Related commands
eap-profile
method
ssl-server-policy (Security Command Reference)
dot1x handshake enable
Use dot1x handshake enable to enable the 802.1X online user handshake feature.
Use undo dot1x handshake enable to disable the 802.1X online user handshake feature.
Syntax
Default
The 802.1X online user handshake feature is disabled.
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
The online user handshake feature examines the connection status of an online 802.1X client by sending unicast EAP-Request/Identity message to that client at intervals. The device sets a client to the offline state if it does not receive a response from that client after it has made the maximum number of handshake attempts. To set the handshake interval (handshake timer), use the dot1x timer handshake-period command. To set the maximum handshake attempts, use the dot1x retry command.
The device does not respond to a client after it receives handshake responses from that client. Some clients might initiate reauthentication or go offline if they do not receive the device's responses to their handshake responses. If your network has such clients, disable the online user handshake feature as needed.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
The online user handshake feature might cause some wireless clients to go offline. If such wireless clients exist, disable this feature as a best practice.
Examples
# Enable the online user handshake feature for 802.1X clients in service template service1.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] dot1x handshake enable
Related commands
dot1x handshake secure enable
dot1x retry
dot1x timer handshake-period
dot1x handshake secure enable
Use dot1x handshake secure enable to enable the 802.1X online user handshake security feature.
Use undo dot1x handshake secure enable to disable the 802.1X online user handshake security feature.
Syntax
undo dot1x handshake secure enable
Default
The 802.1X online user handshake security feature is disabled.
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
For the 802.1X online user handshake security feature to take effect, you must enable the 802.1X online user handshake feature.
The online user handshake security feature protects only authenticated online 802.1X clients.
Examples
# Enable the 802.1X online user handshake security feature in service template service1.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] dot1x handshake enable
[Sysname-wlan-st-service1] dot1x handshake secure enable
Related commands
dot1x max-user
Use dot1x max-user to set the maximum number of concurrent 802.1X clients that a service template supports on a radio.
Use undo dot1x max-user to restore the default.
Syntax
dot1x max-user count
Default
A service template permits a maximum of 512 concurrent 802.1X clients to access the network on a radio.
Views
Service template view
Predefined user roles
network-admin
Parameters
count: Specifies the maximum number of concurrent 802.1X clients. The value range is 1 to 512.
Usage guidelines
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
This setting takes effect on a per-radio basis. If the number of 802.1X clients of the service template reaches the limit on a radio, no additional 802.1X clients can access the network through the service template on that radio.
Examples
# In service template service1, set the maximum number of concurrent 802.1X clients on a radio to 32.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] dot1x max-user 500
dot1x re-authenticate enable
Use dot1x re-authenticate enable to enable the 802.1X periodic online user reauthentication feature.
Use undo dot1x re-authenticate enable to disable the 802.1X periodic online user reauthentication feature.
Syntax
undo dot1x re-authenticate enable
Default
The 802.1X periodic online user reauthentication feature is disabled.
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
Periodic reauthentication enables the device to periodically authenticate online 802.1X clients in a service template. This feature checks the connection status of online clients and updates the authorization attributes assigned by the server, such as the ACL, VLAN, and user profile.
To configure the interval for reauthentication, use the dot1x timer reauth-period command.
If the server assigns session timeout timer (Session-Timeout attribute) and termination action (Termination-Action attribute) settings to a client, the server-assigned settings might take effect on the client. To identify settings for the server-assigned Session-Timeout and Termination-Action attributes, execute the display dot1x connection command.
· If the termination action is Default (logoff), periodic online user reauthentication on the template takes effect only when the periodic reauthentication timer is shorter than the server-assigned session timeout timer.
· If the termination action is Radius-request, the periodic online user reauthentication configuration on the template does not take effect. The device reauthenticates the online 802.1X client when the server-assigned session timeout timer expires.
If no session timeout timer is assigned by the server, whether the device performs periodic 802.1X reauthentication depends on the periodic reauthentication configuration on the device.
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
The periodic reauthentication feature might cause some wireless clients to go offline. If such wireless clients exist, disable this feature as a best practice.
Examples
# Enable the 802.1X periodic online user reauthentication feature in service template service1.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] dot1x re-authenticate enable
Related commands
fail-permit enable
Use fail-permit enable to enable authentication fail-permit.
Use undo fail-permit enable to disable authentication fail-permit.
Syntax
fail-permit enable [ keep-online | url-user-logoff ]
undo fail-permit enable
Default
Authentication fail-permit is disabled.
Views
Service template view
Predefined user roles
network-admin
Parameters
keep-online: Allows online fail-permit users to stay online when an authentication fail-permit event occurs. If you do not specify this keyword, the device disconnects online fail-permit users when an authentication fail-permit event occurs.
url-user-logoff: Enables the URL user logoff mechanism. This mechanism logs off MAC authentication users if an authentication fail-permit event occurs after they have been assigned a redirect URL. This keyword is applicable only to MAC authentication users.
Usage guidelines
Authentication fail-permit (also called fail-open) allows 802.1X, MAC authentication, and Bypass clients to access the network after the AC disconnects from the RADIUS server or the AP. When either event occurs, the AP continues to provide access services and forward traffic for those clients.
The impact of an authentication fail-permit event on clients differs depending on their authentication method and depending on whether a fail-permit service template has been configured.
· Bypass clients:
¡ If a fail-permit service template has been configured, the Bypass clients will be logged off. To access the network, the Bypass clients must manually reconnect to the SSID in the preconfigured fail-permit service template.
¡ If no fail-permit service template has been configured, the Bypass clients can continue to access the network with the existing service template without interruption.
· MAC authentication clients:
¡ If a fail-permit service template has been configured, the MAC authentication clients will be logged off. To access the network, the MAC authentication clients must manually reconnect to the SSID in the preconfigured fail-permit service template.
¡ If no fail-permit service template has been configured, the MAC authentication clients can continue to access the network with the existing service template after a transient interruption. In this situation, the clients will be logged off and then automatically connected to the network.
· The 802.1X clients will be logged off. To access the network, the 802.1X clients must manually reconnect to the SSID in a preconfigured fail-permit service template.
When you configure authentication fail-permit for clients, follow these restrictions and guidelines:
· Enable authentication fail-permit in the service template to be protected.
· Configure another service template as the fail-permit service template to be used when authentication fail-permit occurs.
For authentication fail-permit to take effect, perform the following steps:
1. Execute the radius-server test-profile command to configure a RADIUS test profile to test the reachability of the RADIUS server.
In the profile, set the interval for sending detection packets as needed. The shorter the interval is, the quicker the response to the change will be.
2. Apply the profile to the RADIUS server in the RADIUS scheme for the authentication ISP domain.
Fail-permit will occur when the RADIUS server is determined to be unreachable.
For more information about configuring RADIUS test profiles, see AAA configuration in User Access and Authentication Configuration Guide.
As a best practice, enable the URL user logoff mechanism if the RADIUS server on the network (for example, an AD-Campus network) redirects MAC authentication users to the Web server at a URL to do authentication. MAC authentication users might be stuck in the authentication phase if a fail-permit event occurs and then the RADIUS server becomes unreachable after they have been assigned a redirect URL. The URL user logoff mechanism enables the device to log off such MAC authentication users when a fail-permit event occurs, so they can be reauthenticated to access critical service resources.
The fail-permit enable command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
The fail-permit enable command is mutually exclusive with the fail-permit template command in the same service template.
If you do not specify any parameters, the device disconnects online fail-permit users when an authentication fail-permit event occurs.
Examples
# Enable authentication fail-permit in a WLAN service template.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] fail-permit enable
Related commands
client url-redirect enable
fail-permit template
fail-permit template
Use fail-permit template to specify a service template as a fail-permit service template.
Use undo fail-permit template to remove the fail-permit attribute of a fail-permit service template.
Syntax
fail-permit template
undo fail-permit template
Default
No service templates are specified as fail-permit service templates.
Views
Service template view
Predefined user roles
network-admin
Usage guidelines
You can use this command for the following purposes:
· Authentication fail-permit—To use the authentication fail-permit feature for clients associated with one service template, specify another service template as a fail-permit service template. If the protected service template has 802.1X clients, you must specify a fail-permit service template. This requirement is optional for other types of authentication clients. For more information about the authentication fail-permit feature, see the usage guidelines for the fail-permit enable command.
· 5G radio silence fail-permit—Allows an AP to move the clients of a service template on a 5G radio to a different 5G radio for network access when radio silence is imposed on the former radio.
You can execute the fail-permit template command only when the service template is disabled, and it takes effect after the service template is enabled.
The fail-permit template command is mutually exclusive with the fail-permit enable command in the same service template.
To ensure a successful fail-permit, follow these restrictions and guidelines:
· Enable APs to forward client data traffic in the fail-permit service template by using the client forwarding-location command.
· If APs are configured as the authenticator in a service template by using the client-security authentication-location command, the authenticator in the fail-permit service template of this service template must also be APs.
Use the following guidelines when you configure an authentication fail-permit service template:
· As a best practice, configure only one fail-permit service template for clients on an AP. If you configure multiple fail-permit service templates, only the one that is first bound to a radio on the AP will take effect.
· To ensure a successful fail-permit for clients, set the AKM mode to PSK or do not specify any AKM mode in the fail-permit service template.
Use the following guidelines when you configure a 5G silence fail-permit service template for 5G clients:
· Specify one 5G silence fail-permit service template for each 5G service template on a 5G radio. These 5G silence fail-permit service templates must contain the same settings as their protected 5G service templates except that the protected 5G service templates cannot contain the fail-permit template command.
· Bind a 5G silence fail-permit service template to a different radio than its protected 5G service template on the same AP.
Examples
# Specify a service template as a fail-permit service template.
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] fail-permit template
Related commands
akm mode (WLAN Security Command Reference)
fail-permit enable
mac-authentication domain
Use mac-authentication domain to specify an authentication domain for MAC authentication clients in a service template.
Use undo mac-authentication domain to restore the default.
Syntax
mac-authentication domain domain-name
undo mac-authentication domain
Default
No authentication domain is specified for MAC authentication clients in a service template.
Views
Service template view
Predefined user roles
network-admin
Parameters
domain-name: Specifies an ISP domain by its name, a case-insensitive string of 1 to 255 characters.
Usage guidelines
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
MAC authentication chooses an authentication domain for WLAN clients in the following order:
1. The authentication domain specified by using the mac-authentication domain command in service template view.
2. The global authentication domain specified by using the mac-authentication domain command in system view.
3. The default authentication domain specified by using the domain default enable command.
Examples
# Specify ISP domain my-domain as the authentication domain for MAC authentication clients in service template service1.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] mac-authentication domain my-domain
mac-authentication max-user
Use mac-authentication max-user to set the maximum number of concurrent MAC authentication clients that a service template supports on a radio.
Use undo mac-authentication max-user to restore the default.
Syntax
mac-authentication max-user count
undo mac-authentication max-user
Default
A service template permits a maximum of 4096 concurrent MAC authentication clients to access the network on a radio.
Views
Service template view
Predefined user roles
network-admin
Parameters
count: Specifies the maximum number of concurrent MAC authentication clients. The value range for this argument is 1 to 4096.
Usage guidelines
This command is configurable when the service template is disabled, and it takes effect after the service template is enabled.
This command takes effect on a per-radio basis. If the number of MAC authentication clients of a service template reaches the limit on a radio, no additional MAC authentication clients can access the network through the service template on that radio.
Examples
# Configure service template service1 to support a maximum of 32 concurrent MAC authentication clients on a radio.
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] mac-authentication max-user 32
wlan authentication optimization
Use wlan authentication optimization to configure a modifier to adjust the authentication success ratio and abnormal offline ratio for 802.1X authentication, MAC authentication, and Layer 2 portal authentication.
Use undo wlan authentication optimization to restore the default.
Syntax
wlan authentication optimization value
undo wlan authentication optimization
Default
The modifier is 0. The device does not adjust the authentication success ratio and abnormal offline ratio for 802.1X authentication, MAC authentication, and Layer 2 portal authentication.
Views
System view
Predefined user roles
network-admin
Parameters
value: Sets the modifier, in the range of 900 to 1000. The lower the value, the lower the authentication success ratio, and the higher the abnormal offline ratio.
Usage guidelines
The authentication success ratio is the ratio of authentication successes to the total number of authentications. The abnormal offline ratio is calculated by using the following formula:
Abnormal offline ratio = number of abnormal offline events/(number of online client authentication successes + number of current online users)
WLAN access authentication statistics optimization uses a modifier to adjust the authentication success ratio and abnormal offline ratio of 802.1X authentication, MAC authentication, and Layer 2 portal authentication.
The modifier takes effect only on RADIUS-based 802.1X authentication, MAC authentication, and Layer 2 portal authentication.
Examples
# Set the modifier to 950 to adjust the authentication success ratio and abnormal offline ratio of 802.1X authentication, MAC authentication, and Layer 2 portal authentication.
<Sysname> system-view
[Sysname] wlan authentication optimization 950
wlan client-security authentication clear-previous-connection
Use wlan client-security authentication clear-previous-connection to enable the clear-previous-connection feature for WLAN authentication.
Use undo wlan client-security authentication clear-previous-connection to disable the clear-previous-connection feature for WLAN authentication.
Syntax
wlan client-security authentication clear-previous-connection
undo wlan client-security authentication clear-previous-connection
Default
The clear-previous-connection feature is disabled for WLAN authentication.
Views
System view
Predefined user roles
network-admin
Usage guidelines
|
|
IMPORTANT: When this feature is enabled, the 802.1X reauthentication, WLAN Auth-Fail VLAN, and WLAN critical VLAN features cannot take effect. |
Some RADIUS servers reject to authenticate a client if they have an online user entry for that client. If they fail to remove the online user entry for a client that has gone offline incorrectly, that client will be unable to get authenticated and come online again.
To resolve this issue, use the clear-previous-connection feature.
With this feature, the device checks the local online user entries before it sends an authentication request to the RADIUS server for an 802.1X or MAC authentication client. If an entry is found, the device removes the entry and sends a stop-accounting request to the RADIUS server. Upon receipt of the stop-accounting request, the RADIUS server removes the online user entry. Then, the client can be authenticated correctly.
Examples
# Enable the clear-previous-connection feature.
<Sysname> system-view
[Sysname] wlan client-security authentication clear-previous-connection
