Using

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

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.

RADIUS server group command output

Syntax

Syntax

Syntax

Syntax

Configuring the maximum number of consecutive cached reauthentications and setting allowable time period

To control access to the CLI commands, enter this command at the CLI.

Syntax

HP Switch(config)# aaa authorization commands radius

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:

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 aaa authorizationcommands local to use this feature.

To create a group, enter this command.

Syntax

[no] aaa autnorization 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 <command-string> 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.
<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, sh ver would be expanded to show version and then this command is compared against the command strings of the authorization group. Creating a local authorization group and assigning the commands authorized

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.

Configuring authorized commands for a group in the correct order

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.

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:

Search order for accessing a RADIUS server

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:

Example of new RADIUS server search order

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:

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, HP 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), HP 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 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.

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

1. A cached-reauth-period is set to 900 seconds (15 minutes) and the reauth period is 180 seconds.

2. A client is successfully authenticated or reauthenticated.

3. The RADIUS server becomes unavailable. In 180 seconds from the authentication in step 1, 802.1X or web-based/MAC authentication initiates reauthentication.

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

5. 802.1X or web-based/MAC authentication allows the first cached reauthentication and starts the cached reauth period.

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

7. The cached reauthentication period (900 seconds) ends.

8. The next reauthentication begins 180 seconds after the last cached reauthentication.

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

10. 802.1X or web-based/MAC authentication terminates the client's session.

Determining the maximum amount of time before client session termination

1. The maximum amount of time between step 2 and step 3 is 180 seconds.

2. The amount of time between step 3 and step 5 is X seconds.

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

4. The time between step 8 and step 9 is X seconds.

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

When the switch is configured to use RADIUS, it reverts to local authentication only if one of these two conditions exists:

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 interfacewhich enables only local password configuration.

To help prevent unauthorized access through the WebAgent, do one or more of the following:

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.

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.

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:

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.

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:

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.

Output for dynamic authorization configuration

Output showing dynamic authorization statistics

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.

The switch can be configured to support either of the following options for the accounting service types used in a 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.

Accounting in the (default) unique mode

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.

Accounting in common mode (same session ID throughout)