RADIUS (Remote Authentication Dial-In User Service) enables you to use up to fifteen servers and maintain separate authentication and accounting for each RADIUS server employed.
Authentication with RADIUS allows for a unique password for each user, instead of the need to maintain and distribute switch-specific passwords to all users. RADIUS verifies identity for the following types of primary password access to the HP switch:
|
|
|
![[NOTE: ]](images/note.gif) |
NOTE: The switch does not support RADIUS security for SNMP (network management) access. For information on blocking access through the WebAgent, see Controlling WebAgent access. |
|
|
HP Switches support RADIUS accounting for web-based authentication and MAC authentication sessions, collecting resource consumption data and forwarding it to the RADIUS server. This data can be used for trend analysis, capacity planning, billing, auditing, and cost analysis.
RADIUIS-administered commands authorization enables RADIUS server control of an authenticated client's access to CLI commands on the switch. See Commands authorization.
RADIUS accounting on the switch collects resource consumption data and forwards it to the RADIUS server. This data can be used for trend analysis, capacity planning, billing, auditing, and cost analysis. Accounting support is provided for WebAgent sessions on the switch.
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 supports four types of accounting services:
-
Network accounting
-
Exec accounting
-
System accounting
-
Commands accounting
Provides records containing the information listed below on clients directly connected to the switch and operating under Port-Based Access Control (802.1X):
Provides records holding the information listed below about login sessions (console, Telnet, and SSH) on the switch:
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.
Provides records containing information on CLI command execution during user sessions.
| Acct-Session-ID | User-Name | Calling-Station-Id |
| Acct-Status-Type | NAS-IP-Address | HP-Command-String |
| Service-Type | NAS-Identifier | Acct-Delay-Time |
| Acct-Authentic | Nas-Port-Type |
|
|
|
|
|
NOTE: For improved interoperability with Cisco ACS, the Calling-Station-Id RADIUS attribute and Remote Address TACACS+ fields are sent in authentication requests for management telnet, ssh, and http service. This provides the authentication server with the remote IP Address of the connecting station, if available, to provide more granular access policies and auditing based on incoming source IP Address. |
|
|
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.
-
You can configure up to four types of accounting to run simultaneously: exec, system, network, and command.
-
RADIUS servers used for accounting are also used for authentication.
-
The switch must be configured to access at least one RADIUS server.
-
RADIUS servers are accessed in the order in which their IP addresses were configured in the switch. Use
show radiusto view the order. As long as the first server is accessible and responding to authentication requests from the switch, a second or third server is not be accessed. For more on this topic, see Changing RADIUS-server access order. -
If access to a RADIUS server fails during a session, but after the client has been authenticated the switch continues to assume the server is available to receive accounting data. Thus, if server access fails during a session, it does not receive accounting data transmitted from the switch.
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.)
-
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
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. |
|
|
The switches covered in this guide take advantage of vendor-specific attributes (VSAs) applied in a RADIUS server to support these optional, RADIUS assigned attributes:
-
802.1p (CoS) priority assignment to inbound traffic on the specified ports for port-access authentication only
-
Per-Port Rate-Limiting on a port with an active link to an authenticated client for port-access authentication only
This feature enables RADIUS server control of an authenticated client’s access to CLI commands on the switch. See Commands authorization.
Beginning with software release K.12.xx, the switch’s default configuration allows SNMP access to the hpSwitchAuth MIB (Management Information Base). A management station running an SNMP networked device management application such as HP PCM+ or HP OpenView can access the switch’s MIB for read access to the switch’s status and read/write access to the switch’s configuration. For more information, including the CLI command to use for disabling this feature, see Using SNMP to view and configure switch authentication features.
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 HP 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 portbased mode, then client authentication is allowed. |
|
|
-
You must have at least one RADIUS server accessible to the switch.
-
The switch supports authentication and accounting using up to fifteen RADIUS servers. The switch accesses the servers in the order in which they are listed by
show radius. If the first server does not respond, the switch tries the next one, and so-on. To change the order in which the switch accesses RADIUS servers, see Changing RADIUS-server access order. -
You can select RADIUS as the primary authentication method for each type of access. (Only one primary and one secondary access method is allowed for each access type.)
-
In the HP switch, EAP RADIUS usesMD5 and TLS to encrypt a response to a challenge from a RADIUS server.
-
When primary/secondary authentication is set to Radius/Local (for either Login or Enable) and the RADIUS server fails to respond to a client attempt to authenticate, the failure is noted in the Event Log with the message
radius: Can't reach RADIUS server <server-ip-addr>. When this type of failure occurs, the switch prompts the client again to enter a user name and password. In this case, use the local user name (if any) and password configured on the switch itself. -
Zero-length user names or passwords are not allowed for RADIUS authentication, even though allowed by some RADIUS servers.
-
Only RADIUS authentication supports the new VSAs. Other authentication types, such as TACACS, are not supported.
-
The new VSAs are not supported in IDM and they cannot be specified in the configurations. The new VSAs must be configured manually.
-
If the RADIUS server delivers a new VSA to an authenticator switch that does not understand it, the Access-Accept message is rejected.
Beginning with software release K.12.xx, the switch default configuration allows SNMP access to the hpSwitchAuth Management Information Base (MIB). A management station running an SNMP networked device management application such as PCM+ or HP OpenView can access the switch MIB for read access to the switch status. and read/write access to the switch configuration.
HP Switches take advantage of vendor-specific attributes (VSAs) applied in a RADIUS server to support the following optional, RADIUS-assigned attributes:
-
802.1p (CoS) priority assignment to inbound traffic on specified ports (port-access authentication only)
-
Per-Port Rate-Limiting on a port with an active link to an authenticated client (port-access authentication only)
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).
Commands authorization assigns a list of CLI commands that can be executed by a specified user. The permitted CLI commands are defined on the remote RADIUS server in a user’s profile. When authentication is successful, the RADIUS server returns the permitted list of CLI commands that the authenticated user is authorized to execute. 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.
The user’s profile is encoded into HP Vendor Specific Attributes (VSAs):
The list of permitted commands is used to filter all the commands executed by the user until the end of the session. This allows greater authorization control, where different rights can be given to different manager or operator users.
When using Commands authorization, the WebAgent windows may show or hide fields, or allow or deny configuration steps, based on the access or deny list (VSA filtering) for the authenticated user. The following differences may be seen depending on the authorized commands in effect:
-
When none of the fields in a window are editable, that is, they are readonly, the Change button is disabled and grayed out.
-
When an option is not editable, the Change button is grayed out.
-
Contents of table rows, table columns, and individual table fields can be:
-
If there are some configured VLANs for which a field is hidden, for example, the Name column, and configuring a new VLAN is allowed, the currently configured VLANs appear in the Name column with a grayish background. The Name column is only completely hidden if configuring the Name (or any specified column or field) for all VLANs is not allowed.
-
When there is a check box for enabling/disabling a feature and that feature is not allowed, the check box is disabled.
Fields in a window that are marked as “na” are not accessible and are light gray background. The contents are blank. A selection can be missing from the navigation tree in the left pane as well, for example, the Configuration Report. The Wizard utility is not accessible in the Navigation pane if the setup command is not allowed.
If the user is not authorized to use the WebAgent, the WebAgent displays a blank window with a message that states “You are not authorized to access Web UI”.
In some cases, there may be authorization to configure a subset of options or values. One of the following messages may appear:
-
You are not authorized to configure <value> for <option>
-
You are authorized to configure only <value_1>, <value_2> values for <option>
-
You are not authorized to <operation><value>, where <operation> can be delete/upload/download, and <value> is the configured value.
MAC-Based VLANs (MBVs) allow multiple clients on a single switch port to receive different untagged VLAN assignments. VLAN assignment of untagged traffic is based on the source MAC address rather than the port. Clients receive their untagged VLAN assignment from the RADIUS server. This feature adheres to the requirement that if all known IDM attributes for a given client cannot be applied the authentication request for that client must be rejected.
Both authenticated and unauthenticated clients can reside on the same port on different VLANs, but only if the mixed-mode configuration is enabled. This is not the default behavior. The normal operating behavior is to not allow unauthenticated clients on the port when at least one authenticated client is present on the port. If an unauthenticated client is present on the unauth VLAN and another client successfully authenticates on that port, the unauthenticated client is kicked off the port.
When a MBV cannot be applied due to a conflict with another client on that port a message indicating VID arbitration error is logged.
When a MBV cannot be applied due to lack of resources a message indicating lack of resources is logged.
There is no command line support for this feature. The decision to use a MBV is made automatically if the hardware is capable and if the situation necessitates. If multiple clients authenticate on different untagged VLANs on hardware that does not support MBVs, the switch rejects all clients authorized on a VLAN different from the first client's VLAN - the first authenticated client sets the Port VID (PVID).
This feature has the side effect of allowing egress traffic from one client's VLAN to be accepted by all untagged clients on that port. For example, suppose that clients A and B are both located on the same switch port, but on two different VLANs. If client A is subscribing to a multicast stream, then client B also receives that multicast traffic.