Configuring RADIUS schemes

A RADIUS scheme specifies the RADIUS servers that the switch can cooperate with and defines a set of parameters that the switch uses to exchange information with the RADIUS servers. There may be authentication/authorization servers and accounting servers, or primary servers and secondary servers. The parameters include the IP addresses of the servers, the shared keys, and the RADIUS server type.

Before performing other RADIUS configurations, follow these steps to create a RADIUS scheme and enter RADIUS scheme view:

	NOTE: A RADIUS scheme can be referenced by multiple ISP domains at the same time.

You can specify one primary authentication/authorization server and up to 16 secondary authentication/authorization servers for a RADIUS scheme. When the primary server is not available, the switch searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.

If redundancy is not required, specify only the primary server.

In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS clients. There is no separate RADIUS authorization server.

You can enable the server status detection feature. With the feature, the switch periodically sends an authentication request to check whether or not the target RADIUS authentication/authorization server is reachable. If yes, the switch sets the status of the server to active. If not, the switch sets the status of the server to block. This feature can promptly notify authentication modules of latest server status information. For example, server status detection can work with the 802.1X critical VLAN feature, so that the switch can trigger 802.1X authentication for users in the critical VLAN immediately on detection of a reachable RADIUS authentication/authorization server.

Follow these guidelines when you specify RADIUS authentication/authorization servers:

• The IP addresses of the primary and secondary authentication/authorization servers for a scheme must be different from each other. Otherwise, the configuration fails.

• All servers for authentication/authorization and accounting, primary or secondary, must use IP addresses of the same IP version.

• You can specify a RADIUS authentication/authorization server as the primary authentication/authorization server for one scheme and as a secondary authentication/authorization server for another scheme at the same time.

To specify RADIUS authentication/authorization servers for a RADIUS scheme:

You can specify one primary accounting server and up to 16 secondary accounting servers for a RADIUS scheme. When the primary server is not available, the switch searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.

If redundancy is not required, specify only the primary server.

By setting the maximum number of real-time accounting attempts for a scheme, you make the switch disconnect users for whom no accounting response is received before the number of accounting attempts reaches the limit.

When the switch receives a connection teardown request from a host or a connection teardown notification from an administrator, it sends a stop-accounting request to the accounting server. You can enable buffering of non-responded stop-accounting requests to allow the switch to buffer and resend a stop-accounting request until it receives a response or the number of stop-accounting attempts reaches the configured limit. In the latter case, the switch discards the packet.

Follow these guidelines when you specify RADIUS accounting servers:

• The IP addresses of the primary and secondary accounting servers must be different from each other. Otherwise, the configuration fails.

• All servers for authentication/authorization and accountings, primary or secondary, must use IP addresses of the same IP version.

• If you delete an accounting server that is serving users, the switch can no longer send real-time accounting requests and stop-accounting requests for the users to that server, or buffer the stop-accounting requests.

• You can specify a RADIUS accounting server as the primary accounting server for one scheme and as a secondary accounting server for another scheme at the same time.

• RADIUS does not support accounting for FTP users.

To specify RADIUS accounting servers and set relevant parameters for a scheme:

The RADIUS client and RADIUS server use the MD5 algorithm to authenticate packets exchanged between them and use shared keys for packet authentication and user passwords encryption. They must use the same key for the same type of communication.

A shared key configured in this task is for all servers of the same type (accounting or authentication) in the scheme, and has a lower priority than a shared key configured individually for a RADIUS server.

To specify a shared key for secure RADIUS communication:

	NOTE: A shared key configured on the switch must be the same as that configured on the RADIUS server.

A username is usually in the format of userid@isp-name, where isp-name represents the name of the ISP domain the user belongs to and is used by the switch to determine which users belong to which ISP domains. However, some earlier RADIUS servers cannot recognize usernames that contain an ISP domain name. In this case, the switch must remove the domain name of each username before sending the username. You can set the username format on the switch for this purpose.

The switch periodically sends accounting updates to RADIUS accounting servers to report the traffic statistics of online users. For normal and accurate traffic statistics, make sure the unit for data flows and that for packets on the switch are consistent with those on the RADIUS server.

Follow these guidelines when you set the username format and the traffic statistics units for a RADIUS scheme:

• If a RADIUS scheme defines that the username is sent without the ISP domain name, do not apply the RADIUS scheme to more than one ISP domain. Otherwise, users using the same username but in different ISP domains are considered the same user.

• For level switching authentication, the user-name-format keep-original and user-name-format without-domain commands produce the same results. They make sure usernames sent to the RADIUS server carry no ISP domain name.

To set the username format and the traffic statistics units for a RADIUS scheme:

The supported RADIUS server type determines the type of the RADIUS protocol that the switch uses to communicate with the RADIUS server. It can be standard or extended:

• Standard—Uses the standard RADIUS protocol, compliant to RFC 2865 and RFC 2866 or later.

• Extended—Uses the proprietary RADIUS protocol of HPE.

When the RADIUS server runs on IMC, you must set the RADIUS server type to extended. When the RADIUS server runs third-party RADIUS server software, either RADIUS server type applies. For the switch to function as a RADIUS server to authenticate login users, you must set the RADIUS server type to standard.

To set the RADIUS server type:

	NOTE: Changing the RADIUS server type restores the unit for data flows and that for packets that are sent to the RADIUS server to the defaults.

Because RADIUS uses UDP packets to transfer data, the communication process is not reliable. RADIUS uses a retransmission mechanism to improve the reliability. If a NAS sends a RADIUS request to a RADIUS server but receives no response after the response timeout timer (defined by the timer response-timeout command) expires, it retransmits the request. If the number of transmission attempts exceeds the specified limit but it still receives no response, it tries to communicate with other RADIUS servers in active state. If no other servers are in active state at the time, it considers the authentication or accounting attempt a failure. For more information about RADIUS server states, see "Setting the status of RADIUS servers."

To set the maximum number of RADIUS request transmission attempts for a scheme:

	NOTE: The maximum number of transmission attempts of RADIUS packets multiplied by the RADIUS server response timeout period cannot be greater than 75 seconds. For more information about the RADIUS server response timeout period, see "Setting timers for controlling communication with RADIUS servers."

By setting the status of RADIUS servers to blocked or active, you can control which servers the switch communicates with for authentication, authorization, and accounting or turn to when the current servers are no longer available. In practice, you can specify one primary RADIUS server and multiple secondary RADIUS servers, with the secondary servers functioning as the backup of the primary servers. Generally, the switch chooses servers based on these rules:

• When the primary server is in active state, the switch communicates with the primary server. If the primary server fails, the switch changes the server's status to blocked and starts a quiet timer for the server, and then turns to a secondary server in active state (a secondary server configured earlier has a higher priority). If the secondary server is unreachable, the switch changes the server's status to blocked, starts a quiet timer for the server, and continues to check the next secondary server in active state. This search process continues until the switch finds an available secondary server or has checked all secondary servers in active state. If the quiet timer of a server expires or an authentication or accounting response is received from the server, the status of the server changes back to active automatically, but the switch does not check the server again during the authentication or accounting process. If no server is found reachable during one search process, the switch considers the authentication or accounting attempt a failure.

• Once the accounting process of a user starts, the switch keeps sending the user's real-time accounting requests and stop-accounting requests to the same accounting server. If you remove the accounting server, real-time accounting requests and stop-accounting requests for the user are no longer delivered to the server.

• If you remove an authentication or accounting server in use, the communication of the switch with the server soon times out, and the switch looks for a server in active state from scratch by checking any primary server first and then secondary servers in the order they are configured.

• When the primary server and secondary servers are all in blocked state, the switch communicates with the primary server. If the primary server is available, its status changes to active. Otherwise, its status remains to be blocked.

• If one server is in active state and all the others are in blocked state, the switch only tries to communicate with the server in active state, even if the server is unavailable.

• After receiving an authentication/accounting response from a server, the switch changes the status of the server identified by the source IP address of the response to active if the current status of the server is blocked.

The device does not change the status of an unreachable authentication or accounting server if the server quiet timer is set to 0. Instead, the device keeps the server status as active and sends authentication or accounting packets to another server in active state, so subsequent authentication or accounting packets can still be sent to that server. For more information about the server quiet timer, see "Setting timers for controlling communication with HWTACACS servers."

By default, the switch sets the status of all RADIUS servers to active. In cases such as a server failure, you can change the status of the server to blocked to avoid communication with the server.

To set the status of RADIUS servers in a RADIUS scheme:

	NOTE: The server status set by the state command cannot be saved to the configuration file. After the switch restarts, the status of each server is restored to active. To display the states of the servers, use the display radius scheme command.

The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon receiving a RADIUS packet, a RADIUS server checks whether the source IP address of the packet is the IP address of any managed NAS. If yes, the server processes the packet. If not, the server drops the packet.

You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view for a specific RADIUS scheme, or in system view for all RADIUS schemes. Before sending a RADIUS packet, a NAS selects a source IP address in the following order:

• Source IP address specified for the RADIUS scheme.

• Source IP address specified in system view.

• IP address of the outbound interface specified by the route.

To specify a source IP address for all RADIUS schemes:

To specify a source IP address for a specific RADIUS scheme:

The switch uses the following types of timers to control the communication with a RADIUS server:

• Server response timeout timer (response-timeout)—Defines the RADIUS request retransmission interval. After sending a RADIUS request (authentication/authorization or accounting request), the switch starts this timer. If the switch receives no response from the RADIUS server before this timer expires, it resends the request.

• Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If a server is not reachable, the switch changes the server's status to blocked, starts this timer for the server, and tries to communicate with another server in active state. After this timer expires, the switch changes the status of the server back to active.

• Real-time accounting timer (realtime-accounting)—Defines the interval at which the switch sends real-time accounting packets to the RADIUS accounting server for online users. To implement real-time accounting, the switch must periodically send real-time accounting packets to the accounting server for online users.

To set timers for controlling communication with RADIUS servers:

• For a type of users, the maximum number of transmission attempts multiplied by the RADIUS server response timeout period must be less than the client connection timeout time and must not exceed 75 seconds. Otherwise, stop-accounting messages cannot be buffered, and the primary/secondary server switchover cannot take place. For example, the product of the two parameters must be less than 10 seconds for voice users, and less than 30 seconds for Telnet users because the client connection timeout period for voice users is 10 seconds and that for Telnet users is 30 seconds.

• When you configure the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout period, be sure to take the number of secondary servers into account. If the retransmission process takes too much time, the client connection in the access module may be timed out while the switch is trying to find an available server.

• When a number of secondary servers are configured, the client connections of access modules that have a short client connection timeout period may still be timed out during initial authentication or accounting, even if the packet transmission attempt limit and server response timeout period are configured with small values. In this case, the next authentication or accounting attempt may succeed because the switch has set the state of the unreachable servers to blocked and the time for finding a reachable server is shortened.

• Be sure to set the server quiet timer properly. Too short a quiet timer may result in frequent authentication or accounting failures because the switch has to repeatedly attempt to communicate with an unreachable server that is in active state.

• For more information about the maximum number of RADIUS packet transmission attempts, see "Setting the maximum number of RADIUS request transmission attempts."

The accounting-on feature enables a switch to send accounting-on packets to the RADIUS server after it reboots, making the server log out users who logged in through the switch before the reboot. Without this feature, users who were online before the reboot cannot re-log in after the reboot, because the RADIUS server considers they are already online.

If a switch sends an accounting-on packet to the RADIUS server but receives no response, it resends the packet to the server at a particular interval for a specified number of times.

To configure the accounting-on feature for a RADIUS scheme:

	NOTE: The accounting-on feature requires the cooperation of the HPE IMC network management system.

The core of the HPE EAD solution is integration and cooperation, and the security policy server is the management and control center. Using a collection of software, the security policy server provides functions such as user management, security policy management, security status assessment, security cooperation control, and security event audit.

The NAS checks the validity of received control packets and accepts only control packets from known servers. To use a security policy server that is independent of the AAA servers, you must configure the IP address of the security policy server on the NAS. To implement all EAD functions, configure both the IP address of the security policy server and that of the IMC Platform on the NAS.

To configure the IP address of the security policy server for a scheme:

According to RFC 2865, a RADIUS server assigns the RADIUS class attribute (attribute 25) to a RADIUS client. However, the RFC only requires the RADIUS client to send the attribute to the accounting server on an "as is" basis. It does not require the RADIUS client to interpret the attribute. Some RADIUS servers use the class attribute to deliver the assigned committed access rate (CAR) parameters. In this case, the switch must interpret the attribute as the CAR parameters to implement user-based traffic monitoring and controlling.

To configure the switch to interpret the RADIUS class attribute as CAR parameters:

	NOTE: Whether interpretation of RADIUS class attribute as CAR parameters is supported depends on two factors: Whether the switch supports CAR parameters assignment. Whether the RADIUS server supports assigning CAR parameters through the class attribute.

With the trap function, a NAS sends a trap message when either of the following events occurs:

• The status of a RADIUS server changes. If a NAS receives no response to an accounting or authentication request before the specified maximum number of RADIUS request transmission attempts is exceeded, it considers the server unreachable, sets the status of the server to block and sends a trap message. If the NAS receives a response from a RADIUS server that it considers unreachable, the NAS considers that the RADIUS server is reachable again, sets the status of the server to active, and sends a trap message.

• The ratio of the number of failed transmission attempts to the total number of authentication request transmission attempts reaches the threshold. This threshold ranges from 1% to 100% and defaults to 30%. This threshold can only be configured through the MIB.

The failure ratio is generally small. If a trap message is triggered because the failure ratio is higher than the threshold, troubleshoot the configuration on and the communication between the NAS and the RADIUS server.

To enable the trap function for RADIUS:

To receive and send RADIUS packets, enable the RADIUS client service on the device. If RADIUS is not required, disable the RADIUS client service to avoid attacks that exploit RADIUS packets.

To enable the RADIUS client service: