Filter
Top Products
2-17
Configuration Guide for Cisco Secure ACS 4.2
OL-14390-02
Chapter 2 Deploy the Access Control Servers
Additional Topics
access, other decisions can also affect how 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.
You can implement remote-access policies for employees who telecommute, or mobile users who dial
in over ISDN or a public switched telephone network (PSTN). Such policies are enforced at the
corporate campus with ACS and the AAA client. Inside the enterprise network, remote-access policies
can control wireless access by individual employees.
ACS remote-access policies provide control by using central authentication and authorization of remote
users. The Cisco user database maintains all user IDs, passwords, and privileges. You can download ACS
policies 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 the overall Cisco corporate security policy.
Security Policy
Every organization that maintains a network should develop a security policy for the organization. The
sophistication, nature, and scope of your security policy directly affect how you deploy ACS.
For more information about developing and maintaining a comprehensive security policy, refer to these
documents:
• Network Security Policy: Best Practices White Paper
• 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. A network device can be authenticated locally; but, this ability is not scalable. The use of
network management tools can help in large networks (25,000 to 50,000 users); but, if local
authentication is used on each network device, the policy usually entails a single login on the network
device. A single login on the network device does not provide adequate network device security.
ACS provides a centralized administrator database, and you can add or delete administrators 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 the time of initial authentication.
The type of access is also an important consideration. In the case of different administrative access levels
to the AAA clients, or if a subset of administrators is to be limited to certain systems, you can use ACS
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 by using privilege
levels to control access.
Controlling access by means of privilege levels is cumbersome and not very scalable. Such control
requires altering the privilege levels of specific commands on the AAA client device and defining
specific privilege levels for the user login. You can easily create more problems by editing command
privilege levels. Using command authorization on ACS does not require that you alter the privilege level
of controlled commands. The AAA client sends the command to ACS to be parsed and ACS determines
whether the administrator has permission to use the command. The use of AAA allows authentication
on any AAA client for any user on ACS and limits access to these devices on a per-AAA-client basis.