Configuring RADIUS schemes

A RADIUS scheme specifies the RADIUS servers that the device can work with and defines a set of parameters. The device uses the parameters to exchange information with the RADIUS servers, including the server IP addresses, UDP port numbers, shared keys, and server types.

	IMPORTANT: This feature is available in Release 1121 and later.

Use a test profile to detect whether a RADIUS authentication server is reachable at a detection interval. To detect the RADIUS server status, you must configure the RADIUS server to use this test profile in a RADIUS scheme.

With the test profile specified, the device sends a detection packet to the RADIUS server within each detection interval. The detection packet is a simulated authentication request that includes the specified username and password in the test profile.

• If the device receives a response from the server within the interval, it sets the server to the active state.

• If the device does not receive any response from the server within the interval, it sets the server to the blocked state.

The device refreshes the RADIUS server status at each detection interval according to the detection result.

The device stops detecting the status of the RADIUS server when one of the following operations is performed:

• The RADIUS server is removed from the RADIUS scheme.

• The test profile configuration is removed for the RADIUS server in RADIUS scheme view.

• The test profile is deleted.

• The RADIUS server is manually set to the blocked state.

• The RADIUS scheme is deleted.

To configure a test profile for RADIUS server status detection:

Create a RADIUS scheme before performing any other RADIUS configurations. You can configure a maximum of 16 RADIUS schemes. A RADIUS scheme can be used by multiple ISP domains.

To create a RADIUS scheme:

A RADIUS authentication server completes authentication and authorization together, because authorization information is piggybacked in authentication responses sent to RADIUS clients.

You can specify one primary authentication server and a maximum of 16 secondary authentication servers for a RADIUS scheme. When the primary server is not available, the device 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. A RADIUS authentication server can act as the primary authentication server for one scheme and a secondary authentication server for another scheme at the same time.

To specify RADIUS authentication servers for a RADIUS scheme:

You can specify one primary accounting server and a maximum of 16 secondary accounting servers for a RADIUS scheme. When the primary server is not available, the device 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. A RADIUS accounting server can act as the primary accounting server for one scheme and a secondary accounting server for another scheme at the same time.

The device sends a stop-accounting request to the accounting server in the following situations:

• The device receives a connection teardown request from a host.

• The device receives a connection teardown command from an administrator.

When the maximum number of realtime accounting attempts is reached, the device disconnects users who have no accounting responses.

RADIUS does not support accounting for FTP, SFTP, and SCP users.

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

The RADIUS client and server use the MD5 algorithm and shared keys to generate the Authenticator value for packet authentication and user password encryption. The client and server must use the same key for each type of communication.

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

To specify a shared key for secure RADIUS communication:

A username is in the userid@isp-name format, where the isp-name argument represents the user's ISP domain name. By default, the ISP domain name is included in a username. However, older RADIUS servers might not recognize usernames that contain the ISP domain names. In this case, you can configure the device to remove the domain name of each username to be sent.

If two or more ISP domains use the same RADIUS scheme, configure the RADIUS scheme to keep the ISP domain name in usernames for domain identification.

The device reports online user traffic statistics in accounting packets. The traffic measurement units are configurable, but they must be the same as the traffic measurement units configured on the RADIUS accounting servers.

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

RADIUS uses UDP packets to transfer data. Because UDP communication is not reliable, RADIUS uses a retransmission mechanism to improve reliability. A RADIUS request is retransmitted if the NAS does not receive a server response for the request within the response timeout timer. For more information about the RADIUS server response timeout timer, see "Setting RADIUS timers."

You can set the maximum number for the NAS to retransmit a RADIUS request to the same server. When the maximum number is reached, the NAS tries to communicate with other RADIUS servers in active state. If no other servers are in active state at the time, the NAS considers the authentication or accounting attempt a failure.

To set the maximum number of RADIUS request transmission attempts:

To control the RADIUS servers with which the device communicates when the current servers are no longer available, set the status of RADIUS servers to blocked or active. You can specify one primary RADIUS server and multiple secondary RADIUS servers. The secondary servers act as the backup of the primary server. The device chooses servers based on the following rules:

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

• If the primary server fails, the device performs the following operations:

  • Changes the server status to blocked.

  • Starts a quiet timer for the server.

  • Tries to communicate with a secondary server in active state that has the highest priority.

• If the secondary server is unreachable, the device performs the following operations:

  • Changes the server status to blocked.

  • Starts a quiet timer for the server.

  • Tries to communicate with the next secondary server in active state that has the highest priority.

• The search process continues until the device finds an available secondary server or has checked all secondary servers in active state. If no server is available, the device considers the authentication or accounting attempt a failure.

• When the quiet timer of a server expires or you manually set the server to the active state, the status of the server changes back to active. The device does not check the server again during the authentication or accounting process.

• When you remove a server in use, communication with the server times out. The device looks for a server in active state by first checking the primary server, and then checking secondary servers in the order they are configured.

• When the primary server and secondary servers are all in blocked state, the device tries to communicate with the primary server.

• When one or more servers are in active state, the device tries to communicate with these active servers only, even if the servers are unavailable.

• When a RADIUS server's status changes automatically, the device changes this server's status accordingly in all RADIUS schemes in which this server is specified.

• When a RADIUS server is manually set to blocked, server detection is disabled for the server, regardless of whether a test profile has been specified for the server. When the RADIUS server is set to active state, server detection is enabled for the server on which an existing test profile is specified.

By default, the device sets the status of all RADIUS servers to active. However, in some situations, you must 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.

To set the status of RADIUS servers:

	IMPORTANT: This feature is available in Release 1121 and later.

By default, the device communicates with RADIUS servers based on the server roles. It first attempts to communicate with the primary server, and, if the primary server is unavailable, it then searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication. In this process, the workload is always placed on the active server.

Use the RADIUS server load sharing feature to dynamically distribute the workload over multiple servers regardless of their server roles. The device forwards an AAA request to the most appropriate server of all active servers in the scheme after it compares the weight values and numbers of currently served users. Specify a weight value for each RADIUS server based on the AAA capacity of the server. A larger weight value indicates a higher AAA capacity.

In RADIUS server load sharing, once the device sends a start-accounting request to a server for a user, it forwards all subsequent accounting requests of the user to the same server. If the accounting server is unreachable, the device returns an accounting failure message rather than searching for another active accounting server.

To enable the RADIUS server load sharing feature:

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 a managed NAS.

• If the source IP address of the packet is the IP address of a managed NAS, the server processes the packet.

• If the source IP address of the packet is not the IP address of a managed NAS, the server drops the packet.

The source address of outgoing RADIUS packets is typically the IP address of an egress interface on the NAS to communicate with the RADIUS server. However, in some situations, you must change the source IP address.

You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view or in system view.

• The IP address specified in RADIUS scheme view applies only to one RADIUS scheme.

• The IP address specified in system view applies to all RADIUS schemes.

Before sending a RADIUS packet, the NAS selects a source IP address in the following order:

1. The source IP address specified for the RADIUS scheme.

2. The source IP address specified in system view.

3. The 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 RADIUS scheme:

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

• Server response timeout timer (response-timeout)—Defines the RADIUS request retransmission interval. The timer starts immediately after a RADIUS request is sent. If the device does not receive a response from the RADIUS server before the 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 status to blocked, starts this timer for the server, and tries to communicate with another server in active state. After the server quiet timer expires, the device changes the status of the server back to active.

• Realtime accounting timer (realtime-accounting)—Defines the interval at which the device sends realtime accounting packets to the RADIUS accounting server for online users.

When you set RADIUS timers, follow these guidelines:

• When you configure the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout timer, consider the number of secondary servers. If the retransmission process takes too much time, the client connection in the access module (for example, Telnet) might time out during the process.

• For client connections with a short timeout period, the initial authentication or accounting might fail, even if small packet transmission attempt limit and server response timeout period are configured. However, the next authentication or accounting attempt can succeed, because the device has set the unreachable servers to blocked, which shortens the amount of time for finding a reachable server.

• Make sure the server quiet timer is set correctly. A timer that is too short might result in frequent authentication or accounting failures. This is because the device will continue to attempt to communicate with an unreachable server that is in active state. A timer that is too long might temporarily block a reachable server that has recovered from a failure. This is because the server will remain in blocked state until the timer expires.

• A short realtime accounting interval helps improve accounting precision but requires many system resources. When there are 1000 or more users, set the interval to 15 minutes or longer.

To set RADIUS timers:

When the accounting-on feature is enabled, the device automatically sends an accounting-on packet to the RADIUS server after a reboot. Upon receiving the accounting-on packet, the RADIUS server logs out all online users so they can log in again through the device. Without this feature, users cannot log in again after the reboot, because the RADIUS server considers them to come online.

You can configure the interval for which the device waits to resend the accounting-on packet and the maximum number of retries.

The RADIUS server must run on IMC to correctly log out users when a card reboots on the distributed device to which the users connect.

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

The NAS verifies 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, configure the IP address of the security policy server on the NAS.

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

The device supports the following check methods for the Login-Service attribute (RADIUS attribute 15) of SSH, FTP, and terminal users:

• Strict—Matches Login-Service attribute values 50, 51, and 52 for SSH, FTP, and terminal services, respectively.

• Loose—Matches the standard Login-Service attribute value 0 for SSH, FTP, and terminal services.

An Access-Accept packet received for a user must contain the matching attribute value. Otherwise, the user cannot log in to the device.

Use the loose check method only when the server does not issue Login-Service attribute values 50, 51, and 52 for SSH, FTP, and terminal users.

To configure the Login-Service attribute check method for SSH, FTP, and terminal users:

When SNMP notifications are enabled for RADIUS, the SNMP agent supports the following notifications generated by RADIUS:

• RADIUS server unreachable notification—The RADIUS server cannot be reached. RADIUS generates this notification if it cannot receive any response to an accounting or authentication request within the specified RADIUS request transmission attempts.

• RADIUS server reachable notification—The RADIUS server can be reached. RADIUS generates this notification for a previously blocked RADIUS server after the quiet timer expires.

• Excessive authentication failures notification—The number of authentication failures to the total number of authentication attempts exceeds the specified threshold.

You can configure SNMP parameters to control the output of these SNMP notifications. For more information, see Network Management and Monitoring Configuration Guide.

To enable SNMP notifications for RADIUS:

Execute display commands in any view and reset commands in user view.