Table of Contents

Deploying Cisco Secure ACS

Deployment of Cisco Secure Access Control Server (Cisco Secure ACS) for Windows Server version 3.1 can be complex and iterative, depending on the specific implementation required. This chapter provides insight into the deployment process and presents a collection of factors that you should consider before deploying Cisco Secure ACS.

The complexity of deploying Cisco Secure ACS reflects the evolution of AAA servers in general, and the advanced capabilities, flexibility, and features of Cisco Secure ACS in particular. AAA was conceived originally to provide a centralized point of control for user access via dial-up services. As user databases grew and the locations of AAA clients became more dispersed, more capability was required of the AAA server. Regional, and then global, requirements became common. Today, Cisco Secure ACS is required to provide AAA services for dial-up access, dial-out access, wireless, VLAN access, firewalls, VPN concentrators, administrative controls, and more. The list of external databases supported has also continued to grow and the use of multiple databases, as well as multiple Cisco Secure ACSes, has become more common. Regardless of the scope of your Cisco Secure ACS deployment, the information contained in this chapter should prove valuable. If you have deployment questions that are not addressed in this guide, contact your Cisco technical representative for assistance.

This chapter contains the following sections:

Basic Deployment Requirements for Cisco Secure ACS

This section details the minimum requirements you must meet to be able to successfully deploy Cisco Secure ACS. The following topics are covered:

System Requirements

Your Cisco Secure ACS server must meet the minimum hardware and software requirements detailed in the following sections.

Hardware Requirements

Your Cisco Secure ACS server must meet the following minimum hardware requirements:

Operating System Requirements

The server that runs Cisco Secure ACS should use an English-language version of Windows 2000 Server with Service Pack 3 installed.

Note   Both the operating system and the applicable service pack must be English-language versions.

Windows service packs can be applied either before or after installing Cisco Secure ACS. If you do not install a required service pack before installing Cisco Secure ACS, the Cisco Secure ACS installation program may warn you that the required service pack is not present on your server. If you receive a service pack message, continue the installation, and then install the required service pack before starting user authentication with Cisco Secure ACS.

Note   Beginning with Cisco Secure ACS version 3.1, we no longer support running Cisco Secure ACS on a Windows NT 4.0 server. For information about upgrading the operating system of a server running Cisco Secure ACS, see the Installation Guide for Cisco Secure ACS for Windows Server, version 3.1.

For the latest information about tested operating systems and service packs, see the Release Notes. The latest version of the Release Notes are posted on Cisco.com atthe following URL:

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/csacs4nt/

Third-Party Software Requirements

The Windows server that runs Cisco Secure ACS must have a compatible browser installed. We tested Cisco Secure ACS with English-language versions of the following browsers on Microsoft Windows operating systems:

For the latest information about tested browsers and other third-party applications, see the Release Notes. The latest version of the Release Notes are posted on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/csacs4nt/
index.htm.

Network Requirements

Your network should meet the following requirements before you begin deploying Cisco Secure ACS.

Basic Deployment Factors for Cisco Secure ACS

Generally, the ease in deploying Cisco Secure ACS is directly related to the complexity of the implementation planned and the degree to which you have defined your policies and requirements. This section presents some basic factors you should consider before you begin implementing Cisco Secure ACS.

This section includes the following topics:

Network Topology

How your enterprise network is configured is likely to be the most important factor in deploying Cisco Secure ACS. While an exhaustive treatment of this topic is beyond the scope of this guide, this section details how the growth of network topology options has made Cisco Secure ACS deployment decisions more complex.

When AAA was created, network access was restricted to either devices directly connected to the LAN or remote devices gaining access via modem. Today, enterprise networks can be complex and, thanks to tunneling technologies, can be widely geographically dispersed.

Dial-Up Topology

In the traditional model of dial-up access (a PPP connection), a user employing a modem or ISDN connection is granted access to an intranet via a network access server (NAS) functioning as a AAA client. Users may be able to connect via only a single AAA client as in a small business, or have the option of numerous geographically dispersed AAA clients.

In the small LAN environment, see Figure 2-1, network architects typically place a single Cisco Secure ACS internal to the AAA client, protected from outside access by means of a firewall and the AAA client. In this environment, the user database is usually small, there are few devices that require access to the Cisco Secure ACS for AAA, and any database replication is limited to a secondary Cisco Secure ACS as a backup.

In a larger dial-in environment, a single Cisco Secure ACS installation with a backup may be suitable, too. The suitability of this configuration depends on network and server access latency. Figure 2-2 shows an example of a large dial-in arrangement. In this scenario the addition of a backup Cisco Secure ACS is a recommended addition.

In a very large, geographically dispersed network (Figure 2-3), there may be access servers located in different parts of a city, in different cities, or on different continents. If network latency is not an issue, a central Cisco Secure ACS may work but connection reliability over long distances may cause problems. In this case, local Cisco Secure ACSes may be preferable to a central Cisco Secure ACS. If the need for a globally coherent user database is most important, database replication or synchronization from a central Cisco Secure ACS may be necessary. Authentication using external databases, such as Windows NT/2000 or the Lightweight Directory Access Protocol (LDAP), can further complicate the deployment of distributed, localized Cisco Secure ACSes. While Cisco Secure ACS uses encryption for all replication and database synchronization traffic, additional security measures may be required to protect the network and user information that Cisco Secure ACS sends across the WAN.

Wireless Network

The wireless network access point is a relatively new client for AAA services. The wireless access point (AP), such as the Cisco Aironet series, provides a bridged connection for mobile end-user clients into the LAN. Authentication is absolutely necessary due to the ease of access to the AP. Encryption is also necessary because of the ease of eavesdropping on communications. As such, security plays an even bigger role than in the dial-up scenario and is discussed in more detail later in this section.

Scaling can be a serious issue in the wireless network. Like the "wired" LAN, the mobility factor of the wireless LAN (WLAN) requires considerations similar to those given to the dial-up network. Unlike the wired LAN, however, the WLAN can be more readily expanded. Though WLAN technology does have physical limits as to the number of users that can be connected via an AP, the number of APs can grow quickly. As with the dial-up network, you can structure your WLAN to allow full access for all users, or to provide restricted access to different subnets between sites, buildings, floors, or rooms. This brings up a unique issue with the WLAN: the ability of a user to "roam" between APs.

In the simple WLAN, there may be a single AP installed (Figure 2-4). Because there is only one AP, the primary issue is security. In this environment, there is generally a small user base and few network devices to worry about. Providing AAA services to the other devices on the network does not cause any significant additional load on the Cisco Secure ACS.

In the LAN where a number of APs are deployed, as in a large building or a campus environment, your decisions on how to deploy Cisco Secure ACS become a little more involved. Though Figure 2-5 shows all APs on the same LAN, they may be distributed throughout the LAN, connected via routers, switches, and so on. In the larger, geographical distribution of WLANs, deployment of Cisco Secure ACS is similar to that of large regional distribution of dial-up LANs (Figure 2-3).

This is particularly true when the regional topology is the campus WLAN. This model starts to change when you deploy WLANs in many small sites that more resemble the simple WLAN shown in Figure 2-4. This model may apply to a chain of small stores distributed throughout a city or state, nationally, or globally (Figure 2-6).

For the model in Figure 2-6, the location of Cisco Secure ACS depends on whether all users need access on any AP, or whether users require only regional or local network access. Along with database type, these factors control whether local or regional Cisco Secure ACSes are required, and how database continuity is maintained. In this very large deployment model, security becomes a more complicated issue, too.

Remote Access using VPN

Virtual Private Networks (VPNs) use advanced encryption and tunneling to permit organizations to establish secure, end-to-end, private network connections over third-party networks, such as the Internet or extranets (Figure 2-7). The benefits of a VPN include the following:

There are two types of VPN access into a network:

Generally speaking, site-to-site VPNs can be viewed as a typical WAN connection and are not usually configured to use AAA to secure the initial connection and are likely to use the device-oriented IPSec tunneling protocol. Remote Access VPNs, however, are similar to classic remote connection technology (modem/ISDN) and lend themselves to using the AAA model effectively (Figure 2-8).

For more information about implementing VPN solutions, see the reference guide A Primer for Implementing a Cisco Virtual Private Network.

Remote Access Policy

Remote access is a broad concept. In general, it defines how the user can connect to the LAN, or from the LAN to outside resources (that is, the Internet). There are several ways this may occur. The methods include dial-in, ISDN, wireless bridges, and secure Internet connections. Each method incurs its own advantages and disadvantages, and provides a unique challenge to providing AAA services. This closely ties remote access policy to the enterprise network topology. In addition to the method of access, other decisions can also affect how Cisco Secure ACS is deployed; these include specific network routing (access lists), time-of-day access, individual restrictions on AAA client access, access control lists (ACLs), and so on.

Remote access policies can be implemented for employees who telecommute or for mobile users who dial in over ISDN or public switched telephone network (PSTN). Such policies are enforced at the corporate campus with Cisco Secure ACS and the AAA client. Inside the enterprise network, remote access policies can control wireless access by individual employees.

Cisco Secure ACS remote access policy provides control by using central authentication and authorization of remote users. The CiscoSecure user database maintains all user IDs, passwords, and privileges. Cisco Secure ACS access policies can be downloaded in the form of ACLs to network access servers such as the Cisco AS5300 Network Access Server, or by allowing access during specific periods, or on specific access servers.

The remote access policy is part of the overall corporate security policy.

Security Policy

We recommend that every organization that maintains a network develop a security policy for the organization. The sophistication, nature, and scope of your security policy directly affect how you deploy Cisco Secure ACS.

For more information about developing and maintaining a comprehensive security policy, refer to the following documents:

Administrative Access Policy

Managing a network is a matter of scale. Providing a policy for administrative access to network devices depends directly on the size of the network and the number of administrators required to maintain the network. Local authentication on a network device can be performed, but it is not scalable. The use of network management tools can help in large networks, but if local authentication is used on each network device, the policy usually consists of a single login on the network device.This does not promote adequate network device security. Using Cisco Secure ACS allows a centralized administrator database, and administrators can be added or deleted at one location. TACACS+ is the recommended AAA protocol for controlling AAA client administrative access because of its ability to provide per-command control (command authorization) of AAA client administrator access to the device. RADIUS is not well-suited for this purpose because of the one-time transfer of authorization information at time of initial authentication.

The type of access is also an important consideration. If there are to be different administrative access levels to the AAA clients, or if a subset of administrators is to be limited to certain systems, Cisco Secure ACS can be used with command authorization per network device to restrict network administrators as necessary. To use local authentication restricts the administrative access policy to no login on a device or using privilege levels to control access. Controlling access by means of privilege levels is cumbersome and not very scalable. This requires that the privilege levels of specific commands are altered on the AAA client device and specific privilege levels are defined for the user login. It is also very easy to create more problems by editing command privilege levels. Using command authorization on Cisco Secure ACS does not require that you alter the privilege level of controlled commands. The AAA client sends the command to Cisco Secure ACS to be parsed and Cisco Secure ACS determines whether the administrator has permission to use the command. The use of AAA allows authentication on any AAA client to any user on Cisco Secure ACS and facilitates the limitation of access to these devices on a per-AAA client basis.

A small network with a small number of network devices may require only one or two individuals to administer it. Local authentication on the device is usually sufficient. If you require more granular control than that which authentication can provide, some means of authorization is necessary. As discussed earlier, controlling access using privilege levels can be cumbersome. Cisco Secure ACS reduces this problem.

In large enterprise networks, with many devices to administer, the use of Cisco Secure ACS becomes a practical necessity. Because administration of many devices requires a larger number of network administrators, with varying levels of access, the use of local control is simply not a viable way of keeping track of network device configuration changes required when changing administrators or devices. The use of network management tools, such as CiscoWorks 2000, helps to ease this burden, but maintaining security is still an issue. Because Cisco Secure ACS can comfortably handle up to 100,000 users, the number of network administrators that Cisco Secure ACS supports is rarely an issue. If there is a large remote access population using RADIUS for AAA support, the corporate IT team should consider separate TACACS+ authentication using Cisco Secure ACS for the administrative team.This would isolate the general user population from the administrative team and reduce the likelihood of inadvertent access to network devices. If this is not a suitable solution, using TACACS+ for administrative (shell/exec) logins, and RADIUS for remote network access, provides sufficient security for the network devices.

Separation of Administrative and General Users

It is important to keep the general network user from accessing network devices. Even though the general user may not intend to gain unauthorized access, inadvertent access could accidentally disrupt network access. AAA and Cisco Secure ACS provide the means to separate the general user from the administrative user.

The easiest, and recommended, method to perform such separation is to use RADIUS for the general remote access user and TACACS+ for the administrative user. An issue that arises is that an administrator may also require remote network access, like the general user. If you use Cisco Secure ACS this poses no problem. The administrator can have both RADIUS and TACACS+ configurations in Cisco Secure ACS. Using authorization, RADIUS users can have PPP (or other network access protocols) set as the permitted protocol. Under TACACS+, only the administrator would be configured to allow shell (exec) access.

For example, if the administrator is dialing into the network as a general user, a AAA client would use RADIUS as the authenticating/authorizing protocol and the PPP protocol would be authorized. In turn, if the same administrator remotely connects to a AAA client to make configuration changes, the AAA client would use the TACACS+ protocol for authentication/authorization. Because this administrator is configured on Cisco Secure ACS with permission for shell under TACACS+, he would be authorized to log in to that device. This does require that the AAA client have two separate configurations on Cisco Secure ACS, one for RADIUS and one for TACACS+. An example of a AAA client configuration under IOS that effectively separates PPP and shell logins follows:

Conversely, if a general user attempts to use his or her remote access to log in to a network device, Cisco Secure ACS checks and approves the username and password, but the authorization process would fail because that user would not have credentials that allow shell/exec access to the device.

Database

Aside from topological considerations, the user database is one of the most influential factors involved in making deployment decisions for Cisco Secure ACS. The size of the user base, distribution of users throughout the network, access requirements, and type of user database contribute to how Cisco Secure ACS is deployed.

Number of Users

Cisco Secure ACS is designed for the enterprise environment, comfortably handling 100,000 users. This is usually more than adequate for a corporation. In an environment that exceeds these numbers, the user base would typically be geographically dispersed, which lends itself to the use of more than one Cisco Secure ACS configuration. A WAN failure could render a local network inaccessible because of the loss of the authentication server. In addition to this issue, reducing the number of users that a single Cisco Secure ACS handles improves performance by lowering the number of logins occurring at any given time and by reducing the load on the database itself.

Type of Database

Cisco Secure ACS supports a number of database options, including the CiscoSecure user database or using remote authentication with any of the external databases supported. For more information about database options, types, and features, see Authentication and User Databases, or "Working with User Databases," or "Administering External User Databases." Each database option has its own advantages and limitations in scalability and performance.

Network Latency and Reliability

Network latency and reliability are also important factors in how you deploy Cisco Secure ACS. Delays in authentication can result in timeouts at the end-user client or the AAA client.

The general rule for large, extended networks, such as a globally dispersed corporation, is to have at least one Cisco Secure ACS deployed in each region. This may not be adequate without a reliable, high-speed connection between sites. Many corporations use secure VPN connections between sites so that the Internet provides the link. This saves time and money but it does not provide the speed and reliability that a dedicated frame relay or T1 link provides. If reliable authentication service is critical to business functionality, such as retail outlets with cash registers that are linked by a wireless LAN, the loss of WAN connection to a remote Cisco Secure ACS could be catastrophic.

The same issue can be applied to an external database used by Cisco Secure ACS. The database should be deployed close enough to Cisco Secure ACS to ensure reliable and timely access. Using a local Cisco Secure ACS with a remote database can result in the same problems as using a remote Cisco Secure ACS. Another possible problem in this scenario is that a user may experience timeout problems. The AAA client would be able to contact Cisco Secure ACS, but Cisco Secure ACS would wait for a reply that might be delayed or never arrive from the external user database. If the Cisco Secure ACS were remote, the AAA client would time out and try an alternative method to authenticate the user, but in the latter case, it is likely the end-user client would time out first.

Suggested Deployment Sequence

While there is no single process for all Cisco Secure ACS deployments, you should consider following the sequence, keyed to the high-level functions represented in the navigation toolbar. Also bear in mind that many of these deployment activities are iterative in nature; you may find that you repeatedly return to such tasks as interface configuration as your deployment proceeds.

For more information about setting up administrators, see "Setting Up and Managing Administrators and Policy."

For information about configuring particular aspects of the HTML interface, see the following sections of the interface configuration chapter:

Along with the decision to implement an external user database (or databases), you should have detailed plans that specify your requirements for Cisco Secure ACS database replication, backup, and synchronization. These aspects of configuring CiscoSecure user database management are detailed in "Establishing Cisco Secure ACS System Configuration."