-
User Guide for Cisco Secure ACS Solution Engine Version 3.3
-
Preface
-
Overview
-
Deployment Considerations
-
Interface Configuration
-
Network Configuration
-
Shared Profile Components
-
User Group Management
-
User Management
-
System Configuration: Basic
-
System Configuration: Advanced
-
System Configuration: Authentication and Certificates
-
Logs and Reports
-
Administrators and Administrative Policy
-
User Databases
-
Network Admission Control
-
Unknown User Policy
-
User Group Mapping and Specification
-
Troubleshooting
-
TACACS+ Attribute-Value Pairs
-
RADIUS Attributes
-
VPDN Processing
-
RDBMS Synchronization Import Definitions
-
Internal Architecture
-
Feedback
Table Of Contents
Basic Deployment Requirements for Cisco Secure ACS
System Installation Requirements
Basic Deployment Factors for Cisco Secure ACS
Separation of Administrative and General Users
Network Latency and Reliability
Deployment Considerations
Deployment of Cisco Secure ACS Solution Engine 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 topics:
•
Basic Deployment Requirements for Cisco Secure ACS
•
•
Basic Deployment Requirements for Cisco Secure ACS
This section details the minimum requirements you must meet to successfully deploy Cisco Secure ACS.
This section contains the following topics:
•
•
System Installation Requirements
Before fully configuring and deploying a Cisco Secure ACS Solution Engine, you must properly install the appliance. For information and procedures about installing an appliance, see Installation and Setup Guide for Cisco Secure ACS Solution Engine.
Network and Port Requirements
Your network should meet the following requirements before you begin deploying Cisco Secure ACS.
•
•
•
•
•
•
Table 2-1 lists the ports that Cisco Secure ACS listens to for communications with AAA clients, other Cisco Secure ACSes and applications, and web browsers. Cisco Secure 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.
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 contains 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, 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 Figure 2-1, network architects typically place a single Cisco Secure 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 Cisco Secure ACS for AAA, and any database replication is limited to a secondary Cisco Secure ACS as a backup.
Figure 2-1 Small Dial-up Network
In a larger dial-in environment, a single Cisco Secure ACS 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.
Figure 2-2 Large Dial-up Network
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 a Windows user database 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.
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 (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.
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 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).
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 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).
Figure 2-6 Large Deployment of Small Sites
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:
•
•
•
•
Figure 2-7 Simple VPN Configuration
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 very effectively (Figure 2-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 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 policies 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.
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 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. 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 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 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. 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 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 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:
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 consoleConversely, 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 or 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 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 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 WLAN, 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, one-size-fits-all 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 "Overview".
•
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 "System Configuration: Basic".
•
•
•
•
