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.
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:
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.
See Also
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:
Configured RADIUS server authentication. Configure users on the authentication server and set the first-tried option in the authentication order to radius. See Example: Connecting a RADIUS Server for 802.1X to an EX Series Switch.
To configure MS-CHAPv2, specify the following:
[edit system radius-options] user@switch# set password-protocol mschap-v2
You must have the required access permission on the switch in order to change your password.
See Also
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:
[edit system radius-options] password-protocol mschap-v2;
The following example shows statements for configuring the MS-CHAPv2 password protocol, password authentication order, and user accounts:
[edit]
system {
authentication-order [ radius password ];
radius-server {
192.168.69.149 secret "$9$G-j.5Qz6tpBk.1hrlXxUjiq5Qn/C"; ## SECRET-DATA
}
radius-options {
password-protocol mschap-v2;
}
login {
user bob {
class operator;
}
}
}
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.
See Also
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.
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:
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:
[edit protocols dot1x authenticator] user@switch# set interface interface-name server-reject-vlan vlan-sf
See Also
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.