Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RADIUS Server Configuration for Authentication

Juniper Networks Ethernet Switches use 802.1X, MAC RADIUS, or captive portal authentication to provide access control to the devices or users. When 802.1X, MAC RADIUS, or captive portal authentications are configured on the switch, end devices are evaluated at the initial connection by an authentication (RADIUS) server. To use 802.1X or MAC RADIUS authentication, you must specify the connections on the switch for each RADIUS server to which you want to connect. Read this topic for more information.

Specifying RADIUS Server Connections on Switches (CLI Procedure)

IEEE 802.1X and MAC RADIUS authentication both provide network edge security, protecting Ethernet LANs from unauthorized user access by blocking all traffic to and from devices at the interface until the supplicant's credentials or MAC address are presented and matched on the authentication server (a RADIUS server). When the supplicant is authenticated, the switch stops blocking access and opens the interface to the supplicant.

To use 802.1X or MAC RADIUS authentication, you must specify the connections on the switch for each RADIUS server to which you will connect.

To configure multiple RADIUS servers, include multiple radius-server statements. When multiple servers are configured, servers are accessed in order of configuration, by default. The first server configured is the primary server. If the primary server is unreachable, the router attempts to reach the second configured server, and so on. You can load balance the requests by configuring the round-robin method. The servers are tried in order and in a round-robin fashion until a valid response is received from one of the servers, or until all the configured retry limits are reached.

Note:

The round-robin access method is not recommended for use with EX Series switches.

You can also configure a fully qualified domain name (FQDN) that resolves to one or more IP addresses. See Specifying RADIUS Server Connections on Switches (CLI Procedure).

To configure a RADIUS server on the switch:

  1. Configure the IP address of the RADIUS server, the RADIUS server authentication port number, and the secret password. The secret password on the switch must match the secret password on the server.
    Note:

    Specifying the authentication port is optional, and port 1812 is the default. However, we recommend that you configure it in order to avoid confusion as some RADIUS servers might refer to an older default.

  2. (Optional) Specify the IP address by which the switch is identified by the RADIUS server. If you do not specify the IP address, the RADIUS server uses the address of the interface that sends the RADIUS request. We recommend that you specify this IP address because if the request gets diverted on an alternate route to the RADIUS server, the interface relaying the request might not be an interface on the switch.
  3. Configure the authentication order, making radius the first method of authentication:
  4. (Optional) Configure the method the router uses to access RADIUS authentication and accounting servers when multiple servers are configured:
    • direct—The default method, in which there is no load balancing. The first server configured is the primary server; servers are accessed in order of configuration. If the primary server is unreachable, the router attempts to reach the second configured server, and so on.

    • round-robin—The method that provides load balancing by rotating router requests among the list of configured RADIUS servers. The server chosen for access is rotated based on which server was used last. The first server in the list is treated as a primary for the first authentication request, but for the second request, the second server configured is treated as primary, and so on. With this method, all of the configured servers receive roughly the same number of requests on average so that no single server has to handle all of the requests.

      Note:

      When a RADIUS server in the round-robin list becomes unreachable, the next reachable server in the round-robin list is used for the current request. That same server is also used for the next request because it is at the top of the list of available servers. As a result, after a server failure, the server that is used takes up the load of two servers.

    • To configure the method the router uses to access RADIUS accounting servers:

    • To configure the method the router uses to access RADIUS authentication servers:

  5. Create a profile and specify the list of RADIUS servers to be associated with the profile. For example, you might choose to group your RADIUS servers geographically by city. This feature enables easy modification whenever you want to change to a different sent of authentication servers.
  6. Specify the group of servers to be used for 802.1X or MAC RADIUS authentication by identifying the profile name:
  7. Configure the IP address of the switch in the list of clients on the RADIUS server. For information about configuring the RADIUS server, consult the documentation for your server.

Configuring a RADIUS Server Using an FQDN

You can configure a fully qualified domain name (FQDN) that resolves to one or more IP addresses. Configure a RADIUS server using an FQDN at the [edit access radius-server-name hostname] hierarchy level. When an FQDN resolves to multiple addresses, the servers are accessed in order of configuration, by default. The first resolved address is the primary server. If the primary server is unreachable, the router attempts to reach the second server, and so on. You can load balance the requests by configuring the round-robin method. The servers are tried in order and in a round-robin fashion until a valid response is received from one of the servers, or until all the configured retry limits are reached.

  1. Configure the FQDN of the RADIUS server, the RADIUS server authentication port number, and the secret password. The secret password on the switch must match the secret password on the server.
    Note:

    Specifying the authentication port is optional, and port 1812 is the default. However, we recommend that you configure it in order to avoid confusion as some RADIUS servers might refer to an older default.

  2. (Optional) Configure the interval for resolving an FQDN as the server address. The FQDN is resolved dynamically at fixed intervals based on the configured value.
  3. (Optional) Specify the IP address by which the switch is identified by the RADIUS server. If you do not specify the IP address, the RADIUS server uses the address of the interface that sends the RADIUS request. We recommend that you specify this IP address because if the request gets diverted on an alternate route to the RADIUS server, the interface relaying the request might not be an interface on the switch.
  4. Configure the authentication order, making radius the first method of authentication:
  5. (Optional) Configure the method the switch uses to access RADIUS authentication and accounting servers when multiple servers are configured:
    • direct—The default method, in which there is no load balancing. The first server configured is the primary server; servers are accessed in order of configuration. If the primary server is unreachable, the router attempts to reach the second configured server, and so on.

    • round-robin—The method that provides load balancing by rotating requests among the list of configured RADIUS servers. The server chosen for access is rotated based on which server was used last. The first server in the list is treated as a primary for the first authentication request, but for the second request, the second server configured is treated as primary, and so on. With this method, all of the configured servers receive roughly the same number of requests on average so that no single server has to handle all of the requests.

      Note:

      When a RADIUS server in the round-robin list becomes unreachable, the next reachable server in the round-robin list is used for the current request. That same server is also used for the next request because it is at the top of the list of available servers. As a result, after a server failure, the server that is used takes up the load of two servers.

    • To configure the method the switch uses to access RADIUS accounting servers:

    • To configure the method the switch uses to access RADIUS authentication servers:

  6. Create a profile and specify the list of RADIUS servers to be associated with the profile. For example, you might choose to group your RADIUS servers geographically by city. This feature enables easy modification whenever you want to change to a different set of authentication servers.
  7. Specify the group of servers to be used for 802.1X or MAC RADIUS authentication by identifying the profile name:
  8. Configure the IP address of the switch in the list of clients on the RADIUS server. For information about configuring the RADIUS server, consult the documentation for your server.

Understanding Session-Aware Round-Robin RADIUS Requests

Starting in Junos OS Release 22.4R1, authentication(authd) services are session aware when round-robin algorithm is configured so that the corresponding access request is sent to the same RADIUS server in response to access challenge from the RADIUS server, which results in successful authentication.

As per existing behaviour, on receipt of access challenge and state attribute from one of the RADIUS servers, the corresponding access request is sent to the next RADIUS Server using Round-robin algorithm. Since the next RADIUS server does not have a record of this session, it rejects the access request which results in authentication failure. With the new feature, the corresponding algorithm is configured so that the respective access request gets sent to the same RADIUS server in response to the access challenge from RADIUS server, and this results in successful authentication. If the RADIUS server does not respond with an access challenge, it either accepts or rejects the request. For the next authentication request, requests get sent to the next RADIUS server as per the Round-robin method. Any number of access challenges can be sent from the RADIUS server in response to each access request and authd responds to the same RADIUS server until the request is accepted or rejected by the RADIUS server.

Note that this feature is supported only for authd-lite clients (dot1x etc) and not for broadband clients that use Point-to-Point Protocol (PPP), as this is not supported on broadband clients. Also, access challenge messages are exchanged between RADIUS client and RADIUS server only in case of authentication, and not for accounting.

Configuring MS-CHAPv2 to Provide Password-Change Support (CLI Procedure)

Junos OS for EX Series switches enables you to configure the Microsoft Corporation implementation of the Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2) on the switch to provide password-change support. Configuring MS-CHAPv2 on the switch provides users accessing a switch the option of changing the password when the password expires, is reset, or is configured to be changed at next login.

See RFC 2433, Microsoft PPP CHAP Extensions, for information about MS-CHAP.

Before you configure MS-CHAPv2 to provide password-change support, ensure that you have:

To configure MS-CHAPv2, specify the following:

You must have the required access permission on the switch in order to change your password.

Configuring MS-CHAPv2 for Password-Change Support

Before you configure MS-CHAPv2 for password-change support, ensure that you have done the following:

  • Configured RADIUS server authentication parameters.

  • Set the first tried option in the authentication order to RADIUS server.

You can configure the Microsoft implementation of the Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2) on the router or switch to support changing of passwords. This feature provides users accessing a router or switch the option of changing the password when the password expires, is reset, or is configured to be changed at next logon.

To configure MS-CHAP-v2, include the following statements at the [edit system radius-options] hierarchy level:

The following example shows statements for configuring the MS-CHAPv2 password protocol, password authentication order, and user accounts:

Understanding Server Fail Fallback and Authentication on Switches

Juniper Networks Ethernet Switches use authentication to implement access control in an enterprise network. If 802.1X, MAC RADIUS, or captive portal authentication is configured on the switch, end devices are evaluated at the initial connection by an authentication (RADIUS) server. If the end device is configured on the authentication server, the device is granted access to the LAN and the EX Series switch opens the interface to permit access.

Server fail fallback enables you to specify how end devices connected to the switch are supported if the RADIUS authentication server becomes unavailable. Server fail fallback is triggered most often during reauthentication when the already configured and in-use RADIUS server becomes inaccessible. However, server fail fallback can also be triggered by an end device’s first attempt at authentication through the RADIUS server.

Server fail fallback enables you to specify one of four actions to be taken for end devices awaiting authentication when the server is timed out. The switch can accept or deny access to supplicants or maintain the access already granted to supplicants before the RADIUS timeout occurred. You can also configure the switch to move the supplicants to a specific VLAN. The VLAN must already be configured on the switch. The configured VLAN name overrides any attributes sent by the server.

  • Permit authentication, allowing traffic to flow from the end device through the interface as if the end device were successfully authenticated by the RADIUS server.

  • Deny authentication, preventing traffic from flowing from the end device through the interface. This is the default.

  • Move the end device to a specified VLAN if the switch receives a RADIUS access-reject message. The configured VLAN name overrides any attributes sent by the server. (The VLAN must already exist on the switch.)

  • Sustain authenticated end devices that already have LAN access and deny unauthenticated end devices. If the RADIUS servers time out during reauthentication, previously authenticated end devices are reauthenticated and new users are denied LAN access.

Configuring RADIUS Server Fail Fallback (CLI Procedure)

You can configure authentication fallback options to specify how end devices connected to a switch are supported if the RADIUS authentication server becomes unavailable.

When you set up 802.1X or MAC RADIUS authentication on the switch, you specify a primary authentication server and one or more backup authentication servers. If the primary authentication server cannot be reached by the switch and the secondary authentication servers are also unreachable, a RADIUS server timeout occurs. If this happens, because it is the authentication server that grants or denies access to the end devices awaiting authentication, the switch does not receive access instructions for end devices attempting access to the LAN, and normal authentication cannot be completed.

You can configure the server fail fallback feature to specify an action that the switch applies to end devices when the authentication servers are unavailable. The switch can accept or deny access to supplicants or maintain the access already granted to supplicants before the RADIUS timeout occurred. You can also configure the switch to move the supplicants to a specific VLAN.

You can also configure the server reject fallback feature for end devices that receive a RADIUS access-reject message from the authentication server. The server reject fallback feature provides limited access to a LAN, typically only to the Internet, for responsive end devices that are 802.1X-enabled but that have sent the wrong credentials.

Server fail fallback is supported for voice traffic starting in Release 14.1X53-D40 and Release 15.1R4. To configure server fail fallback actions for VoIP clients sending voice traffic, use the server-fail-voip statement. For all data traffic, use the server-fail statement. The switch determines the fallback method to use based on the type of traffic sent by the client. Untagged data frames are subject to the action configured with server-fail, even if they are sent by a VoIP client. Tagged VoIP VLAN frames are subject to the action configured with server-fail-voip. If server-fail-voip is not configured, the voice traffic is dropped.

Note:

Server reject fallback is not supported for VoIP VLAN tagged traffic. If a VoIP client starts authentication by sending untagged data traffic to a VLAN while server reject fallback is in effect, the VoIP client is allowed to access the fallback VLAN. If the same client subsequently sends tagged voice traffic, the voice traffic is dropped.

If a VoIP client starts authentication by sending tagged voice traffic while server reject fallback is in effect, the VoIP client is denied access to the fallback VLAN.

You can use the following procedure to configure server fail actions for data clients. To configure server fail fallback for VoIP clients sending voice traffic, use the server-fail-voip statement in place of the server-fail statement.

To configure server fail fallback actions:

  • Configure an interface to allow traffic to flow from a supplicant to the LAN if a RADIUS server timeout occurs (as if the end device had been successfully authenticated by a RADIUS server):
  • Configure an interface to prevent traffic flow from an end device to the LAN (as if the end device had failed authentication and had been denied access by the RADIUS server):
  • Configure an interface to move an end device to a specified VLAN if a RADIUS server timeout occurs:
  • Configure an interface to recognize already connected end devices as reauthenticated if there is a RADIUS timeout during reauthentication (new end devices are denied access):

You can configure an interface that receives a RADIUS access-reject message from the authentication server to move end devices attempting LAN access on the interface to a server-reject VLAN, a specified VLAN already configured on the switch.

To configure a server reject fallback VLAN:

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
14.1X53-D40
Server fail fallback is supported for voice traffic starting in Release 14.1X53-D40 and Release 15.1R4.