Access Control and Authentication on Switching Devices
You can control access to your network through a switch by using several different authentication. Junos OS switches support 802.1X, MAC RADIUS, and captive portal as an authentication methods to devices requiring to connect to a network. Read this topic for more information.
Understanding Authentication on Switches
You can control access to your network through a Juniper Networks EX Series Ethernet Switch by using authentication methods such as 802.1X, MAC RADIUS, or captive portal. Authentication prevents unauthenticated devices and users from gaining access to your LAN. For 802.1X and MAC RADIUS authentication, end devices must be authenticated before they receive an IP address from a Dynamic Host Configuration Protocol (DHCP) server. For captive portal authentication, the switch allows the end devices to acquire an IP address in order to redirect them to a login page for authentication.
This topic covers:
Sample Authentication Topology
Figure 1 illustrates a basic deployment topology for authentication on an EX Series switch:
For illustration purposes, we have used an EX Series switch, but a QFX5100 switch can be used in the same way.
The topology contains an EX Series access switch connected to the authentication server on port ge-0/0/10. Interface ge-0/0/1 connects to the conference room host. Interface ge-0/0/8 is connected to four desktop PCs through a hub. Interfaces ge-0/0/9 and ge-0/0/2 are connected to IP phones with an integrated hub to connect the phone and desktop PC to a single port. Interfaces ge-0/0/19 and ge-0/0/20 are connected to printers.
802.1X is an IEEE standard for port-based network access control (PNAC). It provides an authentication mechanism for devices seeking to access a LAN. The 802.1X authentication feature on an EX Series switch is based upon the IEEE 802.1X standard Port-Based Network Access Control.
The communication protocol between the end device and the switch is Extensible Authentication Protocol over LAN (EAPoL). EAPoL is a version of EAP designed to work with Ethernet networks. The communication protocol between the authentication server and the switch is RADIUS.
During the authentication process, the switch completes multiple message exchanges between the end device and the authentication server. While 802.1X authentication is in process, only 802.1X traffic and control traffic can transit the network. Other traffic, such as DHCP traffic and HTTP traffic, is blocked at the data link layer.
You can configure both the maximum number of times an EAPoL request packet is retransmitted and the timeout period between attempts. For information, see Configuring 802.1X Interface Settings (CLI Procedure).
An 802.1X authentication configuration for a LAN contains three basic components:
Supplicant (also called end device)—Supplicant is the IEEE term for an end device that requests to join the network. The end device can be responsive or nonresponsive. A responsive end device is 802.1X-enabled and provides authentication credentials using EAP. The credentials required depend on the version of EAP being used—specifically, a username and password for EAP MD5 or a username and client certificates for Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), EAP-Tunneled Transport Layer Security (EAP-TTLS), and Protected EAP (PEAP).
You can configure a server-reject VLAN to provide limited LAN access for responsive 802.1X-enabled end devices that sent incorrect credentials. A server-reject VLAN can provide a remedial connection, typically only to the Internet, for these devices. See Example: Configuring Fallback Options on EX Series Switches for EAP-TTLS Authentication and Odyssey Access Clients for additional information.
If the end device that is authenticated using the server-reject VLAN is an IP phone, voice traffic is dropped.
A nonresponsive end device is one that is not 802.1X-enabled. It can be authenticated through MAC RADIUS authentication.
Authenticator port access entity—The IEEE term for the authenticator. The switch is the authenticator, and it controls access by blocking all traffic to and from end devices until they are authenticated.
Authentication server—The authentication server contains the backend database that makes authentication decisions. It contains credential information for each end device that is authenticated to connect to the network. The authenticator forwards credentials supplied by the end device to the authentication server. If the credentials forwarded by the authenticator match the credentials in the authentication server database, access is granted. If the credentials forwarded do not match, access is denied. The EX Series switches support RADIUS authentication servers.
You cannot configure 802.1X authentication on redundant trunk groups (RTGs). For more information about RTGs, see Understanding Redundant Trunk Links (Legacy RTG Configuration).
MAC RADIUS Authentication
The 802.1X authentication method only works if the end device is 802.1X-enabled, but many single-purpose network devices such as printers and IP phones do not support the 802.1X protocol. You can configure MAC RADIUS authentication on interfaces that are connected to network devices that do not support 802.1X and for which you want to allow to access the LAN. When an end device that is not 802.1X-enabled is detected on the interface, the switch transmits the MAC address of the device to the authentication server. The server then tries to match the MAC address with a list of MAC addresses in its database. If the MAC address matches an address in the list, the end device is authenticated.
You can configure both 802.1X and MAC RADIUS authentication methods on the interface. In this case, the switch first attempts to authenticate the end device by using 802.1X, and if that method fails, it attempts to authenticate the end device by using MAC RADIUS authentication. If you know that only non-responsive supplicants connect on that interface, you can eliminate the delay that occurs for the switch to determine that the end device is not 802.1X-enabled by configuring the mac-radius restrict option. When this option is configured, the switch does not attempt to authenticate the end device through 802.1X authentication but instead immediately sends a request to the RADIUS server for authentication of the MAC address of the end device. If the MAC address of that end device is configured as a valid MAC address on the RADIUS server, the switch opens LAN access to the end device on the interface to which it is connected.
The mac-radius-restrict option is useful when no other 802.1X authentication methods, such as guest VLAN, are needed on the interface. If you configure mac-radius-restrict on an interface, the switch drops all 802.1X packets.
The authentication protocols supported for MAC RADIUS authentication are EAP-MD5, which is the default, Protected EAP (EAP-PEAP), and Password Authentication Protocol (PAP). You can specify the authentication protocol to be used for MAC RADIUS authentication using the authentication-protocol statement.
Captive Portal Authentication
Captive portal authentication (hereafter referred to as captive portal) enables you to authenticate users on EX Series switches by redirecting Web browser requests to a login page that requires users to input a valid username and password before they can access the network. Captive portal controls network access by requiring users to provide information that is authenticated against a RADIUS server database by using EAP-MD5. You can also use captive portal to display an acceptable-use policy to users before they access your network.
Juniper Networks Junos operating system (Junos OS) for EX Series switches provides a template that enables you to easily design and modify the look of the captive portal login page. You enable specific interfaces for captive portal. The first time an end device connected to a captive portal interface attempts to access a webpage, the switch presents the captive portal login page. After the device is successfully authenticated, it is allowed access to the network and to continue to the original page requested.
If HTTPS is enabled, HTTP requests are redirected to an HTTPS connection for the captive portal authentication process. After authentication, the end device is returned to the HTTP connection.
If there are end devices that are not HTTP-enabled connected to the captive portal interface, you can allow them to bypass captive portal authentication by adding their MAC addresses to an authentication whitelist.
When a user is authenticated by the RADIUS server, any per-user policies (attributes) associated with that user are also sent to the switch.
Captive portal on switches has the following limitations:
Captive portal does not support dynamic assignment of VLANs downloaded from the RADIUS server.
If the user remains idle for more than about 5 minutes and there is no traffic passed, the user must log back in to the captive portal.
Static MAC Bypass of Authentication
You can allow end devices to access the LAN without authentication on a RADIUS server by including their MAC addresses in the static MAC bypass list (also known as the exclusion list).
You might choose to include a device in the bypass list to:
Allow non-802.1X-enabled devices access to the LAN.
Eliminate the delay that occurs for the switch to determine that a connected device is a non-802.1X-enabled host.
When you configure static MAC on the switch, the MAC address of the end device is first checked in a local database (a user-configured list of MAC addresses). If a match is found, the end device is successfully authenticated and the interface is opened up for it. No further authentication is done for that end device. If a match is not found and 802.1X authentication is enabled on the switch, the switch attempts to authenticate the end device through the RADIUS server.
For each MAC address, you can also configure the VLAN to which the end device is moved or the interfaces on which the host connects.
When you clear the learned MAC addresses from an interface, using the clear dot1x interface command, all MAC addresses are cleared, including those in the static MAC bypass list.
Fallback of Authentication Methods
You can configure 802.1X, MAC RADIUS, and captive portal authentication on a single interface to enable fallback to another method if authentication by one method fails. The authentication methods can be configured in any combination, except that you cannot configure both MAC RADIUS and captive portal on an interface without also configuring 802.1X. By default, an EX Series switch uses the following order of authentication methods:
- 802.1X authentication—If 802.1X is configured on the interface, the switch sends EAPoL requests to the end device and attempts to authenticate the end device through 802.1X authentication. If the end device does not respond to the EAP requests, the switch checks whether MAC RADIUS authentication is configured on the interface.
- MAC RADIUS authentication—If MAC RADIUS authentication is configured on the interface, the switch sends the MAC RADIUS address of the end device to the authentication server. If MAC RADIUS authentication is not configured, the switch checks whether captive portal is configured on the interface.
- Captive portal authentication—If captive portal is configured on the interface, the switch attempts to authenticate the end device by using this method after the other authentication methods configured on the interface have failed.
For an illustration of the default process flow when multiple authentication methods are configured on an interface, see Understanding Access Control on Switches.
You can override the default order for fallback of authentication methods by configuring the authentication-order statement to specify that the switch use either 802.1X authentication or MAC RADIUS authentication first. Captive portal must always be last in the order of authentication methods. For more information, see Configuring Flexible Authentication Order.
Starting with Junos OS Release 15.1R3, if an interface is configured in multiple-supplicant mode, end devices connecting through the interface can be authenticated using different methods in parallel. Therefore, if an end device on the interface was authenticated after fall back to captive portal, then additional end devices can still be authenticated using 802.1X or MAC RADIUS authentication.
Understanding Access Control on Switches
You can control access to your network through a switch by using several different authentication methods—including 802.1X, MAC RADIUS, or captive portal.
Figure 2 illustrates the authentication process:
Understanding Authentication Session Timeout
Information about authentication sessions—including the associated interfaces and VLANs for each MAC address that is authenticated—is stored in the authentication session table. The authentication session table is tied to the Ethernet switching table (also called the MAC table). Each time the switch detects traffic from a MAC address, it updates the timestamp for that network node in the Ethernet switching table. A timer on the switch periodically checks the timestamp and if its value exceeds the user-configured mac-table-aging-time value, the MAC address is removed from the Ethernet switching table. When a MAC address ages out of the Ethernet switching table, the entry for that MAC address is also removed from the authentication session table, with the result that the session ends.
When the authentication session ends due to MAC address aging, the host must re-attempt authentication. To limit the downtime resulting from re-authentication, you can control the timeout of authentication sessions in the following ways:
For 802.1X and MAC RADIUS authentication sessions, disassociate the authentication session table from the Ethernet switching table by using the no-mac-table-binding statement. This setting prevents the termination of the authentication session when the associated MAC address ages out of the Ethernet switching table.
For captive portal authentication sessions, configure a keep-alive timer using the user-keepalive statement. With this option configured, when the associated MAC address ages out of the Ethernet switching table, the keep-alive timer is started. If traffic is received within the keep-alive timeout period, the timer is deleted. If there is no traffic within the keep-alive timeout period, the session is deleted.
You can also specify timeout values for authentication sessions to end the session before the MAC aging timer expires. After the session times out, the host must re-attempt authentication.
For 802.1X and MAC RADIUS authentication sessions, the duration of the session before timeout depends on the value of the reauthentication statement. If the MAC aging timer expires before the session times out, and the no-mac-table-binding statement is not configured, the session is ended, and the host must re-authenticate.
For captive portal authentication sessions, the duration of the session depends on the value configured for the session-expiry statement. If the MAC aging timer expires before the session times out, and the user-keepalive statement is not configured, the session is ended, and the host must re-authenticate.
If the authentication server sends an authentication session timeout to the client, this takes priority over the value configured locally using either the reauthentication statement or the session-expiry statement. The session timeout value is sent from the server to the client as an attribute of the RADIUS Access-Accept message. For information about configuring the authentication server to send an authentication session timeout, see the documentation for your server.
Controlling Authentication Session Timeouts (CLI Procedure)
The expiration of an authentication session can result in downtime because the host must re-attempt authentication. You can limit this downtime by controlling the timeout period for authentication sessions.
An authentication session can end when the MAC address associated with the authenticated host ages out of the Ethernet switching table. When the MAC address is cleared from the Ethernet switching table, the authenticated session for that host ends, and the host must re-attempt authentication.
To prevent the authentication session from ending when the MAC address ages out of the Ethernet switching table:
- For sessions authenticated using 802.1X or MAC RADIUS authentication,
you can prevent authentication session timeouts due to MAC address
aging by disassociating the authentication session table from the
Ethernet switching table using the no-mac-table-binding statement:
user@switch# set protocols dot1x authenticator no-mac-table-binding;
- For sessions authenticated using captive portal authentication,
you can prevent authentication session timeouts due to MAC address
aging by extending the timeout period using the user-keepalive statement:
user@switch# set services captive-portal interface interface-name user-keepalive minutes;
You can also configure timeout values for authentication sessions to end an authenticated session before the MAC aging timer expires.
Configuring the session timeout for an authentication session does not extend the session after the MAC aging timer expires. You must configure either the no-mac-table-binding statement for 802.1X and MAC RADIUS authentication, or the user-keepalive statement for captive portal authentication, to prevent session timeout due to MAC aging.
For 802.1X and MAC RADIUS authentication sessions, configure the timeout value using the reauthentication statement.
- To configure the timeout value on a single interface:
user@switch# set protocols dot1x authenticator interface interface-name reauthentication seconds;
- To configure the timeout value on all interfaces:
user@switch# set protocols dot1x authenticator interface all reauthentication seconds;
For captive portal authentication sessions, configure the timeout value using the session-expiry statement.
- To configure the timeout value on a single interface:
user@switch# set services captive-portal interface interface-name session-expiry minutes;
- To configure the timeout value on all interfaces:
user@switch# set services captive-portal interface all session-expiry minutes;
If the authentication server sends an authentication session timeout to the client, this takes priority over the value configured using the reauthentication statement or the session-expiry statement. The session timeout value is sent from the server to the client as an attribute of the RADIUS Access-Accept message.