Authentication Design
Authentication is the process of validating that a user or device is who they claim to be, and authorization is the process of determining the type of access given to that user or device. This chapter discusses how these tasks are performed in an enterprise network, as well as how to design the systems responsible for authentication and authorization.
Table of contents
Campus & Branch Networks
ClearPass
ClearPass is the on-premise network access control solution for campus and branch networks. It is a flexible and powerful solution that can be implemented as a physical or virtual appliance in multiple virtual environments. While it can be deployed as a stand-alone AAA server, it is best practice to deploy a cluster of multiple ClearPass instances for high availability (HA) and load balancing. Refer to the Installation Guide for details.
The implementation and operation of ClearPass are managed directly within the web UI of the Publisher node. The ClearPass Deployment Guide provides detailed procedures for installing the solution. Refer to the ClearPass User Guide for more complete coverage of features and commands.
When using ClearPass, take time to plan the desired client experience when joining the network. Create a flow chart to outline the authentication and authorization process for sharing with both technical and business teams. This sets proper expectations and illustrates the benefits of the new solution. It also ensures that stakeholders understand the benefits of additional security steps.
Defining user experience and business requirements determines which ClearPass functions are required for implementation. This guide lists ClearPass services and features used in most implementations.
The sections below outline key considerations when deploying ClearPass.
Cluster Design
ClearPass uses a Publisher/Subscriber model to provide multi-instance clustering. Another term for this model is hub and spoke, where the hub corresponds to the Publisher, and the spokes correspond to the Subscribers. This section provides guidance on how to design ClearPass clusters.
ClearPass can be deployed either as a dedicated hardware appliance, virtual machine running on top of VMware vSphere Hypervisor or Microsoft Hyper-V, or in the public cloud.
The Publisher node functions as the controller in a cluster. The Publisher is the central point of configuration, monitoring, reporting, and database replication. The Publisher manages all databases. There can be only one active Publisher in this model, with a potentially unlimited number of Subscribers. The Publisher node has full read/write access to the configuration database. All configuration changes must be made on the Publisher. The Publisher node sends configuration changes to each Subscriber node.
The Subscriber nodes are worker nodes. AAA load, RADIUS requests, and policy decisions are made on Subscriber nodes. Subscriber nodes maintain a read-only local copy of the configuration database.
Note: Refer to the Policy Manager Ordering and Sizing Guide on the Aruba Support Portal for additional ClearPass cluster guidance, or contact your Aruba account team.
The following factors determine the size of a Policy Manager cluster.
Determine how many endpoints must be authenticated.
The number of authenticating endpoints can be determined by taking the number of users times the number of devices per user.
To this total, add other endpoints that perform MAC-based authentication, such as printers and other non-authenticating endpoints.
Take into account the following factors:
Number and type of authentications and authorizations:
- MAC authentication/authorizations vs. PAP vs. EAP-MSCHAPv2 vs. PEAP-MSCHAPv2 vs. PEAP-GTC vs. EAP-TLS
- Active Directory vs. local database vs. external SQL datastore
- No posture assessment vs. in-band posture assessment in a PEAP tunnel vs. HTTPS-based posture assessment by OnGuard.
RADIUS accounting load
Operational tasks taking place during authentications, such as configuration activities, administrative tasks, replication load, periodic report generation, etc.
Disk space consumed
- Note that Policy Manager writes copious amounts of data for each transaction. (this data is displayed in the Access Tracker).
Publisher Design
The Publisher server must be sized appropriately because it handles database write operations from all Subscribers simultaneously. The Publisher also must be capable of handling the total-number of endpoints within the cluster and be capable of processing remote work directed to it when guest-account creation and onboarding occur.
To optimize Publisher performance in a large-scale environment, the Publisher should not receive direct authentication or Guest/Onboard requests, so that its resources can be dedicated to replication traffic and API requests from Subscribers.
If the worker traffic sent from the Subscriber servers is expected to fully saturate the capacity of the Publisher server, ClearPass Insight should not be enabled on the Publisher server. If the Publisher server has spare capacity, it can be used to support the Policy Manager Insight database. However, take care to monitor the Publisher server’s capacity and performance.
Subscriber Design
Network devices should use the nearest Subscriber to redirect Guest and Onboard clients. From the client’s point of view, the internal API call to the Publisher is handled transparently. The best response times for static resources are obtained if the server is nearby.
Subscriber should be used as workers to process the following:
- Authentication requests (RADIUS, TACACS+, Web-Auth)
- Online Certificate Status Protocol (OCSP) requests
- Static content delivery (images, CSS, JavaScript)
Avoid sending worker traffic to the Publisher, since the Publisher services API requests from Subscribers, handles the resulting database changes, and sends replication changes back to the Subscribers.
Verify that Online Certificate Status Protocol (OCSP) checks are enabled for EAP-TLS, if Onboard is configured. When using Onboard, ensure that the EAP-TLS authentication method in Policy Manager is configured to perform localhost OCSP checks.
Bandwidth and Latency Requirements
In a large-scale deployment, bandwidth congestion and high latency (greater than 200 ms) between network devices and a Subscriber may result in a low-quality user experience for users of that Subscriber.
For reliable operation of each Subscriber, ensure that there is sufficient bandwidth available for communications with the Publisher.
For basic authentication operations, there is no specific requirement for high bandwidth. However, the number of round-trips to complete an EAP authentication could cause delay for the end user.
It is important consider the delay between a Policy Manager server and a NAD/NAS (a controller or switch) when building geographically distributed clusters. In a large, geographically dispersed cluster, estimate the worst case round-trip time (RTT) between a NAS/NAD and all potential servers in the cluster that might handle authentication.
- Aruba recommends that the round-trip time between a NAD/NAS and a Policy Manager server should not exceed 600 ms.
- The acceptable delay between cluster servers is less than 100 ms. RTT should be less than 200 ms.
- The link bandwidth should be greater than 10 Mbps.
- Configure each NAD/NAS to reference multiple RADIUS servers that adhere to RTT guidance for load balancing and failover purposes.
Authentication Methods and Sources
Define the authentication methods used to allow or deny clients onto the network. The list of methods available includes, but is not limited to, PEAP, EAP-TLS, EAP-TTLS, and MAC-auth.
Identify all authentication sources needed to support the authentication methods defined in the previous step. Sources such as Active Directory, MDM solutions, and internal user or guest device repositories also can be included.
Consider which users and devices are onboarded to the network, and design an authentication flow to support it. Common methods include:
- 802.1x with EAP-TLS or PEAP for corporate-owned devices and users
- 802.1x with EAP-TLS for contractors, relying on OnBoard to provision the certificate
- MPSK + Device profiling for devices without a supplicant, such as IoT devices and printers
- Lobby registration or Enhanced Open with an acceptable use policy for guest users.
Enforcement Considerations
The following common enforcement methods are considered in depth in the Policy Enforcement design guide:
- Assign an Aruba Role, which is used by infrastructure to enforce policy
- Centralized role enforcement
- Distributed role enforcement
- Assign dynamic VLAN for segmentation
- Assign dynamic ACL for segmentation
Infrastructure Considerations
Use a standardized naming convention for VLANs across the campus so they can be referenced easily by ClearPass. For example, if the enterprise user VLAN ID and name vary by IDF, building, or floor, a complex Enforcement Policy is required to identify the appropriate VLAN ID to return based on the IDF name, subnet, etc. Service configuration is simplified by standardizing VLAN names, even if the IDs are different. Using this method, ClearPass needs to send only one standard response.