Using
Using multiple RADIUS server groups
The authentication and accounting features on the switch can use up to fifteen RADIUS servers and these servers can be put into groups. Up to 5 groups of 3 RADIUS servers each can be configured. The authentication and accounting features can choose which RADIUS server group to communicate with. End-user authentication methods (802.1X, MAC-based and web-based) can authenticate with different RADIUS servers from the management interface authentication methods (console, telnet, ssh, web).
NOTE: If there are more than 3 RADIUS hosts defined in the list of 15 and one of the first 3 is deleted, then the 4th RADIUS host in the list of 15 becomes the 3rd host in the default group "radius". | |
Several commands are used to support the RADIUS server group option. The RADIUS server must be configured before it can be added to a group. See Configuring the switch for RADIUS authentication for more information.
Setting accounting type, and how data is sent
Syntax
aaa accounting <exec | network | system | commands | <start-stop | stop-only> radius [server-group<group-name>
]Configures accounting type and sets how data is sent to the RADIUS server.
radius
Uses RADIUS protocol as accounting method.
server-group <group-name>
Specifies the server group to use with RADIUS.
Allowing reauthentication when RADIUS server is unavailable
Syntax
[no] aaa authentication <port-access | web-based | mac-based> <primary method> <secondary-method>Allows reauthentications to succeed when the RADIUS server is unavailable. Users already authenticated retain their currently-assigned session attributes.
The primary methods for
port-access
authentication arelocal
,chap-radius
, oreap-radius
. The primary method forweb-based
ormac-based
authentication ischap-radius
.The secondary methods can be
none
,authorized
, orcached-reauth
.Default secondary authentication for all types of port access: none.
Setting the time period to allow cached reauthentication
Syntax
Enabling authorization to control access to CLI commands
To control access to the CLI commands, enter this command at the CLI.
Syntax
[no] aaa authorization [<commands> <radius> <none>]Configures authorization for controlling access to CLI commands. When enabled, the switch checks the list of commands supplied by the RADIUS server during user authentication to determine if a command entered by the user can be executed.
radius
The NAS requests authorization information from the RADIUS server. Authorization rights are assigned by user or group.
none
The NAS does not request authorization information.
To enable the RADIUS protocol as the authorization method:
switch(config)# aaa authorization commands radius
When the NAS sends the RADIUS server a valid user name and password, the RADIUS server sends an Access-Accept packet that contains two attributes the command list and the command exception flag. When an authenticated user enters a command on the switch, the switch examines the list of commands delivered in the RADIUS Access-Accept packet as well as the command exception flag, which indicates whether the user has permission to execute the commands in the list. See Configuring commands authorization on a RADIUS server.
After the Access-Accept packet is delivered, the command list resides on the switch. Any changes to the user's command list on the RADIUS server are not seen until the user is authenticated again.
Creating Local Privilege Levels
This feature allows more granular localized control over user access when accessing the switch through the console or by telnet or SSH. Instead of allowing access to all commands with the “manager” command, or very restricted access with the “operator” command, the local access can be customized to allow the commands that the local account is authorized to execute. The new local accounts are in addition to and independent of the existing manager and operator accounts, with the exception that if a user name is set for a manager or operator account, that name cannot be the same as any of the local user account names.
To do this, groups are created that contain up to 16 user accounts. The group has a list of match commands that determine if that user is authorized to execute that command. Up to 100 local user accounts are supported. The local user accounts are stored in the configuration as an SHA1 hash, which is only displayed if “include-credentials” is enabled. A password is required for the local user accounts, but nothing else.
There is one default group—operator. Users assigned to the operator group have only operator privileges.
Applying the authorization group to a local user account only occurs if the user logs in using local as the primary authentication method and the aaa authorization commands local command has been executed. Authorization groups are not supported when the login method is set as secondary local authentication.
These commands are authorized at all access levels:
exit
logout
page
redo
repeat
end
Configuring Groups for Local Authorization
You must create a group for local authorization before you can assign local users to it. When creating the group, at least one command is created as part of that group. Typically, multiple commands are assigned to a group.
NOTE: You must enable local authorization by executing | |
To create a group, enter this command.
Syntax
[no] aaa authorization group<group-name>
<1-2147483647> match-command<command-string>
<permit|deny> [log]Create a local authorization group with the specified name. The name is case-sensitive and may not contain spaces. Duplicate names are not allowed. You can create a maximum of 16 groups. The name of the group can have a maximum of 16 characters.
<1-2147483647>
The evaluation order for the match commands.
match-command
<command-string>
The
<command-string>
is the CLI command. It must be surrounded in double quotes of it contains any spaces, for example,“vlan*”
.The
is a POSIX regular expression and follows POSIX matching rules. For example, the “*” character means match the preceding character zero or more times, so ab*c will match “ac”, “abc”, “abbc”, etc. The “.” character means match any character, so “.*” would match anything, while the command string “aaa.*” would match commands that have “aaa” followed by zero or more characters. The “^” character means match to the beginning of the string, so “^aaa.*” would mean the string must start with “aaa” and can have anything after that.
<command-string>
<permit|deny>
Either permit or deny execution of the command.
[log]
Optional. Indicates the matching of such commands generates an event log entry for either permitted or denied.
Typically multiple commands are assigned to a group. Each command is entered on a separate line. Commands are evaluated in numerical order of the sequence number until a match is found, then the permit or deny action for that command is executed.
NOTE: Commands are expanded before the comparison is
done, for example, | |
When a command must be preceded by the execution
of another command, then both commands need to be permitted for the
command authorization group. For example, you must execute the configure
command
before you can enter the vlan
context, so both
commands must be permitted.
Some commands cause the switch CLI to enter a special context, such as test mode, and the input is not processed by the normal CLI. Keyboard input is not checked against the command authorization group. If these special contexts are permitted, the user can proceed outside the control and logging of the command group configuration.
Configuring a local user for a group
Local manager user logins and authorized command configuration are mutually exclusive with RADIUS or TACACS authentication and with RADIUS authorization and accounting.
To create a local user enter this command for the group with the appropriate authorizations.
Syntax
[no] aaa authentication local-user<username>
group<group-name>
password <plaintext|sha1 <password>Defines a local user for a defined group.
local-user
username
The local user being added to the authorization group. The user name can have a maximum of 16 characters. It must not contain spaces and is case-sensitive.
group
group-name
The authorization group the local user belongs to. The group must have been created already.
password<plaintext|sha1
password
The plaintext password string can have a maximum of 16 characters. It must not contain spaces and is case-sensitive.
NOTE: You are not allowed to actually enter the plaintext password in-line as part of the command. You are prompted for it. The password is obscured when you enter it. The password is obscured when you enter it. This is similar to entering the password for the manager or operator.
If include-credentials is enabled, displaying the configuration shows the user passwords as SHA1 hash. If include-credentials is not enabled, then no password information is shown.
If a user is assigned to a command group and the group is subsequently deleted, the user has operator privileges.
Changing RADIUS-server access order
The switch tries to access RADIUS servers according
to the order in which their IP addresses are listed by the show
radius
command.
NOTE: When you add a new server IP address, it is placed in the highest empty position in the list. | |
Adding or deleting a RADIUS server IP address leaves an empty position, but does not change the position of any other server addresses in the list. For example if you initially configure three server addresses, they are listed in the order in which you entered them. However, if you subsequently remove the second server address in the list and add a new server address, the new address is placed second in the list.
Thus, to move a server address up in the list, you must delete it from the list, ensure that the position to which you want to move it is vacant, and then re-enter it. For example, suppose you have already configured the following three RADIUS server IP addresses in the switch:
To exchange the positions of the addresses so that the server at 10.10.10.3 is the first choice and the server at 10.10.10.1 is the last, perform the following:
Delete 10.10.10.3 from the list. This opens the third (lowest) position in the list.
Delete 10.10.10.1 from the list. This opens the first (highest) position in the list.
Re-enter 10.10.10.3. Because the switch places a newly entered address in the highest-available position, this address becomes first in the list.
Re-enter 10.10.10.1. Because the only position open is the third position, this address becomes last in the list.
Using SNMP to view and configure switch authentication features
Beginning with software release K.12.xx, SNMP MIB object access is available for switch authentication configuration (hpSwitchAuth) features. This means that the switches covered by this guide allow, by default, manager-only SNMP read/write access to a subset of the authentication MIB objects for the following features:
number of primary and secondary login and enable attempts
TACACS+ server configuration and status
RADIUS server configuration
selected 802.1X settings
key management subsystem chain configuration
key management subsystem key configuration
OSPF interface authentication configuration
local switch operator and manager user names and passwords
With SNMP access to the hpSwitchAuth MIB enabled, a device with management access to the switch can view the configuration for the authentication features listed above (excluding user names, passwords, and keys). Using SNMP sets, a management device can change the authentication configuration (including changes to user names, passwords and keys). Operator read/write access to the authentication MIB is always denied.
NOTE: All user names, passwords, and keys configured in the hpSwitchAuth MIB are not returned via SNMP, and the response to SNMP queries for such information is a null string. However, SNMP sets can be used to configure user name, password, and key MIB objects. To help prevent unauthorized access to the switch authentication MIB, Hewlett Packard Enterprise recommends following the reviewing Viewing and changing the SNMP access configuration. If you do not want to use SNMP access to the switch authentication configuration MIB, then use the snmp-server mib hpswitchauthmib excluded command to disable this access, as described in the next section. If you choose to leave SNMP access to the security MIB open (the default setting), Hewlett Packard Enterprise recommends that you configure the switch with the SNMP version 3 management and access security feature, and disable SNMP version 2c access. See “SNMP access to the authentication configuration MIB.” | |
Cached reauthentication
Cached reauthentication allows 802.1X, web-based, or MAC reauthentications to succeed when the RADIUS server is unavailable. Users already authenticated retain their currently-assigned RADIUS attributes. Uninterrupted service is provided for authenticated users with RADIUS-assigned VLANs if the RADIUS server becomes temporarily unavailable during periodic reauthentications.
Cached reauthentication is similar to the authorized authentication method in that user credentials are not checked. Any user credentials are valid even if they are different from those used during the last successful authentication of the same session. However, cached reauthentication maintains the current session attributes, unlike the authorized authentication method. New authentications are not allowed. The RADIUS server can be the only allowed source of session attributes for authenticated users.
Reauthentications are not disabled when the RADIUS server is unavailable. The switch initiates reauthentications of clients at the specified period and the clients must comply with the requirements for the reauthentication procedure exactly as is done for the authorized authentication method.
The table below summarizes the differences between the authorized method and the cached reauthentication method.
Authorized method and cashed reauthentication method
Authorized | Cached reauthentication |
---|---|
New authentications are allowed when RADIUS server is unreachable. | New authentications are not allowed when RADIUS server is unreachable. |
All previously RADIUS-assigned attributes are voided and replaced by switch-configured values on reauthentication when RADIUS server is unreachable. | All previously assigned attributes remain in effect on reauthentication when RADIUS server is unreachable. |
Cached reauthentication is supported for 802.1X, web-based authentication, and MAC authentication. For more information about web-based/MAC authentication, see Configuring MAC authentication on the switch. For more information on 802.1X, see Port-Based and User-Based Access Control (802.1X).
Timing considerations
The reauth period when the RADIUS server is unavailable is the configured reauth period plus an additional X seconds, where X can vary from 1 to approximately 30 seconds in most cases, depending on the number of RADIUS servers and other RADIUS parameters. This period of time can be more or less than 30 seconds if the default "server-timeout" values for 802.1X or web-based/MAC authentication have been changed from their default values. The period of time represented by X is how long 802.1X or web-based /MAC authentication waits for a RADIUS response.
Example
A cached-reauth-period is set to 900 seconds (15 minutes) and the reauth period is 180 seconds.
A client is successfully authenticated or reauthenticated.
The RADIUS server becomes unavailable. In 180 seconds from the authentication in step 1, 802.1X or web-based/MAC authentication initiates reauthentication.
In X seconds after the initiation of authentication in step 3 (1 to 30 seconds if default values for 802.1X or web-based/MAC authentication are used), 802.1X or web-based/MAC authentication receives notification that the RADIUS server is unavailable.
802.1X or web-based/MAC authentication allows the first cached reauthentication and starts the cached reauth period.
A number of cached reauthentications occur within the 900 seconds after the start of the cached reauth period in step 5. These have a period of 180 + X seconds.
The cached reauthentication period (900 seconds) ends.
The next reauthentication begins 180 seconds after the last cached reauthentication.
In X seconds after the reauthentication in step 8, 802.1X or web-based/MAC authentication receives notification that the RADIUS server is still unavailable.
802.1X or web-based/MAC authentication terminates the client's session.
Determining the maximum amount of time before client session termination
The maximum amount of time between step 2 and step 3 is 180 seconds.
The amount of time between step 3 and step 5 is X seconds.
The reauthentication in step 8 happens less than 180 seconds after step 7, and step 7 happens in 900 seconds after step 5. The maximum amount of time between step 5 and step 8 is 900 + 180 seconds.
The time between step 8 and step 9 is X seconds.
The total time is 180 + X + 900 + 180 + X, which equals 900 +2(180+X) seconds.
NOTE: The period of 1 to 30 seconds, represented by X, is not a firm time period; the time can vary depending on other 802.1X and web-based/MAC auth parameters. | |
Local authentication process
When the switch is configured to use RADIUS, it reverts to local authentication only if one of these two conditions exists:
Local
is the authentication option for the access method being used.The switch has been configured to query one or more RADIUS servers for a primary authentication request, but has not received a response, and
Local
is the configured secondary option.
For local authentication, the switch uses the operator-level and manager-level user name/password sets previously configured locally on the switch. These are the user names and passwords you configure using the CLI password command, the WebAgent, or the menu interface which enables only local password configuration.
If the operator at the requesting terminal correctly enters the user name/password pair for either access level (operator or manager), access is granted on the basis of which user name/password pair was used. For example, suppose you configure Telnet primary access for RADIUS and Telnet secondary access for local. If a RADIUS access attempt fails, then you can still get access to either the operator or manager level of the switch by entering the correct user name/password pair for the level you want to enter.
If the user name/password pair entered at the requesting terminal does not match either local user name/password pair previously configured in the switch, access is denied. In this case, the terminal is again prompted to enter a user name/password pair. In the default configuration, the switch allows up to three attempts. If the requesting terminal exhausts the attempt limit without a successful authentication, the login session is terminated and the operator at the requesting terminal must initiate a new session before trying again.
Controlling WebAgent access
To help prevent unauthorized access through the WebAgent, do one or more of the following:
Configure the switch to support RADIUS authentication for WebAgent access.
Configure local authentication (a manager user name and password and, optionally, an operator user name and password) on the switch.
Configure the switch’s Authorized IP manager feature to allow WebAgent access only from authorized management stations. (The Authorized IP manager feature does not interfere with TACACS+ operation.)
Use one of the following methods to disable WebAgent access to the switch via http (Port 80):
CLI: no web-management
Commands authorization
The RADIUS protocol combines user authentication and authorization steps into one phase. The user must be successfully authenticated before the RADIUS server sends authorization information from the user's profile to the Network Access Server (NAS). After user authentication has occurred, the authorization information provided by the RADIUS server is stored on the NAS for the duration of the user's session. Changes in the user's authorization profile during this time is not effective until after the next authentication occurs.
You can limit the services for a user by enabling AAA RADIUS authorization. The NAS uses the information set up on the RADIUS server to control the user's access to CLI commands.
The authorization type implemented on the switches is the "commands" method. This method explicitly specifies on the RADIUS server which commands are allowed on the client device for authenticated users. This is done on a per-user or per-group basis.
By default, all users may execute a minimal set of commands regardless of their authorization status, for example, "exit" and "logout". This minimal set of commands can prevent deadlock on the switch due to an error in the user's authorization profile on the RADIUS server.
VLAN assignment in an authentication session
A switch supports concurrent 802.1X and either web-based or MAC authentication sessions on a port (with up to 32 clients allowed). If you have configured RADIUS as the primary authentication method for a type of access, when a client authenticates on a port, the RADIUS server assigns an untagged VLAN that is statically configured on the switch for use in the authentication session. See the documentation provided with the RADIUS server application.)
If a switch port is configured to accept multiple 802.1X and/or web-based or MAC authentication client sessions, all authenticated clients must use the same port-based, untagged VLAN membership assigned for the earliest, currently active client session. On a port where one or more authenticated client sessions are already running, all clients are on the same untagged VLAN. If the RADIUS server subsequently authenticates a new client, but attempts to re-assign the port to a different, untagged VLAN than the one already in use for the previously existing, authenticated client sessions, the connection for the new client fails.
Tagged and untagged VLAN attributes
When you configure a user profile on a RADIUS
server to assign a VLAN to an authenticated client, you can use either
the VLAN's name or VLAN ID (VID) number. For example, if a VLAN configured
in the switch has a VID of 100 and is named vlan100
,
you could configure the RADIUS server to use either "100"
or "vlan100" to specify the VLAN.
After the RADIUS server validates a client's user name and password, the RADIUS server returns an Access-Accept packet that contains the VLAN assignment and the following attributes for use in the authentication session:
Egress-VLANID: Configures an optional, egress VLAN ID for either tagged or untagged packets (RFC 4675).
Egress-VLAN-Name: Configures an optional, egress VLAN for either tagged or untagged packets when the VLAN ID is not known (RFC 4675).
Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Private-Group-ID: Tunnel attributes that specify an untagged VLAN assignment (RFC 3580).
Tunnel (untagged VLAN) attributes may be included in the same RADIUS packet as the Egress-VLANID and Egress-VLAN-Name attributes. These attributes are not mutually exclusive.
The switch processes the VLAN information returned from the remote RADIUS server for each successfully 802.1X-, web-based, and MAC authenticated client (user). The VLAN information is part of the user's profile stored in the RADIUS server's database and is applied if the VLANs exist on the switch.
The support for RADIUS-assigned tagged and untagged VLAN configuration on an authenticated port allows you to use IDM to dynamically configure tagged and untagged VLANs as required for different client devices, such as PCs and IP phones, that share the same switch port.
Additional RADIUS attributes
The following attributes are included in Access-Request and Access-Accounting packets sent from the switch to the RADIUS server to advertise switch capabilities, report information on authentication sessions, and dynamically reconfigure authentication parameters:
MS-RAS-Vendor (RFC 2548)
Allows switches to inform a Microsoft RADIUS server that the switches are from Networking. This feature assists the RADIUS server in its network configuration.
HP-capability-advert
An proprietary RADIUS attribute that allows a switch to advertise its current capabilities to the RADIUS server for port-based (MAC, Web, or 802.1X) authentication; for example, VSAs for port QoS, ingress rate-limiting, IDM filter rules, RFC 4675 QoS and VLAN attributes, and RFC 3580 VLAN-related attributes.
The RADIUS server uses this information to make a more intelligent policy decision on the configuration settings to return to the switch for a client session.
HP-acct-terminate-cause
An proprietary RADIUS accounting attribute that allows a switch to report to the RADIUS server why an authentication session was terminated. This information allows customers to diagnose network operational problems and generate reports on terminated sessions. This attribute provides extended information on the statistics provided by the acct-terminate-cause attribute.
Change-of-Authorization (CoA) (RFC 3576)
The Dynamic Authorization Extensions to RADIUS is a mechanism that allows a RADIUS server to dynamically disconnect messages (DM) or change the authorization parameters (such as VLAN assignment) used in an active client session on the switch. The switch (NAS) does not have to initiate the exchange.
For example, for security reasons you may want to limit the network services granted to an authenticated user. In this case, you can change the user profile on the RADIUS server and have the new authorization settings take effect immediately in the active client session. The Change-of-Authorization attribute provides the mechanism to dynamically update an active client session with a new user policy that is sent in RADIUS packets. See Output for dynamic authorization configuration and Output showing dynamic authorization statistics. See Configuring the switch to access a RADIUS server for configuration commands for dynamic authorization.
Accounting services
RADIUS accounting collects data about user activity and system events and sends it to a RADIUS server when specified events occur on the switch, such as a logoff or a reboot.
Accounting service types
The switch supports four types of accounting services:
Network accounting
Provides records containing the information listed below on clients directly connected to the switch and operating under Port-Based Access Control (802.1X):
Client records provided under port-based access control
Acct-Session-Id
Acct-Status-Type
Acct-Terminate-Cause
Acct-Authentic
Acct-Delay-Time
Acct-Input-Packets
Acct-Output-Packets
Acct-Input-Octets
Nas-Port
Acct-Output-Octets
Acct-Session-Time
User-Name
Service-Type
NAS-IP-Address
NAS-Identifier
Calling-Station-Id
HP-acct-terminate-cause
MS-RAS-Vendor
Exec accounting
Provides records holding the information listed below about login sessions (console, Telnet, and SSH) on the switch:
Acct-Session-Id
Acct-Status-Type
Acct-Terminate-Cause
Acct-Authentic
Acct-Delay-Time
Acct-Session-Time
User-Name
Service-Type
NAS-IP-Address
NAS-Identifier
Calling-Station-Id
MS-RAS-Vendor
System accounting
Provides records containing the information listed below when system events occur on the switch, including system reset, system boot, and enabling or disabling of system accounting.
Acct-Session-Id
Acct-Status-Type
Acct-Terminate-Cause
Acct-Authentic
Acct-Delay-Time
Username
Service-Type
NAS-IP-Address
NAS-Identifier
Calling-Station-Id
Acct-Session-Time
MS-RAS-Vendor
Commands accounting
Provides records containing information on CLI command execution during user sessions.
Acct-Session-Id
Acct-Status-Type
Service-Type
Acct-Authentic
User-Name
NAS-IP-Address
NAS-Identifier
NAS-Port-Type
Calling-Station-Id
HP-Command-String
Acct-Delay-Time
RADIUS accounting with IP attribute
The RADIUS Attribute 8 (Framed-IP-Address) feature provides the RADIUS server with information about the client's IP address after the client is authenticated. DHCP snooping is queried for the IP address of the client, so DHCP snooping must be enabled for the VLAN of which the client is a member.
When the switch begins communications with the RADIUS server it sends the IP address of the client requesting access to the RADIUS server as RADIUS Attribute 8 (Framed-IP-Address) in the RADIUS accounting request. The RADIUS server can use this information to build a map of user names and addresses.
It may take a minute or longer for the switch to learn the IP address and then send the accounting packet with the Framed-IP-Address attribute to the RADIUS server. If the switch does not learn the IP address after a minute, it sends the accounting request packet to the RADIUS server without the Framed-IP-Address attribute. If the IP address is learned at a later time, it is included in the next accounting request packet sent.
The switch forwards the accounting information it collects to the designated RADIUS server, where the information is formatted, stored, and managed by the server. For more information on this aspect of RADIUS accounting, see the documentation provided with your RADIUS server.
Acct-Session-ID options in a management session
The switch can be configured to support either of the following options for the accounting service types used in a management session:
Unique Acct-Session-ID for each accounting service type used in the same management session (the default)
Same Acct-Session-ID for all accounting service types used in the same management session
See Accounting service types for more information.
Unique Acct-Session-ID operation
In the Unique mode (the default), the various service types running in a management session operate as parallel, independent processes. Thus, during a specific management session, a given service type has the same Acct-Session-ID for all accounting actions for that service type. However, the Acct-Session-ID for each service type differs from the ID for the other types.
NOTE: In Unique Acct-Session-ID operation, the Command service type is a special case in which the Acct-Session-ID for each executed CLI command in the session is different from the IDs for other service types used in the session and also different for each CLI command executed during the session. That is, the ID for each successive CLI command in the session is sequentially incremented from the ID value assigned to the immediately preceding CLI command in that session. | |
Accounting in the (default) unique mode shows Unique mode accounting operation for a new session in which two commands are executed, and then the session is closed.
Common Acct-Session-ID operation
In this case, all service types running in a given management session operate as subprocesses of the same parent process, and the same Acct-Session-ID is used for accounting of all service types, including successive CLI commands.
Dynamic removal of authentication limits
Overview
In some situations, it is desirable to configure RADIUS attributes for downstream supplicant devices that allow dynamic removal of the 802.1X, MAC, and web-based authentication limits on the associated port of the authenticator switch. This eliminates the need to manually reconfigure ports associated with downstream 802.1X-capable devices, and MAC relay devices such as IP phones, on the authenticator switches. When the RADIUS authentication ages out, the authentication limits are dynamically restored. This enhancement allows a common port policy to be configured on all access ports by creating new RADIUS vendor-specific attributes (VSAs) that dynamically override the authentication limits. The changes are always applied to the port on the authenticator switch associated with the supplicant being authenticated.
NOTE: All the changes requested by the VSAs must be valid for the switch configuration. For example, if either MAC or web-based port access is configured while 802.1X port access is in client mode, a RADIUS client with a VSA to change the 802.1X port access to port-based mode is not allowed. 802.1X in port-based mode is not allowed with MAC or web-based port access types. However, if the authenticating client has VSAs to disable MAC and web-based authentication in conjunction with changing 802.1X to port-based mode, then client authentication is allowed. | |