Configuring RADIUS schemes

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

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

Before performing other RADIUS configurations, you must first create a RADIUS scheme and enter RADIUS scheme view.

To create a RADIUS scheme and enter RADIUS scheme view:

In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS clients. It is neither allowed nor needed to specify a separate RADIUS authorization server.

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, a secondary server is used. In a scenario where redundancy is not required, specify only the primary server.

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

You can enable the server status detection feature. With the feature, the device periodically sends an authentication request to check whether or not the target RADIUS authentication/authorization server is reachable. If the server can be reached, the device sets the status of the server to active. If the server cannot be reached, the device 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 device 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.

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, a secondary server is used. When redundancy is not required, specify only the primary server. A RADIUS accounting server can function as the primary accounting server for one scheme and a secondary accounting server for another scheme at the same time.

When the device receives a connection teardown request from a host or a connection teardown command from an administrator, it sends a stop-accounting request to the accounting server. By setting the maximum number of real-time accounting attempts for a scheme, the device disconnects users when no accounting response is received before the number of attempts reaches the limit. You can enable buffering of non-responded stop-accounting requests to allow the device to buffer and resend a stop-accounting request until it receives a response. If the number of stop-accounting attempts reaches the upper limit, the device discards the buffered request.

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 accounting, primary or secondary, must use IP addresses of the same IP version.

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

• 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 and use shared keys for packet authentication and user password encryption. They must use the same key for the same type of communication.

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

A shared key configured on the device must be the same as that configured on the RADIUS server.

To specify a shared key for secure RADIUS communication:

After you specify a VPN for a RADIUS scheme, all AAA servers specified for the scheme belong to the VPN. However, if you also specify a VPN when specifying a server for the scheme, the server belongs to the specific VPN.

To specify a VPN for a RADIUS scheme:

A username is usually in the format userid@isp-name, where isp-name represents the ISP domain name of the user and is used by the device to determine which users belong to which ISP domains. However, some earlier RADIUS servers do not recognize usernames that contain the user ISP domain name. In this case, you can configure the device to remove the domain name from each username before sending the username.

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

Follow these guidelines when you set the username format and the traffic statistics units:

• 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 that 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 device 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 device to function as a RADIUS server to authenticate login users, set the RADIUS server type to standard.

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

To set the RADIUS server type:

RADIUS uses UDP packets to transfer data. UDP communication is not reliable. To improve reliability, RADIUS uses a retransmission mechanism. If a NAS sends a RADIUS request to a RADIUS server but receives no response before 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."

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 timer, see "Setting RADIUS timers."

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

By setting the status of RADIUS servers to blocked or active, you can control which servers the device communicates with for AAA or uses 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 device chooses servers based on these rules:

• When the primary server is in active state, the device communicates with the primary server.

  If the primary server fails, the device changes the server's status to blocked, starts a quiet timer for the server, and tries to communicate with a secondary server in active state (a secondary server configured earlier has a higher priority).

  If the secondary server is unreachable, the device 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 device 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 device does not check the server again during the authentication or accounting process.

  If no server is found reachable during one search process, the device considers the authentication or accounting attempt a failure.

• Once the accounting process of a user starts, the device 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 cannot be delivered to the server anymore.

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

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

• If one server is in active state and all others are in blocked state, the device 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 device 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 quiet timer of the servers 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 that subsequent authentication or accounting packets can still be sent to the server. For more information about the quiet timer, see "Setting RADIUS timers."

By default, the device sets the status of all RADIUS servers to active. In some cases, however, you may have to change the status of a server. For example, if a server fails, you can change the status of the server to blocked to avoid communication attempts to the server.

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

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

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.

Usually, the source address of outgoing RADIUS packets can be the IP address of any NAS interface that can communicate with the RADIUS server. In some special cases, however, you must change the source IP address. For example, if a NAT device is present between the NAS and the RADIUS server, the source IP address of outgoing RADIUS packets must be a public IP address of the NAS. If the NAS is configured with VRRP for stateful failover, the source IP address of outgoing RADIUS packets can be the virtual IP address of the uplink VRRP group.

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 whose servers are in the same VPN. Before sending a RADIUS packet, the 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 for the VPN.

• 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:

In a stateful failover scenario, the active device authenticates portal users by interacting with the RADIUS server, and synchronizes its online portal user information to the standby device through the backup link established between them. The standby device only receives and processes synchronization messages from the active device. However, when the active device fails, the RADIUS server cannot send RADIUS packets to the standby device because it does not have the IP address of the standby device.

To solve this problem, configure the source IP address for outgoing RADIUS packets on each device as the backup source IP address for outgoing RADIUS packets on the other device. With such configuration, the active device sends the source IP address for outgoing RADIUS packets that is configured on the standby device to the RADIUS server, so that the RADIUS server can send unsolicited RADIUS packets to the standby device.

You can specify a backup IP address for outgoing RADIUS packets in RADIUS scheme view for a specific RADIUS scheme, or in system view for all RADIUS schemes whose servers are in the same VPN. Before sending a RADIUS packet, the NAS uses the following order to select a backup source IP address:

• Backup source IP address specified for the RADIUS scheme.

• Backup source IP address specified in system view for the VPN.

If no backup source IP address is specified in the views, the NAS sends no backup source IP address to the server.

To specify a backup source IP address for all RADIUS schemes:

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

The backup source IP address specified for outgoing RADIUS packets takes effect only when stateful failover is configured, and it must be the source IP address for outgoing RADIUS packets that is configured on the standby device.

The device 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 device starts the server response timeout timer. If the device 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 one server is not reachable, the device changes the server's status to blocked, starts the server quiet timer, and tries to communicate with another server in active state. After the timer expires, the device changes the status of the server back to active.

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

Follow these guidelines when you set RADIUS timers:

• For the same 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 timer, 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 device 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 device has set the status of the unreachable servers to blocked and the time for finding a reachable server is shortened.

• Set the server quiet timer properly. Too short a quiet timer may result in frequent authentication or accounting failures because the device keeps trying 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."

To set RADIUS timers:

The accounting-on feature enables a device to send an accounting-on packet to the RADIUS server after it reboots so the server can log out users who logged in through the device before the reboot. Without this feature, users who were online before the reboot could not re-log in after the reboot, because the RADIUS server would consider them already online.

If a device 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.

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

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

The core of the HPE EAD solution is integration and cooperation. The security policy server is the management and control center for EAD. 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 IMC 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:

This task is required when the RADIUS server supports assigning CAR parameters through the class attribute and the device supports CAR parameters assignment.

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, but does not require the RADIUS client to interpret the attribute. When RADIUS servers use the class attribute to deliver the assigned CAR parameters, the device must interpret the attribute as the CAR parameters to implement user-based traffic monitoring and controlling.

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

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

• The status of a RADIUS server changes. If the 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 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: