Access Control Authentication Methods

802.1X Authentication

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 is based upon the IEEE 802.1X standard Port-Based Network Access Control.

The communication protocol between the end device and the device 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 device is RADIUS.

During the authentication process, the device 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.

Note:

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. Note: 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 device 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.

Note:

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 device 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 device 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 device to determine that the end device is not 802.1X-enabled by configuring the mac-radius restrict option. When this option is configured, the device 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 device 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 device 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 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.

Junos OS 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 device 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.

Note:

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

Captive portal 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 device to determine that a connected device is a non-802.1X-enabled host.

When you configure static MAC, 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 device, the device 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.

Note:

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, most devices use the following order of authentication methods:

1. 802.1X authentication—If 802.1X is configured on the interface, the device 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 device checks whether MAC RADIUS authentication is configured on the interface.

2. MAC RADIUS authentication—If MAC RADIUS authentication is configured on the interface, the device sends the MAC RADIUS address of the end device to the authentication server. If MAC RADIUS authentication is not configured, the device checks whether captive portal is configured on the interface.

3. Captive portal authentication—If captive portal is configured on the interface, the device 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 device 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.

Note:

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.