User Guide for Cisco Secure ACS for Windows Server 3.2
Deployment Considerations

Table Of Contents

Deployment Considerations

Basic Deployment Requirements for Cisco Secure ACS

System Requirements

Network and Port Requirements

Basic Deployment Factors for Cisco Secure ACS

Network Topology

Remote Access Policy

Security Policy

Administrative Access Policy


Network Latency and Reliability

Suggested Deployment Sequence

Deployment Considerations

Deployment of CiscoSecure ACS for WindowsServer 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 CiscoSecure ACS.

The complexity of deploying CiscoSecure ACS reflects the evolution of AAA servers in general, and the advanced capabilities, flexibility, and features of CiscoSecure 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, CiscoSecure 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 CiscoSecure ACSes, has become more common. Regardless of the scope of your CiscoSecure 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 topics:

Basic Deployment Requirements for CiscoSecure ACS

Basic Deployment Factors for CiscoSecure ACS

Suggested Deployment Sequence

Basic Deployment Requirements for Cisco Secure ACS

This section details the minimum requirements you must meet to successfully deploy CiscoSecure ACS.

This section contains the following topics:

System Requirements

Hardware Requirements

Operating System Requirements

Third-Party Software Requirements

Network and Port Requirements

System Requirements

The computer running CiscoSecure ACS must meet the minimum hardware and software requirements detailed in the following sections.

Hardware Requirements

The computer running CiscoSecure ACS must meet the following minimum hardware requirements:

Pentium III processor, 550 MHz or faster.

256 MB of RAM.

At least 250 MB of free disk space. If you are running your database on the same computer, more disk space is required.

Minimum graphics resolution of 256 colors at 800 x 600 lines.

Operating System Requirements

The computer running CiscoSecure ACS use an English-language version of Windows 2000 Server with Service Pack 3 installed. Both the operating system and the applicable service pack must be English-language versions.

Note Windows 2000 Advanced Server and Windows 2000 Datacenter Server are not supported.

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

For the most recent information about tested operating systems and service packs, see the Release Notes. The current version of the Release Notes are posted on, accessible from the following URL:

Third-Party Software Requirements

Note The Release Notes provide information about third-party software products that we tested with CiscoSecure ACS and that we support. Other than the software products described in the Release Notes, we have not tested the interoperability of CiscoSecure ACS and other software products on the same computer. We only support interoperability issues of software products that are mentioned in the Release Notes. The most recent version of the Release Notes are posted on, accessible from the following URL:

The computer running CiscoSecure ACS must have a supported browser installed. We tested CiscoSecure ACS using English-language versions of the following browsers on Microsoft Windows operating systems:

Microsoft Internet Explorer Version 5.5 and 6.0.

Netscape Communicator Version 7.0.

Note To use a web browser to access the CiscoSecure ACS HTML interface, you must enable both Java and JavaScript in the browser. Also, the web browser must not be configured to use a proxy server. For more information about other network environment factors that affect access to the HTML interface, see User Guide for CiscoSecure ACS for Windows Server, version 3.2.

For the most recent information about tested browsers and other third-party applications, such as Novell NDS clients and token-card clients, see the Release Notes. The most recent version of the Release Notes are posted on, accessible from the following URL:

Network and Port Requirements

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

For full TACACS+ and RADIUS support on Cisco IOS devices, AAA clients must run Cisco IOS Release 11.2 or later.

Non-Cisco IOS AAA clients must be configured with TACACS+ and/or RADIUS.

Dial-in, VPN, or wireless clients must be able to connect to the applicable AAA clients.

The computer running CiscoSecure ACS must be able to ping all AAA clients.

Gateway devices between CiscoSecure ACS and other network devices must permit communication over the ports needed to support the applicable feature or protocol. For information about ports listened to by CiscoSecure ACS, see Table2-1.

A supported web browser must be installed on the computer running CiscoSecure ACS. For the most recent information about tested browsers, see the Release Notes. The most recent version of the Release Notes are posted on, accessible from the following URL:

All network cards in the computer running CiscoSecure ACS must be enabled. If there is a disabled network card on the computer running CiscoSecure ACS, installing CiscoSecure ACS may proceed slowly due to delays caused by Microsoft CryptoAPI.

Note We tested CiscoSecure ACS on computers that only have one network interface card.

To have CiscoSecure ACS use the Grant Dial-in Permission to User feature in Windows when authorizing network users, this option must be selected in the Windows User Manager or Active Directory Users and Computers for the applicable user accounts.

Table2-1 lists the ports that CiscoSecure ACS listens to for communications with AAA clients, other CiscoSecure ACSes and applications, and web browsers. CiscoSecure ACS uses other ports to communicate with external user databases; however, it initiates those communications rather than listening to specific ports. In some cases, these ports are configurable, such as with LDAP and RADIUS token server databases. For more information about ports that a particular external user database listens to, see the documentation for that database.

Table 2-1 Ports that Cisco Secure ACS Listens To 


RADIUS authentication and authorization


1645, 1812

RADIUS accounting


1646, 1813




CiscoSecure Database Replication



RDBMS Synchronization with synchronization partners



User-Changeable Password web application






Administrative HTTP port for new sessions



Administrative HTTP port range


Configurable; default 1024 through 65535

Basic Deployment Factors for Cisco Secure ACS

Generally, the ease in deploying CiscoSecure 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 CiscoSecure ACS.

This section contains the following topics:

Network Topology

Remote Access Policy

Security Policy

Administrative Access Policy


Network Latency and Reliability

Network Topology

How your enterprise network is configured is likely to be the most important factor in deploying CiscoSecure 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 CiscoSecure 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, because of 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 Figure2-1, network architects typically place a single CiscoSecure ACS internal to the AAA client, protected from outside access by a firewall and the AAA client. In this environment, the user database is usually small, there are few devices that require access to the CiscoSecure ACS for AAA, and any database replication is limited to a secondary CiscoSecure ACS as a backup.

Figure 2-1 Small Dial-up Network

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

Figure 2-2 Large Dial-up Network

In a very large, geographically dispersed network ( Figure2-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 CiscoSecure ACS may work but connection reliability over long distances may cause problems. In this case, local CiscoSecure ACSes may be preferable to a central CiscoSecure ACS. If the need for a globally coherent user database is most important, database replication or synchronization from a central CiscoSecure ACS may be necessary. Authentication using external databases, such as a Windows user database or the Lightweight Directory Access Protocol (LDAP), can further complicate the deployment of distributed, localized CiscoSecure ACSes. While CiscoSecure ACS uses encryption for all replication and database synchronization traffic, additional security measures may be required to protect the network and user information that CiscoSecure ACS sends across the WAN.

Figure 2-3 Geographically Dispersed Network

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. 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 raises 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 ( Figure2-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 CiscoSecure ACS.

Figure 2-4 Simple WLAN

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 CiscoSecure ACS become a little more involved. Though Figure2-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 CiscoSecure ACS is similar to that of large regional distribution of dial-up LANs ( Figure2-3).

Figure 2-5 Campus WLAN

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 Figure2-4. This model may apply to a chain of small stores distributed throughout a city or state, nationally, or globally ( Figure2-6).

Figure 2-6 Large Deployment of Small Sites

For the model in Figure2-6, the location of CiscoSecure 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 CiscoSecure 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 ( Figure2-7). The benefits of a VPN include the following:

Cost Savings —By leveraging third-party networks with VPN, organizations no longer have to use expensive leased or frame relay lines and can connect remote users to their corporate networks via a local Internet service provider (ISP) instead of using expensive toll-free or long-distance calls to resource-consuming modem banks.

Security —VPNs provide the highest level of security using advanced encryption and authentication protocols that protect data from unauthorized access.

Scalability —VPNs allow corporations to use remote access infrastructure within ISPs; therefore, corporations can add a large amount of capacity without adding significant infrastructure.

Compatibility with Broadband Technology —VPNs allow mobile workers and telecommuters to take advantage of high-speed, broadband connectivity, such as DSL and cable, when gaining access to their corporate networks, providing workers significant flexibility and efficiency.

Figure 2-7 Simple VPN Configuration

There are two types of VPN access into a network:

Site-to-Site VPNs —Extend the classic WAN by providing large-scale encryption between multiple fixed sites such as remote offices and central offices, over a public network, such as the Internet.

Remote Access VPNs —Permit secure, encrypted connections between mobile or remote users and their corporate networks via a third-party network, such as an ISP, via VPN client software.

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 very effectively ( Figure2-8).

Figure 2-8 Enterprise VPN Solution

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 policies to the enterprise network topology. In addition to the method of access, other decisions can also affect how CiscoSecure 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 CiscoSecure ACS and the AAA client. Inside the enterprise network, remote access policies can control wireless access by individual employees.

CiscoSecure ACS remote access policies provides control by using central authentication and authorization of remote users. The CiscoSecure user database maintains all user IDs, passwords, and privileges. CiscoSecure 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.

Remote access policies are part of 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 CiscoSecure ACS.

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

Network Security Policy: Best Practices White Paper

Delivering End-to-End Security in Policy-Based Networks

Cisco IOS Security Configuration Guide

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 CiscoSecure 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, CiscoSecure ACS can be used with command authorization per network device to restrict network administrators as necessary. Using 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 CiscoSecure ACS does not require that you alter the privilege level of controlled commands. The AAA client sends the command to CiscoSecure ACS to be parsed and CiscoSecure 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 CiscoSecure ACS and limits 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. CiscoSecure ACS reduces this problem.

In large enterprise networks, with many devices to administer, the use of CiscoSecure 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 CiscoSecure ACS can comfortably handle up to 100,000 users, the number of network administrators that CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS this poses no problem. The administrator can have both RADIUS and TACACS+ configurations in CiscoSecure 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 in to the network as a general user, a AAA client would use RADIUS as the authenticating and 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 and authorization. Because this administrator is configured on CiscoSecure 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 CiscoSecure 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:

aaa new-model
tacacs-server host ip-address
tacacs-server key secret-key
radius-server host ip-address
radius-server key secret-key
aaa authentication ppp default group radius
aaa authentication login default group tacacs+ local
aaa authentication login console none
aaa authorization network default group radius
aaa authorization exec default group tacacs+ none
aaa authorization command 15 default group tacacs+ none
username user password password
line con 0
login authentication console

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


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

Number of Users

CiscoSecure 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 CiscoSecure 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 CiscoSecure 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

CiscoSecure ACS supports several 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, "User Databases," or "User Group Mapping and Specification" 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 CiscoSecure 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 CiscoSecure 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 WLAN, the loss of WAN connection to a remote CiscoSecure ACS could be catastrophic.

The same issue can be applied to an external database used by CiscoSecure ACS. The database should be deployed close enough to CiscoSecure ACS to ensure reliable and timely access. Using a local CiscoSecure ACS with a remote database can result in the same problems as using a remote CiscoSecure ACS. Another possible problem in this scenario is that a user may experience timeout problems. The AAA client would be able to contact CiscoSecure ACS, but CiscoSecure ACS would wait for a reply that might be delayed or never arrive from the external user database. If the CiscoSecure 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 CiscoSecure 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.

Configure Administrators —You should configure at least one administrator at the outset of deployment; otherwise, there is no remote administrative access and all configuration activity must be done from the server. You should also have a detailed plan for establishing and maintaining an administrative policy.

For more information about setting up administrators, see "Overview"

Configure the CiscoSecure ACS HTML Interface —You can configure the CiscoSecure ACS HTML interface to show only those features and controls that you intend to use. This makes using CiscoSecure ACS less difficult than it would be if you had to contend with multiple parts of the HTML interface that you do not plan to use. The price of this convenience can sometimes be frustration that features and controls do not appear because you failed to configure them in the Interface Configuration section. For guidance on configuring the HTML interface, see Interface Design Concepts.

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

User Data Configuration Options

Advanced Options

Protocol Configuration Options for TACACS+

Protocol Configuration Options for RADIUS

Configure System —There are more than a dozen functions within the System Configuration section to be considered, from setting the format for the display of dates and password validation to configuring settings for database replication and RDBMS synchronization. These functions are detailed in "System Configuration: Basic" Of particular note during initial system configuration is setting up the logs and reports to be generated by CiscoSecure ACS; for more information, see "Overview"

Configure Network —You control distributed and proxied AAA functions in the Network Configuration section of the HTML interface. From here, you establish the identity, location, and grouping of AAA clients and servers, and determine what authentication protocols each is to use. For more information, see "Network Configuration"

Configure External User Database —During this phase of deployment you must decide whether and how you intend to implement an external database to establish and maintain user authentication accounts. Typically, this decision is made according to your existing network administration mechanisms. For information about the types of databases CiscoSecure ACS supports and instructions for establishing them, see "User Databases"

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

Configure Shared Profile Components —With most aspects of network configuration already established and before configuring user groups, you should configure your Shared Profile Components. When you set up and name the network access restrictions and command authorization sets you intend to employ, you lay out an efficient basis for specifying user group and single user access privileges. For more information about Shared Profile Components, see "Shared Profile Components"

Configure Groups —Having previously configured any external user databases you intend to employ, and before configuring your user groups, you should decide how to implement two other CiscoSecure ACS features related to external user databases: unknown user processing and database group mapping. For more information, see Unknown User Processing, and "User Group Mapping and Specification" Then, you can configure your user groups with a complete plan of how CiscoSecure ACS is to implement authorization and authentication. For more information, see "User Group Management"

Configure Users —With groups established, you can establish user accounts. Remember that a particular user can belong to only one user group, and that settings made at the user level override settings made at the group level. For more information, see "User Management"

Configure Reports —Using the Reports and Activities section of the CiscoSecure ACS HTML interface, you can specify the nature and scope of logging that CiscoSecure ACS performs. For more information, see "Overview"