Description

When deploying Juniper’s leading Unified Access Control (UAC) solution, maximum security can be achieved by enabling layer 2 (IEEE 802.1x) authentication across all devices accessing the network. By default the dot1x protocol will fail shut if the Radius server (in the UAC’s case the Infranet Controller (IC)) is unreachable.

For the headquarters a single point of failure can be avoided by having a locally present IC controller and a link to a redundant controller in another location. However in the case of branch offices this redundancy cannot be practically achieved due to a single ISP link coupled with the fact that the branch does not justify the cost of having a local IC.

Symptoms

Juniper's UAC solution can be deployed with Layer 2 enforcement using 802.1x. The default behavior of dot1x enabled switches is to fail shut if communication is lost with the Radius server. It is the purpose of this article to discuss options available to change this behavior.

Solution

 

When considering typical UAC deployment scenarios, some of the cost benefit advantages to this solution are the ability to authenticate all corporate and branch users through the use of a single logical controller in addition to the use of the 802.1x protocol which is a dedicated security protocol.

A typical deployment of the UAC system is illustrated in the following diagram:

alt


Figure1 - Typical UAC Enterprise-Wide Deployment :


When considering users in the HQ or the DR they can be authenticated against the IC controller which is locally present or the IC controller which is available in the other main site. As such there is no single point of failure: the users will be locked out of the network only if both the local controller and the connection to the other main location fails.

However in the case of branch locations, many companies have international branches or local branches which are connected through IPSEC VPN tunnels over Internet connections. For these branches if dot1x authentication is implemented we have a single point of failure which is the connection to the main office. Implementing a second link from another ISP or placing an IC appliance in each of those branches is often not a practical solution.

With the default behavior of UAC and dot1x, and taking into consideration the security requirements of most scenarios, it is a requirement to have security solutions fail shut. The downside of a security solution that fails open is that malicious entities can force a security compromise by interrupting the link between the switches and the IC controllers. When this happens access control is nullified and anybody can gain access to the network.

However, in certain scenarios such as the one described above, a fail close solution may be overridden by the business requirement for users to have access to local services in the branch. It is the purpose of this article to offer some alternatives in these cases.


Option 1 -  Radius Services on the Local Server :

It is typically seen that such remote branches will have a remote server in the local branch for local file storage and Identity store functions. Reasons being obviously reducing latency in authentication over the WAN link and reducing relocated file transfer.

As such there is a valid option to install a redundant Radius service on this server. Enterprise class access requestors (dot1x capable switches/access points) have the ability to specify multiple Radius servers as authentication severs. During a standard UAC configuration, the IC controllers will be specified as the Radius servers. With this option we specify the Radius service installed on the local server as a backup to the IC controllers.

The advantage of this option is that even with the loss of communication between the switches and the IC, machines are still authenticated before they are admitted on the network even though the advanced features of UAC will not be present; such as posture checking. This reduces the risk present with allowing all devices on the network with a fail open scenario.

Option 2 - Switch server-fail action :

Juniper’s EX series switches include optional controls for allowing actions to be taken on specific interfaces when communication to the Radius server is lost. These options are:

  • deny
  • permit
  • use-cache
  • vlan-id
  • vlan-name

If communication to the server is lost then one of the above actions can be applied. The option ‘use-cache’ can be used to force succeed the supplicant authentication only if it was previously authenticated successfully. This action ensures that already authenticated supplicants are not affected. The advantage of this option is that only legitimate clients will be allowed on the network even if there is a communication failure.

Alternatively the option of "permit" can be used to allow all users access to the network while running the risk of allowing illegitimate users on the network.


While both options present a viable option depending on the specifics of the implementation, a hybrid solution implementing both options is also possible.  This can be done by adding the local radius server to the list of switches’ radius severs and also specifying server fail options for critical users in the case of the double failure of the communications line and the local server simultaneously.


References :

802.1X Authenticated Wired Access Deployment Guide

EX Series - Server Fail