ACS 5.8.1 Deployment Overview
The ACS 5.8.1 deployment model, which is similar to ACS 4.x, consists of a single primary and multiple secondary ACS servers, where configuration changes are made on the primary ACS server. These configurations are replicated to the secondary ACS servers.
All primary and secondary ACS servers can process AAA requests. The primary ACS server is also the default log collector for the Monitoring and Report Viewer, although you can configure any ACS server to be the log collector.
Although you can manage with a single ACS server, we recommend that you have two or more ACS servers, to provide AAA request processing redundancy. ACS 5.8.1 provides syslog support for external logging, and interfaces for automated and batch configuration provisioning.
An ACS deployment can scale for increased AAA request processing capacity by adding secondary servers. In large deployments, the secondary servers can be dedicated for specific functions. For example, you can use the primary ACS server only for configuration changes and not for processing AAA requests. You can designate a secondary ACS server only as the log collector.
In large environments, you can use load balancers to distribute AAA requests among the ACS servers in the deployment, simplify AAA client management, and provide high availability.
ACS servers are typically placed in the data centers or close to user clusters, for example, at regional sites.
For additional deployment information, see Understanding the ACS Server Deployment in the Installation and Upgrade Guide for Cisco Secure Access Control System 5.8.1.
Table 1 describes the various ACS server roles.
Table 1 ACS Server Roles
|
|
Primary |
Configuration changes performed on the primary ACS server are replicated to all the secondary ACS servers in the deployment. At a time, you can have only one ACS server as the primary server. |
Secondary |
All ACS servers that receive configuration changes from the ACS primary server, are secondary servers. |
Log Collector |
ACS primary or secondary server that is also the log collector for the Monitoring and Report Viewer. There can only be one log collector in a deployment. Other ACS deployments (servers not synchronized with this deployment) cannot send ACS logs to this server. |
The following sections describe the deployment differences between ACS 4.x and ACS 5.8.1, as well as some considerations when deploying ACS 5.8.1:
■Windows Versus Linux-Based Applications
■Replication
■Identity Stores
■Logging
■Configuration
■Licensing
■Server Deployment Recommendations
Windows Versus Linux-Based Applications
ACS 3.x and 4.x releases are available as Windows-based applications that can be installed on a Windows server platform. These applications are also available on an appliance called the ACS Solution Engine. This appliance is a hardware platform that is preloaded with ACS and Windows operating systems.
ACS 5.8.1 is a Linux-flavour application and is packaged with a Linux operating system. The application and the operating system package are shipped on an appliance, and they can also be installed in a virtual machine on a VMware ESXi Server.
There are functional and deployment differences between ACS for Windows and the ACS Solution Engine, but there is no functional difference between the ACS 5.8.1 hardware appliance and the ACS 5.8.1 installed on a virtual machine. Deployments that consist of ACS 5.8.1 hardware appliances and ACS 5.8.1 virtual machines are also supported.
Replication
ACS 3.x and 4.x provide a loose replication model. The characteristics of the ACS 3.x and 4.x replication model are:
■The configuration blocks represent logical areas of ACS configuration. For example, users and usergroups, usergroups only, network devices, distribution table, interface configuration, interface security settings, password validation settings, EAP-FAST settings, network access profiles, and logging configuration.
■The option to replicate one or more of the configuration blocks from the primary to secondary server.
■The whole block is replicated, regardless of the size of the configuration change.
■Cascading replication, which is the ability for a secondary ACS server to push a replication update to another ACS server.
■Replication can be initiated manually or according to a schedule.
■TACACS+ password updates are received on the primary server only.
In this loose replication model, the replicated blocks are synchronized between the primary and secondary servers, but other parts of the configuration can be different and tailored for the local environment.
The ACS 5.8.1 replication model is simple, efficient, and robust. The characteristics of the ACS 5.8.1 replication model are:
■Full synchronization between the primary and secondary servers.
■Transparent and immediate replication.
■Only configuration changes are replicated.
■Configuration changes can be made only on the primary server.
■No cascading replication.
■Automatic recovery for missed updates.
■Ability to promote a secondary server to primary server.
■TACACS+ password updates can be received on any ACS instance.
A region-specific access policy must be implemented in the ACS 5.8.1 network access policy configuration. This is because ACS 5.8.1 configuration is fully synchronized between the primary and secondary servers, and configuration changes cannot be made directly to the secondary servers.
Identity Stores
The main difference related to identity store support between ACS 3.x and 4.x and 5.8.1 is that ACS 5.8.1 does not support Open Database Connectivity (ODBC) for authentication to databases and proxy forwarding of TACACS+ requests. ACS 5.8.1 supports the following identity stores for authentication:
■ACS internal store
■Active Directory
■Lightweight Directory Access Protocol (LDAP) directories
■One-time password servers, using the
–RSA SecurID interface
–RADIUS interface
■Proxy forwarding to other stores through RADIUS (RADIUS proxy)
Logging
In ACS 5.8.1, the Monitoring and Report Viewer functionality is part of ACS. In an ACS 5.8.1 deployment, an ACS server is designated as the log collector for the reporting and monitoring functionality. All of the other ACS servers send log messages to the designated log collector.
ACS supports syslog for logging to external servers.
ACS 5.8.1 provides a web service interface for the Cisco Wireless Control System (WCS) to obtain user authentication information from the Monitoring and Report Viewer.
Configuration
In ACS 5.8.1, the primary mode for configuration is a web-based user interface. ACS 5.8.1 also has a command-line interface (CLI) through which system tasks and file-based configuration updates can be made.
You can access the CLI from the console port, keyboard, video, mouse (KVM), and SSH. A web-service interface is provided to develop password change applications for internal ACS users.
Table 2 provides the number of internal users and network devices supported by ACS. Users and network devices are the commonly used and largely populated ACS objects.
Table 2 Internal Users and Device Configuration Capacity
|
|
Internal Users |
300,000 |
Internal Hosts |
150,000 |
Network Devices |
100,000 |
Licensing
The 3.x and 4.x releases of ACS did not require application of the key or license files. However, you need to apply a license file for the 5.x releases. The ACS 5.8.1 licenses are available at: http://cisco.com/go/license
Table 3 lists the available ACS 5.8.1 licenses.
Table 3 Available ACS 5.8.1 Licenses
|
|
Base Server |
One for each ACS instance. |
Large Deployment |
One for each ACS deployment when the network device count (based on IP address) in ACS exceeds 500. Configuring the Default Network Device contributes to the device count. |
Server Deployment Recommendations
Table 4 describes the component mapping from ACS 3.x and 4.x to ACS 5.8.1.
Table 4 Component Mapping
ACS 3.x and 4.x Component
|
|
|
ACS for Windows |
VM in VMware ESXi, 1121, 3415, 3495, 3515, or 3595 appliance |
There is no ACS 5.8.1 Windows option. ACS 5.8.1 is an application that can run on a VMware or supported appliance. |
ACS Solution Engine (1111, 1112, 1113) |
VM in VMware ESXi, 1121, 3415, 3495, 3515, or 3595 appliance |
ACS 1111, 1112 and 1113 platforms do not support ACS 5.8.1. ACS 4.2 can run on the 1120. |
ACS Remote Agent |
N/A |
Remote Agent is not required in ACS 5.8.1. |
ACS View 4.0 |
VM in VMware ESXi, 1121, 3415, 3495, 3515, or 3595 appliance |
ACS 5.8.1 has built-in ACS View functionality. |
Deployment guidelines for ACS 5.8.1:
■In most cases, a one-to-one ACS server replacement is appropriate.
The authentication performance of ACS 5.8.1 is same as the previous versions.
■Deploy at least two ACS instances to provide redundancy.
■Add more ACS servers to scale the authentication performance.
Ensure that a single ACS server can handle peak authentication rates of its AAA clients and any AAA clients that rely on it as a backup AAA server.
■You can use secondary ACS servers to process AAA requests only to scale a deployment environment. Use the primary for configuration updates and log collection only.
Use the most powerful hardware for the log collector. For example, the Cisco SNS-3515, Cisco SNS-3595, Cisco SNS-3415 or Cisco SNS-3495 appliances over the 1121 appliance.
■Use load balancers to receive AAA requests, simplify AAA client management, improve resiliency, and better utilize ACS authentication capacity.
■Monitor the ongoing resource utilization. You can do this by enabling the ACS system health alarm threshold in the Monitoring and Report Viewer, as shown in Figure 1.
Figure 1 Alarm Threshold in ACS 5.8.1