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.

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 user name 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 function 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 function 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 real-time 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:

The VPN instance specified for a RADIUS scheme applies to all authentication and accounting servers in that scheme. If a VPN instance is also configured for an individual RADIUS server, the VPN instance specified for the RADIUS scheme does not take effect on that server.

To specify a VPN instance for a scheme:

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 function 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 all servers are in blocked state, the device only 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:

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 it is the IP address of a managed NAS, the server processes the packet.

• If it 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. For example, when VRRP is configured for stateful failover, configure the virtual IP of the uplink VRRP group as the source 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 whose servers are in a VPN or the public network.

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 for the VPN or public network, depending on where the RADIUS server resides.

3. The IP address of the outbound interface specified by the route.

To specify a source IP address for all RADIUS schemes in a VPN or the public network:

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.

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

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 real-time 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.

The extended accounting-on feature enhances the accounting-on feature by applying to the scenario that an SPU reboots but the device does not reboot. For the extended accounting-on feature to take effect, you must enable the accounting-on feature.

When the extended accounting-on feature is enabled, the device automatically sends an accounting-on packet to the RADIUS server after an SPU reboot. The packet contains both the device and SPU identifiers. Upon receiving the accounting-on packet, the RADIUS server logs out all online users who access the device through the SPU.

The extended accounting-on feature is applicable to IPoE, LAN, and PPP (L2TP LAC-side) users. Data of these users is saved to the SPUs through which the users access the device.

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

A RADIUS server may deliver CAR parameters for user-based traffic monitoring and control by using the RADIUS class attribute (attribute 25) in RADIUS packets. You can configure the device to interpret the class attribute to CAR parameters.

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

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:

The RADIUS server uses Remanent_Volume attribute in authentication or real-time accounting responses to notify the device of the current amount of data available for online users.

Perform this task to set the data measurement unit for the Remanent_Volume attribute. Make sure the configured measurement unit is the same as the user data measurement unit on the RADIUS server.

To set the data measurement unit for the Remanent_Volume attribute:

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 does not receive a response to an accounting or authentication request within the specified number of 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 compared to the total number of authentication attempts exceeds the specified threshold.

For RADIUS SNMP notifications to be sent correctly, you must also configure SNMP on the device. For more information about SNMP configuration, see the network management and monitoring configuration guide for the device.

To enable SNMP notifications for RADIUS:

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