Ccna Security

Cisco Secure ACS v3.
0 2002 Cisco Systems, Inc 1

Cisco Secure
Access Control Server (ACS) v3.0
User Authentication, Authorization, and
Accounting (AAA)
1
Tutorial Revision 3/02
Cisco Secure ACS v3.0 2002 Cisco Systems, Inc 2
The products and specifications, configurations, and other technical information regarding the products in this manual are subject to change
without notice. All statements, technical information, and recommendations in this manual are believed to be accurate but are presented without
warranty of any kind, express or implied. You must take full responsibility for their application of any products specified in this manual.
LICENSE
PLEASE READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THE MANUAL, DOCUMENTATION, AND/OR SOFTWARE
(MATERIALS). BY USING THE MATERIALS YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS OF THIS LICENSE. IF YOU
DO NOT AGREE WITH THE TERMS OF THIS LICENSE, PROMPTLY RETURN THE UNUSED MATERIALS (WITH PROOF OF PAYMENT)
TO THE PLACE OF PURCHASE FOR A FULL REFUND.
Cisco Systems, Inc. (Cisco) and its suppliers grant to you (You) a nonexclusive and nontransferable license to use the Cisco Materials solely
for Your own personal use. If the Materials include Cisco software (Software), Cisco grants to You a nonexclusive and nontransferable license
to use the Software in object code form solely on a single central processing unit owned or leased by You or otherwise embedded in equipment
provided by Cisco. You may make one (1) archival copy of the Software provided You affix to such copy all copyright, confidentiality, and
proprietary notices that appear on the original. EXCEPT AS EXPRESSLY AUTHORIZED ABOVE, YOU SHALL NOT: COPY, IN WHOLE OR IN
PART, MATERIALS; MODIFY THE SOFTWARE; REVERSE COMPILE OR REVERSE ASSEMBLE ALL OR ANY PORTION OF THE
SOFTWARE; OR RENT, LEASE, DISTRIBUTE, SELL, OR CREATE DERIVATIVE WORKS OF THE MATERIALS.
You agree that aspects of the licensed Materials, including the specific design and structure of individual programs, constitute trade secrets
and/or copyrighted material of Cisco. You agree not to disclose, provide, or otherwise make available such trade secrets or copyrighted material
in any form to any third party without the prior written consent of Cisco. You agree to implement reasonable security measures to protect such
trade secrets and copyrighted Material. Title to the Materials shall remain solely with Cisco.
This License is effective until terminated. You may terminate this License at any time by destroying all copies of the Materials. This License will
terminate immediately without notice from Cisco if You fail to comply with any provision of this License. Upon termination, You must destroy all
copies of the Materials.
Software, including technical data, is subject to U.S. export control laws, including the U.S. Export Administration Act and its associated
regulations, and may be subject to export or import regulations in other countries. You agree to comply strictly with all such regulations and
acknowledge that it has the responsibility to obtain licenses to export, re-export, or import Software.
This License shall be governed by and construed in accordance with the laws of the State of California, United States of America, as if
performed wholly within the state and without giving effect to the principles of conflict of law. If any portion hereof is found to be void or
unenforceable, the remaining provisions of this License shall remain in full force and effect. This License constitutes the entire License between
the parties with respect to the use of the Materials
Restricted Rights - Ciscos software is provided to non-DOD agencies with RESTRICTED RIGHTS and its supporting documentation is provided
with LIMITED RIGHTS. Use, duplication, or disclosure by the U.S. Government is subject to the restrictions as set forth in subparagraph C of
the Commercial Computer Software - Restricted Rights clause at FAR 52.227-19. In the event the sale is to a DOD agency, the U.S.
Governments rights in software, supporting documentation, and technical data are governed by the restrictions in the Technical Data
Commercial Items clause at DFARS 252.227-7015 and DFARS 227.7202.
DISCLAIMER OF WARRANTY. ALL MATERIALS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL
WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL
DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR
INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
In no event shall Ciscos or its suppliers liability to You, whether in contract, tort (including negligence), or otherwise, exceed the price paid by
You. The foregoing limitations shall apply even if the above-stated warranty fails of its essential purpose.
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a
Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful
interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency
energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications.
Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the
interference at their own expense.
The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-
frequency energy. If it is not installed in accordance with Ciscos installation instructions, it may cause interference with radio and television
reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications
in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential
installation. However, there is no guarantee that interference will not occur in a particular installation.
You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by the
Cisco equipment or one of its peripheral devices. If the equipment causes interference to radio or television reception, try to correct the
interference by using one or more of the following measures:
Turn the television or radio antenna until the interference stops.
Move the equipment to one side or the other of the television or radio.
Move the equipment farther away from the television or radio.
Plug the equipment into an outlet that is on a different circuit from the television or radio. (That is, make certain the equipment and the television
or radio are on circuits controlled by different circuit breakers or fuses.)
Modifications to this product not authorized by Cisco Systems, Inc. could void the FCC approval and negate your authority to operate the
product.
The following third-party software may be included with your product and will be subject to the software license agreement:
CiscoWorks software and documentation are based in part on HP OpenView under license from the Hewlett-Packard Company. HP OpenView
is a trademark of the Hewlett-Packard Company. Copyright 1992, 1993 Hewlett-Packard Company.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB)
as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of
California.
Network Time Protocol (NTP). Copyright 1992, David L. Mills. The University of Delaware makes no representations about the suitability of
this software for any purpose.
Point-to-Point Protocol. Copyright 1989, Carnegie-Mellon University. All rights reserved. The name of the University may not be used to
endorse or promote products derived from this software without specific prior written permission.
The Cisco implementation of TN3270 is an adaptation of the TN3270, curses, and termcap programs developed by the University of California,
Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981-1988, Regents of
the University of California.
Cisco incorporates Fastmac and TrueView software and the RingRunner chip in some Token Ring products. Fastmac software is licensed to
Cisco by Madge Networks Limited, and the RingRunner chip is licensed to Cisco by Madge NV. Fastmac, RingRunner, and TrueView are
trademarks and in some jurisdictions registered trademarks of Madge Networks Limited. Copyright 1995, Madge Networks Limited. All rights
reserved.
The X Window System is a trademark of the X Consortium, Cambridge, Massachusetts. All rights reserved.
Cisco Secure, ACS, VMS, DFM, QoS Policy Manager, QPM, URT, IPM, SAA, CiscoWorks, RME, Resource Manager Essentials, AutoConnect,
AutoRoute, AXIS, BPX, Catalyst, CD-PAC, CiscoAdvantage, CiscoFusion, Cisco IOS, the Cisco IOS logo, CiscoLink, CiscoPro, the CiscoPro
logo, CiscoRemote, theCiscoRemote logo, CiscoSecure, Cisco Systems, CiscoView, CiscoVision, CiscoWorks, CiscoWorks 2000, ClickStart,
ControlStream, CWSI, EdgeConnect, EtherChannel, FairShare, FastCell, FastForward, FastManager, FastMate, FastPADlmp, FastPADmicro,
FastPADmp, FragmentFree, FrameClass, Fulcrum INS, IGX, Impact, InternetJunction, JumpStart, LAN2LAN Enterprise, LAN2LAN Remote
Office, LightSwitch, MICA, NetBeyond, NetFlow, Newport Systems Solutions, Packet, PIX, Point and Click Internetworking, RouteStream,
Secure/IP, SMARTnet, StrataSphere, StrataSphere BILLder, StrataSphere Connection Manager, StrataSphere Modeler, StrataSphere
Optimizer, Stratm, StrataView Plus, StreamView, SwitchProbe, SwitchVision, SwitchWare, SynchroniCD, The Cell, The FastPacket Company,
TokenSwitch, TrafficDirector, Virtual EtherSwitch, VirtualStream, VlanDirector, Web Clusters, WNIC, Workgroup Director, Workgroup Stack, and
XCI are trademarks; Access by Cisco, Bringing the Power of InternetworkingtoEveryone, Enter the Net with MultiNet, and The Network Works.
No Excuses. are service marks; and Cisco, theCisco Systems logo, CollisionFree, Combinet, EtherSwitch, FastHub, FastLink, FastNIC,
FastPacket, FastPAD, FastSwitch, ForeSight, Grand, GrandJunction, GrandJunction Networks, the Grand Junction Networks logo, HSSI, IGRP,
IPX, Kalpana, theKalpana logo, LightStream, MultiNet, MultiWare, OptiClass, Personal Ethernet, Phase/IP, RPS, StrataCom, TGV, the TGV
logo, and UniverCD are registered trademarks of Cisco Systems, Inc. All other trademarks, service marks, registered trademarks, or registered
service marks mentioned in this document are the property of their respective owners.
Copyright 2002, Cisco Systems, Inc.
All rights reserved. Printed in USA.
4 ACS v3.0 2002, Cisco Systems, Inc. All rights reserved.
About This Tutorial
Identify the challenges of user
authentication, authorization, and
accounting (AAA)
Describe the Cisco solution for
managing these challenges
using Cisco Secure ACS
Provide common AAA/ACS
scenarios
Provide helpful guidelines on
installation and troubleshooting
Cisco Secure ACS
Provide links to helpful
documentation
About This Tutorial
The Cisco Secure Access Control Server (ACS) tutorial provides self-paced training focused on using the
Cisco Secure ACS v3.0 application to control user access to networked resources using Terminal Access
Controller Access Control System (TACACS+) or Remote Access Dial-In User Service (RADIUS)
features. The Cisco Secure ACS application is a high performance, highly scalable, centralized user
access control server controlling the authentication, authorization, and accounting (AAA) for all users
accessing corporate resources.
The ways in which we access networked resources are changing and the challenges associated with
managing network access can be difficult. This tutorial will address these challenges when presenting
the Cisco Secure solution Cisco Secure ACS. The tutorial will then focus on the major aspects of
setting up and using ACS to manage network access. Since every network is different, not all readers of
this tutorial will use all the discussed features. Likewise, network administrators with very specific access
requirements may have to do further research before deploying Cisco Secure ACS in their environment.
Because of the tremendous flexibility of the Cisco Secure ACS product, this tutorial cannot cover all
possible deployments of Cisco Secure ACS. It is suggested that the reader refer to Chapter 5, a helpful
reference section, containing links to technical documentation on the Cisco Secure ACS product,
concepts, terminology, and deployment white papers.
Who Should Use This Tutorial
Network administrators
responsible for managing:
User access to the network
and networked services
Access to networked
devices for administration
purposes
Prerequisites
Allow 24 hours to complete
Who Should Use This Tutorial
This tutorial was written as a technical resource for network administrators responsible for
managing user access and administration to the network infrastructure.
Cisco Secure ACS administers user access for Cisco IOS routers, virtual private networks
(VPNs), firewalls, dial and broadband DSL, cable access solutions, voice over IP (VoIP), Cisco
wireless solutions (Aironet), Cisco Catalyst switches via IEEE 802.1x access control, and all
TACACS+ and/or RADIUS enabled network devices.
Prerequisites
Users of the ACS application, should have at least the following prerequisites.
A basic understanding of the operation and configuration of your network, including the topology,
device inventory, and security requirements.
A basic understanding of switching and routing; knowledge of how to configure and use Cisco IOS
routers and Cisco Catalyst switches using RADIUS or TACACS+.
A working understanding of the different access methodologies used in their networks.
Be able to define the following terms and know how they relate to network access: Authentication,
Authorization, Accounting, RADIUS, TACACS+, PAP, CHAP, MS-CHAP, EAP, ARAP.
Estimated Time to Complete Tutorial
24 hours
How the Tutorial Is Organized
Chapter 1: Introduction
Chapter 2: Using Cisco Secure ACS for
User AAA
Chapter 3: AAA Scenarios
Chapter 4: Installation and Troubleshooting
Guidelines
Chapter 5: Reference Material
How This Tutorial Is Organized
The tutorial is structured as a series of five self-paced modules or chapters. The tutorial material is
presented through text, illustrations, hypertext links, and typical scenarios. Each chapter outlines its
specific learning objectives, and concludes with a series of self-assessment exercises based on the
chapter objectives. The multiple-choice exercises provide a means for you to assess your understanding
of the material presented in a given chapter. A summary of each chapter is given below.
Chapter 1 - Introduction
This chapter introduces the challenges of managing user authorization, authentication, and accounting
(AAA). An overview of Ciscos solution to these management challenges is presented by introducing the
Cisco Secure Access Control Server (ACS) application before learning to use ACS in Chapter 2 and
applying the products features in Chapter 3.
Chapter 2 - Using Cisco Secure ACS for User AAA
This chapter discusses the key features of Cisco Secure ACS in a manner that allows the user to
understand not only the product as a whole, but any reason for individual tasks necessary for using Cisco
Secure ACS. Before getting into the specifics on how to use the various functions of the Cisco Secure
ACS product, its architecture is discussed to provide an understanding of how all the components work
together. A roadmap for using Cisco Secure ACS is presented in a logical workflow of how a user would
begin to, and continue to use the Cisco Secure ACS application.
Chapter 3 - AAA Scenarios
This chapter walks the reader through several scenarios to provide hands-on experience using the Cisco
Secure ACS application for user authentication, authorization, and accounting. These scenarios will help
to reinforce the information learned in Chapter 2.
How the Tutorial Is Organized
Chapter 1: Introduction
Chapter 2: Using ACS for User AAA
Chapter 3: AAA Scenarios
Chapter 4: Installation & Troubleshooting
Guidelines
Chapter 5: Reference Material
How This Tutorial Is Organized - continued
Chapter 4 - Installation and Troubleshooting Guidelines
This chapter provides information about AAA client and AAA server (ACS platform) requirements,
software installation guidelines, and tips for troubleshooting and avoiding common problems when using
the Cisco Secure ACS application. Detailed instructions on installing the software can be found in the
Cisco Secure ACS installation guide. A link to the user and installation guides can be found in the
reference section (Chapter 5).
Chapter 5 - References
This chapter contains a comprehensive list of additional product information, such as links to product
literature, technical documentation, and white papers on deploying Cisco Secure ACS.
Chapter Questions and Answers
This section contains the answers to the questions that conclude each chapter.
Other Product Tutorials
URT v2.0
(Standalone)
URT v2.0
(Standalone)
QPM v2.1
(Standalone)
QPM v2.1
(Standalone)
Campus Manager v3.1
Campus Manager v3.1
Essentials v3.3
Essentials v3.3
ACL Manager v1.3
ACL Manager v1.3
IPM v2.1
IPM v2.1
CD One 4th Edition
CD One 4th Edition
SLM v1.0
SLM v1.0
Voice Health Monitor v1.0
Voice Health Monitor v1.0
ACS v3.0
(Standalone)
ACS v3.0
(Standalone)
VPN Monitor v1.1
VPN Monitor v1.1
Other Product Tutorials
This tutorial provides a comprehensive study of the Cisco Secure Access Control Server application,
version 3.0. Cisco also has other tutorials for many of the CiscoWorks family of products. The ACS
product does not rely on any other Cisco management application and thus is a stand-alone tutorial.
The interested reader may wish to review other CiscoWorks product tutorials to learn about how to manage
their networks using a comprehensive set of applications. Since many of the CiscoWorks products rely or
benefit on other products, it is recommended that you read the tutorials in the depicted order. Here are
some additional notes on the reading order dependency.
Review the CD One tutorial first to obtain a quick understanding of the CiscoWorks server, the
Integration Utility, and CiscoView.
If you have purchased the LAN Management Solution bundle, review sections in Campus Manager
(Topology Services) prior to reading the Essentials tutorial. The importing of devices into Essentials
is greatly enhanced by Campus Managers auto-discovery of devices.
If you have purchased the RWAN Management Solution bundle, review sections within the
Essentials tutorial on Inventory and Configuration Management. ACL Manager requires that the
devices being managed by ACL Manager also be in the CiscoWork inventory and that the
configuration archive have the latest device configuration files.
If you have purchased the RWAN Management Solution bundle, review sections within the
Essentials tutorial on Inventory Management. IPM (Internetwork Performance Manager) can import
the devices stored in the CiscoWorks inventory database.
VPN Monitor requires that devices be imported from the Essentials inventory and that Essentials can
generate Syslog reports pertaining to VPN devices. Other functions within Essentials, such as
configuration file and software image management, are also useful in the overall management of
VPNs.
URT and QPM are stand-alone products. However, by understanding the inventory features in
Essentials, one can import devices into URT and QPM from the Essentials inventory.
9
Chapter 1
Introduction
Cisco Secure Access Control Server v3.0
The Access Environment
Access Control Challenges
Cisco Secure Solution
Access Control Server
Chapter 1 Objectives
This chapter first introduces the reader to the ever-increasing methods for accessing the
network and its resources, and will briefly discuss some of the terminology used by the industry
when referring to access control procedures. Next, the main challenges of controlling and
securing user access to networked resources are presented. These challenges are then
addressed when presented with a Cisco Secure solution, the Access Control Server (ACS).
At the completion of this chapter, the reader should understand the basic purpose and
management solution space of Cisco Secure ACS, and how it can save you time, yet still provide
you with greater flexibility. Chapter 2 will then presents the features and capabilities of Cisco
Secure ACS in a logical workflow.
The Expanding Access Environment
PSTN
802.1x Switches
Mobile
Worker
Remote
Office
Home
Office
Mobile
Worker
Home
Office
Internet
VPN
Wireless
Dial-Up
VoIP
Telnet Admin
Firewall
The Expanding Access Environment
In the ever-changing business environment, employees are often not restricted to a single office
space to perform their job functions, but are rather given the flexibility to perform their jobs from
anywhere. Therefore, employers need to give employees the flexibility to access network
resources in a multitude of ways. In recent years, more and more corporations have added
additional access capabilities to take advantage of technology and security advances.
Unfortunately, the sensitive nature of corporate network resources, and the mischievous and
sometimes malicious behavior of some, requires network administrators to carefully control and
monitor access. Combine this with the fact that the control (protocols and databases) of these
different types of network access are many times not consistent, and the task of managing
access can become a time consuming and arduous process. The concept of access control can
also be extended to the administrative access to the network devices for configuration and
monitoring.
The control and management of access is achieved through a set of three independent security
functions collectively known as AAA or Authentication, Authorization, and Accounting.
What Is AAA?
Authentication- Who is allowed access?
Authorization- What are they allowed to do?
Accounting - What did they do?
What is AAA?
AAA (Triple A) provides a modular way of performing authentication, authorization, and
accounting services for verifying the identity of, granting access to, and tracking the actions of
users who require access to the network and network devices. Lets define each component of
AAA.
Authentication - Provides the method of identifying users, including the traditional username and
fixed password dialog, and more modern and secure methods such as challenge and response
(like CHAP) and one-time passwords (OTPs).
Authorization - Provides the method for controlling which services or devices the authenticated
user has access to. Many individuals may be allowed access to the network; however, only select
individuals may be allowed access to core network devices or services.
Accounting - Provides the method for collecting and sending security information. When users
attempt to access the network infrastructure and resources, the network administrator may want to
know about it. The information recorded may include user identities, start and stop times, and
executed commands. The collected information can be used for billing, auditing, and reporting
purposes.
AAA Challenges
How can I easily control all
user authentication and access
to the network?
How can I track and report user
behavior in the network and
keep a record of every remote
access?
How can I reduce the
administrative costs for
managing access to the
network?
Challenges
A common challenge in all small, large, public, private, wired, and wireless networks is the
decision on how to authenticate users and control access to the network and the connected
resources. Use of the network needs to be controlled, authorized, and accounted for.
With the tremendous increase in the use of networks for business productivity, network
administrators need to battle new AAA challenges to support the ever growing population of
users who connect to the network from all types of devices and services (i.e. dialup, wireless,
VPN). Network administrators need a way to control:
Who can log in to the network from different types of connection?
What privileges each user has in the network?
What accounting information is recorded in terms of security audits or account billing?
What access and command controls are enabled for each configuration administrator?
Having a centralized means to control the AAA services would greatly facilitate the network
administrators ability to quickly manage all user access to the network from a single source;
thus, improving the network administrators overall ability to scale and deploy secure network
services.
The Hard Way to Manage Access
802.1x Switches
VPN
Wireless
Dial-Up
VoIP
Telnet Admin
Firewall
Device Administration
Access and privilege rights
options limited
Not scalable
Network Access
Not scalable
Time-consuming
Difficult logistics
Individual Device Configuration Required
The Hard Way to Manage - Per Device
In the past, it was not as much of an issue securing the network. The user needed to be
physically located within the corporate campus and the networks were smaller. But now, the
corporate networks can be accessed using wireless interface cards or using the public ISP
network and VPN. It is not uncommon for a wireless user to easily access the Internet and other
corporate resources through unsecured resources. So why arent all network administrators
securing their resources. Either the network administrators are unaware of their vulnerability or
the deployment of AAA services is too time consuming, not scalable, or difficult to administrator.
Most network access devices come with AAA type features embedded in their software. As a
simple example, Cisco IOS
devices allow you to configure access lists (ACLs) to control access

by host, protocol, interface, etc. So problem solved, right? Well, in a very small network, it may
be feasible for a network administrator to individually configure each access device. Also, since
the administrative access needed to configure the devices would be limited to a few individuals
who need complete access, simple enable password protection may be adequate. But what
happens as the network grows and becomes more geographically dispersed? Configuring
individual device one by one becomes very time consuming. With the increase in devices, a
similar increase in network administrators may also become inevitable. Now if certain regional
administrators only need full access to their regional devices, but a global administrator needs
full access to all devices, the management of passwords can become a job in itself.
Surely, there must be a better way!
A Better Way
AAA Server
AAA Client
TACACS+
RADIUS
AAA Client/Server
AAA client defers authorization to centralized
AAA server
Highly scalable
Uses standards-based protocols for AAA
services
A Better Way - AAA Client/Server
Luckily, most access devices also have an embedded AAA client that defers AAA services to a
AAA server. This allows for access control to be centralized to allow for quick administering of
access control changes for users and devices on a global basis; a more scalable solution. The
centralized AAA server allows for precise access control (i.e. allow Jim full administration rights
on routers A and B, but not on router C).
The AAA client uses two distinct protocols to communicate AAA requests with the AAA server:
Terminal Access Controller Access Control System (TACACS+) or Remote Access Dial-In User
Service (RADIUS).
When a user attempts access the network or network devices through a device configured as a
AAA client, the AAA client forwards the users authentication request to the AAA server (i.e.
username and password). The AAA server returns either a success or failure response
depending upon the information in the servers repository. Once the user is successfully
authenticated, the AAA server sends a set of session attributes (authorization) to the AAA client
to provide additional security and control of privileges for the user.
Lets take a closer look at the two AAA protocols used between the AAA client and AAA server.
AAA Protocols
RADIUS / TACACS+
Useful for router
management
Less intrinsically suited for
router management
Independent AAA
architecture
Authentication and
authorization service
combined
Full packet encryption Encrypts only the passwords
up to 16 bytes
TCP connection oriented UDP connectionless
TACACS+ RADIUS
AAA Client
AAA Server
AAA Protocols and Standards
Typically, AAA services are provided for two different types of access requests: accessing the
network and accessing networked devices for administration purposes. In today's networks,
TACACS+ and RADIUS are the most commonly used protocols to provide communication between a
AAA client and AAA server. Lets look at their characteristics and where each is best suited.
RADIUS
Developed by Livingston Enterprises, Inc. (Lucent) as an access server authentication and accounting
protocol. Implemented by several vendors of network access servers, RADIUS has gained support
among a wide customer base, including many Internet service providers (ISPs) and is considered the
industry standard for AAA support.
Uses UDP as the transport protocol to send data between the AAA client and the AAA server. Issues
related to server availability, retransmission, and timeouts are handled by the RADIUS-enabled devices
rather than the transmission protocol.
RADIUS encrypts only the passwords up to 16 bytes.
RADIUS combines the authentication and authorization service.
TACACS+
Drafted by Cisco Systems and provides enhancements from earlier releases in TACACS and
Enhanced TACACS.
Uses TCP has the transport protocol to send the data between the AAA client and the AAA server.
This is a connection-oriented protocol and provides reliable transfer of data segments.
TACACS encrypts the entire packet prior to transmission.
Provides separate and modular authentication, authorization, and accounting services.
RADIUS is generally recommended when providing network access, such as PPP or VPN. TACACS+,
though functional as a network access protocol, is recommended for device access because of its
ability to support more extensive capabilities, such as command filtering.
So what is Ciscos solution to AAA?
Ciscos Solution
Cisco Secure Access Control Server (ACS)
WinNT/2000
Novell NDS
LDAP/ODBC
Token Server
External User
Database User Authentication
TACACS+ &
RADIUS
Authentication for inbound and
outbound firewall access
User Authentication
TACACS+ & RADIUS
Other Networks
Firewalls
Authentication
Forwarding Cisco Secure ACS Servers
Accounting & Authorization
VPN Devices
NAS
Network
Devices
VPN
Users
Dial-up/PPP
Net-Ops
Staffs
Telnet/Login
Users Access
Cisco Catalyst
Switches
Routers
AAA
Clients
VoIP
Cisco
Aironet
Switch
Centralized AAA Control
Ciscos AAA Solution - Access Control Server (ACS)
Ciscos solution to AAA services is the Cisco Secure Access Control Server (ACS) v3.0 software
application for Windows 2000 and NT. ACS is a highly scalable, high performance access
control server that operates as a centralized RADIUS or TACACS+ server system to control the
authentication, authorization, and accounting of users accessing corporate resources through
the network. ACS is administered from a web-based, graphical interface, and distributes AAA
controls to hundreds or thousands of access gateways in the network. ACS can manage and
administer user access for Cisco IOS
routers, virtual private networks (VPNs), firewalls, dialup

and broadband DSL access, cable access solutions, voice over IP (VoIP), Cisco wireless
solutions, and Cisco Catalyst switches via IEEE 802.1X access control. In addition, ACS also
allows for enhanced administration of TACACS enabled network devices using a device
command policy engine. ACS optionally supports many popular user repository implementations
allowing companies to leverage investments already made in building their corporate user
repositories.
Lets now highlight some of the AAA functions embedded in the ACS application.
Cisco Secure ACS Authentication
Features
Cisco Secure ACS
AAA Client
(Network Access Server)
TACACS+
RADIUS
Variety of
Authentication
Methods
Local or
Variety of External
Databases
Variety of Authentication Methods
(ASCII, PAP, CHAP, MS-CHAP, LEAP, EAP-CHAP, EAP-TLS)
Passwords Options
Single or separate passwords
Inbound / outbound
Password aging
Local or Variety of External User Databases
Cisco Secure ACS Authentication Features
The simplest form of authentication requires the user to provide a username and password.
Upon receiving this information, a AAA client forwards it to the AAA server or Cisco Secure ACS
system using either RADIUS or TACACS+. As previously discussed, both RADIUS and TACACS+
encrypt the password, using different methods, but the password is in clear text between the
users workstation and the AAA client.
Using a username and a password that is fixed for authentication may be fine for some
implementations; however, the more authorization privileges granted to a user, the stronger the
authentication should be. Using simplistic forms of authentication and clear-text passwords
across unsecured links can compromise security. Therefore, more modern and secure
authentication methods were developed, like Challenge Handshake Authentication Protocol
(CHAP) and OTPs (one-time passwords). To provide network administrators with the greatest
flexibility, Cisco Secure ACS supports a wide variety of authentication methods, such as:
PAP (Password Authentication Protocol) Uses clear-text passwords (that is, unencrypted
passwords) and is the least sophisticated authentication protocol. If you are using the Windows
NT/2000 user database to authenticate users, you must use PAP password encryption or MS-
CHAP.
CHAPUses a challenge-response mechanism with one-way encryption on the response. CHAP
enables Cisco Secure ACS to negotiate downward from the most secure to the least secure
encryption mechanism, and it protects passwords transmitted in the process. CHAP passwords
are reusable. If you are using the Cisco Secure user database for authentication, you can use
either PAP or CHAP. CHAP does not work with the Windows NT/2000 user database; use MS-
CHAP.
MS-CHAP (Microsoft CHAP)
ARAPUses a two-way challenge-response mechanism. The AAA client challenges the end-user
client to authenticate itself, and the end-user client challenges the AAA client to authenticate itself.
Features
Cisco Secure ACS
AAA Client
TACACS+
RADIUS
Variety of
Authentication
Methods
Local or
Variety of External
Databases
Passwords Options
Inbound / outbound
Password aging
Variety of Authentication Methods (wireless) continued
In the last year, network administrators have become more aware of the vulnerabilities of
deploying wireless technology without proper AAA services and encryption methods. The
vulnerabilities lie with the implementation of RC4 (an encryption algorithm) in the Wired
Equivalent Privacy (WEP) encryption framework. EAP (Extensible Authentication Protocol)
provides static WEP keys on a per session basis for wireless encryption. There are several
weaknesses in the key scheduling algorithm of RC4, which is a widely used stream cipher in
software applications. This cipher can provide unauthorized users with a small number of key
bits that can be used to construct the "WEP key necessary to gaining access to a network.
Cisco Systems has been shipping a security scheme known as LEAP (Lightweight EAP or EAP
Cisco Wireless) since November 2000. Based on the 802.1x authentication framework, LEAP
mitigates several of the weaknesses by utilizing dynamic WEP and sophisticated key
management on a per packet basis. Refer to Chapter 5 for a links to several papers that highlight
WEP vulnerabilities and configurations for LEAP and MAC authentication in the access points
(APs), workgroup bridges, and client software.
Features
Passwords Options
Inbound / outbound
Password aging
Cisco Secure ACS
AAA Client
TACACS+
RADIUS
Variety of
Authentication
Methods
Local or
Variety of External
Databases
Cisco Secure ACS Authentication Features
Cisco Secure ACS also offers support for many password options including:
Single password for each authentication method: ACSII, PAP, CHAP, MS-CHAP, ARAP. This is
the easiest set-up, but since the ASCII and PAP password is clear text, there is a chance the
CHAP password can be compromised.
Separate passwords for ASCII/PAP and CHAP/MS-CHAP/ARAP. This option is less convenient
for the end user (needs two passwords), but if the ASCI/PAP password is compromised, the
CHAP password can remain intact.
Inbound password - Most commonly used by Cisco Secure ACS users and supported by both the
TACACS+ and RADIUS protocols. They are held internally to the Cisco Secure user database
and are not usually given up to an external source if an outbound password has been configured.
Outbound password Supported by TACACS+; The outbound password enables a AAA client to
authenticate itself to another AAA client or end-user client via outbound authentication. The
outbound authentication can be PAP, CHAP, MS-CHAP, or ARAP and results in the Cisco Secure
ACS password being given out. By default, the user's ASCII/PAP or CHAP/MS-CHAP/ARAP
password is used. To prevent compromising inbound passwords, the user can configure a
separate SENDAUTH password.
Token caching - Caches the OTP (one-time password) token for limited time use in a second ISDN
B channel.
Password aging Password expires after a number of logins, days, etc.
User changeable passwords
Chapter 2 discusses how to enable these password options in Cisco Secure ACS.
Cisco Secure ACS Authentication Flexibility
External Database Support
Authentication Protocol
ASCII PAP CHAP ARAP MS-CHAP MS-CHAP LEAP EAP- EAP-
Database v.1 v.2 MD5 TLS
Cisco Secure ACS Yes Yes Yes Yes Yes Yes Yes Yes Yes
Windows SAM Yes Yes No No Yes Yes Yes No No
Windows AD Yes Yes No No Yes Yes Yes No Yes
Novell NDS Yes Yes No No No No No No No
LDAP Yes Yes No No No No No No Yes
OCBC Yes Yes Yes Yes Yes Yes Yes No No
LEAP Proxy No No No No Yes No Yes No No
RADIUS Server
ActivCard Yes Yes No No No No No No No
CRYPTOCard Yes Yes No No No No No No No
RADIUS Token Yes Yes No No No No No No No
Server
Vasco Yes Yes No No No No No No No
AXENT Yes Yes No No No No No No No
RSA Yes Yes No No No No No No No
Safeword Yes Yes No No No No No No No
Cisco Secure ACS Authentication Flexibility External Database Support
The network administrator also has flexibility in the type of database to employ to store AAA
information. Cisco Secure ACS includes its own database; in addition, the administrator can
leverage many external databases that contain user authentication information. Cisco Secure
ACS maps the user to an external database for authentication to centralize the information.
Different levels of security can be concurrently used with Cisco Secure ACS for varying customer
security requirements and policies.
Not all the authentication protocols supported by Cisco Secure ACS can be used with the
external databases supported by Cisco Secure ACS. Use the chart above as a reference to
determine which databases support which authentication protocol. As illustrated, the Cisco
Secure ACS database supports all listed authentication protocols.
Cisco Secure ACS Authorization Features
Cisco Secure ACS
AAA Client
User
Profile
What network services the user can access
Different levels of service by user or group
Permit or deny logins based on time/day
Disable account based on failed attempts or
on a specific date
Maximum sessions by user or group
Dynamic usage quotas
Cisco Secure ACS Authorization Features
Once the user has been authenticated, Cisco Secure ACS will send a user profile to the AAA
client containing policies dictating what network services a user can access. Cisco Secure ACS
allows the administrator to customize authorization on an individual user or a user group.
Access can be differentiated by levels of security, access times, and services. For example,
logins can be configured to permit or deny access based on time-of-day and day-of-the-week.
Downloaded policies could also include access control lists (ACLs) on a per-user or per-group
basis restricting areas of the network or limiting certain services such as FTP.
Some additional Cisco Secure ACS authorization features include:
Ability to disable an account after a number of failed attempts or on a specific date
Limit the number of concurrent sessions for either a group or a user
Define usage quotas by duration or total number based on daily, weekly, or monthly periods
It should start to become clear to the reader that to provide some of these capabilities (i.e. time
restricted accounts) throughout the enterprise would consume vast amounts of time without a
centralized AAA server. But with ACS, access configuration becomes much less complicated
and time-consuming.
Cisco Secure ACS Accounting Features
Cisco Secure ACS
AAA Client
What the
user is
doing
CSV or ODBC accounting records
Records session start/stop duration
AAA client messages with username
Caller-line identification
ACS Accounting Features
Now that the user has been granted access to the network with certain privileges, the accounting
functions provided by RADIUS and TACACS+ protocols allow the AAA clients to forward relevant
data for each user session to Cisco Secure ACS. Depending upon the configuration, Cisco
Secure ACS writes accounting records to either a comma-separated value (CSV) log file or an
ODBC database. The logs are configurable to capture as much information as needed, but
generally record information on session start and stop times, AAA client messages by username,
caller line identification, and duration of each session. The log files can easily be exported into
popular database and spreadsheet applications for billing, security audits, and report generation.
Cisco Secure ACS Device Administration
Features
Authentication - Access per user, group, or network
device group
Authorization - Commands per user, group, or
network device group
Accounting - Lists commands entered
Cisco Secure ACS
Telnet Admin
TACACS+
ACS Device Administration Features
As mentioned earlier in this chapter, AAA functionality within Cisco Secure ACS can be used for
two similar access functions - network access which was discussed on the previous pages, and
access to network devices for administration and configuration. It was also mentioned that the
TACACS+ protocol is better suited for the later task in that it has more features for user and
command authorization.
Similar to network access, access to a device is controlled by an authentication dialog between
the AAA client (device to be accessed) and the Cisco Secure ACS server. Most network
administrators are familiar with logging into a device, providing the enable password, and
performing whichever functions they choose. With Cisco Secure ACS, different users can be
given different privileges even with device functions at the same privilege level. To achieve this
granularity of authorization, Cisco Secure ACS uses the concept of Command Authorization Sets
(also known as Device Command Sets - DCSs). The Cisco Secure ACS DCS mechanism controls
the authorization of each command on each device per user, per group, or per network device
group mapping for greatly enhanced scalability and manageability of setting authorization
restrictions for network administrators. When TACACS+ command authorization is enabled,
each command executed by the authenticated user is sent by the AAA client to Cisco Secure
ACS for inclusion in the accounting logs.
26 ACS v3.0 2002, Cisco Systems, Inc. All rights reserved. 26
Thank You!
Chapter 1 provided you with a quick overview of the challenges of managing user access and a
solution to address these challenges - Cisco Secure ACS. Continue on to Chapter 2 to discover
how to set-up and use ACS to provide a centralized user access control framework from a
graphical user interface.
Chapter 2
Product Features
Cisco Secure ACS
Architecture
How Cisco Secure ACS
Works
Road Map to Using Cisco
Secure ACS
Cisco Secure ACS is a powerful and flexible AAA server product. The user can choose from
many configuration options when implementing Cisco Secure ACS for use as a Authentication,
Authorization, and Accounting (AAA) server. This chapter discusses the key configuration and
use features of Cisco Secure ACS in a manner that allows the user to understand not only the
product as a whole, but any reason for individual tasks necessary when configuring Cisco Secure
ACS.
Because every corporations network and access policies are different, each implementation of
Cisco Secure ACS will also differ. This tutorial focuses on the high level steps involved in the
configuration of Cisco Secure ACS, but because of the tremendous number of different
configuration options, the tutorial can not cover all the minute details of each configuration
option. You should use the tutorial in conjunction with the Cisco Secure ACS User Guide for a
complete understanding of how to configure their chosen options.
Before getting into the specifics on how to use the various functions of the Cisco Secure ACS
product, its architecture is discussed to provide an understanding of the details on how all the
components work together. Next, the roadmap to using Cisco Secure ACS is presented in a
logical workflow of how a user would begin to, and continue to use the Cisco Secure ACS
application. Chapter 3 complements this chapter by providing you with a typical Cisco Secure
ACS deployment, with step by step instructions.
This chapter can be used simply as informational and/or reference material, or can be used as a
primer to the actual use of the Cisco Secure ACS product. If you have already purchased Cisco
Secure ACS, Cisco recommends that you install the product first so that you can follow along.
Refer to Chapter 4 for installation guidelines and the Cisco Secure ACS Installation Guide for
step-by-step installation instructions.
Cisco Secure ACS Functional Architecture
RADIUS/
TACACS+
RADUIS/
3rd Party API
AAA Client ACS AAA Server
Local ACS Database/
optional 3rd Party
External User DB
End User Client
ACS
NT/ADS
NDS
LDAP
ODBC
OTP
LEAP Proxy
ASCII/PAP (dial)
CHAP/ARAP/MSCHAP (dial, VPN)
LEAP (Wireless)
EAP (dial,VPN,Wireless, 802.1X)
Windows, MAC, Unix, Linux, ...
Cisco Access Servers
Cisco IOS
Cisco Cat OS
Cisco PIX Firewall
Cisco Aironet AP
Cisco VPN 3000, 5000
Cisco Broadband Access
Cisco 802.1X Enabled Switches
3rd party devices that
support RADUIS or TACACS+
Four-Component AAA Architecture
Cisco Secure
ACS Functional Architecture
The Cisco Secure ACS AAA server is part of a four component AAA architecture as depicted
above. Rather than have each access device process end users requests for access, the access
devices are configured as AAA clients and pass all access requests to the Cisco Secure ACS
AAA server. This client/server relationship allows for the centralization of all AAA processing.
Cisco Secure ACS will now handle all end-users requests for authentication which are forwarded
to Cisco Secure ACS by a AAA client using either the RADUIS or TACACS+ security protocols.
ACS can authenticate the end-user with its local database or forwards the requests on to an
external user database for authentication. Once authenticated, Cisco Secure ACS returns the
access policy (authorization) for the authenticated user, as defined by the Cisco Secure ACS
administrator, to the AAA client. Cisco Secure ACS then records all accounting packets
forwarded by the AAA client about the users session.
Cisco Secure ACS works with Cisco access gateways including Access Servers, IOS devices,
Aironet APs, VPN Concentrators, and more. Since RADIUS is an accepted industry standard for
AAA, and TACACS is developed by Cisco, Cisco Secure ACS will handle AAA functions for any
3rd party device implementing either of these protocols. Besides having a scalable database for
authentication, Cisco Secure ACS also allows users to authenticate against existing 3rd party
user databases to leverage any existing authentication resource. Finally, Cisco Secure ACS has
the flexibility to handle many existing and emerging password security protocols such as CHAP,
LEAP, and EAP.
Internal ACS Components
CSAdmin
CSAuth
CSDBSync
CSLog
CSMon
CSTacacs
CSRadius
Built-in Web Server for ACS Administration
Multi-thread server apps allows multiple sessions
Default using HTTP port 2002
Built-in Web Server for ACS Administration
Multi-thread server apps allows multiple sessions
Default using HTTP port 2002
Cisco Secure ACS Services Modules
Authenticates users, grant or deny service privileges
Manages ACS databases
External database authentication forwarding
Authenticates users, grant or deny service privileges
Manages ACS databases
External database authentication forwarding
Manage database synchronization and replication
to other ACS AAA servers.
Manage database synchronization and replication
to other ACS AAA servers.
Monitors and records: Users and admin activities /
Backup and restore / Database replication/sync /
ACS core services / TACACS+ and RADIUS Accounting /
VoIP Accounting
Monitors and records: Users and admin activities /
Backup and restore / Database replication/sync /
ACS core services / TACACS+ and RADIUS Accounting /
VoIP Accounting
Monitors status of ACS services and server resources
Records and reports all critical errors to log
E-mail alerts Admin any potential problems
Automatically detects and restarts ACS services
Test login frequency
Monitors status of ACS services and server resources
Records and reports all critical errors to log
E-mail alerts Admin any potential problems
Automatically detects and restarts ACS services
Test login frequency
CSTacacs and CSRadius communicate with devices
and CSAuth module
Parses AAA information between devices and CSAuth
CSTacacs and CSRadius communicate with devices
and CSAuth module
Parses AAA information between devices and CSAuth
Cisco Secure
Internal ACS Services
The processing for the core functionality of Cisco Secure ACS is handled by a set of seven
Window services installed with Cisco Secure ACS. The Cisco Secure ACS services include the
following:
CSAdmin - Provides the HTML interface for administration of Cisco Secure ACS.
CSAuth - Provides authentication services.
CSDBSync - Provides synchronization of the Cisco Secure ACS user database with an external
RDBMS application.
CSLog - Provides logging services, both for accounting and system activity.
CSTacacs - Provides communication between TACACS+ AAA clients and the CSAuth service.
CSRadius - Provides communication between RADIUS AAA clients and the CSAuth service.
CSMon - Provides monitoring, recording, and notification of Cisco Secure ACS performance, and
includes automatic response to some scenarios.
Each module can be started and stopped individually from within the Microsoft Service Control
Panel or as a group from within the Cisco Secure ACS HTML interface.
Lets take a look at some Cisco Secure ACS use concepts and how Cisco Secure ACS actually
processes AAA requests.
How Cisco Secure ACS Works
ACS Authentication and Authorization Concepts
Group: New York Admins
Group Access Policies
Time-of-day
Max Sessions
Device Restrictions
Usage Quotas
TACACS+ Settings
Authentication Database
Cisco Secure or External
User: Billy
User Access Policies-
Optional
Time-of-day, Max Sessions,
Usage Quotas, Device Restrictions,
TACACS+ Settings
Authentication
Groups contain authorization policies
for group of users
Can define up to 500 different groups
User access policies take precedence
over group access policies
Users in same group can authenticate
against different databases
How Cisco Secure ACS Works - ACS Authentication and Authorization
Concepts
To reduce configuration repetition for user authorization, Cisco Secure ACS uses the concept of
user groups to control authorization. A user group is simply a collection of authorizations to be
passed to the AAA client when a group member (user) is authenticated. Users with identical
authorization needs can be grouped together into a user group. This means that the
administrator only has to configure the authorizations for all like users once. Of course, this will
also ease the configuration necessary when an authorization change is required for all those
users; again it is configured once and all users in that user group inherit the authorization
change. Cisco Secure ACS allows up to 500 groups to be defined.
Each user is represented in Cisco Secure ACS by means of a User Profile. The user profile
contains the means of authenticating the user (local Cisco Secure ACS database or external user
database), and any access authorizations. Access authorizations for a user are based on the
users group membership, and can also be defined specifically for the user in their profile. If
certain users in a group have slightly different access requirements, the administrator can either
create a new group and put that user in it, or can just configure the users profile with the specific
authorization needs. Any set user authorizations take precedence over the same type of
authorization set for the group the user is in. As will be seen shortly, Cisco Secure ACS has a
mechanism (search external databases in a given order) for authenticating unknown users (no
user profile in the Cisco Secure ACS database), and associating that user with a user group for
authorization purposes.
This tutorial discusses the creation and management of groups and users later in this chapter.
Let's now look at Cisco Secure ACS AAA processing from first a high level and then in more detail.
High Level
Username and
Password
Dial-Up or
VPN
Client
AAA Client
Network Access
Server (NAS) /
VPN
Requests and
Responses
External Database
AAA/LDAP/Microsoft/Token
Username: john
Password: cisco
Check external
database
External DB
response
Check ACS DB
AAA Server
Cisco Secure ACS
Accounting
Authentication
Authorization
How ACS Works - High Level
Conceptually, Authorization, Authentication, and Accounting with the Cisco Secure ACS application
is straightforward. The steps are outlined below.
Step 1. When a user connects, their username and password are sent to a AAA client, such as a network access
server (NAS).
Step 2. The AAA client then forwards this information to the AAA server (ACS) and waits for a response.
Step 3. The ACS then checks its built-in database to see if the username is valid. If the username is valid, Cisco
Secure ACS attempts to authenticate against the database listed (ACS or external) in the users profile;
proceed to step 6.
Step 4. If the username is not found, the Cisco Secure ACS sends this information to any external database that it is
configured to query.
Step 5. The external database verifies the username and password and sends a response back to the Cisco Secure
ACS. Cisco Secure ACS adds a new user record to speed future processing for this user.
Step 6. If the username and password match, the Cisco Secure ACS then reads the user profile for additional
attributes.
Step 7. Cisco Secure ACS then sends the authentication success or failure. When the user has successfully been
authenticated, a set of session attributes (authorizations) associated with the user (group membership) is
sent to the AAA client to provide additional security and control of privileges. Note: networking vendors are
expanding the use of the attribute sets returned to cover an increasingly wider aspect of user session
provisioning.
Step 8. When the AAA client receives the response from the Cisco Secure ACS, it either establishes or denies the
connection for the user.
Step 9. Finally, the AAA client begins forwarding accounting information to the Cisco Secure ACS and the Cisco
Secure ACS generates and records accounting information for each user session (access or denial).
More Detail - Known User
User: Billy
Authentication: NT
No User Access Policies
Group: New York Admins
New York Admins
Access Policies
Cisco Secure ACS DB
UID: Billy
PWD: letmein UID: Billy
PWD: letmein
NT
Authentication
Authorization
OK
How Cisco Secure ACS Works - More Detail for Known User
The figure above shows a little more detail on the Cisco Secure ACS AAA processing with
respect to Cisco Secure ACS user profiles and authorization groups. The Cisco Secure ACS
administrator creates a user group named New York Admins and configures a set of
authorizations to be associated with this group. Next, the administrator adds the user Billy, who
will use an external NT database for authentication, and is assigned to be a member of the New
York Admins user group for authorization purposes.
When Billy attempts to access the network, his login information is passed by the NAS to Cisco
Secure ACS. Cisco Secure ACS searches its database for a user profile with the UID - Billy. When
found, Cisco Secure ACS notices that the password must be authenticated by an external NT
database, and forwards the login information to it. Billy is authenticated by the external
database, and Cisco Secure ACS is notified. Cisco Secure ACS passes the authentication result
back to the AAA client. Cisco Secure ACS checks Billys user profile and sees that he is a
member of the New York Admins user group. Cisco Secure ACS sends the authorizations defined
in the New York Admins group to the AAA client to further control Billys access privileges.
Next, let's look at how Cisco Secure ACS processes a request from an unknown user.
Unknown User Policy
Authentication: NT,ODBC
Database Group Mapping
NT: New York Admins
ODBC: Default
Cisco Secure ACS DB
New York Admins
Access Policies
Default
Access Policies
More Detail - Unknown Users
UID: Rick
PWD: hereiam
UID: Rick
PWD: hereiam
ODBC
Authentication
Authorization
User: Rick
Authentication: ODBC
Group: Default
NT
Look in first
Look in second
Create new Cisco
Secure ACS DB
entry for fast
processing the
next time
OK
How Cisco Secure ACS Works - More Detail for Unknown Users
An unknown user in the Cisco Secure ACS AAA paradigm is any user requesting
authentication services from ACS without a user profile in the Cisco Secure ACS database.
Typically, these users are defined in an external user database. To handle the authentication of
an unknown user, the Cisco Secure ACS administrator first creates user group(s) to associate
with the unknown users from each external user database. Next, the Cisco Secure ACS
administrator creates the Unknown User Policy which states the order of external user databases
to search for the unknown users. The Cisco Secure ACS administrator further sets up a mapping
of groups to external user databases. These mappings dictate which group an unknown user will
become a member of after being authenticated by a particular external user database. In the
example depicted above, unknown users found in the external NT database will receive the
authorizations defined in the New York Admins group, and any unknown users authenticated by
the external ODBC database will receive the authorizations defined in the Default group.
When user Rick attempts to access the network, his login information is passed by the NAS to
Cisco Secure ACS. Cisco Secure ACS searches its database for a user profile with the UID - Rick.
No user profile is found in the Cisco Secure ACS database matching this user ID. According to
the Unknown User Policy, Cisco Secure ACS passes Ricks login information to first an external
NT database, and if not found there, then to an external ODBC database. Rick is authenticated by
the external ODBC database, and Cisco Secure ACS is notified. Cisco Secure ACS passes the
authentication result back to the AAA client. Cisco Secure ACS looks at the group mappings and
then sends the Default user groups authorizations to the AAA client. To speed up future access
attempts by Rick, Cisco Secure ACS creates a User Profile for Rick which states to authenticate
using the external ODBC database and to use the Default authorization group.
The reader should begin to notice some necessary items to configure within Cisco Secure ACS
including, external databases, group authorization policies, users, and unknown user policy.
These items, as well as many more Cisco Secure ACS configuration items, are discussed in
upcoming sections of this tutorial.
Road-map
To Using Cisco Secure
ACS for Authentication,
Authorization, and
Accounting
View
ACS Reports
View
ACS Reports
Cisco Secure Access Control Server
Road-map
Getting
Started
Getting
Started
Planning
Planning
General
Configuration
General
Configuration
Configure
Authorization
Configure
Authorization
Configure
ACS Users
Configure
ACS Users
Configure
ACS Network
Configure
ACS Network
Access Control Server Roadmap
Because there are many possible deployments of Cisco Secure ACS, there is no single one-size-
fits-all configuration process. The roadmap presented in this tutorial presents the Cisco Secure
ACS configuration and use steps in one possible order. The order is based on logical
dependencies (i.e. configure groups prior to users because users must be associated with a
group), but it should be noted that many of the Cisco Secure ACS configuration processes are
iterative in nature and may necessitate repeated visits as deployment continues.
Each of the blocks in the roadmap represent a set of Cisco Secure ACS configuration tasks and
help delineate this chapter into sections.
CiscoSecure ACS Road-map
Planning
View
ACS Reports
View
ACS Reports
Getting
Started
Getting
Started
Configure
ACS Users
Configure
ACS Users
Planning
Planning
General
Configuration
General
Configuration
Configure
Authorization
Configure
Authorization
Configure
ACS Network
Configure
ACS Network
Planning for AAA and Cisco Secure
ACS
ACS
Security
Access
Administrative
Access
Number of Users
Types of Database
Network Topology
Policies
Planning
Planning
Planning for AAA and Cisco Secure ACS
Before actually deploying Cisco Secure ACS, the administrators must first do their homework.
Cisco Secure ACS provides many different configuration options to be as flexible as possible for
all possible types of deployments, users, and access methodologies. The figure above illustrates
some of the factors that must be taken into consideration when deploying Cisco Secure ACS,
they include the network topology, corporate policies for security, access, and administration,
the types of user databases to be used, the number of users, their access method (dial-up,
wireless, VPN, or local LAN), and their access needs. Each of these factors can have impacts on
the others, so they should be considered collectively. Carefully considering each of these factors
will determine how many and where the Cisco Secure ACS platforms should be deployed (user
access, network topology, performance), what authorization groups should be created, what
limitations there are as to where users can access the network from, as well as many other
deployment items.
Chapter 2 of the Cisco Secure ACS User Guide and many Cisco White Papers focus on
deployment issues. A link to these documents can be found in Chapter 5 of this tutorial. Proper
planning ahead of time, including a solid working knowledge of Cisco Secure ACS and its
functionality, will make the deployment of Cisco Secure ACS much smoother.
The rest of this chapter will focus on the configuration of Cisco Secure ACS. Again, the
discussions will concentrate on high-level aspects of how to configure various components of
Cisco Secure ACS, but will not go into detail on each configuration option. Please refer to the
online documentation for additional details on each field in a dialog window or configuration
option.
ACS Road-map
Getting Started
View
ACS Reports
View
ACS Reports
Configure
Authorization
Configure
Authorization
Configure
ACS Network
Configure
ACS Network
Getting
Started
Getting
Started
Configure
ACS Users
Configure
ACS Users
General
Configuration
General
Configuration
Planning
Planning
Getting Started Topics
Network Device Configuration
Software Installation
Accessing Cisco Secure ACS
Cisco Secure ACS GUI
Create First Admin User
Set Admin Policies
Remote Access
Getting
Started
Getting
Started
Getting Started Tasks
This section presents a logical flow of tasks to begin using Cisco Secure ACS. The objectives of
this section are to prepare devices to use Cisco Secure ACS for AAA services, to get the user
comfortable with the ACS GUI, and to create a super user (all administrative privileges), the
administrative access methods, and allow access to the Cisco Secure ACS from anywhere using
a web browser.
Network Device Configuration for Cisco Secure
ACS
Getting Started
Cisco Secure ACS
Configure all AAA Clients to send AAA requests to
Cisco Secure ACS using TACACS+ and/or RADIUS
Optionally configure to send AAA update packets
Configure all AAA Clients to send AAA requests to
Cisco Secure ACS using TACACS+ and/or RADIUS
Optionally configure to send AAA update packets
AAA Requests
AAA Requests
AAA Clients
For Device Administration,
Enable TACACS+ Command
Authorization
For Device Administration,
Enable TACACS+ Command
Authorization
Use IOS 11.2 or
greater on Cisco
devices
for full TACACS+
and RADUIS
support
Use IOS 11.2 or
greater on Cisco
devices
for full TACACS+
and RADUIS
support
Network Device Configuration for Cisco Secure ACS
Obviously, for any network device to take advantage of Cisco Secure ACS for AAA services, it
must be configured as a AAA client, told where their AAA server (ACS) is, and choose which
security protocol(s) to use to communicate between the AAA client and server. The network
administrator can optionally configure the AAA client to send update packets (default accounting
packets include only start and stop) that drive password expiry messages. Further, in order to
take advantage of ACSs ability of Cisco Secure ACS to authorize each administrative command
entered on a device by a particular user, the TACACS+ command authorization feature on the
device must be enabled. To ensure full support for the TACACS+ and RADIUS protocols, Cisco
access devices should be running IOS 11.2 or greater. The results of your planning efforts will
dictate which Cisco Secure ACS to use for each AAA client, and if command authorization will be
used.
For exact command syntax and options refer to the corresponding release of the IOS technical
documentation for the AAA client to be configured.
Cisco Secure ACS Software Install
Getting Started
READ the Release Notes
Back up server including Windows registry.
Make sure all network cards in the ACS are enabled.
System meets or exceeds hardware and software
requirements.
Ensure that Dial-up users can successfully access
the network.
Prepare to answer the installation questions.
Install software as the local administrator
Run install script or setup.exe
Start the Cisco Secure ACS services
ACS Software Install
Prior to installing Cisco Secure ACS, read the release notes and ensure that the Cisco Secure
ACS platform meets or exceeds the hardware and software system requirements. It is also a good
practice to backup the Windows platform, including the Windows registry, before installing any
new application. If the installation is an upgrade or a reinstallation of Cisco Secure ACS, backup
the current Cisco Secure ACS configuration and database, and copy the Cisco Secure ACS
backup file to a drive other than other one local to the Cisco Secure ACS.
Make sure the Cisco Secure ACS installation is performed as the local administrator on a
Windows platform. During the installation, Cisco Secure ACS must have all network cards
enabled. If there is a disabled network card on the ACS, the installation will proceed very slowly
because of delays caused by the Microsoft CryptoAPI. Place the CD in the CD drive, run the
install script and answer all questions asked to proceed with the installation.
At the end of the installation script, the user can elect to have the script start the Cisco Secure
ACS services. If this option is not selected, the Cisco Secure ACS web interface will not be
available until the ACS is rebooted or the CSAdmin service is started manually in the Windows
Control Panel.
For complete details on the Cisco Secure ACS installation refer to the Installation Guide and
review Chapter 4 of this tutorial.
Accessing Cisco Secure ACS - First Time (Local)
Getting Started
aaaaaaaaa
aaaaaaaaa
Start on port 2002, ACS
selects unique port for
administrative session
Start on port 2002, ACS
Accessing Cisco Secure ACS - First Time (local)
After Cisco Secure ACS is first installed, access to it is via a web browser client on the same
machine as the Cisco Secure ACS application. Upcoming discussions will illustrate how an
administrator can be configured in Cisco Secure ACS to allow for remote access to the
application.
To access the Cisco Secure ACS desktop, follow these steps:
1. Open a supported web browser on the Cisco Secure ACS local machine. Make sure a supported
web browser is properly configured. For example, Java and JavaScript must be enabled.
2. Enter the following URL to access the ACS:
http://<server IP address or hostname or localhost or 127.0.0.1>:2002.
3. By default, ACS doesnt require authentication when accessed from a Web browser on the
server. (This can be changed) In fact, no ACS administrators have been configured yet. The
ACS desktop will load immediately.
ACS allows you to configure a range of TCP ports to be used as the HTTP port for administrative
sessions. As can be seen in the above diagram, the initial HTTP port of 2002 for connection to
the ACS was changed to 4878. A different port for HTTP will be selected for each administrative
session. Later in this section, we will look at how to configure the range of ports used for HTTP
administrative sessions.
Lets take a closer look at the ACS GUI.
Getting Started
Cisco SecureACS
Configuration
Task
Cisco SecureACS
Configuration
Task
Help on Choices
(or display results)
Help on Choices
(or display results)
Configuration
options
Configuration
options
Next choices for
configuration
task/option selected
Next choices for
configuration
task/option selected
Back to initial screen
Back to initial screen
Screen Use
Screen Use
Selected Configuration
Task
Selected Configuration
Task
Navigation
Menu
Left Display Area Right Display Area
The Cisco Secure ACS GUI can be broken down into three main components: the navigation
menu, and a left and right display area. The major functions/tasks of Cisco Secure ACS are
organized on the left side of the Cisco Secure ACS desktop in the navigation menu. When one of
these functions or configuration tasks is selected, the two display areas will change. Notice that
the function or configuration task selected is listed above the left display area. Typically, the left
display area displays other selectable subtasks or items to be configured. The title bar of the
display area indicates what to do with the display contents. The right display area typically
displays content sensitive help for the items displayed in the left display area. The right display
area also can display results of items selected in the left display area or error messages for
incorrect configurations. Scrolling to the bottom of the help display reveals a Section
Information button that when selected will display the appropriate section of the Cisco Secure
ACS User Guide for the task selected from the navigation menu. Finally, the X button in the upper
right corner of the desktop ends the administrative session.
Navigation Menu
Getting Started - Cisco Secure ACS GUI
Configure individual user settings
Configure group settings
Configure NASs, NDGs, AAA servers and
Distribution tables
Distribution tables
Service & logging control, date format, password
validation, database replication, RDBMS synchronization,
ACS backup/restore, IP Pool mgmt, & VoIP accounting
Configure TACACS+, RADIUS, user, and group options
Configure ACS administrators, access/session/audit policies
Unknown user policy, database group mappings, configure
External Databases
External Databases
Online documentation
View enabled reports from ACS browser interface
Develop reusable, shared sets of authorization components
Navigation Menu
The navigation bar is where the configuration of Cisco Secure ACS begins. Understanding what
items of Cisco Secure ACS can be configured by each function/task in the navigation bar will
ease the use of Cisco Secure ACS. The following is a brief description of each Cisco Secure ACS
configuration task on the navigation menu. Each of these will be discussed at some point in the
remainder of this chapter.
User Setup - create user profiles and add to the Cisco Secure ACS database (map user to authentication
database, associate user with a user group for authorization, and configure any user specific
authorizations)
Group Setup - name groups and configure group authorizations
Shared Profile Components - develop reusable, shared sets of authorization components to ease the
authorization configuration for users and groups. Create shared components for Downloadable Cisco
PIX ACLs, Network Access Restrictions, and Command Authorization sets.
Network Configuration - create Network Device Groups (optional), add AAA clients and servers, map
AAA clients and servers to Network Device Groups
Navigation Menu
Getting Started - Cisco Secure ACS GUI
Distribution tables
Distribution tables
External Databases
External Databases
Navigation Menu - continued
System Configuration - configure database maintenance, IP Pool Management, VoIP accounting,
Cisco Secure ACS service control, logging features, date format, and password validation
Interface Configuration - choose which features and options the Cisco Secure ACS interface will
display
Administration Control - create administrator users and define administrative access, session, and
audit policies
External User Databases - configure which external databases are to be used, create unknown user
policy, and map user databases to a user group
Reports and Activities - view any enabled reports
On-Line Documentation - view the online documentation
Next, let's add an administrator user. Use this discussion to also help further your understanding
of how to use the ACS GUI.
Create First Admin User Account
Getting Started
Help on Administration
Control Buttons
Help on Administration
Control Buttons
Create First Admin User Account
In order to secure the local access to Cisco Secure ACS and to allow for remote access to Cisco
Secure ACS, a Cisco Secure ACS administrator user must be created. The navigation menu
buttons descriptions on the previous page, indicate that the Administration Control task is used
to complete this function.
The Administrative Control page displays a list of all configured administrator accounts and
various task buttons used to add new Cisco Secure ACS administrators and to configure various
administrative policies. The right display area shows help descriptions for each of the
Administrative Control sub-tasks.
To add a new Cisco Secure ACS administrator select the Add Administrator button.
Add Administrator
Getting Started - Create First Admin User Account
Grant this Administrator
All Privileges
Grant this Administrator
All Privileges
More Admin
Privileges
More Admin
Privileges
Submit to Add Administrator
Cancel to return to previous screen
Enter Administrator ID
and Password
Enter Administrator ID
and Password
Help on Add Administrator
Attributes
Help on Add Administrator
Attributes
Sub-task
Sub-task
Add Administrator
To add a Cisco Secure ACS administrator, the Add Administrator configuration page asks for the
obvious user input of the administrator: (account) name and a password. The rest of the Add
Administrator page allows for the configuration of the privileges for this administrator.
Administrators must be explicitly granted privileges to administer user groups, as well as all
other configuration activities associated with the functions listed in the navigation bar. For some
of these functions, privileges can also be granted at the sub-task level. For this user, however, we
wish to have at least one Cisco Secure ACS administrator who has all privileges - a super user.
To grant all privileges, select the Grant All button in the Administrator Privileges display box.
This will cause all groups listed in the left Available Groups box to be moved into the Editable
Groups box, and for all other privileges to be granted allowing this administrator to perform all
Cisco Secure ACS configuration functions.
Select Submit to create this new Cisco Secure ACS administrator and to return to the
Administrative Control display page. The Cancel button would return you to the main
Administrative Control display page without actually creating the administrator.
Note: The Administrator Privileges listed will change based on what is selected in the Advanced
Options sub-task of the Interface Configuration function. Later in this chapter, we will revisit
adding administrators and discuss the Interface Configuration function.
Administrator Policies
Getting Started - Create First Admin User Account
Edit/Delete Admin User
Edit/Delete Admin User
1
2
3
Click on Policy to Set/Edit
Click on Policy to Set/Edit
Administrator Policies
The administrator policies can be configured by selecting the appropriate button from the main
Administrative Control display page. Note that the administrator just configured is now displayed
in the list of Cisco Secure ACS administrators. To edit or delete administrators, select them from
this list.
The next three pages look at the configuration of the administrator policies for administrative
access, session, and audit control. Click on the appropriate button to enter the configuration
dialog page for each of these policies. Submitting the policy will return you to this main
Administrative Control display page.
Access Policy
Getting Started - Create First Admin User Account - Administrator Policies
Contents of Edit Screen
separated to fit on this page
Contents of Edit Screen
Restrict Ports to be used for
Administrator Session
(Defaults Displayed)
Restrict Ports to be used for
Administrator Session
(Defaults Displayed)
IP Address that a Cisco Secure
ACS Administrator is allowed
to connect from
(defaults displayed)
IP Address that a Cisco Secure
ACS Administrator is allowed
to connect from
(defaults displayed)
Access Policy
Not all deployments of Cisco Secure ACS may want the system to be accessed remotely for
administration purposes. Therefore, use the Access Policy to determine the rules for
administrative access to the Cisco Secure ACS system. Remote access to the Cisco Secure ACS
can be limited to hosts with select IP addresses. Use the IP Address Filtering configuration box
to determine the filtering criteria for permit/deny access to Cisco Secure ACS for the IP addresses
listed in the IP Address Ranges configuration box. Note: the IP address used for filtering is the
one received by Cisco Secure ACS. This is crucial to understand if either NAT or proxy HTTP is
implemented.
As previously mentioned, Cisco Secure ACS allocates the TCP port to be used for HTTP when the
administrator is granted access. The range of TCP ports to be used can be limited using the
HTTP Port Allocation configuration box. This can help to secure remote access to Cisco Secure
ACS through a firewall.
Along with the account login information, the Administrative Access Policy can be used to further
refine security for access to Cisco Secure ACS. Click Submit to enforce the newly configured
access policies and return to the main Administrative Control display page.
Session Policy
Session Control
Attributes
Session Control
Attributes
Uncheck to force username
and passwords for all
logins (local or remote)
Uncheck to force username
and passwords for all
logins (local or remote)
Session Policy
Use the Session Policy to configure parameters controlling the Cisco Secure ACS administrative
sessions. Again, the session policies are used to help increase the security of Cisco Secure
ACS. When initially installed, Cisco Secure ACS allows for automatic local login (no username or
password). Now that an administrator account with all privileges has been created, this capability
can be disabled to force all access to Cisco Secure ACS to be authenticated. Because leaving a
Cisco Secure ACS administrative session unattended can be a recipe for disaster, use the
Session Policy to cease a session after a configurable amount of idle time.
Previously, the Access Policy configured a valid range of IP addresses to be used for remote
administrative access to Cisco Secure ACS. Cisco Secure ACS is by default configured to send
an error message for any access attempt made from a machine not in the valid range. Uncheck
this option in the Session Policy to send no message. Finally, use the Session Policy to lock out
an administrator after a configurable number of failed login attempts.
Click Submit to enforce the newly configured session policies and return to the main
Administrative Control display page.
Audit Policy
Parameters for
Administrator Audit
Reports
Parameters for
Administrator Audit
Reports
To view Administrator Audit
Reports select:
Reports and Activities >
Administrator Audit > filename
To view Administrator Audit
Reports select:
Reports and Activities >
Administrator Audit > filename
Audit Policy
All activities performed by Cisco Secure ACS administrators are logged to an audit file. The
Audit Policy controls the time or amount of information in each file and the duration maintained
in the database. New audit files can be generated on a daily, weekly, monthly, or on a
configurable file size basis. Depending on which time option is selected, new daily files are
opened at 12:01 a.m. every day, new weekly files are opened at 12:01 a.m.every Sunday, and
monthly files are opened at 12:01 a.m. the first day of every month. Files can be maintained in the
directory based on a number of files, or on the age of the files. If the Manage Directory check box
is not selected, all logs are kept indefinitely. The Administrator Audit information can be viewed
by selecting Reports and Activities > Administrator Audit > filename.
Click Submit to enforce the newly configured audit policies and return to the main Administrative
Control display page.
Remotely Accessing Cisco Secure ACS
Getting Started
aaaaaaaaa
aaaaaaaaa
Starts on port 2002; ACS
Starts on port 2002; ACS
All remote users must login.
Sessions are controlled by
administration control policies.
All remote users must login.
Sessions are controlled by
administration control policies.
Remotely Accessing Cisco Secure ACS
Now that a Cisco Secure ACS administrator account has been created, along with administrative
policies, an administrator can remotely access Cisco Secure ACS from a host machine in the
valid IP address range defined in the Access Policy.
To remotely access Cisco Secure ACS follow these steps:
1. Open a supported web browser. Make sure a supported Web browser is properly configured.
For example, Java and JavaScript must be enabled.
2. Enter the following URL to access the Cisco Secure ACS:
http://<server IP address or hostname>:2002
3. At this point, you will receive the Login dialog as illustrated above. Enter the Cisco Secure ACS
administrators account name and password and click Login
The Cisco Secure ACS start page will now be displayed. Also, notice that Cisco Secure ACS has
assigned a new TCP port for HTTP use for this session based on the range of ports to be used for
HTTP allocation as configured in the Access Policy.
Now that the basics have been taken care of, lets look at some general configuration tasks
necessary for using Cisco Secure ACS.
Cisco Secure
ACS Road Map
General Configuration
Configure
Authorization
Configure
Authorization
Getting
Started
Getting
Started
Configure
ACS Network
Configure
ACS Network
Planning
Planning
General
Configuration
General
Configuration
View
ACS Reports
View
ACS Reports
Configure
ACS Users
Configure
ACS Users
Configure External User
Databases
Configure Interface
Configure System
Configure Cisco Secure ACS
Logs
General
Configuration
General
Configuration
This section discusses general configuration tasks for Cisco Secure ACS use. With a good Cisco
Secure ACS deployment plan in place, most of these configuration tasks can be performed once.
However, because of the flexibility of Cisco Secure ACS, Cisco Secure ACS administrator may
find themselves returning to some of these configuration tasks on a periodic basis to fine-tune
their Cisco Secure ACS deployment.
There is some logic to the listed order for the configuration tasks in this section based on display
dependencies. The external databases are configured first because they drive some System
Configuration tasks. The Interface Configuration task drives which configuration components
will be displayed in most of the other Cisco Secure ACS configuration task screens. Finally, the
Configure Reports task was included here because it is actually configured from within the
System Configuration tasks of Cisco Secure ACS.
Configure External User Databases
ACS
API for 3rd
Party
Authentication
Source
3rd Party
Authentication
Source
Specific ACS
configuration
for External
Database
External Database ACS uses to Communicate with
NT/2000, Generic LDAP, Novell NDS OS contains necessary files
ODBC Windows ODBC and 3rd Party ODBC Drivers
Traditional Token Server Software provided by OTP vendor
RADIUS Token Server Uses RADIUS interface
When the Cisco Secure ACS plan is complete and the initial Cisco Secure ACS setup tasks are
completed, one logical starting point is to configure any external user databases to be used for
authentication. Keep in mind that not all external databases support every type of authentication
method. Chapter 1 contains a table mapping the external database type to the supported
authentication protocols. For example, the Aironet EAP-MD5 authentication protocol is not
supported by any external databases.
In order for Cisco Secure ACS to communicate with the external databases, some form of API for
communication with the external database is required. For some of the external databases, the
API is either part of the Cisco Secure ACSs operating system, or part of the actual Cisco Secure
ACS software. Other external databases require additional software to be loaded on to the Cisco
Secure ACS host platform. This is typically done when the Cisco Secure ACS software is first
installed. The table above lists the extra software components required by each type of
supported external user database.
ACS
API for 3rd
Party
Authentication
Source
3rd Party
Authentication
Source
Specific ACS
configuration
for External
Database
External Database ACS uses to Communicate with
NT/2000, Generic LDAP, Novell NDS OS contains necessary files
ODBC Windows ODBC and 3rd Party ODBC Drivers
Traditional Token Server Software provided by OTP vendor
RADIUS Token Server Uses RADIUS interface
Configure External User Databases - continued
With the necessary APIs in place, the Cisco Secure ACS administrator must configure the
communication and feature parameters of the external databases employed. Authenticating
users with an external user database, requires more than just configuring Cisco Secure ACS to
communicate with an external user database. Cisco Secure ACS must also be instructed to send
authentication requests to the database for a particular user. Associating a database for
authentication to a user will be discussed in the Configure ACS Users section of this chapter.
This current configuration discussion is only used to inform Cisco Secure ACS that an external
user database will be used, and how to communicate with it.
It is not the intention of this tutorial to show how to configure each external database supported
by Cisco Secure ACS, but rather to give the reader an understanding of the possibilities and
choices for configuring Cisco Secure ACS. As an example of external database configuration, this
tutorial will present a brief discussion on the configuration of an external NT user database. For
details on how to configure other supported external databases, refer to Chapter 11 of the Cisco
Secure ACS User Guide.
Configure Cisco Secure ACS for External Windows NT/2000 Database
General Configuration - Configure External User Databases
Deployment Consideration
Location of the Cisco Secure ACS systems is a factor when using an external Windows NT
database. Location of the primary domain controllers (PDCs) with respect to the Cisco Secure
ACS may cause authentication delays. Cisco Secure ACS initially requests authentication service
from the PDC that serves the local domain in which the Cisco Secure ACS resides. If the user does
not exist in that PDC, the PDC requests authentication from its trusted neighbors. Due to the
nature of NT domain networking, this authentication may take a significant period of time, during
which the AAA client may time out. A user might make 3-5 attempts before successfully logging
in. This is not an issue in a distributed NT network where there is no appreciable delay for users
requesting NT authentication when logging into a local domain and getting authenticated by a
remote PDC. If users are having this problem without Cisco Secure ACS logins (NT domain only), it
is recommend to place Cisco Secure ACS systems in the remote regions to serve the wireless
community, using the central ACSes for backup. This has the added advantage of maintaining
login capability in the event of a WAN failure.
Configuring Cisco Secure ACS for External Database Support
The next few pages will illustrate the steps involved in configuring Cisco Secure ACS to
communicate with an external Windows NT (or Windows 2000 Active Directory) database with
which Cisco Secure ACS can use to authenticate users.
Step 1 In the navigation menu, click the External User Databases task.
Step 2 Click Database Configuration from the options presented.
Result: ACS displays a list of all possible external user database types.
Step 3 Click Windows NT/2000.
Note: to simplify the figures, the entire desktop will not be displayed for most selections. Unless
otherwise noted, the screens shown are in the left display area of the ACS desktop. The right
display area for the desktop continues to display help for the current selection in the left display
area.
Configure Cisco Secure ACS for External Windows NT/2000
Database
Default Name
Default Name
If no Windows NT/2000 database configuration exists, the Database Configuration Creation page
appears. Otherwise, the External User Database Configuration page appears.
Step 4 To create a new configuration:
a. Click Create New Configuration
b. Type a name for the new configuration for Windows NT/2000 authentication in the box
provided, or accept the default name in the box
c. Click Submit.
Result: ACS lists the new configuration on the External User Database Configuration page.
Step 5 Click Configure.
Configure Cisco Secure ACS for External NT/2000 Database
Contents of Screen
Contents of Screen
The Windows NT/2000 User Database Configuration page appears. This page has three
configuration boxes.
Step 6 To restrict network access to users who have Windows dial-in permission, select the Grant
dial-in permission to user check box in the Dial-in Permissions configuration box.
Note: Windows dial-in permission can be enabled in the Dial-in section of user properties
in Windows NT and on the Dial-in tab of the user properties in Windows 2000.
Step 7 Use the Configure Domain List configuration box to authenticate explicitly using each
trusted Windows domain for usernames that are not domain-qualified (Windows did not
specify domain in login attempt). Select the domains you want Cisco Secure ACS to use to
authenticate unqualified usernames in the Available Domains list and move them to the
Domain List list by clicking the > button. Note: the order of the list dictates which domain
will be used first to authenticate a user that is not domain-qualified.
Step 8 To enable password changes using MS-CHAP, select the check boxes for the applicable
MS-CHAP version in the MS-CHAP Settings configuration box.
Step 9 Click Submit.
Cisco Secure ACS saves the Windows NT/2000 user database configuration you created. In the
Configure ACS User section, discusses how to assign specific user accounts to use this
database for authentication.
Interface Configuration
X
X
X
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
Interface Configuration controls
which configuration tasks are
displayed for the
other ACS functions
Interface Configuration controls
which configuration tasks are
displayed for the
other ACS functions
The Interface Configuration task is the next logical choice in the progression of configuring Cisco
Secure ACS because it can be used to display or hide different configuration items in most other
functional configuration areas of Cisco Secure ACS. This feature enhances the ease of use of the
Cisco Secure ACS product by hiding those features that are not being used, thus simplifying
configuration screens. Of course, this can be the source of some frustration when attempting to
configure an aspect of Cisco Secure ACS and it is not displayed. Note: During the installation
procedure, some of these options are initially configured according to the installers answers to
the installation questions.
If at all possible, the Cisco Secure ACS administrators should be well versed in which
configuration features they wish to use ahead of time. This way the interface can be configured
prior to any detailed configuration work. There is always the possibility of returning to this
section to turn on or off a feature, but it could mean a fair amount of re-configuration of
previously configured aspects.
It should be noted that disabling an option in the Interface Configuration task does not affect
anything except the display of that function in the Cisco Secure ACS interface. Configurations
made while an Interface Configuration option was active, remain in effect even when that
Interface Configuration option is turned off. Further, the interface still displays any option that
has non-default values, even if you have configured that option to be hidden. If you later delete
values associated with that option, Cisco Secure ACS then hides the option from the interface.
User Data Configuration
General Configuration - Interface Configuration
RADIUS and TACACS appear
as options on this page only
after a AAA client is configured
to use them
RADIUS and TACACS appear
as options on this page only
after a AAA client is configured
to use them
Choose the fields to be displayed
on the User Setup page
Can edit name of field and can later select to
include field in accounting logs
Choose the fields to be displayed
on the User Setup page
Can edit name of field and can later select to
include field in accounting logs
User Data Configuration
When selecting the Interface Configuration task from the navigation menu, the Cisco Secure
ACS administrator is presented with several options for controlling what will be displayed on the
various configuration screens within Cisco Secure ACS. There are four categories of Interface
Configuration options: User Data, TACACS+, RADIUS, and Advanced. The RADIUS and
TACACS+ options only appear after a AAA client has been configured to use the security
protocol. We will revisit this after discussing AAA Client configuration in the next section.
Selecting the User Data Configuration option enables you to add (or edit) up to five fields for
recording additional information on each user. The fields you define on the Configure User
Define Fields page subsequently appear in the Supplementary User Information section at the top
of the User Setup page. For example, you could add the user's company name, telephone
number, department, billing code, and so on. These fields will also be available to be included in
the accounting logs. This will be discussed later in this section.
Click Submit to include these fields in the User Setup configuration dialog.
Advanced Options
Reduce configuration complexity
by turning off features you do not
intend to use
intend to use
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
1
7
6
5
4
3
2
1
1, 3, 6
1, 3, 6
1
2
2
2
2, 3, 6
2, 3, 6
1, 2
1, 2
4
5
5
5, 7
5, 7
5
5, 6
2
4
Interface Configuration - Advanced Options
Use the Advanced Options sub-task of the Interface Configuration task to select which
configuration options to display for the various Cisco Secure ACS tasks, thus simplifying their
configuration screens. The figure above indicates which Cisco Secure ACS task displays will
be modified because of the selection of one of the Advanced Options. The Advanced Options
can be loosely put into general areas of configuration including: various authorization
parameters on either a user or group level, the features of ACS network to use, logging options,
and specialized system configurations.
Advanced Options
intend to use
intend to use
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
1
7
6
5
4
3
2
1
1, 3, 6
1, 3, 6
1
2
2
2
2, 3, 6
2, 3, 6
1, 2
1, 2
4
5
5
5, 7
5, 7
5
5, 6
2
4
Interface Configuration - Advanced Options - continued
The Advanced Options features include the following:
Per-User TACACS+/RADIUS Attributes - enables TACACS+/RADIUS attributes to be set at a per-
user level, in addition to being set at the group level.
User-Level Network Access Restriction (NAR) Sets - allows for named, IP-based and CLI/DNIS-
based shared NARs to be used on the User Setup page.
User-Level Network Access Restrictions - enables the two sets of options for defining user-level, IP-
based and CLI/DNIS-based NARs on the User Setup page.
User-Level Downloadable ACLs - allows for shared Downloadable ACLs to be used on the User
Setup page.
Default Time-of-Day/Day-of-Week Specification - enables the default time-of-day/day-of-week
access settings grid on the Group Setup page.
Group-Level Network Access Restriction Sets - allows for named, IP-based and CLID/DNIS-based
shared NARs to be used on the Group Setup page.
Group-Level Network Access Restrictions - enables the two sets of options for defining user-level,
IP-based and CLI/DNIS-based NARs on the Group Setup page.
Group-Level Downloadable ACLs - allows for shared Downloadable ACLs to be used on the Group
Setup page.
Interface Configuration - Advanced Options - Continued
Group-Level Password Aging - enables the Password Aging section on the Group Setup page. The Password
Aging feature enables you to force users to change their passwords.
Max Sessions - enables the Max Sessions section on both the User and Group Setup pages. The Max
Sessions option sets the maximum number of simultaneous connections for a group or a user.
Usage Quotas - enables the Usage Quotas sections on both the User and Group Setup pages. The Usage
Quotas option sets one or more quotas for usage by a group or a user.
Distributed System Settings - displays the AAA server and proxy table on the Network Interface page. If the
tables are not empty and have information other than the defaults in them, they always appear. Necessary
option for the next three options as well.
Remote Logging - enables the Remote Logging feature in the Logging page of the System Configuration
section. Distributed System Settings must be enabled.
Cisco Secure ACS Database Replication - When selected, this feature enables the Cisco Secure ACS
database replication information on the System Configuration page. Distributed System Settings must be
enabled.
RDBMS Synchronization - enables the RDBMS (Relational Database Management System) Synchronization
option on the System Configuration page. If RDBMS Synchronization is configured, this option always
appears. Distributed System Settings must be enabled.
IP Pools - enables the IP Pools Address Recovery and IP Pools Server options on the System Configuration
page.
Network Device Groups - enables the use of Network Device Groups (NDGs). When NDGs are enabled, the
Network Configuration section and parts of the User Setup and Group Setup pages change to enable you to
manage groups of network devices (AAA clients or AAA servers). This feature is useful if you have many
devices to administer.
Advanced Options (Continued)
intend to use
intend to use
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
1
7
6
5
4
3
2
1
1, 3, 6
1, 3, 6
1
2
2
2
2, 3, 6
2, 3, 6
1, 2
1, 2
4
5
5
5, 7
5, 7
5
5, 6
2
4
Advanced Options (Continued)
intend to use
intend to use
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
~~~~
1
7
6
5
4
3
2
1
1, 3, 6
1, 3, 6
1
2
2
2
2, 3, 6
2, 3, 6
1, 2
1, 2
4
5
5
5, 7
5, 7
5
5, 6
2
4
Interface Configuration - Advanced Options - Continued
Voice over IP (VoIP) Group Settings - enables the VoIP option on the Group Setup page.
Voice-over-IP (VoIP) Accounting Configuration - enables the VoIP Accounting Configuration option
on the System Configuration page. This option is used to determine the logging format of RADIUS
VoIP accounting packets.
ODBC Logging - enables the ODBC logging sections on the Logging page of the System
Configuration section.
After making changes to the Advanced Options, click Submit to have the changes take effect.
System Configuration
Some tasks and sub-tasks show
up only if enabled by the
Interface Configuration task
How Cisco Secure ACS will be used
determines what elements need to be
configured
configured
The System Configuration task is used to configure some basic system parameters (Logging,
Date Format Control, Password Validation, etc.), advanced system features that depend on how
ACS is to be deployed (ACS Certificate Setup, IP Pools Server, etc.), and basic system
management tasks (ACS Backup, ACS Service Management). Thus, what is actually selected for
configuration on the System Configuration page will depend on how the ACS system is to be
deployed and used. Note some of the options on this page may only be displayed if
corresponding Interface Configuration Advanced Options are enabled.
configured
configured
System Configuration - continued
The following is a list of the System Configuration options. Most tasks are self explanatory to
configure, but for additional information consult the ACS User Guide or the on-line content
sensitive information displayed in the right display area of the ACS desktop. Some of these
options will be discussed in more detail in other sections of this chapter.
Service Control - Select to open the page from which you can stop or restart the ACS services and
configure the service log detail. Service Log configuration is discussed later in this section.
Logging - Select to configure various Cisco Secure ACS reports and customize the type of
information that is logged. Logging configuration is discussed later in this section.
Date Format Control - Select to configure the date format, either month/day/year or
day/month/year, for CSV files, Service Logs, and in the ACS GUI.
Password Validation - Select to configure password parameters; for example, password length.
Note: this option does not apply to administrator passwords, Enable passwords, or Sendauth
passwords.
Cisco Secure Database Replication - If this option does not appear, click Interface Configuration >
Advanced Options > Database Replication. Select to configure database replication among ACSs.
Note: To use this option you must have already enabled and configured Distributed-System
Settings in the Interface Configuration section. Database Replication is discussed in the ACS
Network Configuration section.
RDBMS Synchronization - If this feature does not appear, click Interface Configuration > Advanced
Options > RDBMS Synchronization. Select to configure database synchronization. Note: To use
this option you must have already enabled and configured the ODBC-compliant relational
database.
Cisco Secure ACS Backup - Select to back up or to configure parameters for backing up the Cisco
Secure ACS system. (This topic is discussed next.)
Cisco Secure ACS Restore - Select to restore or to configure parameters for restoring the Cisco
Secure ACS configuration from a A Cisco Secure CS system backup file.
Cisco Secure ACS Service Management - Select to configure the Cisco Secure ACS monitoring
service, CSMon, and for e-mail notification of CSMon events.
IP Pools Address Recovery - If this feature does not appear, click Interface Configuration >
Advanced Options > IP Pools Server. Select to enable automatic recovery of IP pools whose
addresses have not been used for a specified amount of time.
System Configuration (Continued)
configured
configured
IP Pools Server - If this feature does not appear, click Interface Configuration > Advanced Options
> IP Pools Server. Select to configure IP pools. The IP Pools feature enables you to assign the
same IP address to multiple users, as long as the users are on different segments of the network.
This enables you to re-use IP addresses and reduce the number of IP addresses on your network.
When you enable the IP Pools feature, ACS dynamically issues IP addresses from the IP pools you
have defined by number or name. You can configure up to 999 IP pools, for approximately 255,000
users.
VoIP Accounting Configuration - If this feature does not appear, click Interface Configuration >
Advanced Options > Voice-over-IP (VoIP) Accounting Configuration. Select to configure VoIP
accounting. The VoIP Accounting Configuration feature enables you to specify whether VoIP
accounting packets are logged along with RADIUS accounting data, in a CSV file, or in both
locations.
configured
configured
configured
configured
Cisco Secure ACS Certificate Setup - Select to configure automatic or manual certificate enrollment
to support EAP-TLS.
Certification Authority Setup - Select to configure which certificate authorities Cisco Secure ACS is to
trust when authenticating users with the EAP-TLS protocol.
Global Authentication Setup - Select to specify settings for all EAP and MS-CHAP authentication
requests.
Cisco Secure ACS Backup
General Configuration - System Configuration
Enable to manage the
number of files to keep
Select manual or
Schedule for automatic
backup
Select manual or
Schedule for automatic
backup
Cisco Secure ACS Backup
A tremendous amount of time and effort will be spent configuring Cisco Secure ACS to provide AAA
services to users wanting access to the network and its resource. Hence, it is important to backup Cisco
Secure ACS on a regular basis. The Cisco Secure ACS System Backup utility backs up the ACS user
database and information from the Windows Registry that is relevant to Cisco Secure ACS. The user
database backup includes all user information, such as username, password, and other authentication
information, including server certificates and the certificate trust list. The Windows Registry information
includes any system information that is stored in the Windows Registry, such as Network Device Groups
information, AAA client configuration, and Cisco Secure ACS administrator accounts. (Note that when users
authenticate using a remote database, only the username is saved in the Cisco Secure ACS local database;
thus the password is not maintained on the Cisco Secure ACS and cannot be backed up locally as a
consequence.)
To manually backup the Cisco Secure ACS system or to schedule regular backups, enter the Cisco Secure
ACS System Backup Setup dialog by selecting System Configuration > Cisco Secure ACS Backup. Like
most Cisco Secure ACS configuration functions, Cisco Secure ACS provides flexibility in controlling when
backups are performed. Backups can always be performed manually to capture current data without
waiting for the next scheduled time by clicking the Backup Now button. Backups can also be scheduled to
occur at regular intervals ( every X minutes) or at selected times and days during the week. Choose the
appropriate scheduling option, Every X minutes or At specific times, configure the arguments, and click
Submit to enforce the backup schedule. Note: because Cisco Secure ACS is momentarily shut down during
backups, a backup interval set too low may cause users to have trouble when trying to authenticate.
By default, the backup files are in the <drive>:\<install directory>\CSAuth\System Backups directory. To
change the default location, enter another existing directory. It is recommended to copy the files to
another system's hard drive in case the hardware fails on the primary system.
Maintaining multiple generations of backup files can help minimize downtime if the system information
becomes corrupt or is misconfigured. Remember to select the Manage Directory check box to be able to
automatically control how many, or for how long, backup files are to be kept on the hard drive. If not
selected, every backup file will be retained indefinitely.
Cisco Secure ACS Logs
Accounting Logs (Must Be Enabled - CSV or ODBC Format)
- TACACS+ Accounting Log
- TACACS+ Administration Log
- RADIUS Accounting Log
- VoIP Accounting Log
- Failed Attempts Log
- Passed Authentications Log (CSV Only)
Accounting Logs (Must Be Enabled - CSV or ODBC Format)
- TACACS+ Accounting Log
- TACACS+ Administration Log
- RADIUS Accounting Log
- VoIP Accounting Log
- Failed Attempts Log
- Passed Authentications Log (CSV Only)
Service Logs (Must Be Enabled)
- Diagnostic Reports
Service Logs (Must Be Enabled)
- Diagnostic Reports
System Activity Logs (Always Enabled)
- ACS Backup and Restore Log
- RDBMS Synchronization Log
- Database Replication Log
- Administration Audit Log
- ACS Service Monitoring Log
System Activity Logs (Always Enabled)
- ACS Backup and Restore Log
- RDBMS Synchronization Log
- Database Replication Log
- Administration Audit Log
- ACS Service Monitoring Log
Administrative Logs (Always Enabled)
- Logged-in Users
- Disabled Accounts
Administrative Logs (Always Enabled)
- Logged-in Users
- Disabled Accounts
Details of Accounting Packets
(View with Reports & Activities task)
Details of ACS System Activities
Current Administrative Status of Users
Status Information on ACS Services
(For use by Cisco Personnel for Troubleshooting)
Cisco Secure ACS Logs
Cisco Secure ACS maintains four categories of logs to detail system and user activity. Except for the
Service Logs, these logs can be viewed as HTML reports using the Reports & Activity task discussed in the
upcoming View Cisco Secure ACS Reports section of this chapter. Note: Some of the logs availability are
dependent on selections made in the Interface Configuration task.
Accounting Logs - contain information about the use of remote access services by users. These logs must be
enabled to be viewed by the Reports & Activity task, and can be configured for included content. The default
format for all accounting logs is CSV; however, all accounting logs except for the Passed Authentications log
can also be generated in ODBC format. The accounting logs include: TACACS+ Accounting Log, TACACS+
Administration Log (Command Authorization), RADIUS Accounting Log, VoIP Accounting Log, Failed Attempts
Log, and Passed Authentications Log. (Note that Aironet APs using software releases earlier than v11.10 do
not send accounting records.)
System Activity Logs - record system-related events. These logs are primarily useful for troubleshooting and/or
audits. These logs are always enabled. The system activity logs include: Cisco Secure ACS Backup and
Restore Log, RDBMS Synchronization Log, Database Replication Log, Administration Audit Log, and ACS
Service Monitoring Log.
Administration Logs - These reports show the current status of user accounts. These logs are always enabled.
The Administration Reports include: Logged-In Users Report and Disabled Accounts Report.
Service Logs - contain a record of all Cisco Secure ACS services (CSAdmin, CSAuth, CSDBSync, CSLog,
CSMon, CSRadius, CSTacacs) actions and activities. The service logs are considered to be diagnostic logs and
are used for troubleshooting and/or debugging purposes only. These logs are not intended for general use by
Cisco Secure ACS administrators; instead, they are mainly sources of information for Cisco support personnel.
These reports are not viewable from the Reports & Activity task.
Let's take a look at how to allow for ODBC formatted logs, and the configuration of both formats of
Accounting Logs.
Preparing for ODBC Logging
General Configuration Cisco Secure ACS Logs
Create the System
DSN to be used by
ACS for ODBC
Logging
Communication
Create the System
DSN to be used by
ACS for ODBC
Logging
Communication
Preparing for ODBC Logging
Before any of the accounting logs can be generated in ODBC format, the Cisco Secure ACS
Administrator must first configure Cisco Secure ACS for their use. The first step is simply
enabling their use and thus allowing the ODBC configuration option to be displayed by the Cisco
Secure ACS desktop. Like many other features that can be selected to be displayed or not, ODBC
Logging is enabled by selecting the option in Interface Configuration > Advanced Options.
The second step requires a system DSN (data source names) in order to be created for Cisco
Secure ACS to communicate with the relational database that will be used to store the logging
data. This is done through the ODBC Data Sources task in the Windows Control Panel. Add a
System DSN, select the appropriate driver, and configure the necessary information for the
selected driver (log-in and location of database information).
When configured, this DSN is available for use when configuring an ODBC log file.
(Chapter 4 highlights the importance of installing the correct ODBC components (ODBC Jet
Driver v2.6) needed by Cisco Secure ACS. If the Cisco Secure ACS installation program does not
find them, or if they are not functioning properly, abort the installation program and install the
necessary ODBC components by running the Microsoft Data Access Components (MDAC) v2.5
program located on the Cisco Secure ACS CD, or download the latest version from Microsofts
web site.)
Configuring ODBC Accounting Logs
General Configuration - Cisco Secure ACS Logs
Use DSN Configured
Use DSN Configured
Enable Log
Enable Log
Select Attributes to
include in log
Select Attributes to
include in log
Configuring ODBC Accounting Logs
The Accounting Logs are configured by selecting the Logging option from the System
Configuration task. The Log Target will display a list of the possible accounting logs for
configuration (one for each accounting record). ODBC logging enables Cisco Secure ACS to log
directly into an ODBC-compliant relational database, where data is stored in tables, one table per
log type. To configure any of the ODBC logs, select them by name from the Log Target list. Note:
The Remote Logging option will be discussed in the Cisco Secure ACS Network Configuration
section.
The first portion of the log configuration box consists of a check box to enable logging for the
selected accounting record. The Select Columns to Log dialog allows the Cisco Secure ACS
administrator to configure which attributes to include in the log. Note that the more attributes
included, the better the log file is for troubleshooting. This comes at the expense of processing and
disk space. These first two configuration areas are exactly the same for CSV formatted logs.
Among the many attributes that Cisco Secure ACS can record in its CSV or ODBC logs, a few are of
special importance including:
User-defined Attributes - These logging attributes appear in the Attributes list for any log
configuration page. Cisco Secure ACS lists them using their default names: Real Name, Description,
User Field 3, User Field 4, and User Field 5. If you change the name of a user-defined attribute, the
default name still appears in the Attributes list rather than the new name.
ExtDB Info - If the user is authenticated with an external user database, this attribute contains a value
returned by the database. In the case of a Windows NT/2000 user database, this attribute contains
the name of the domain that authenticated the user.
Access Device - The name of the AAA client sending the logging data to the Cisco Secure ACS.
Network Device Group - The network device group to which the access device (AAA client) belongs.
Configuring ODBC Accounting Logs (Continued)
Use DSN Configured
Use DSN Configured
Configuring ODBC Accounting Logs - continued
Device Command Set This is the name of the device command set, if any, that was used to
satisfy a command authorization request. The Device Command Set attribute is available for
Passed Authentication and Failed Attempts logs.
Filter Information This is the result of network access restrictions (NARs) applied to the user, if
any. The message in this field indicates whether all applicable NARs permitted the user access, all
applicable NARs denied the user access, or more specific information about which NAR
permitted/denied the user access. If no NARs apply to the user, this logging attribute notes that no
NARs were applied. The Filter Information attribute is available for Passed Authentication and
Failed Attempts logs.
The final configuration task is to associate the log with the previously configured DSN so Cisco
Secure ACS can properly communicate with the database. The Data Sources pull down list will
contain all system DSNs defined on the Cisco Secure ACS platform. Enter the intrinsic data for
the selected ODBC database, and click Submit to have Cisco Secure ACS immediately begin
logging the appropriate data to the selected database.
Configuring CSV Accounting Logs
Only difference in Setup is Log File Management instead of ODBC Connection Settings
Only difference in Setup is Log File Management instead of ODBC Connection Settings
Default CSV Log Directories
\Program Files\CiscoSecure ACS v3.0\Logs\log type
Default CSV Log Directories
\Program Files\CiscoSecure ACS v3.0\Logs\log type
How Often to Create
How Often to Create
Where to Put
Where to Put
How Long to Keep
(must enable)
How Long to Keep
(must enable)
Configuring CSV Accounting Logs
The CSV format records log data in columns separated by commas in files located on the Cisco
Secure ACS platform. These files can be easily imported into a variety of third-party applications
for performing user defined queries and other reporting tasks. When configuring log files to be
generated in the CSV format, the same steps, as used for the ODBC formatted logs, apply to
enabling the log and selecting the attributes to include in the log. Where the CSV log
configuration differs from the ODBC log configuration is in the configuration of the management
of the CSV log files.
The Log File Management configuration dialog is used to configure how often to create new log
files, where to store the files, and how long to keep them around (automatic deletion). New log
files can be generated daily, weekly, monthly, or every time the current one reaches a certain size.
By default, the CSV logs are stored in the \Program Files\CiscoSecure ACS v3.0\Logs\log type
directory (example of log type is TACACS+ Administration) with the file name log type yyyy-mm-
dd.csv (example -TACACS+ Administration 2002-02-28). Note: The date format can be changed by
selecting the Date Format Control option in the System Configuration task. If enabled, CSV log
files are generated according to the scheduled time even if no corresponding activity occurred.
Selecting the Manage Directory check box allows the Cisco Secure ACS administrator to control
the number of logs to keep and thus be available for viewing. If the Manage Directory check box
is not selected, every log file remains in the directory and is available for viewing.
When the settings for the log file are complete, click Submit to have Cisco Secure ACS
immediately begin logging the appropriate data.
Configuring Cisco Secure ACS Service Logs
\Program Files\CiscoSecure ACS v3.0\ACS Service\Logs
\Program Files\CiscoSecure ACS v3.0\ACS Service\Logs
Used for troubleshooting or
debugging purposes
Used for troubleshooting or
debugging purposes
Configuring Cisco Secure ACS Service Logs
The servicelogs contain a record of all actions and activities for each of the Cisco Secure ACS
internal services. These logs are generated whenever you log in to Windows NT/2000 and the
Cisco Secure ACS services are started. Though these logs are used primarily by Cisco support
personnel to debug and troubleshoot Cisco Secure ACS system problems, their configuration is
briefly discussed for completeness. Selecting the Service Control function from the System
Configuration task, displays the current state of the Cisco Secure ACS system and allows you to
determine the detail to include in the Cisco Secure ACS Service Logs. Like the CSV accounting
logs, the Cisco Secure ACS administrator can configure how often to create new files, and when
to purge files. To control the number of logs kept, select the Manage Directory check box. To
view any of the service logs, go to the appropriate directory and use a text reader application.
The service logs are stored in the \Program Files\CiscoSecure ACS v3.0\ACS Service\Logs directory,
where Cisco Secure ACS Service is the name of a particular Cisco Secure ACS Service.
Note: Even if the Service Logs are never to be reviewed, it is wise to select the Manage Directory
check box to help control the utilization of disk space.
Click Restart to restart the Cisco Secure ACS services and to make the changes to the Service
Log configuration effective.
ACS Road Map
Configure Cisco Secure
ACS Network
Configure
Authorization
Configure
Authorization
Configure
ACS Network
Configure
ACS Network
View
ACS Reports
View
ACS Reports
Getting
Started
Getting
Started
Configure
ACS Users
Configure
ACS Users
General
Configuration
General
Configuration
Planning
Planning
Configure Cisco Secure ACS Network
ACS Network Configuration
Options
Network Device Groups
Add AAA Clients
Using Cisco Secure ACS as a
Distributed System
Revisit Interface Configuration
New options based on added AAA
Clients
Configure
ACS Network
Configure
ACS Network
The Cisco Secure ACS network is the collection of AAA clients using Cisco Secure ACS for AAA
services, and optionally is the use of Cisco Secure ACS as part of a distributed system of ACSs.
When adding the AAA clients to the Cisco Secure ACS network, they can optionally be grouped
together in network device groups (NDG) to ease their administration and association with
various access policies. Using ACS as part of a distributed system allows for the configuration
of remote AAA servers to be used for proxy authentication requests, remote logging, and Cisco
Secure ACS database replication.
This section discusses the different configuration options for the Cisco Secure ACS network,
how to add and configure AAA clients, define NDGs, add and configure remote AAA servers, and
configure proxy authentication requests.
Cisco Secure ACS Network Configuration Options
Distributed/
No NDG
Not Distributed/
NDG
Not Distributed/
No NDG
Distributed/
NDG
Config Proxy
Distribution
Table
Add Network Device Groups
Add AAA Clients Add ACS Servers
For Network Configuration Options
Solid arrows show configuration menu hierarchy
Dashed arrow indicates configuration dependency
For Network Configuration Options
Solid arrows show configuration menu hierarchy
Dashed arrow indicates configuration dependency
Cisco Secure ACS Network Configuration Options
The configuration options for the Cisco Secure ACS network configuration depend on selections
made in the Advanced Options section of the Interface Configuration task. The Cisco Secure
ACS deployment can choose to use Cisco Secure ACS in a distributed system or not, and can
choose to use NDGs or not. This leads to four possible Cisco Secure ACS network
configurations. Based on the configuration chosen, the Cisco Secure ACS Network Configuration
task will display different sets of configuration screens in different orders.
Distributed System using NDGs - First page displays the Network Device Groups and Proxy
Distribution tables. Drilling down into a NDG will allow the Cisco Secure ACS administrator to
configure AAA clients and AAA servers. Note: Distributed system services cannot be configured
until remote AAA servers have been defined.
Distributed System not using NDGs - First page displays the AAA clients, AAA servers, and proxy
distribution tables. Note: Distributed system services cannot be configured until remote AAA
servers have been defined.
Non-Distributed System using NDGs - First page displays the Network Device Groups table.
Drilling down into a NDG will allow the ACS administrator to configure AAA clients.
Non-Distributed System not using NDGs - First page will display the AAA clients table.
Let's first discuss creating NDGs and the adding of AAA clients. This will be followed by a
discussion on using Cisco Secure ACS in a distributed system and the configuration options
available when making this choice.
Groupings of network devices
Groupings of ACSs (distributed system)
Simplified administration
Groupings of network devices
Groupings of ACSs (distributed system)
Simplified administration
Select to edit group membership or
to rename or delete group
Select to edit group membership or
to rename or delete group
Contains devices not
associated with a group
Contains devices not
associated with a group
Create new group
Create new group
NDGs can greatly simplify the administration of a large numbers of AAA clients by logically
grouping together devices and assigning each NDG a convenient name that can be used to refer
to all devices within that NDG. These NDGs can then later be assigned to access policies
potentially saving the administrator the time of entering a large number of AAA clients
individually. As discussed in the next section, Configure Authorization, access policies can be
created to permit or deny user access from certain devices, and to allow different levels of
administration to different devices. If used in this way, NDGs will greatly simplify the
configuration of these access policies.
To create a new NDG, select Add Entry form the Network Device Groups configuration table.
(This table lists all currently configured NDGs. If any AAA clients and/or AAA servers were
configured prior to enabling NDGs, they will be accounted for in the Not Assigned NDG.
Discussed later is the mechanism for associating these devices with a NDG. But first, the NDG
must be created.) In the New Network Device Group configuration box, enter a name for the new
NDG, and click Submit. The left display area of the Cisco Secure ACS desktop now re-displays
the Network Device Groups table with the NDG just configured as an entry.
Add AAA Clients
Unique Name
Can associate more than 1 AAA
client with an entry.
Assign client to group
Choose protocol
(Can create custom RADIUS VSAs)
Shared Secret between client
and server for encryption
Cisco Secure ACS must be
restarted for changes to take effect.
Click to edit (all except name)
or to delete.
or to delete.
Group name if using NDGs else blank
Add AAA Clients
AAA clients are added from the AAA Clients table. If NDGs have not been enabled, this table
appears in the left display area after selecting the Network Configuration task from the navigation
menu. If NDGs are enabled, display the Add Clients table for the NDG by selecting the NDG name
from the Network Device Groups table.
Click the Add Entry button on the AAA Clients table to access the configuration dialog for adding
a new AAA client. In the AAA Client Hostname box, type the name assigned to this AAA client.
(This field is not displayed if editing an existing AAA client.) This AAA client can actually be a
collection of AAA clients. In the AAA Client IP Address box, type the AAA client's IP address or
addresses. To designate more than one AAA client with a single Cisco Secure ACS AAA client
entry, specify the IP address for each AAA client separately or use the wildcard asterisk (*) for an
octet in the IP address.
In the Key box, type the shared secret that the AAA client and AAA server (Cisco Secure ACS)
share to encrypt the data. Note: Keys are case sensitive. Also, be careful not to make mistakes
when entering the keys because they are not synchronized in any way. Mistakes will cause the
Cisco Secure ACS to discard all packets from the client because it must treat the client as a
potential intruder and a threat to network security.
If you are using NDGs, from the Network Device Group list, select the name of the NDG to which
this AAA client should belong (default name is the group this AAA client configuration was
launched from), or select Not Assigned to set this AAA client to be independent of NDGs. Use
this field to change the AAA clients group association at any time.
<continue on next page >
Add AAA Clients - continued
Select the authentication protocol to be used by this AAA client from the the Authenticate Using
list. Selecting which authentication protocol to use is fairly straightforward. For example:
TACACS+ is the standard choice when authenticating shell access using Cisco Systems access
servers, routers, and firewalls.
Remote Access Dial-In User Service (RADIUS) (Cisco Aironet
Switch) is a Cisco Secure ACS

supported Cisco Aironet device such as Cisco Aironet Access Point 340 or 350. A user is first
authenticated by using Ciscos Lightweight Extensible Authentication Protocol (LEAP); if this fails,
Cisco Secure ACS fails over to EAP-TLS.
RADIUS (Internet Engineering Task Force [IETF]) should be used if you are using RADIUS from
more than one manufacturer and you want to use standard IETF RADIUS attributes. This is also
the protocol to select if you want EAP-TLS to be used with Cisco Aironet AAA clients.
RADIUS (Cisco IOS
Software/PIX
Firewall) enables you to pack commands sent to a Cisco IOS

AAA client. The commands are defined in the upcoming Shared Profile Setup section.
Note: Custom RADIUS vendor-specific attributes (VSAs) can be configured to be used as the
security protocol for a AAA client. To configure a custom RADIUS VSA, see Appendix E of the
Cisco Secure ACS User Guide.
Note: The same device can be entered as a AAA device more than once as long as the AAA
hostname is different. This allows for both RADIUS processing for network access and
TACACS+ processing for device administration for the same device.
Add AAA Clients (continued)
Unique Name
Choose protocol
or to delete.
or to delete.
Add AAA Clients (continued)
Unique Name
Choose protocol
or to delete.
or to delete.
Select any additional security protocol processing options desired from the options listed. To
save your changes and apply them immediately, click Submit + Restart. Note: Restarting the
service clears the Logged-in User report and temporarily interrupts all Cisco Secure ACS
services, including resetting the Max Sessions counter to zero. To save your changes and apply
them later, click Submit. When you are ready to implement the changes, select System
Configuration > Service Control > Restart.
Note: Any errors in the configuration of AAA clients will be flagged and displayed in the right
display area of the Cisco Secure ACS desktop after clicking either Submit or Submit + Restart.
Using Cisco-Secure ACS as a Distributed System
Configuring Cisco Secure ACS Network
la-users
Bob
x1y2z3
Bob@la
x1y2z3
la-users
Bob
Accounting
Bob on
travel to
NY
(needs
proxy
access to
network)
Bobs Office
(normal network
access point)
LA-Primary Cisco Secure ACS
User Profile
Userid: bob
Password: x1y2z3
Group: la-users
Distributed Cisco Secure ACS
System allows for:
Proxy
Database replication
Remote and centralized logging
System allows for:
Proxy
Bob
Accounting
Proxy Distribution Entry
String: @la
Strip: Yes
Forward: la-acs, la-acs2
Accounting: Local & Remote
NY-Primary Cisco Secure ACS
Bob
Accounting
Bob
Accounting
Using Cisco Secure ACS as a Distributed System
In large enterprises, chances are that multiple Cisco Secure ACS systems are deployed.
Configuring Cisco Secure ACS as a distributed system allows the overall Cisco Secure ACS
deployment to take advantage of information from other Cisco Secure ACS systems. In
particular, proxy is a feature that allows authentication requests to be forwarded to another Cisco
Secure ACS system. This feature reduces the duplication of the Cisco Secure ACS user database
at each location. This is best illustrated using the example depicted in the figure above.
Bob normally accesses the corporate network from his home office on the west coast. As such,
Bobs user profile is stored in the Cisco Secure ACS system configured in the Los Angeles
offices. Occasionally, Bob must travel to the east coast to perform his job, but still wishes to
retrieve information from the corporate network. While travelling, Bob can access the corporate
network from access gateways configured to use the AAA services provided by the Cisco Secure
ACS system in New York. Rather than duplicating Bobs user profile in the New York Cisco
Secure ACS system, the New York system can be configured to pass Bobs authentication
request to the Los Angeles Cisco Secure ACS system, which has Bobs user profile. When
authenticated in Los Angeles, the authentication-granted message and Bobs access profile are
sent back to the New York Cisco Secure ACS system.
Using Cisco-Secure ACS as a Distributed System
la-users
Bob
x1y2z3
Bob@la
x1y2z3
la-users
Bob
Accounting
Bob on
travel to
NY
(needs
proxy
access to
network)
Bobs Office
(normal network
access point)
LA-Primary Cisco Secure ACS
User Profile
Userid: bob
Password: x1y2z3
Group: la-users
System allows for:
Proxy
System allows for:
Proxy
Bob
Accounting
Proxy Distribution Entry
String: @la
Strip: Yes
Forward: la-acs, la-acs2
Accounting: Local & Remote
NY-Primary Cisco Secure ACS
Bob
Accounting
Bob
Accounting
Using Cisco Secure ACS as a Distributed System- continued
To configure this proxy request, the New York Cisco Secure ACS system must be configured with
the Los Angeles Cisco Secure ACS as a remote AAA server, and a policy must be implemented to
recognize Bobs authentication information to forward to the Los Angeles Cisco Secure ACS for
processing. Recognition of Bobs authentication request is done with a string-matching
mechanism.
Utilizing Cisco Secure ACS as a distributed system also allows for Cisco Secure ACS database
replication between servers (perhaps primary to a backup), and the ability to forward all log
information to a central Cisco Secure ACS.
Let's next look at how to add remote AAA servers to Cisco Secure ACS, configure proxy
distribution information, and briefly look at the other possibilities available when using Cisco
Secure ACS as a distributed system. Remember that in order to implement these features the
appropriate options (Distributed System Settings, Cisco Secure ACS Database Replication, and
Remote Logging) must be enabled in the Advanced Options of the Interface Configuration task.
Add Remote AAA Servers
Configuring Cisco Secure ACS Network Using Cisco Secure ACS
as a Distributed System
Cisco Secure ACS must be restarted
for changes to take effect.
or to delete.
or to delete.
Direction traffic to/from remote
AAA server is allowed to flow from
local AAA server.
If not using NDGs, local ACS will be listed.
Interim packets are sent to enable
approximation of session length if
no stop packet is received.
ACS, RADUIS, TACACS+
Shared Secret for Encryption
Remote AAA Server
To add a new remote AAA server, click the Add Entry button from the AAA Servers configuration
table. If NDGs are not enabled, the AAA Server configuration table is displayed in the left display
area after selecting the Network Configuration task from the navigation menu. If NDGs are enabled,
the AAA Servers configuration table can be displayed by selecting an NDG from the Network Device
Groups table. With NDGs, the Cisco Secure ACS administrator can choose to group AAA servers
together, associate them with the Not Assigned NDG, or can include them in the same groups as
AAA clients. Note that defining a AAA server in the same group as AAA clients does not create any
type of processing correlation between the two. Use NDGs of AAA servers to configure which set
of remote AAA servers will receive replication data from this Cisco Secure ACS system, and which
set of remote AAA servers this Cisco Secure ACS system will accept replication data from.
When the Add AAA Server dialog configuration box is displayed, provide a name, IP address, and
shared secret key for the remote AAA server being configured. If NDGs are enabled, assign the
remote AAA server to the desired group or select Not Assigned.
Configuring Cisco Secure ACS Network Using Cisco Secure ACS
or to delete.
or to delete.
Direction traffic to/from remote
AAA server is allowed to flow from
local AAA server.
Interim packets are sent to enable
approximation of session length if
no stop packet is received.
ACS, RADUIS, TACACS+
Shared Secret for Encryption
Remote AAA Server
Add Remote AAA Servers -continued
Access devices can be configured to send periodic updates (watchdog packets) to serve as an
approximation of session length in the event that no stop packet is received to mark the end of the
session. When using Cisco Secure ACS as part of a distributed system, all accounting packets can
be forwarded to a central server (remote logging). If this Cisco Secure ACS is acting as the central
server and you wish to log the watchdog packets being sent from the remote server being
configured, select the Log Update/Watchdog Packets from this remote AAA Server check box.
Remote logging is discussed later in this chapter.
Finally, select the direction in which traffic to and from the remote AAA server is allowed to flow
from this local Cisco Secure ACS. To add this device to Cisco Secure ACS and have it immediately
available to the system for use, click the Submit + Restart button. Remember that restarting the
service clears the Logged-in User report and temporarily interrupts all Cisco Secure ACS services,
including resetting the Max Sessions counter to zero. To save your changes and apply them later,
click Submit. When you are ready to implement the changes, select System Configuration > Service
Control > Restart.
With remote AAA servers now available to the distributed Cisco Secure ACS system, proxy
authentication requests, database replication, and remote logging services can be configured.
Proxy Distribution Table Configuration
Configuring Cisco Secure ACS Network - Using Cisco Secure ACS as
a Distributed System
Click to edit.
Click to edit.
Forward all authentication
requests containing a
suffix of @la to la-acs
after stripping the suffix.
Log accounting to both
remote and local AAA
servers.
servers.
List
multiple
Servers
for back-
up proxy
in case of
failure
If no other matches,
forward to default
(local AAA server; can
be changed).
forward to default
be changed).
The Proxy Distribution Table comprises entries that show the character strings on which to proxy, the
AAA servers to proxy to, whether to strip the character string from the authentication request
information, and where to send the accounting information (local/remote, remote, or local). When the
Distributed Systems Settings option is selected, all authentication requests that Cisco Secure ACS
receives from AAA clients are compared against the Character String entries in the Proxy Distribution
Table. When a match is found, Cisco Secure ACS forwards the authentication request to the AAA
server associated with the matched character string in the Proxy Distribution Table. Prior to any
Cisco Secure ACS administrator proxy configuration, a single entry exists in the Proxy Distribution
Table, with the character string (default) and the AAA server to forward to being the local Cisco
Secure ACS. The "(Default)" entry matches authentication requests that do not match any other
defined character strings.
Note: The character string definition for the (Default) entry cannot be changed, but the distribution of
authentication requests matching the (Default) entry can be. It is often easier to define strings that
match authentication requests to be processed locally, rather than defining strings that match
authentication requests to be processed remotely. In such a case, associating the (Default) entry with
a remote AAA server permits you to configure your Proxy Distribution Table with the more easily
written entries.
Configuring Cisco Secure ACS Network - Using Cisco Secure ACS as
a Distributed System
Click to edit.
Click to edit.
servers.
servers.
List
multiple
Servers
for back-
up proxy
in case of
failure
forward to default
be changed).
forward to default
be changed).
Proxy Distribution Table Configuration - continued
To create a new Proxy Distribution entry, select Add Entry from the Proxy Distribution Table. Enter
the string of characters, including the delimiter, to forward on when users dial in to be authenticated,
select the position of the character string (prefix or suffix), and choose whether or not to strip the
character string from the authentication request before forwarding.
Next, select the AAA servers to forward the request to from the available AAA Servers column. Click
the > button to move it to the Forward To column. Additional AAA servers can be selected to act as
backups in the event the prior servers fails. Finally, choose where to log the accounting information.
To add this proxy definition to Cisco Secure ACS and have it immediately available to the system for
use, click the Submit + Restart button. Remember that restarting the service clears the Logged-in
User report and temporarily interrupts all Cisco Secure ACS services, including resetting the Max
Sessions counter to zero. To save your changes and apply them later, click Submit. When you are
ready to implement the changes, select System Configuration > Service Control > Restart.
Database Replication
Configuring Cisco Secure ACS Network - Using Cisco Secure ACS
Select
Components
Replicate
Select
Replication
Partners
(out)
Select
Schedule
Select
Replication
Partners
(in)
Primary - Secondary
Primary - Secondary
Local Cisco
Secure
ACS
Another feature available when Distributed Systems is enabled is the ability to replicate all or
portions of the Cisco Secure ACS database between two or more Cisco Secure ACS systems.
This greatly simplifies having backup Cisco Secure ACS systems identical to the primary.
Obviously to use this feature, remote Cisco Secure ACS systems (receivers or senders of
replication data) must be entered into the local Cisco Secure ACS system. As discussed
previously, enabling the Distributed Systems Settings option in the Advanced Options function of
the Interface Configuration tasks allows for AAA servers to be entered using the Network
Configuration task.
When the desired remote Cisco Secure ACS systems are configured in Cisco Secure ACS, the
configuration of Database Replication is straightforward. Select the Cisco Secure Database
Replication function from the Systems Configuration task menu. The flexibility of the product
allows you to configure which of the Cisco Secure ACS database components to send to other
Cisco Secure ACS systems, and which components can be received. Replication can then be
scheduled to occur either manually, whenever a replication is received, at selected times, or at
periodic intervals. The Cisco Secure ACS administrator can then select whom to send the
selected components to, and whom to receive selected components from. Using NDGs of AAA
servers can facilitate the selection of multiple servers to receive from, especially when it is a
subset of all servers defined.
The Cisco Secure ACS administrator can then choose to start a replication, or submit the
replication schedule. Review the database replication caveats, discussed next, before replicating
your database.
Note: The RDBMS synchronization has a similar configuration, but a slightly different use in that
it uses any defined ODBC database for the purpose of sharing data.
Caveats
Data is overwritten when Receive
checkbox is selected.
Data flow is one direction.
During replication process,
authentication service is halted on both
machines, but not at the same time.
Select
Components
(check boxes)
Replicate
Cisco Secure ACS is receiving
data; data is overwritten.
Select
Schedule
Primary Cisco
Secure ACS
Database Replication - Caveats
For each component that Cisco Secure ACS is to receive from another Cisco Secure ACS, that
component is completely overwritten in favor of the replicated component. For example, if the
Receive checkbox is selected for User and group database, any user records in the database
prior to the replication is lost upon replication, when the user database of the other Cisco Secure
ACS is received.
Keep in mind that database replication is not the same as database synchronization. The data
flow in replication is one way and the data on the secondary is overwritten, as described in the
previous paragraph.
During the replication process, the authentication service is halted briefly on both machines
(although not at the same time). On the sender AAA server, service is halted while the appropriate
files and Registry information are collated and prepared for sending. On the receiver AAA server,
service is halted when the incoming file and registry set are restored. Service is normal while the
replication set is being transmitted between servers.
Remote and Centralized Logging
Configuring ACS Network - Using Cisco Secure ACS as a
Distributed System
Central-log-1 Central-log-2
Accounting
Packets
Backup if
Central-log-1
fails
Backup if
Central-log-1
fails
Enable distributed systems
Enter remote AAA servers
Set up remote logging on
local Cisco Secure ACS
Enable distributed systems
Enter remote AAA servers
Set up remote logging on
local Cisco Secure ACS
Local Cisco
Secure ACS
On Local Cisco Secure ACS
Remote and Centralized Logging
Enabling Distributed Systems allows for the ability to centralize accounting logs generated by
multiple Cisco Secure ACS systems. Each Cisco Secure ACS system can be configured to point
to a Cisco Secure ACS system to be used as the logging server. The Cisco Secure ACS system
acting as a logging server can still perform all Cisco Secure ACS AAA duties.
To utilize Remote Logging, the Cisco Secure ACS system acting as a central logging server must
enter all remote AAA servers that will be sending accounting log information. If the watchdog
packets are also to be logged, select the Log Update/Watchdog Packets from this remote AAA
server check box when configuring the remote AAA server. The logging client Cisco Secure ACS
systems must enter all remote Cisco Secure ACS systems acting as the central logging server or
one of its backups.
To configure Cisco Secure ACS to forward accounting packets to a central server, select System
Configuration from the navigation menu, and then select Logging > Remote Logging. You can
configure this Cisco Secure ACS system to not remotely log, to forward log information to
multiple servers, or to forward to a single server with a list of backups in case of failures. Then
select the appropriate AAA servers from the list of remote AAA servers previously configured.
Click Submit for remote logging to commence.
New Interface
Configuration
Options
(available after configuring
AAA clients to support the
security control protocol)
Display security protocol
configuration attributes in user and
group setup.
Display security protocol
configuration attributes in user and
group setup.
Allow for TACACS+ settings to be
configured per user or group.
Allow for TACACS+ settings to be
configured per user or group.
Before moving on to the next section on configuring authorization, we need to revisit the
Interface Configuration task because new options were added when we associated security
protocols with the added AAA clients. The new options provide the capability to configure which
configuration attributes of the security protocols are displayed in the user and user group setup
screens. Note: Displaying every attribute for every protocol would make the user or group setup
very cumbersome.
Select each protocol and choose which attributes to display. Click Submit for the changes to
take effect. Lets now move on to the next section, which discusses the configuration of
authorization policies.
Configure
Cisco Secure
ACS Users
Configure
Cisco Secure
ACS Users
Cisco Secure
ACS Road Map
Configure Authorization
View
Cisco Secure
ACS Reports
View
Cisco Secure
ACS Reports
Getting
Started
Getting
Started
General
Configuration
General
Configuration
Planning
Planning
Configure
Authorization
Configure
Authorization
Configure
Cisco Secure
ACS Network
Configure
Cisco Secure
ACS Network
Cisco Secure ACS Authorization
Relationships
Shared Profile Components
User Groups
Create Cisco Secure ACS
Administrators for Groups
Configure
Authorization
Configure
Authorization
When the user is authenticated, Cisco Secure ACS can force the user to meet additional
authorization conditions before granting the user access to the network. Cisco Secure ACS
provides a wide variety of authorization conditions that can be configured for either a single user
or for a group of users. Additionally, shared profiles can be configured that allow certain
conditions to be defined once and then associated with many users, thus simplifying
configuration and administration. This section first presents the relationships between the
different components that allow for configuration of authorization conditions, and then
discusses the actual configuration of these components.
Cisco Secure ACS Authorization Relationships
~~~~
~~~~
~~~~
User Group 1
Authorizations
~~~~
~~~~
~~~~
User Group 2
Authorizations
~~~~
~~~~
~~~~
User-Specific
Authorizations
User 1
~~~~
~~~~
~~~~
User-Specific
Authorizations
User 2
~~~~
~~~~
~~~~
User-Specific
Authorizations
User 3
User groups are a collection
of authorization policies.
Users are members of one
user group; they inherit the
authorizations defined for
the group.
User-specific authorizations
over-ride group
authorizations.
User or group
authorizations can include
shared named sets of
authorizations.
User 3 Authorizations
Shared profile 3 authorizations
Group 2 authorizations
User 3 Authorizations
Group 2 authorizations
~~~~
~~~~
~~~~
Shared Profile 1
Authorizations
~~~~
~~~~
~~~~
Shared Profile 2
Authorizations
~~~~
~~~~
~~~~
Shared Profile 3
Authorizations
Cisco Secure ACS Authorization Relationships
The brute force way of implementing AAA services would be to enter and configure authentication
and authorization conditions for each user of the network. This would result in a very time-
consuming, error-prone process, especially given the probability that many of the users
configurations would be identical. To simplify configuration and administration, Cisco Secure
ACS implements many time-saving features and constructs. This tutorial has previously alluded
to the ability to share authentication tasks with an external database, thus taking advantage of
previous investments in time and money. Of course, the authorization conditions for each of
these users, authenticated by either an external or the Cisco Secure ACS database, still needs to
be configured.
To simplify the authorization configuration, Cisco Secure ACS allows for the grouping of users
with common authorization constraints. The administrator now configures a set of authorization
constraints once, and associates all users having the same access constraints to use this set of
authorizations. Further, Cisco Secure ACS allows for the sharing of some types of authorizations
between user groups, thus further simplifying the configuration process. Of course, Cisco Secure
ACS still allows for authorizations to be configured for a specific user. This is helpful if a group of
users all require the same set of authorization constraints except for one user who needs one or
two different constraints. The administrator could define a separate user group for this user, or
simply configure the differences in the users user profile. User-based authorizations take
precedence over group authorizations.
Before discussing the configuration of groups, let's first look at the configuration of the
authorization components that can be shared between users or groups.
Named, Reusable, Shared Sets of Authorization Components
Simplifies authorization configuration
Negates the need to repeatedly enter long lists of devices or commands
Applies to one or more users or user groups
Named, Reusable, Shared Sets of Authorization Components
Simplifies authorization configuration
Negates the need to repeatedly enter long lists of devices or commands
Applies to one or more users or user groups
Enter ACL once, download to any
number of Cisco PIX
firewalls that
authenticate users using the Cisco
IOS /PIX RADIUS protocol
Enter ACL once, download to any
number of Cisco PIX
firewalls that
authenticate users using the Cisco
IOS /PIX RADIUS protocol
List of calling/point of access
locations to be used for permitting or
denying user access based on IP
address, CLI, or DNIS
List of calling/point of access
locations to be used for permitting or
denying user access based on IP
address, CLI, or DNIS
Set of administrative commands to
permit or deny during an administrative
session
Set of administrative commands to
permit or deny during an administrative
session
Shared profile components are configured once and then applied to many users or user groups,
making it unnecessary to repeatedly enter long lists of devices or commands when defining
network access parameters. Without this ability, flexible and comprehensive authorization could
be accomplished only by explicitly configuring the authorization of each user group for each
possible command on each possible device. The Cisco Secure ACS Shared Profile Components
task enables administrators to develop and name these reusable, shared sets of authorization
components that may be applied to one or more users or groups of users during their
configuration.
The configurable shared profile components include:
Downloadable Cisco PIX ACLsCreate ACLs to be downloaded to any number of Cisco PIX
devices when users attempt to authenticate through the firewall.
Network access restrictionsUser access can be permitted or denied based on IP address,
calling-line ID, dialed number identification service (DNIS), or port for a set of AAA clients.
Command authorization setsThis is a list of administrative commands to be permitted or denied
during an administrative session on a device.
To create or edit existing shared profile components, select the Shared Profile Components task
from the Cisco Secure ACS navigation menu, followed by the appropriate Shared Profile
Component. Note that the shared profile components listed are controlled by selections enabled
in the Advanced Options of the Interface Configuration task.
Downloadable Cisco PIX ACLs
Home
Office
Cisco PIX RADIUS
Authentication
Request
Cisco PIX RADIUS
Authentication
Request
Cisco
Secure ACS
Cisco PIX
Firewall
Cisco PIX RADIUS receives
access accept packet
containing named ACL for that user.
ACS:CiscoSecure-Defined-ACL= <acl set name>
Cisco Secure ACS v3.0 allows for the creation of Cisco PIX ACLs of any size to be grouped
together for download to a Cisco PIX Firewall (with Version 6.2 or later) when associated with a
user/group profile of a user attempting to authenticate through a Cisco PIX using the RADIUS
Cisco IOS/PIX protocol. Downloadable Cisco PIX ACLs enable you to enter an ACL when in Cisco
Secure ACS, and then load that ACL to any number of Cisco PIX Firewalls. This is far more
efficient than directly entering the ACL into each Cisco PIX Firewall via its command-line
interface. Below is an outline of how the Cisco PIX Firewall obtains the ACLs from the Cisco
Secure ACS.
When a user accesses the network through a Cisco PIX Firewall, the Cisco PIX Firewall issues a
RADIUS authentication request packet to the AAA server for the requisite user session. If
successfully authenticated, Cisco Secure ACS returns a RADIUS access accept packet containing
the named ACL set for that user. The ACL is packaged within the Cisco VSA AV-Pair: Cisco
Secure ACS:CiscoSecure-Defined-ACL=<acl set name>.
Home
Office
Cisco PIX RADIUS
Authentication
Request
Cisco PIX RADIUS
Authentication
Request
Cisco
Secure ACS
Cisco PIX
Firewall
Downloadable Cisco PIX ACLs - continued
The Cisco PIX Firewallchecks the returned profile and examines the returned ACL set name. If the
Cisco PIX Firewall already has a valid cache entry for the named ACL set, the communication is
complete and the Cisco PIX Firewall applies the ACL it has cached to the user session. If the ACL
set has not previously been downloaded, the Cisco PIX Firewall issues a new RADIUS
authentication request using the ACL set name as the username in the RADIUS request along
with a null password attribute.
Upon receipt of a RADIUS authentication request packet containing a username attribute
containing the name of an ACL set, the Cisco Secure ACS accepts the authentication and
responds with an access accept packet containing the individual ACLs comprising the named
set. Initially the Cisco PIX Firewall will support only a single type of ACL (ip:inacl), although the
Cisco Secure ACS design will not preclude the use of other types/directions at a later date. The
ACLs will be packaged in the standard fashion using Cisco AV-Pair VSAs: Av-pair =
ip:inacl#1 = <acl 1>
Av-pair = ip:inacl#2 = <acl 2>
Home
Office
Cisco PIX RADIUS
Authentication
Request
Cisco PIX RADIUS
Authentication
Request
Cisco
Secure ACS
Cisco PIX
Firewall
For more efficient Cisco PIX processing, Cisco Secure ACS employs a versioning timestamp for
ensuring that the Cisco PIX Firewall has cached the latest ACL version. If a Cisco PIX Firewall
responds that it does not have the current version of the named ACL in its cache (that is, the ACL
is new or has changed), Cisco Secure ACS automatically uploads the ACL update to the Cisco
PIX Firewall cache.
Configure Authorization - Shared Profile Components
Click to edit or delete.
Use standard Cisco PIX
ACL syntax and

semantics, except do not
use keyword and named
entry.
Use standard Cisco PIX
ACL syntax and

semantics, except do not
use keyword and named
entry.
Name can include spaces.
Name can include spaces.
ACL validity is the
responsibility of the
administrator.
ACL validity is the
responsibility of the
administrator.
Configuring Downloadable Cisco PIX ACLs
Create a Downloadable Cisco PIX ACL by clicking the Add button in the Downloadable Cisco PIX
ACLs table. Provide a name, which will be used to reference the set from the user or group setup
screens, a description to facilitate management, and the list of Cisco PIX ACL definitions to
download. Enter each Cisco PIX ACL command on a separate line using standard Cisco PIX ACL
syntax and semantics, except do not use keyword and named entries. Click the Submit button
and the Downloadable Cisco PIX ACL set is immediately available for use.
To edit or delete any existing downloadable Cisco PIX ACL, simply click on the Downloadable
Cisco PIX ACL name in the Downloadable Cisco PIX ACLs table.
Network Access Restrictions
Add single AAA clients or NDGs to
permit or deny for listed ports/IP
address (wildcards OK).
permit or deny for listed ports/IP
address (wildcards OK).
Enable
Enable
Permit/Deny
Permit/Deny
Enable
Enable
Permit/Deny
Permit/Deny
permit or deny for listed ports/CLI/
DNIS (wildcards OK).
permit or deny for listed ports/CLI/
DNIS (wildcards OK).
Network Access Restrictions (NARs) are a convenient way to create additional access conditions
at calling/ point of access locations based on user IP addresses, caller-line ID (CLI) number,
display number identification service (DNIS) number, or port number. Cisco Secure ACS uses
two similar mechanisms to configure these conditions: IP based to handle access based on IP
addresses, and non-IP based to filter on other conditions. NARs can be configured to permit or
deny access based on the information entered, and they allow the use of wildcards when defining
the filters.
Create a NAR by selecting Add from the Network Access Restrictions table. Provide a name,
which will be used to reference the set from the user or group setup screens, and a description to
facilitate management. To use either form of filter, select the appropriate check box to enable it.
Next decide if the list will be for permit or deny purposes. Select the device or NDG (if used) and
the values (wildcards are allowed) to permit or deny at this location(s). Click Enter to add to the
active filter list. More than one set of location/value pairs can be entered. Click the Submit button
and the NAR is immediately available for use.
To edit or delete any existing NAR, simply click on the NAR name in the Network Access
Restrictions table.
Note: If using non-IP based filters, other values besides CLI can be entered into the CLI field for
use in filtering (that is, Media Access Control [MAC] address). The only requirement for what you
use is that the format must match the format of what is being received from the AAA client. This
value can be determined by reviewing the RADIUS Accounting log.
Command Authorization Sets
Add matched command.
Add matched command.
Choose what to do we unmatched commands.
Choose what to do we unmatched commands.
Matched Arguments
Matched Arguments
Allows all show
commands to be
executed, but not other
commands.
Allows all show
commands to be
executed, but not other
commands.
Command Authorization Sets
Command Authorization Sets are used to control the authorization of each command entered on a
device, thus greatly enhancing the accountability of network administrators, providing greater but
controlled accessibility, and limiting misuse. Properly defined command sets allow different users to
be given different levels of privilege on different devices. For instance, a command authorization set
can be created to allow just for show commands, while another could allow all commands except for
configure. These command sets could then be associated with a user or group of users and a set of
AAA clients resulting in a possible authorization that allows a user just show command
authorization for one set of devices, and all except configure command authorization for another set
of devices.
When Command Authorization is enabled on a device, the command is forwarded to Cisco Secure
ACS, via TACACS+, to see if the user is authorized to run the command. The command is matched
against commands in any associated command authorization set. If a matched command is found,
the next step is to authorize any arguments. Unmatched commands or arguments can be permitted or
denied, providing greater flexibility and ease of configuring. Carefully selecting the permit or deny
condition for unmatched commands and arguments will dictate the precise behavior of the command
authorization set. For example:
Example 1 Example2
Matched command show show
Unmatched commands deny permit
Arguments none none
Permit unmatched args yes no
The two examples have similar configurations, but their meanings are very different. Example 1 allows all types
of show commands to be executed, but no others, whereas Example 2 allows all commands except show
commands to be executed.
Command Authorization Sets (continued)
Dollar Sign ($) - Argument must end with what has gone before $
Caret (^) - Argument must begin with what follows ^
Dollar Sign ($) - Argument must end with what has gone before $
Caret (^) - Argument must begin with what follows ^
Expression Matches Doesnt Match
Permit foo foo
anyfoo
foobar
Permit foo$ foo foobar
anyfoo
Permit ^foo foo anyfoo
foobar
Permit ^foo$ foo anyfoo
foobar
Expression Matches Doesnt match
Command Authorization Sets - continued
Create a Command Authorization set by selecting Add from the Command Authorization Sets
table. Provide a name, which will be used to reference the set from the user or group setup
screens, and a description to facilitate management. Select the appropriate combination of
commands and arguments, and permit or deny unmatched conditions to achieve the desired
command authorization control.
For permit/deny command arguments, Cisco Secure ACS uses pattern matching. That is, the
argument permit foo matches any argument that contains the string foo. Thus, for example,
permit foo would allow not only the argument foo, but also the arguments anyfoo and foobar.
To limit the extent of pattern matching, you can add the following expressions:
dollar sign ($)Expresses that the argument must end with what has gone before; thus permit
foo$ would match against foo or anyfoo, but not foobar
caret (^)Expresses that the argument must begin with what follows; thus permit ^foo would
match against foo or foobar, but not against anyfoo
You can combine these expressions to specify absolute matching. In the example given, you
would use permit ^foo$ to ensure that only foo was permitted, and not anyfoo or foobar.
Click the Submit button, and the Command Authorization set is immediately available for use. To
edit or delete any existing command authorization sets, simply click on the command
authorization set name in the Command Authorization Sets table.
User Groups
Collection of Users with Common Authorization (Access) Policies
Simplifies administration
Can create up to 500 groups to affect different levels of authorization
Group 0 is the default group (used for authenticated users with no group association)
Configurable settings determined by enabled options in the Interface
Configurations task and the system configuration of Cisco Secure ACS
Collection of Users with Common Authorization (Access) Policies
Simplifies administration
Can create up to 500 groups to affect different levels of authorization
Group 0 is the default group (used for authenticated users with no group association)
Configurable settings determined by enabled options in the Interface
Configurations task and the system configuration of Cisco Secure ACS
Common Settings
VoIP Support (Null Password)
Time-of-Day Access
Callback Options
Max Sessions
Usage Quotas
Configuration Specific Settings
Token Card
TACACS+ Enable Privilege
Password Aging (ACS/Windows DBs)
IP Assignment Method
Downloadable PIX ACLs
Shell Command Authorization Sets
PIX Command Authorization Sets
Specific Security Protocol Settings
User Groups
A user group is a collection of users with common authorization constraints. In Cisco Secure
ACS, the administrator configures the set of authorizations on a group, and then assigns users to
the group. The assigned users thus inherit the authorizations configured for the group. Any
authorization configured in the users profile (discussed in the next section) take precedence
over the same type of authorization defined for the group. Cisco Secure ACS supports the use of
500 groups, with Group 0 being the default group for any authenticated user without an explicit
group association.
What authorization settings are available to configure in a group largely depends on selections
made in the Interface Configuration task and the configuration of the Cisco Secure ACS system.
For instance, if a token server is not defined (External User Databases task), then no
configuration will appear to configure that aspect. The settings for group authorizations can be
divided into two categories:
Common settingThe settings not dependent on system components (may still require enabling
Interface Configuration options)
Configuration-specific settingsThe settings that are based on the actual system makeup of Cisco
Secure ACS (requires the presence of certain components and may still require enabling Interface
Configuration options)
The large number of possible settings can make the configuring of user groups a daunting task.
Proper planning, including a well-thought-out access policy plan, can greatly reduce this
complexity. Use the Interface Configuration task to enable only those options required by your
access policy plan, thus simplifying the group setup screen.
List Group
Membership
(In right display area)
List Group
Membership
(In right display area)
Group Management
Configure Authorization - User Groups
Configure
Group Settings
Configure
Group Settings
Simplify
Administration
Simplify
Administration
Group Management
Cisco Secure ACS already has place holders for 500 groups named Group 0 (default group) to
Group 499. To simplify their use, the groups can be readily renamed. Select the Group Setup task
from the navigation bar. The Group Management box is displayed. Use the pull-down menu to
find the desired group to rename, and click Rename Group. Simply type in the new name and
click Submit. The Group Management box can also be used to list the members in the group.
Clicking the Users in Group button will display all associated users in the right display area of
Cisco Secure ACS. The next section of this chapter discusses the association of users to
groups.
Configure Group Settings
restarted for changes to take
effect.
restarted for changes to take
effect.
Lots of Settings
(based on selections in
interface configuration
and the system
configuration)
Lots of Settings
(based on selections in
interface configuration
and the system
configuration)
Configure Group Settings
To edit the authorization settings for a group, select the appropriate group from the pull-down
menu in the Group Management box and click Edit Settings. The Group Setting dialog box is
displayed. As is evident by the scroll bar in the Group Setting screen, there are many possible
authorizations to set, as listed previously. Use the Jump To pull-down menu to quickly locate a
particular section to configure. The setting of options on this screen is simple and essentially
self-explanatory. Therefore, the tutorial doesnt address every possible setting on this screen.
For more detailed information on each setting, refer to either the Cisco Secure ACS User Guide or
the online content-sensitive help displayed in the right display area of the Cisco Secure ACS
desktop. To complete the discussion on the tasks presented earlier in this section, the next page
discusses how to select the different shared profile components to associate with a user groups
authorization policy.
When the group is configured, select Submit + Restart to have the changes take place
immediately. Remember, restarting Cisco Secure ACS clears the Logged-in User report (does not
end user sessions, however) and temporarily interrupts all Cisco Secure ACS services including
resetting the Max Sessions counter to zero. To save your changes and apply them later, click
Submit. When you are ready to implement the changes, select System Configuration > Service
Control > Restart.
Note: The usage counters for all users in a group can be reset by selecting the On submit reset all
usage counters for all users of this group check box, and then clicking Submit.
Using Shared Profiles in Group Settings
Enable use.
Enable use.
Enable use.
Enable use.
Select set.
Select set.
AND/
OR
AND/
OR
Device(s)
Command Set for them
Device(s)
Command Set for them
Using Shared Profiles in Group Settings
The selection of shared profile components for a user group is straightforward. For
downloadable Cisco PIX
ACLs, simply enable their use and pick the appropriate set of
downloadable ACLs to use for this user group. If a Cisco PIX Firewall is making an
authentication request for a user, the set of ACLs associated with the user group of the user
being authenticated will be downloaded to the Cisco PIX Firewall.
In the case of NARs, you can select as many sets of NARs as you want and decide on the
Boolean logic to use; it must match all selected NARs to result in an access permit (AND), or it
must match at least one selected NAR to result in an access permit (OR).
Finally, the command authorization sets provide the most flexibility, because you can use
different command sets for different sets of devices, or one command set for all devices.
These become active when selecting Submit + Restart for the associated group they were
configured in.
Note: User group settings also allow for the setting of NARs and command authorizations sets
independent of the shared profile components. Of course, if you wish to use these same settings
for another user group, you will need to reenter them for that other group.
Create Cisco Secure ACS Administrators for Groups
More Privileges
(see next page)
More Privileges
(see next page)
Select groups and edit
features this administrator
will be responsible for.
Select groups and edit
features this administrator
will be responsible for.
Create Cisco Secure ACS Administrators for Groups
Earlier in this chapter, we discussed how to create a Cisco Secure ACS administrator who had
privileges to perform any Cisco Secure ACS function or task. Lets revisit the addition of a Cisco
Secure ACS administrator, but this time discuss limiting the administrators privileges. Like
before, to create a new administrator, click the Administration Control task from the navigation
menu to display the list of administrators currently defined. From this table select Add
Administrator to create a new administrator or click the name of an existing administrator to edit
the administrators profile. Enter a name and password to use for authentication. Remember that
all remote access to Cisco Secure ACS must be authenticated, and the administrator session
policy determines if local access must also be authenticated.
Previously when creating the superuser account, the Grant All button was selected in the
Administrator Privileges section, granting all administrative privileges. This time, administrators
can be created with limited privileges. The first section of Administrator Privileges allows the
administrator to have Add/Edit/Setup rights for only a select number of groups localizing
authority and accountability.
The next page shows the other privileges that can be granted per administrator.
Create Cisco Secure ACS Administrators for Groups (continued)
Set which functions
within Cisco Secure ACS
this administrator is
authorized to configure.
Set which functions
within Cisco Secure ACS
this administrator is
authorized to configure.
Submit to add administrator
and their privileges.
Submit to add administrator
and their privileges.
Create Cisco Secure ACS Administrators for Groups - continued
For any given, Cisco Secure ACS administrator, the items displayed in the Cisco Secure ACS
interface may be limited by what the administrator has been given privileges to configure. Thus,
not only will the options selected in the Interface Configuration task limit what is displayed for all
administrators, but the display may be further limited based on granted privileges on a per Cisco
Secure ACS administrator basis. As shown in the figure above, privileges to all functional areas
of Cisco Secure ACS can be granted, some with a finer level of granularity than others.
When the administrators privileges are configured, select Submit for the settings to take effect.
The configuration process of Cisco Secure ACS is almost complete. The chapter has so far
looked at general configurations (including accounting - logging), adding AAA clients, and
configuring authorizations. The final piece is the configuration of the actual users who need to
be authenticated and authorized prior to receiving access to the network.
View
Cisco Secure
ACS Reports
View
Cisco Secure
ACS Reports
Configure
Cisco Secure
ACS Network
Configure
Cisco Secure
ACS Network
Configure
Cisco Secure
ACS Users
Configure
Cisco Secure
ACS Users
Getting
Started
Getting
Started
General
Configuration
General
Configuration
Planning
Planning
Cisco Secure
ACS Roadmap
Configure Cisco Secure ACS Users
Configure
Authorization
Configure
Authorization
ACS Database and Authorization
User Profiles
Handling Unknown Users
Configure Users
Configure Cisco
Secure ACS Users
Configure Cisco
Secure ACS Users
Configure Users
Cisco Secure ACS provides the flexibility to authenticate users against either the internal Cisco
Secure ACS database or one of several possible external databases. No matter which database is
used to authenticate a user, authorization is always performed using information configured in
the Cisco Secure ACS database. Therefore, all users must have either an explicit account within
the Cisco Secure ACS user database or a mechanism to associate them with an authorization
policy (user group). This section looks at the different methods to create users in the Cisco
Secure ACS database, and the methods to associate authorization policies with unknown users
(users without Cisco Secure ACS user records).
Cisco Secure ACS Database and Authorization
Configure Users
UID: Billy
PWD: letmein
NT
UID: Rick
PWD: hereiam
ODBC
Cisco Secure ACS
interface
Unknown user policy
RDBMS synchronization
CSUtil.exe (Database Import
utility)
~~~~
~~~~
~~~~
Group 1
Authorizations
~~~~
~~~~
~~~~
Group 2
Authorizations
~~~~
~~~~
~~~~
User specific
Authorizations
User: Sally
PWD: imlocal
~~~~
~~~~
~~~~
User specific
Authorizations
User: Billy
Authentication: NT
Check: NT
ODBC
Unknown User
Policy
Database Group
Mappings
NT: Group 1
ODBC: Group 2
Cisco Secure
ACS Database
Authorization is
always handled
by the Cisco
Secure ACS
database,
regardless of
where
authenticated.
Authorization
How Users Can Be Added
The Cisco Secure ACS database is crucial for the authorization process. Regardless of whether a
user is authenticated by the internal user database or by an external user database, Cisco Secure
ACS authorizes network services for users based upon group membership and specific user
settings configured in the Cisco Secure ACS database. Thus, all users authenticated by Cisco
Secure ACS, even those whose authentication is performed with an external user database, must
have a means to be associated with a user group in the Cisco Secure ACS database.
There are five ways to add user profiles to the Cisco Secure ACS database:
Cisco Secure ACS interfaceThe Cisco Secure ACS administrator enters the user profile,
including: the database (internal or external) to use for authentication, the user group the user will be
a member of, and any user-specific authorizations.
Unknown user policy and database group mappingA user who is attempting to be authenticated
but is not found in the Cisco Secure ACS user database can be sent to external databases for
authentication. The Cisco Secure ACS administrator creates the unknown user policy, detailing the
order of external databases to search. The Cisco Secure ACS administrator can also map
unknown users in the various databases to a user group. If an unknown user is authenticated by
one of the external databases, a new user profile is created based on the external database
authenticating the user and the user group membership dictated by the database group mapping
policy.
Configure Users
UID: Billy
PWD: letmein
NT
UID: Rick
PWD: hereiam
ODBC
Cisco Secure ACS
interface
Unknown user policy
RDBMS synchronization
CSUtil.exe (Database Import
utility)
~~~~
~~~~
~~~~
Group 1
Authorizations
~~~~
~~~~
~~~~
Group 2
Authorizations
~~~~
~~~~
~~~~
User specific
Authorizations
User: Sally
PWD: imlocal
~~~~
~~~~
~~~~
User specific
Authorizations
User: Billy
Authentication: NT
Check: NT
ODBC
Unknown User
Policy
Database Group
Mappings
NT: Group 1
ODBC: Group 2
Cisco Secure
ACS Database
Authorization is
always handled
by the Cisco
Secure ACS
database,
regardless of
where
authenticated.
Authorization
How Users Can Be Added
Database replicationCisco Secure ACS allows for the replication of the database with other
Cisco Secure ACS systems. This feature allows one Cisco Secure ACS system to mirror its
database with another Cisco Secure ACS system for backup.
RDBMS synchronizationCisco Secure ACS allows for the synchronization of the database with
other ODBC databases.
CSUtil.exeThis is a command line utility to import users via a file. See Appendix E of the Cisco
Secure ACS User Guide for more information on command-line utilities.
The remainder of this section discusses how to configure users via the Cisco Secure ACS
interface, create an unknown user policy, and map unknown users to a user group.
User Profiles
Configure Users
Basic User Information
Supplementary User Information
Where to Authenticate
Group Assignment
Callback
IP Address Assignment
Max Sessions for User
User Usage Quotas
Advanced User Settings
Shared NARs
Per-User NARs
Downloadable Cisco PIX
ACLs
Shared Command Authorization Sets
Per-User Command Authorization
Security Protocol Settings
Account Management Settings
Account Disable
Current User Usage
The configurable user settings are
determined by enabled options in the
Interface Configurations task and the
configuration of the Cisco Secure
ACS system.
The configurable user settings are
determined by enabled options in the
Interface Configurations task and the
configuration of the Cisco Secure
ACS system.
User Profiles
A user profile is an entry in the Cisco Secure ACS database that contains the method to
authenticate the user and a set of authorizations for the user to further define access rights. Like
the settings available for configuration in the user group setup, the settings available for
configuration in a users profile vary, depending on enabled options in the Interface
Configuration task and configured Cisco Secure ACS system components (that is, external
databases and security protocols used).
Many of the available settings in the users profile are identical to the settings in the user group
setup except they are applied only to this user and not a group of users. The settings in the
users profile can be arranged into three categories:
Basic user informationThese settings include who the user is, what database to authenticate against or
passwords used for authentication, which user group this user is assigned to, how to supply an IP address,
maximum session settings for the user, usage quotas for the user, and some callback controls. Many of
these settings have an option to use the settings configured for the group instead. Remember, if the same
type of setting is configured in both the user profile and the user group, the settings in the user profile take
precedence.
Advance user settingsThese authorization settings are similar to the ones in the group settings for NARs,
downloadable Cisco PIX ACLs, command authorizations, and security protocols. Again, if the same type of
setting is configured in both the user profile and the user group, the settings in the user profile take
precedence.
Account management settingsThese setting allow you to disable the account or set up a policy (date or
number of failed attempts) as to when to disable the account. Also, if usage quotas by user are enabled, the
user profile contains a table displaying the current usage.
This section discusses some of the above settings. Generally, all the settings and their
configuration are self-explanatory. For more information on any of the settings, consult either
the Cisco Secure ACS User Guide or the content-sensitive help provided in the right display area
of the Cisco Secure ACS desktop.
Adding Users via the Cisco Secure ACS Interface
Configure Users - User Profiles
Edit or delete user.
Edit or delete user.
Enter new user ID, existing
user ID, or user ID (wildcard
OK for find).
Enter new user ID, existing
user ID, or user ID (wildcard
OK for find).
Adding Users via the Cisco Secure ACS Interface
The configuration of users is the functional configuration area within Cisco Secure ACS that will
probably be the most visited. As previously stated, all users, regardless of their authentication
method, must have an entry in the Cisco Secure ACS user database to associate them with a user
group. Using the Cisco Secure ACS interface, the Cisco Secure ACS administrator can add users
no matter what their authentication method is. This provides the ultimate control in setting
authorizations for each user (associate with a user group or per-user authorizations). Later in
this section, we discuss how all users in external databases can easily be added to the Cisco
Secure ACS database as members of the same user group.
To create a new user, click the User Setup task from the navigation menu, enter a user ID for the
new user in the User field of the User Setup dialog box, and click Add/Edit. A users profile can
be edited at any time by entering the users name in this same field and also clicking the Add/Edit
button. Because there will probably be a large number of users, this screen also allows you to
find users (use wildcards) or list users by the first letter/digit of their account name. Results of
the list or find operations are displayed in the right display area of the Cisco Secure ACS
desktop. Click on the desired user from this list to begin editing the user profile.
Basic User Settings
Configure User - User Profiles
Select database to
use for
authentication.
Select database to
use for
authentication.
Assign user to
group.
Assign user to
group.
Enter password
information for ACS
database.
Enter password
information for ACS
database.
Fields Enabled from Interface
Configuration Task
Fields Enabled from Interface
Configuration Task
Password authentication
method is required!
(figure does not display all possible
fields to configure)
Password authentication
method is required!
(figure does not display all possible
fields to configure)
Basic User Settings
The figure above shows just a few of the possible basic user settings. The top of the User Profile
screen indicates the user ID being created (ID followed by the words (New User)) or edited. The
User Data Configuration option in the Interface Configuration task allows you to include up to five
additional fields of information to associate with the user. Values for these fields can be entered
in the Supplementary User Info configuration box.
The most important configuration for the user is the authentication database and user group
association. The Cisco Secure ACS Administrator can associate this user with any configured
database. Only the configured databases will be available for selection from the pull-down list. If
you select the internal Cisco Secure ACS database, you have two options for specifying a
password:
Use a single passwordused for PAP, CHAP, MS-CHAP, and ARAP
Use separate passwordsone for PAP and the second for CHAP/MS-CHAP/ARAP
Note: When a token card server is used for authentication, a separate CHAP/MS-CHAP password
can be supplied for a token card user to permit CHAP/MS-CHAP authentication. This is especially
useful when token caching is enabled.
To make this user a member of a user group, simply select the desired group from the pull-down
list. Note: Cisco Secure ACS administrators that were given only privileges to configure a subset
of all the groups will only see the groups that they can administer.
At this point you can click Submit and the user can now be authenticated and authorized (via
associated user group settings) for network access via Cisco Secure ACS. The user profile also
allows for the configuration of additional user-specific authorizations. These authorizations will
take precedence over the authorizations defined in the user group associated with the selected
user.
Configure User - User Profiles
Existing User
Existing User
View Usage for User
View Usage for User
Administratively Disable Account
Administratively Disable Account
Disable Account Policy
Disable Account Policy
Cisco Secure ACS provides the capability to perform simply account management tasks. Any
user account can be disabled at any time to prevent any further access by simply clicking the
Account Disabled check box at the top of the users profile. Accounts can also be disabled
based on a date or a number of failed login attempts. These values can be configured in the
Account Disable settings configurations box.
Finally, if the Usage Quotas option was enabled in the Advanced Options of the Interface
Configuration task, the current usage values for a user can be viewed in a table located in the
Usage Quotas settings configuration box. These values can be reset by checking the On submit
reset all usage counters check box and clicking Submit.
Unknown User Policy
Authentication: NT,ODBC
Database Group Mapping
NT: New York Admins
ODBC: Consultants
Cisco Secure ACS DB
New York Admins
Access Policies
Consultants
Access Policies
Configure Users
UID: Rick
PWD: hereiam
UID: Rick
PWD: hereiam
ODBC
Authentication
Authorization
User: Rick
Authentication: ODBC
Group: Consultants
NT
Look in First
Look in Second
Create new Cisco
Secure ACS DB
entry for faster
processing the
next time.
OK
No user profile for user
Rick is found in Cisco
Secure ACS database.
No user profile for user
Rick is found in Cisco
Secure ACS database.
Entering all users represented in an external database into the Cisco Secure ACS database can
be a very time-consuming process. Cisco Secure ACS has a mechanism to automate the addition
of these users. A figure similar to the one above was seen earlier in this chapter and is repeated
here to explain the automatic user profile addition to the Cisco Secure ACS database for users
authenticated by external databases with no user profile in the Cisco Secure ACS database.
Because initially there is no entry in the Cisco Secure ACS database for these external database
users, they are considered unknown to Cisco Secure ACSsimply meaning they have no user
profile. To first authenticate these unknown users (no user profile means Cisco Secure ACS
doesnt know which external database the user is in), the Cisco Secure ACS administrator creates
the Unknown Users Policy. This policy simply lists the external databases in the order they
should be searched for any unknown users. The Cisco Secure ACS Administrator also creates a
Database to Group Mapping policy, which states which User Group to associate with Unknown
Users from a given external database.
When an unknown user attempts to authenticate with Cisco Secure ACS, Cisco Secure ACS
searches its database for the users profile. When no user profile is found matching this user ID,
Cisco Secure ACS then sends the login information to the external databases for authentication
in the order listed in the Unknown User Policy. When an external database authenticates this
login, the OK is sent back to Cisco Secure ACS. Cisco Secure ACS looks up the database it
received this OK from in the Database Group Mapping table to determine which user group to
associate with this unknown user.
Cisco Secure ACS now has all the basic information needed to create a user profile for this
previously unknown user. The new profile is added to Cisco Secure ACS, where it can now be
viewed using the User Setup edit feature and used for authentication when the previously
unknown users attempt to log in again.
Lets look at how to set up this time-saving feature.
Unknown User Profile
Configure Users - Handling Unknown Users
Choose the order
of the external user
databases defined
to be searched for
the unknown user.
Choose the order
of the external user
databases defined
to be searched for
the unknown user.
Submit to have the Unknown User
Policy immediately put into use.
Submit to have the Unknown User
Policy immediately put into use.
Unknown User Profile
Because unknown users are users authenticated in external databases without Cisco Secure ACS
user profiles, it makes sense that to configure the Unknown User Profile using the navigation
menu item, External User Databases. Two Unknown User Policies can be configured. The first
says that if the user is unknown to Cisco Secure ACS, fail the attempt. The second provides a
search order of external user databases to ask to authenticate the unknown user. To configure
this list, simply select the external databases to search from the provided list (currently
configured external user databases) and click the -> button to add them to the search list. The
search list can be reordered by selecting an external database in the search list and clicking the
Up or Down button to place it in the proper order. When the search order is set, click the Submit
button to make the Unknown User Policy become immediately effective.
Database Group Mappings
Configure Users - Handling Unknown Users
Select group to be
associated with
any unknown user
from a particular
external database.
Select group to be
associated with
any unknown user
from a particular
external database.
Submit to have the unknown user group
mappings immediately put into use.
Submit to have the unknown user group
mappings immediately put into use.
The database group mappings are also configured from the External User Databases task. When
selecting the Database Group Mappings option, you are presented with a list of all configured
external databases. Select the external database from the list and associate it with the user
group. From the pull-down list of user groups, select the user group to associate with this
database. Click Submit to make the Database Group Mappings become immediately effective.
Note: Windows databases allow you to associate a user group with a domain of users.
At this point Cisco Secure ACS is all configured and ready for use. Of course, there will be times
when various configurations will need to be revisited to fine-tune the Cisco Secure ACS
deployment or to add additional features, groups, or users. To finish this chapter, let's look at
how to view the various reports provided by Cisco Secure ACS.
View
Cisco Secure
ACS Reports
View
Cisco Secure
ACS Reports
Configure
Authorization
Configure
Authorization
Getting
Started
Getting
Started
Configure
Cisco Secure
ACS Users
Configure
Cisco Secure
ACS Users
Configure
Cisco Secure
ACS Network
Configure
Cisco Secure
ACS Network
General
Configuration
General
Configuration
Planning
Planning
Cisco Secure
ACS Roadmap
View Cisco Secure ACS Reports
Reports and Activities
Sample Reports
View Cisco Secure
ACS Reports
View Cisco Secure
ACS Reports
The Cisco Secure ACS Administrator can review the various log file reports generated by Cisco
Secure ACS to determine system/user/administrator activity and accounting information sent by
AAA clients. The configuration of the log files was discussed in the General Configuration
section of this chapter.
Reports listed depend on security
protocols in use and configured logging.
Reports listed depend on security
protocols in use and configured logging.
Current Log
Current Log
When Cisco Secure ACS is configured according to the deployment plan, day-to-day use is
typically limited to the review of activity and accounting logs and the occasional change or
addition to the existing Cisco Secure ACS configuration. The logs should be periodically
reviewed to determine proper system behavior and to detect any possible misconfigurations.
To view any of the enabled reports generated by Cisco Secure ACS, select the Reports and
Activity task from the navigation menu. A list of all available report categories is displayed.
Select the desired report type, and the right display area of the Cisco Secure ACS desktop
displays the actual report or reports of this type available for viewing. The top report listed is the
current log being used by Cisco Secure ACS. The remaining logs are listed in chronological
order from most recent to oldest stored. To view any report, simply click on it.
Sample Reports
Reports are displayed in the
right display area of the
Cisco Secure ACS desktop.
Reports are displayed in the
right display area of the
Sample Reports
The figure above displays samples of three different reports. Note that there may be many more
fields to display for these reports if so configured (see General Configuration section of this
chapter for details on configuring logs). The data in the reports can be sorted by the data in a
column by clicking the column header. The reports are displayed in the right display area of the
Review of Cisco Secure ACS Key
Points
Centralized Authentication, Authorization, and Accounting
(AAA) Services
Can Utilize Either Local or External Databases for Authentication
Flexible Configuration of Access Authorizations
Easy-to-Use HTML Interface
Protocol Flexibility (RADIUS/TACACS+, many password protocols)
Configurable Administrator Configuration Privileges
Highly Scalable
Review of Cisco Secure ACS Key Points
Cisco Secure ACS is a powerful access control server that allows for the centralization of AAA
services. Cisco Secure ACS can provide AAA services via either the RADUIS or TACACS+
security protocols and offers support for a large number of password authentication protocols.
Cisco Secure ACS is easy to use, utilizing an HTML interface that is configurable to display only
the items of Cisco Secure ACS being deployed, and can be accessed remotely. Administrator
configuration privileges can be limited to provide a more secure environment. Log files track
every action and activity of Cisco Secure ACS for reporting, troubleshooting, and accountability
purposes. Cisco Secure ACS can scale to fit most any size network, with support for redundant
servers and external user databases. Finally, Cisco Secure ACS provides flexible time-saving
authorization configuration mechanisms that allow for fine-granularity access policies that can be
applied to single users or groups of users.
Congratulations!
We hope that this chapter has helped you to understand what Cisco Secure ACS can do for you.
Continue on with Chapter 3 to experience a sample deployment of Cisco Secure ACS.
Cisco Systems
Chapter 3
Deployment Scenario
Chapter 3 Topics
Cisco Secure ACS Deployment Scenario
The Customers Network
Planning the Cisco Secure ACS Deployment
Getting Started
Configure Users
Using Cisco Secure ACS
Chapter 2 provided information on the features and capabilities of Cisco Secure ACS for
centralizing command and control for all user authentication, authorization, and accounting
(AAA) from a Web-based, graphical interface. Please review Chapter 2 if you havent done so
already. This chapter reviews several of these key features of Cisco Secure ACS by illustrating a
simple Cisco Secure ACS deployment scenario. This scenario will help you to understand how to
provide AAA services using Cisco Secure ACS, as well as help you to understand how to
administer the Cisco Secure ACS application.
By going through this sample deployment, you will view specific examples on how to configure
and administer the Cisco Secure ACS application. This scenario does not illustrate how to
configure the end users workstation or the commands to enable on the AAA client.
Now, lets describe the customers network to be used in this scenario.
Creative Engineering Corporation
Cisco VPN 3000
PSTN
Cisco AS5300
Access Server
Mobile
Worker
Dial-Up
Public
Internet
Remote
Office
Home
Office
DSL
VPN
Cisco
Aironet
Switch
ACS-1 Primary
ACS-2 Backup
Corporate
Network
Creative Engineering - Deploying Cisco Secure Cisco Secure ACS
Today, many corporations are making network management and security enhancements by
centralizing user access control . In doing so, corporations can minimize administrative costs,
optimize security, manage the access of networked resources, and lower operational costs.
Tom Smith of Creative Engineering has made that transition for his company by recently
deploying several Cisco Secure Access Control Servers (ACSs) to control network and device
access for local administrator, dial-up, wireless, and virtual private network (VPN) users. In the
deployment of Cisco Secure ACS, Tom has made the following considerations:
Creative Engineering has a large number of remote users (dialup, VPN, and wireless). Dial-up users access
the network through a network access server (NAS), the Cisco AS5300. The wireless users access the
network using a wireless access point (AP), such as the Cisco Aironet
Series.
With Cisco Secure ACS v3.0, the network administrators can quickly manage wireless user accounts and
globally administer and distribute wireless encryption keys using Remote Access Dial In-User Service
(RADIUS). This improves their ability to scale and deploy secure wireless services, and saves time by
centralizing that control, access management, accounting, and wireless key distribution within the Cisco
Secure ACS framework.
Note: In Cisco Secure ACS v3.0, all RADIUS attributes are shared by all RADIUS devices for a given group
or users. One of these attributes is session timeout. Session timeouts are generally long periods of time on
the "normal" network access device. VPN concentrators, dial-in servers and so on can share a common
timeout period without serious impact. However, with the dynamic Wired Equivalent Privacy (WEP) rekeying
feature of the Cisco Aironet Series, this poses a different problem. A shorter period of 10 to 30 minutes is
recommended for security reasons. Therefore, if the same Cisco Secure ACS system is used to manage the
wired and wireless community, an access point will use the same session timeout value as a Cisco VPN
3000 Concentrator, resulting in VPN users being logged off at the same rate as wireless users. This is
known as the "attribute 27" problem. In an upcoming release, Cisco Secure ACS will separate the session
timeout attribute for RADIUS.
And finally, Tom has considered deploying multiple Cisco Secure ACS platforms to ensure that network
access will not be comprised if access to the primary Cisco Secure ACS is lost.
Cisco VPN 3000
PSTN
Cisco AS5300
Access Server
Mobile
Worker
Dial-Up
Public
Internet
Remote
Office
Home
Office
DSL
VPN
Cisco
Aironet
Switch
ACS-1 Primary
ACS-2 Backup
Corporate
Network
Creative Engineering Corporation
This scenario highlights how Tom has planned for deploying Cisco Secure ACS and its actual
configuration. For more information on deploying Cisco Secure ACS in various network
environment, refer to the reference section in Chapter 5 for a list of available white papers.
Planning the Cisco Secure ACS Deployment
Cisco Secure ACS System Maintenance Policy
Two identical systems (primary/backup)
Authentication via Cisco Secure ACS
database or external Windows NT
Daily backups and replication
All logs and backup files kept for 7 days
Cisco Secure ACS System Maintenance Policy
Two identical systems (primary/backup)
Authentication via Cisco Secure ACS
database or external Windows NT
Daily backups and replication
All logs and backup files kept for 7 days
Cisco Secure ACS
Administration Policy
One super user
Access from anywhere
(must be authenticated)
CSV logging
Cisco Secure ACS
Administration Policy
One super user
Access from anywhere
(must be authenticated)
CSV logging
User types Network access policy Device admin policy
Network admin Unrestricted
Authentication: Windows NT
Unrestricted
Help desk No external access Show commands only
(all devices)
General users Unrestricted
Authentication: Windows NT
No access
Consultants Dial-in access only
Restrict time
Usage quotas
Account disable (date)
Authentication: Cisco Secure ACS
Show commands only
(all devices except access devices)
The First Step - Planning the Cisco Secure ACS Deployment
As with most projects, if the planning is carefully considered, the implementation is
straightforward. This is true with deploying AAA services using Cisco Secure ACS. Tom has
determined how to maintain the Cisco Secure ACS platform, has determined who can manage the
access policies, and has organized the network users into categories based on their network
access policy and device administration policy. This chapter illustrates how to deploy this plan
using Cisco Secure ACS.
Getting Started
Accessing the Cisco Secure ACS
Application
Creating the Cisco Secure ACS Super User
Defining the Administration Policy
Accessing the Cisco Secure ACS Application
Getting Started
aaaaaaaaa
aaaaaaaaa
Starting on port 2002,
Cisco Secure ACS
administrative session.
Starting on port 2002,
Cisco Secure ACS
administrative session.
Getting Started Accessing the Cisco Secure ACS Application
To initially administer the Cisco Secure ACS application, you must use a supported Web browser
with Java and JavaScript enabled and be physically at the Cisco Secure ACS platform.
(Thereafter, you can configure the Cisco Secure ACS application to allow remote access by
defining the Administration Control Access Policy, as discussed in Chapter 2.)
Follow the steps below to access the Cisco Secure ACS application.
Step 1: From the Cisco Secure ACS platform, launch a supported Web browser. Ensure that Java
and JavaScript are enabled.
Step 2: In the URL field, enter the IP address of the Cisco Secure ACS platform followed by the
TCP port number, 2002. For example:
http://127.0.0.1:2002
If the system has not yet been configured, the Cisco Secure ACS desktop will load
immediately. When the Cisco Secure ACS administrator and the administrators access
policy are defined, the user may be required to log in.
Create Cisco Secure ACS Admin Super User
Getting Started
Super user has
admin privileges for
all Cisco Secure
ACS functions.
Super user has
admin privileges for
all Cisco Secure
ACS functions.
Getting Started Creating the Cisco Secure ACS Admin Users
The first thing that should be configured is the administrator user or super user for the Cisco
Secure ACS application. The super user has privilege to all Cisco Secure ACS functions. This
account information must be protected. It provides the keys to all Cisco Secure ACS managed
resources.
Follow the steps below to configure the Cisco Secure ACS admin or super user.
Step 1: From the Cisco Secure ACS desktop, select the navigation button, Administration Control.
Initially, Cisco Secure ACS will illustrate that no administrator accounts have been
configured.
Step 2: Click the Add Administrator button.
Step 3: Provide a name and password for the admin or super user.
Step 4. An administrator can be limited to administering privileges to selected user groups.
Because Tom will be the only administrator for now, he will be granted all privileges for all
user groups. Click the Grant All button.
Step 5. Save the changes by clicking the Submit button.
Defining the Admin Policies
Getting Started
Use Default Access Policy
- Allow any IP Address to connect.
- Allow any TCP port to be allocated
for HTTP.
for HTTP.
- Authenticate all Cisco
Secure ACS administrator
access.
- Lockout after 10 minutes.
access.
- Lockout after 10 minutes. Limit number of files.
Limit number of files.
Getting Started Defining the Administration Policy
The administration policy defines how the Cisco Secure ACS application will be accessed and
maintained. As previously stated, initially, the Cisco Secure ACS application can be accessed
only from the local console. When an administrator account has been established and the
administration policy is in place, the Cisco Secure ACS application can be accessed remotely
based on the established policy.
Based on the Cisco Secure ACS system maintenance and administrator access policies defined
in the planning steps, Tom can now configure the super user to have access to the Cisco Secure
ACS application from anywhere, require that a user log in and enter a password when at the
Cisco Secure ACS platform console, and delete audit logs older than one week. Users will also
be automatically logged out if the session is idle for more than 10 minutes. To configure these
policies, follow the steps below.
Defining the Admin Policies
Getting Started
for HTTP.
for HTTP.
access.
- Lockout after 10 minutes.
access.
- Lockout after 10 minutes. Limit number of files.
Getting Started Defining the Administration Policy
Step 1: From the Cisco Secure ACS desktop, select the navigation button, Administration
Control.
Step 2: Click the Access Policy button to configure Cisco Secure ACS to accept access by a client
using any IP address and allow Cisco Secure ACS to use any TCP port range between
1024 and 65535. This is the configuration by default.
Step 3: To save any changes, click the Submit button. This returns you to the Administration
Control window.
Step 4: Click the Session Policy button to configure Cisco Secure ACS to force the user to enter a
username and password when physically at the Cisco Secure ACS platform and to
automatically log out the user if the session is idle for more than 10 minutes.
Control window.
Step 6: Click the Audit Policy button to configure Cisco Secure ACS to delete log files older than
one week.
Control window.
Configure External Windows NT User
Databases
Configure Interface
Schedule Backups
Configure Logs
General Configuration Topics
Configure External
Windows NT User
Databases
Configure Interface
Schedule Backups
Configure Logs
In this part of the Cisco Secure ACS deployment scenario, Tom will configure some general
things that help define the Cisco Secure ACS system and its use. Tom will first add the external
Windows NT database used to authenticate the users to Cisco Secure ACS, and will then set the
options in the Interface Configuration task to simplify the screens used to configure the rest of
the Cisco Secure ACS application.
As part of this general configuration, Tom decides to schedule the backups and configure the
logs. These two tasks can be performed any time after the Interface Configuration task is
completed.
Configuring External Windows Database
Cisco
Secure ACS
Windows
NT Database Specific Cisco
Secure ACS
Configuration
for External
Windows NT
Database
General Configuration Configuring External User Database
Creative Engineering already has a large user database stored in the Windows primary domain
controller. Tom can take advantage of the work already invested in building the database by
configuring the Cisco Secure ACS system to authenticate usernames and passwords against
those already in the Windows user database.
To inform Cisco Secure ACS of the existence of an external Windows user database to be used
for authentication purposes, follow these steps:
Step 1: In the navigation menu, click the External User Databases button.
Step 2: Click Database Configuration from the options presented. Cisco Secure ACS displays a list of all
possible external user database types.
Step 3: Click Windows NT/2000.
Step 4: To create a new configuration:
a. Click Create New Configuration.
b. Provide a name for the new configuration in the box provided, or accept the default.
c. Click Submit to save the change.
Result: Cisco Secure ACS lists the new configuration on the External User Database Configuration
page.
Step 5: Click Configure.
The Windows NT/2000 User Database Configuration page appears. This page has three
configuration boxes.
Step 6: Enable password changes using Microsoft Challenge Handshake Authentication Protocol (MS-
CHAP) Version 1.
Step 7: Click Submit to save the changes.
Include two additional
fields for user
supplemental information.
Include two additional
fields for user
supplemental information.
Selections are based on
planned Cisco Secure
ACS features to utilize.
Selections are based on
planned Cisco Secure
ACS features to utilize.
General Configuration Interface Configuration
Cisco Secure ACS provides a wide variety of configuration possibilities. Because Tom has
already created a detailed deployment plan, he knows which features he actually needs to
configure to achieve his stated objectives. Tom will use the Interface Configuration task to
enable the display of only the options he wishes to configure. As Toms network grows, the
Cisco Secure ACS configuration can include some of the features hidden from the displays by
revisiting this section and enabling them.
Step 1: Select the Interface Configuration task from the navigation menu.
Step 2: For easy reference, Tom wishes to store the users phone number and department name for each
user. Select User Data Configuration.
Step 3: Enable fields 3 and 4 and change the field names to Department and Phone #.
Step 4: Click Submit. These fields will now be displayed on the User Setup screen.
Step 5: Click Advanced Options.
Step 6: Enable/disable according to plan.
- Disable all user-level authorizations. All authorizations will be based on group policies.
- Enable group-level policies except for downloadable Cisco PIX access control lists (ACLs).
- Enable usage quotas (used for the consultant group).
- Enable distributed systems and Cisco Secure Cisco Secure ACS database replication to make
sure the primary and backup Cisco Secure ACS systems are identical.
- Enable network device groups (NDGs) because they will help make the network access
restrictions (NARs) and command set authorization policies easier to configure.
- Disable the remaining categories because they are not necessary for configuration according to
the deployment plan.
Schedule Backups
Daily Backups
M-F, Twice on
Friday
Daily Backups
M-F, Twice on
Friday
General Configuration - Schedule Backups
If a catastrophe occurs, Tom wants to make sure he can quickly get back to a working Cisco
Secure ACS configuration. Though Tom will perform a manual backup after each major change
he makes to the system, he also wants to capture the quick small changes he may make in the
course of a day without performing a backup for each change. To do this, he schedules a backup
to occur every workday, and twice on Friday, just to be sure. According to Toms Cisco Secure
ACS deployment plan, he also manages the number of backup files kept in order to better
manage disk utilization.
Step 1: From the Cisco Secure ACS navigation menu, select the System Configuration task.
Step 2: From the presented options, select Cisco Secure ACS Backup.
Step 3: Select the radio button, At specific times.
Step 4: Click on the appropriate square on the graph for the time to perform the backup.
Step 5: To delete backup files older than one week, select Manage Directories and keep the default
of Delete files older than 7 days.
Configure Logs
Enable log.
Enable log.
Select attributes to
include in log.
Select attributes to
include in log.
Perform for all CSV Logs
(VoIP not needed according to plan).
Perform for all CSV Logs
(VoIP not needed according to plan).
General Configuration - Configure Logs
Tom wants to capture as much information about AAA service activity and Cisco Secure ACS
usage. So Tom will enable all accounting logs. According to the Cisco Secure ACS deployment
plan, all logs will be stored in a comma-separated value (CSV) format. The Open Database
Connectivity (ODBC) logs should not be displayed because that option was not enabled in the
Interface Configuration task. Within each accounting log, Tom wants to include all attributes that
make sense to help him to troubleshoot his deployment. As needed, Tom can enable additional
attributes or disable selected attributes for logging.
Step 1: From the Cisco Secure ACS navigation menu, select System Configuration.
Step 2: From the presented options, select Logging. The Accounting Log files available are
displayed.
Step 3: Select the log file to configure.
Step 4: If not already checked, select the Log to <log type> report check box.
Step 5: Select the attributes to include in the log from the left column and click the --> button.
Step 6: Select Manage Directories and keep the defaults of Generate a New File Every Day and
Delete files older than 7 days.
Repeat for all log files, except the voice over IP (VoIP) accounting.
Configure Cisco
Secure ACS Network
Create Network Device Groups
Add AAA Clients
Add Backup Cisco Secure ACS Server
Schedule Database Replication
Configure Cisco Secure ACS Network Topics
Add AAA Clients
Add Backup Cisco Secure
ACS Server
In this part of the deployment scenario, we illustrate how to perform the following tasks:
Categorize the networked devices based on their purpose or how or why the end users access the
devices. The networked devices will be organized using the NDGs feature in Cisco Secure ACS.
When the network device groups are in place, we will add the devices (AAA clients).
The backup Cisco Secure ACS server will be defined along with the components to be replicated
and the schedule for replication.
Network
Access Devices
(use for network access only)
Network
Access Devices
(use for admin access only)
Core
Network Devices
(use for admin access only)
TACACS+
RADIUS (Cisco IOS
Software/
Cisco PIX
Firewall)
RADIUS (Aironet) - LEAP
TACACS+
Configure Network - Create Network Device Groups
Tom is ready to add the AAA clients to the Cisco Secure ACS application. Remember that the
AAA clients are the networked devices that have TACACS+ or RADIUS enabled. It was
determined that Tom would utilize NDGs to assist in the configuration of group-based command
authorization sets and network access restrictions. Based on the Cisco Secure ACS deployment
plan, Tom realizes that much of his access policy is based on network access and device
administrative access (shell access). Further, the consultants need administrative access only to
the core network devices, and not the network access devices. Hence, Tom decides to create
three NDGs.
1. AccessDevicesGroup for network access via the network access server devices
2. AccessDeviceAdminGroup for administrative access to the network access server devices
3. NetworkDevicesAdminGroup for administrative access to the core network devices
The following steps are used to create these three NDGs.
Step 1: From the Cisco Secure ACS navigation menu, select the Network Configuration task.
Step 2: From the Network Device Groups (NDG) list box, select Add Entry.
Step 3: Type in the name of the NDG to be created (AccessDevices, AccessDeviceAdmin, or
NetworkDevicesAdmin).
Step 4: Click Submit.
Repeat Steps 24 to add the other two groups.
When finished, four NDGs should be listed, as illustrated above. The (Not Assigned) NDG is
where the local Cisco Secure ACS server is initially assigned.
Add AAA Clients (AccessDevices NDG)
Just submit for now and restart Cisco
Secure ACS after all configuration is done.
Add all AAA clients.
Configure Network - Add AAA Clients (AccessDevices NDG)
The AAA clients to be added to the AccessDevices NDG are the various devices that users
connect through to access the corporate network, such as the Cisco AS5300 Access Server, the
Cisco PIX Firewall, and the Cisco Aironet devices. Each of these AAA clients will request AAA
services from the Cisco Secure ACS via the RADIUS security protocol.
In Toms network, there are three devices used for remote network access, the Cisco Aironet
Access Point, a Cisco AS5300, and a PIX firewall. To add these devices to the Cisco Secure ACS
network configuration, use the following steps:
Step 2: From the Network Device Groups list box, select the AccessDevices NDG.
Step 3: From the AccessDevices AAA clients list box, select Add Entry.
Step 4: Enter a name for this AAA client (that is, AS5300).
Step 5: Enter the IP address for this AAA client.
Step 6: Enter the shared secret key. (This is configured on the network device and must match
here for communication between the client and Cisco Secure ACS to occur.)
Step 7: Select RADIUS (Cisco IOS/PIX) from the pull-down list to set the authentication security
protocol for the Cisco PIX Firewall and Cisco AS5300 devices. Use the RADIUS (Cisco Aironet
device) for the Cisco Aironet AP 340 or 350; this utilizes the Cisco Lightweight Extensible
Authentication Protocol (LEAP) authentication method and Extensible Authentication Protocol-
transparent LAN services (EAP-TLS) as a backup method.
Step 8: Click the Log/Update/Watchdog Packets from the AAA Client check box to enter this
additional accounting information into the RADIUS accounting log. (Note that Cisco Aironet access
points using software releases earlier than v11.10 do not send accounting records.)
Add AAA Clients (AccessDevices NDG)
Step 9: Click Submit to save changes. A message is displayed informing Tom that The current
configuration has been changed. Restart Cisco Secure ACS in "System Configuration:Service
Control" to adopt the new settings. Tom will restart the Cisco Secure ACS after all changes have
been made.
Repeat Steps 3 to 9 to add all other access devices to the AccessDevices NDG.
Add AAA Clients (AccessDeviceAdmin NDG)
(Note: same devices as in the
AccessDevices NDG but with different
names and different security protocol)
(Note: same devices as in the
AccessDevices NDG but with different
names and different security protocol)
0
Configure Network - Add AAA Clients (AccessDeviceAdmin NDG)
The previous step created a group of devices that users connect to when accessing the
corporate network. Cisco Secure ACS would use the RADIUS protocol when authenticating
these users. Now Tom wants to group these devices together again to allow Cisco Secure ACS
to authenticate administrators using TACACS+ when someone wants to access the devices for
administration purposes (that is, Shell access, Telnet).
Using the AccessDeviceAdmin NDG, Tom will add the same AAA clients. However, in this case,
Tom must enter a different hostname and configure this NDG to use the TACACS+ security
protocol instead of RADIUS.
Step 2: From the Network Device Groups list box, select the AccessDeviceAdmin NDG.
Step 3: From the AccessDeviceAdmin AAA clients list box, select Add Entry.
Step 4: Enter a name for this AAA client that is different from the one used in the AccessDevices NDG (that
is, AS5300Admin).
Step 5: Enter the IP address for this AAA client (same as before).
Step 6: Enter the shared secret key. (This is configured on the client and must match here for communication
between the client and Cisco Secure ACS to occur.)
Step 7: Select TACACS+ (Cisco IOS) from the pull-down list to use as the authentication security protocol.
Step 8: Click Submit to save changes. A message is displayed informing Tom that The current configuration
has been changed. Restart Cisco Secure ACS in "System Configuration:Service Control" to adopt
the new settings. Tom will restart the Cisco Secure ACS after all additions have been made. This
will speed up the configuration process.
Repeat steps 3 to 8 to add all other access devices to the AccessDeviceAdmin NDG.
Add AAA Clients (NetworkDevicesAdmin NDG)
The AAA client in this NDG includes
all devices on three subnets.
The AAA client in this NDG includes
all devices on three subnets.
Configure Network - Add AAA Clients (NetworkDevicesAdmin NDG)
The third NDG will group all remaining network devices together. This group will be used to
authenticate administrators attempting to access Cisco IOS
devices for administration purposes

(that is, Shell access, Telnet). All devices will be authenticated using TACACS+.
As discussed in Chapter 2, the new Cisco Secure ACS multi-network access server (NAS) feature
allows an administrator to define a set of network devices with the same attributes: shared key,
authentication method, or login/accounting parameters. The NAS wildcarding enables
administrators to provide multiple IP addresses or ranges of IP addresses using wildcards. Tom
will use this feature to quickly configure all other network devices for TACACS+ administration.
Step 2: From the Network Device Groups list box, select the NetworkDevices NDG.
Step 3: From the NetworkDevices AAA Clients list box, select Add Entry.
Step 4: Enter a name for this multi-NAS AAA client (that is, NeworkDevices).
Step 5: Enter the IP addresses for devices to be included in this AAA client. Wildcards can be used.
Step 6: Enter the shared secret key. (This is configured on the clients and must match here for
communication between the client and Cisco Secure ACS to occur.)
Step 7: Select TACACS+ (Cisco IOS) from the pull-down list to use as the authentication security protocol.
Step 8: Click Submit to save changes. A message is displayed informing Tom that The current configuration
has been changed. Restart Cisco Secure ACS in "System Configuration:Service Control" to adopt
the new settings. Tom will restart the Cisco Secure ACS after all additions have been made. This
will speed up the configuration process.
ACS-1
ACS-2
ACS-1
Local Cisco Secure ACS
This same setup is necessary on
the backup Cisco Secure ACS
server (ACS-2).
server (ACS-2).
Configure Network - Add Backup Cisco Secure ACS Server
After creating the NDGs and adding the appropriate AAA clients, Tom needs to configure the
relationship between the primary and backup Cisco Secure ACS systems. Earlier, Tom
configured the Distributed System Settings option in the Interface Configuration task, resulting in
the display for adding remote servers to the Cisco Secure ACS Network Configuration. The
remote server will be the device that is receiving the replicated data for backup purposes. Toms
Cisco Secure ACS deployment plan calls for a backup Cisco Secure ACS server to be identical to
the primary one Tom is currently configuring. Tom can replicate the primary Cisco Secure ACS
database to the backup Cisco Secure ACS to achieve this with minimal duplicated configuration
steps. Before replication can occur, the Cisco Secure ACS systems must know of each other.
Use the following steps to configure the primary server to be aware of the backup. (The steps to
inform the backup server about the primary Cisco Secure ACS would be similar. Note that the
backup server would require the Distributed Systems Settings option to be enabled in the
Advanced Options of the Interface Configuration task.)
Step 1: From the navigation menu, select the Network Configuration task.
Step 2: From the Network Device Groups list box, select the (Not Assigned) NDG. Because there will be only
two Cisco Secure ACS servers entered (primary and backup), creating a NDG for the AAA servers
was not really necessary.
Step 3: From the (Not Assigned) AAA Servers list box, select Add Entry. (The local Cisco Secure ACS should
already be listed.)
Step 4: Enter a name, IP address, and the shared secret key for the remote Cisco Secure ACS server.
Step 5: Make sure the type of AAA server is set to CiscoSecure Cisco Secure ACS for Windows 2000/NT.
Step 6: Set the Traffic Type to inbound/outbound. The Traffic Type defines the direction in which traffic to and
from the remote AAA server is allowed to flow from this local Cisco Secure ACS system. Setting the
field to inbound/outbound allows the specified AAA server to forward and accept authentication
requests to/from the other AAA server.
ACS-1
ACS-2
ACS-1
server (ACS-2).
server (ACS-2).
Step 7: Click Submit. A message is displayed informing Tom that The current configuration has
been changed. Restart Cisco Secure ACS in "System Configuration:Service Control" to adopt the
new settings. As indicated, Tom will restart Cisco Secure ACS after all additions have been made.
Daily replications
M-F, twice on
Friday (after
backup).
Daily replications
M-F, twice on
Friday (after
backup).
Duplicate all.
Duplicate all.
Send to backup
Cisco Secure ACS
server.
Send to backup
Cisco Secure ACS
server.
Configure Network - Schedule Database Replication
While Tom is thinking about it, he decides to schedule the times for replicating the Cisco Secure
ACS database. Note that although the following steps configure the primary Cisco Secure ACS to
send information, the backup Cisco Secure ACS will also need to be configured to receive the
information from the primary Cisco Secure ACS.
Step 2: From the presented options, select CiscoSecure Database Replication.
Step 3: Select all components that should be sent to the backup Cisco Secure ACS. (On the
backup Cisco Secure ACS, configure all components to be received from the primary Cisco
Secure ACS.)
Step 4: Set the replication schedule. Select At specific times.
Step 5: Click on the appropriate square for the time to perform the replication. Tom chooses the
hour after he scheduled the database backups.
Step 6: Select the backup Cisco Secure ACS server from the AAA Servers column and click the -->
button to move it into the Replication column. (The replication configuration on the backup
server would not require steps 5 and 6 to be performed.) Instead, on the backup server use
the Accept Replication From pull-down list to select the primary Cisco Secure ACS system.
Step 7: Click Submit to save changes.
Configure
Authorization
Create Command Authorization Sets
Rename User Groups
Configure User Groups
Configure Authorization Topics
Create Command Authorization
Sets
Rename User Groups
Configure User Groups
Cisco Secure ACS allows for the creation of shared sets of constructs that can be used in the
network access restriction (NAR) configurations for user groups and individual users. After
reviewing the Cisco Secure ACS deployment plan, Tom has determined that he can simplify user
group configurations by creating a Shared Command Authorization Set, allowing users to
perform only show commands. (This restriction will apply to the Help Desk and Consultant
user groups.) Also, the different device access restrictions for network access and
administrative access for the consultants user group would be best configured by creating
appropriate Shared Network Access Restrictions for both policies. After defining these
constructs, Tom will be ready to configure the user groups.
Device Administration Policy
Network
Admin
Help
Desk
General
Users
Consultants
Unrestricted
Access
Device Admin Policy
Line Access (tty, aux, console)
Limited Commands
(show only)
Restricted to Specific Device Groups
Limited to show Commands
(show only)
Device Administration Policy
Based on the Cisco Secure ACS deployment plan, three of the four types of users on Toms
network require different levels of administrative access to the devices on the network. The
network admin users need unrestricted administrative privileges to all devices; the Help Desk
users need the ability to run only show commands on all network devices; the Consultants need
to be able to run show commands only on the nonaccess devices; and finally, the general users
are not allowed administrative access.
Configure Authentication
Allows all show
commands to be
executed, but not others.
Allows all show
commands to be
executed, but not others.
From Toms knowledge about Cisco Secure ACS, Tom decides to create a Shared Command
Authorization Set for the show command capability. Later it will be used in the configuration
of the user groups authorization privileges.
Step 1: From the Cisco Secure ACS navigation menu, select the Shared Profile Components task.
Step 2: From the presented options, select Shell Command Authorization.
Step 3: Click Add from the Shell Command Authorization Sets list box to create a new set.
Step 4: Enter the name, Show Only, and a description to help easily manage this command
authorization set.
Step 5: All commands entered on a device by a user will be parsed and compared against any
Command Authorization Sets associated with the user (either in the users profile or in the
users group profile). In this case, Tom wants to deny any command except the show
command. Enter show in the entry box and click Add Command. This becomes a
matched command. Check the Permit Unmatched Args check box to allow any type of
argument for the show command. Finally, click Deny as the policy for any unmatched
command.
Step 6: Click Submit to make this Command Authorization Set available for use when configuring
user or user group access restrictions.
Create Network Access Restrictions
Tom wants to make sure the consultants have only a limited access capability. The consultants
are allowed access to the network only by dialing in through the Cisco AS5300. At the same
time, he wants to be sure that they can administratively access the nonaccess devices in the
network to perform show commands. Tom creates two shared NARs that will be assigned to the
consultants user group to achieve this limited access.
Step 1: From the Cisco Secure ACS navigation menu, select the Shared Profile Components task.
Step 2: From the presented options, select Network Access Restrictions.
Step 3: Click Add from the Network Access Restrictions list box to create a new NAR.
Step 4: Enter the name, Dial-in Only, and a description to help easily manage this NAR.
Step 5: Activate the Define CLI/DNIS-based access restriction.
Step 6: From the Table Definitions pull-down list, select Permitted Calling Point of Access Locations.
Step 7: From the AAA Client pull-down list, select the Cisco AS5300, and use the wildcard (*) for all other
fields. (Tom can always define these fields later to be more granular on his access policy for the
consultants.) Click Enter to add the data to the table of Permitted Calling Point of Access Locations
for this NAR.
Step 9: To create the second NAR, click Add from the Network Access Restrictions list box.
Step 10: Enter a name, nonaccess Devices, and a description to help easily manage this NAR.
Step 11: Activate the Define IP-based access restriction.
Step 12: From the Table Definitions pull-down list, select Permitted Calling Point of Access Locations.
Step 13: From the AAA Client pull-down list, select the NetworkDeviceAdmin NDG that was
created earlier. This device group contains all network devices except the access devices. Enter
the wildcard (*) for all other fields. (Tom can always define these fields later to be more granular
on his access policy for the consultants.) Then click Enter to add the data to the table of Permitted
Calling Point of Access Locations for this NAR.
Step 14: Click Submit to save the changes. These NARs will now be available to define the
network access restrictions for the consultants.
Rename User Groups
Change the names of
four user groups to ease
management.
Change the names of
four user groups to ease
management.
Renaming the Existing User Groups
According to Toms Cisco Secure ACS deployment plan, there are four distinct types of users.
Each type of user has different network access and administrative access requirements. These
access requirements can be configured by defining user groups. When users are added as
members to these groups, they inherit the access restrictions defined in the user group.
The four types of users translate into the use of 4 of the 500 user groups available for use in
Cisco Secure ACS. The default names of these groups are Default Group, and Groups 1499.
Using the default names would be extremely difficult to manage; hence Cisco Secure ACS allows
for the renaming of these user groups.
Before configuring the access restrictions for each user type, Tom needs to rename 4 of the 500
groups. (Use Groups 14). To rename the existing user groups, follow these steps.
Step 1: From the Cisco Secure ACS navigation menu, select the Group Setup task.
Step 2: Select 1: Group 1 from the Group pull-down list.
Step 3: Click Rename Group.
Step 4: Enter the new name for the group, NetworkAdmins.
Repeat Steps 2 through 5 for:
2: Group 2 -> Help desk
3: Group 3 -> General users
4: Group 4 -> Consultants
Configure User Groups - Network Admin
Allow for TACACS Shell usage.
Permit any commands of devices.
Permit any commands of devices.
Allow for RADIUS access.
Just submit for now and restart
Cisco Secure ACS after all
configuration is done.
Just submit for now and restart
Cisco Secure ACS after all
configuration is done.
Configure User Groups - Network Admins
The configuration of the Network Admins group must allow the administrators unrestricted
access to both the corporate network, and shell access to administer the devices. Tom can
achieve this by configuring the group to allow RADUIS logins with no restrictions (NARs) and
allowing TACACS+ shell access to any device for any command.
Step 2: Select 1: Network Admins from the Group pull-down list.
Step 3: Click Edit Settings.
Step 4: Scroll down to the IETF RADIUS Attributes configuration dialog box. Click on the desired attributes
to enable them. To enable Remote Access Dial-In User Service (RADIUS) login access, check the
Service-Type check box and make sure Login is selected from the pull-down list.
Step 5: To enable the TACACS+ shell access capability, scroll to the TACACS+ Settings and check the
Shell (exec) check box.
Step 6: To give the group complete command authority, a command authorization set needs to be
configured specific to this group. (Note that a shared command authorization set could also have
been created.) Select Per Group Command Authorization from the TACACS+ Settings configuration
dialog box.
Step 7: Simply select Permit Unmatched Cisco IOS commands. (Because no commands are entered, any
commands entered by a Network Admin user are unmatched and hence by this policy will be
permitted.)
Step 8: Click Submit to make the changes to this group. A message is displayed informing Tom that The
current configuration has been changed. Restart Cisco Secure ACS in "System
Configuration:Service Control" to adopt the new settings. Tom will restart the Cisco Secure ACS
after all additions have been made.
Configure User Groups - Help Desk
No RADIUS is Allowed, hence no
external network access is available.
No RADIUS is Allowed, hence no
external network access is available.
Help Desk Access Only from NOC
Help Desk Access Only from NOC
Only Show Commands on Any Device
Only Show Commands on Any Device
Configure User Groups - Help Desk
The Cisco Secure ACS deployment plan stipulates that Help Desk users are not allowed any
access to the network from outside the network operations center (NOC). This can easily be
achieved by simply not enabling the RADIUS Login attribute. Further, in order to perform their
jobs, the Help Desk users must be given permission to access all devices, from the NOC, to
perform show commands.
Step 2: Select 2: Help Desk from the Group pull-down list.
Step 4: To enable the TACACS+ shell access capability, scroll to the TACACS+ Settings and check the
Shell (exec) check box.
Step 5: Use the Show Only Command Authorization Set created earlier to limit the users administrative
capabilities on all devices. In the Shell Command Authorization Set configuration dialog box, select
Assign a Shell Command Authorization Set for any network device and select Show Only from the
pull-down list.
Step 6: To limit the Help Desk users to performing only this task from the NOC, create a per-group NAR.
Find the Per User Defined Network Access Restriction configuration dialog box. Check Define IP-
based access restriction.
Step 7: From the Table Defines pull-down list, select Permitted Calling Points of Access Locations.
Step 8: From the AAA Clients pull-down list, select All AAA Clients, enter the wildcard (*) in the Port field,
and enter the NOC subnet in the Address field. Click Enter to add this NAR to the table.
Step 9: Click Submit to make the changes to this group. A message is displayed informing Tom that The
current configuration has been changed. Restart Cisco Secure ACS in System
Configuration:Service Control" to adopt the new settings. Tom will restart the Cisco Secure ACS
after all additions have been made.
Configure User Groups - General Users
No administrative access to devices is allowed.
No administrative access to devices is allowed.
Configure User Groups - General Users
The Cisco Secure ACS deployment plan states that the general users have unrestricted network
access but no administrative access to any devices. To set up these policies, the RADIUS Login
Service must be enabled and you must verify that TACACS+ Shell access is disabled.
Step 2: Select 3: General Users from the Group pull-down list.
Step 4: Scroll down to the IETF RADIUS Attributes configuration dialog box. Click on the desired
attributes to enable them. To enable RADIUS login access, check the Service-Type check
box and make sure Login is selected from the pull-down list.
Step 5: To ensure that TACACS+ shell access is disabled, scroll to the TACACS+ Settings and
verify that the Shell (exec) check box is not selected.
Step 6: Click Submit to make the changes to this group. A message is displayed informing Tom
that The current configuration has been changed. Restart Cisco Secure ACS in "System
Configuration:Service Control" to adopt the new settings. Tom will restart the Cisco Secure
ACS system after all additions have been made.
Configure User Groups - Consultants
Restrict to dial-in only
(TACACS+ access for network
devices only).
devices only).
Limit access to work hours only
The consultants have the most access restrictions. They are allowed network access only via the
Cisco AS5300, and administrative access to the nonaccess devices for show commands only.
Furthermore, the Consultants can access the network only during business hours, and each
consultant is limited to 1000 hours total of online time. Their accounts will also expire at the end of
the contract, but that restriction is linked to each individual user and configured later in this
scenario.
Step 2: Select 4: Consultants from the Group pull-down list.
Step 4: Scroll down to the IETF RADIUS Attributes configuration dialog box. Click on the desired
attributes to enable them. To enable RADIUS login access, check the Service-Type check
box and make sure Login is selected from the pull-down list.
Step 5: Access is restricted to either the Cisco AS5300 for network access or the nonaccess devices
for show command use. In the Network Access Restrictions configuration dialog box under
the Shared NAR section, select Only Allow network access when to enable the shared
NAR configuration, and also select Any one selected NAR results in a permit as the access
rule.
Step 6: Select the Dial-In Only and nonaccess Devices shared NARs and click the -> button to
include them in the Selected NARs list. Together these NARs will not allow the consultants
any type of access to any device other than those contained in these two NARs. Further
policies will dictate the type of access. (Recall that the NARs are created by assigning AAA
clients that are associated with a specific security protocol.)
devices only).
devices only).
Step 7: To set the times that the consultants are allowed to access the network, find the Default
Time-of-Day Access Settings configuration dialog box and check Set as default Access Times.
In the time chart, click the appropriate boxes to allow access only during work hours for the
consultants. (Green boxes indicate allowed access; white boxes indicate restricted access.)
Configure User Groups - Consultant
Allow for TACACS Shell usage. Limit to show commands on
nonaccess devices.
Limit to show commands on
nonaccess devices.
All consultants are limited to a
total of 1000 hours.
All consultants are limited to a
total of 1000 hours.
Add Association
Configure User Groups - Consultants (continued)
Step 8: To limit each consultants network usage, find the Usage Quotas configuration dialog box
and click Limit each user of this group to XXXX hours of on-line time. Enter 1000 for the
hours and select Absolute as the timeframe metric from the pull-down list.
Step 9: To enable the TACACS+ shell access capability, scroll to the TACACS+ Settings and
check the Shell (exec) check box.
Step 10: To limit the consultants command access to show commands only on the nonaccess
devices, find the Shell Command Authorization Set configuration dialog box and check
Assign a Shell Command Authorization Set on a per Network Device Group Basis.
Step 11: From the Device Group pull-down list, select the NetworkDeviceAdmin NDG (includes all
the nonaccess devices and assigned TACACS+ as the security protocol).
Step 12: From the Command Set pull-down list, select Show Only.
Step 13: Click Add Association.
Step 14: Click Submit to make the changes to this group. A message is displayed informing Tom
that The current configuration has been changed. Restart Cisco Secure ACS in "System
Configuration:Service Control" to adopt the new settings. Tom will restart the Cisco
Secure ACS system after all additions have been made.
Now that all the user groups have been defined, Tom can add user account information and
associate each user with one of these user groups.
Configure Users
Add User Profiles
Create Unknown User Policy
Database to Group Mapping
Add User Profiles
Create Unknown User Policy
Database to Group Mapping
Configure Users Topics
Cisco SecureACS Deployment Scenario
Configure Users
Now that the user groups are created that match the Cisco Secure ACS deployment plan and
access policies, all that is left is to add the individual users. Toms strategy is to create entries
in the Cisco Secure ACS database for all Network Admin, Help Desk, and Consultant users, and
to allow the unknown policy to automatically create the user profile entries for the general users.
Adding Network Admin and Help Desk Users
Configure Users
Assign user group.
Assign user group.
Assign authentication.
Assign authentication.
Adding Network Admin and Help Desk Users
Because Tom has decided that all authorization will be done at the group level, adding network
admin and help desk users is very simple and straightforward. Add the user account
information, tell Cisco Secure ACS to use the external Windows database for authentication, and
assign the user to the proper user group.
Step 1: From the Cisco Secure ACS navigation menu, select the User Setup task.
Step 2: Enter the account name for the user to be added.
Step 3: Click Add/Edit.
Step 4: Enter all Supplementary User Information. (This information is strictly for information
purposes and has no effect on Cisco Secure ACS processing.)
Step 5: Set the Password Authentication to the External Windows NT/2000 database previously
configured.
Step 6: Select the appropriate user group for the user from the pull-down list.
Adding Consultant Users
Configure Users
Disable account at the end of contract.
Disable account at the end of contract.
Adding Consultant Users
Creating the user profiles for the consultants differs from the user profiles for the network
admins and help desk users in that the consultants are to be authenticated via the Cisco Secure
ACS database and, therefore, require the configuration of passwords. Also, the consultants
user accounts are to be configured to become disabled at the end of their contract.
Step 1: From the Cisco Secure ACS navigation menu, select the User Setup task.
Step 2: Enter the account name for the consultant user to be added.
Step 3: Click Add/Edit.
Step 4: Enter all Supplementary User Information. (This information is strictly for information
purposes and has no effect on Cisco Secure ACS processing.)
Step 5: Set the Password Authentication to the CiscoSecure Database.
Step 6: Enter the password for this consultants account. For now Tom is not using a separate
password for Challenge Handshake Authentication Protocol (CHAP)/Microsoft CHAP (MS-
CHAP).
Step 7: Select the Consultant user group from the pull-down list.
Step 8: Scroll down to the Account Disable configuration dialog box. Click Disable account if and
the Date Exceeds check boxes. Enter the end date of the contract.
Unknown User Policy
Configure Users
Unknown User Policy
To save time in entering user profiles, Tom has decided to let the Cisco Secure ACS unknown
user policy automatically create user profiles for all the general users when they first attempt
access. Because all general users already have accounts in the external Windows database,
Tom needs to simply inform Cisco Secure ACS to send any authentication requests for an
unknown user to the external Windows database.
Step 1: From the Cisco Secure ACS navigation menu, select the External User Databases task.
Step 2: From the displayed options, select Unknown User Policy.
Step 3: Click Check the following external user databases.
Step 4: Highlight the Windows NT/2000 database in the External Databases column and click the -
-> button to move it into the Selected Databases column.
Remember that the external database authentication is dependent upon the authentication
protocol and the type of external database. External databases do not support all authentication
protocols, as illustrated in Chapter 1. For example, AAA clients using EAP-message digest 5
(MD5) cannot authenticate using any external database, whereas the LEAP authentication
protocol is supported by most external databases.
Configure Users
When the external database authenticates the user, it sends the OK or Deny message back to the
AAA server for forwarding the response to the requesting AAA client. Cisco Secure ACS must
also send any authorizations. To do this, Cisco Secure ACS must associate the user with a user
group. With this information, Cisco Secure ACS can add the user profile to the Cisco Secure
ACS database, and the next login attempt by this user will proceed much quicker.
Step 1: From the Cisco Secure ACS navigation menu, select the External User Databases task.
Step 2: From the displayed options, select Database Group Mappings.
Step 3: From the list of external databases in the Unknown User Group Mappings dialog box,
select the Windows NT/2000 database previously configured.
Step 4: Cisco Secure ACS allows for mappings to be made based on domains and types of users.
Select the domain to map users from the Domain Configurations dialog box.
Step 5: Click Add Mapping from the group mappings for this domain dialog box.
Step 6: Select the Windows user group name and click the Add to selected button.
Step 7: From the CiscoSecure Group pull-down list, select the General Users entry.
Step 9: Continue to add mappings or click the Cancel button to move back up through the
Database Group Mappings configuration screens.
Using Cisco
Secure ACS
Restart Cisco Secure ACS System
Perform Backup
Using Cisco Secure ACS Topic
Restart Cisco Secure
ACS System
Perform Backup
Tom has now completed the configuration of Cisco Secure ACS to match his deployment plan.
To begin using Cisco Secure ACS, Tom needs to restart the system to have all changes become
active. Also, Tom decides to capture these changes by manually backing up the database and
replicating the information to the backup Cisco Secure ACS server. Tom can monitor the Cisco
Secure ACS activities by reviewing the logs generated by Cisco Secure ACS.
Restart the Cisco Secure ACS System
Restart the Cisco Secure
ACS system for all additions
to take effect.
Restart the Cisco Secure
ACS system for all additions
to take effect.
CiscoSecure ACS on ACS-1
Restart Cisco Secure ACS System
When Tom was configuring the Cisco Secure ACS system, he decided to only Submit his
additions rather than Submit and Restart the system for each addition. This is preferred if
making a lot of changes at the same time. Now that he has finished making changes, he needs
to restart the Cisco Secure ACS system to have the changes take effect. The system can be
restarted by rebooting the Cisco Secure ACS platform, restarting the Windows Cisco Secure
ACS services or from the Cisco Secure ACS desktop. Tom decides to use the Cisco Secure ACS
desktop.
Step 2: From the displayed options for System Configuration, click Service Control.
Step 3: The system status will show that the Cisco Secure ACS system is currently running. The
system still needs to be restarted for the additions to take effect. Click Restart.
After a short amount of time Tom restarts the system, and his changes will take effect.
Perform Backup
Back up the Cisco Secure
ACS system so backup files
reflect additions.
Back up the Cisco Secure
ACS system so backup files
reflect additions.
Perform Backup
Even though Tom has scheduled backups of the Cisco Secure ACS system to occur at specified
times, he wants to perform a backup right now to capture his newly configured system before it
goes online. To back up the system now, do the following:
Step 2: From the displayed options for System Configuration, click ACS Backup.
Step 3: The Cisco Secure ACS backup configuration dialog is displayed showing the Cisco Secure
ACS backup schedule previously configured. Click Backup Now to perform the backup
immediately.
Step 4: This may take a few minutes. To verify this operation, select Reports and Activities from
the navigation menu.
Step 5: From the available reports displayed, select Cisco Secure ACS Backup and Restore.
Step 6: From the available logs displayed, select the current log Backup and Restore.csv. You
should see an entry for the start of the backup and one for the completion. If the
completion entry is not displayed, the system is probably not finished being backed up.
Click Refresh periodically until the completion event is displayed.
Replicate Database to Back Up Cisco Secure ACS
Duplicate additions to the
backup ACS system.
Duplicate additions to the
backup ACS system.
Replicate Database to Back up Cisco Secure ACS
Even though Tom has scheduled the primary Cisco Secure ACS system to duplicate its database
to the backup Cisco Secure ACS system at specified times, he wants to duplicate the database
right now so the backup system is equal to the primary. To replicate the database now, do the
following:
Step 2: From the displayed options for System Configuration, click CiscoSecure Database
Replication.
Step 3: The Database Replication configuration dialog is displayed showing the database
replication schedule previously configured. Click Duplicate Now to perform the duplication
immediately.
Step 4: This may take a few minutes. To verify this operation, select Reports and Activities from
the navigation menu.
Step 5: From the available reports displayed, select Database Replication.
Step 6: From the available logs displayed, select the current log Database Replication.csv. You
should see an entry for the start of the procedure and one for the completion. If the
completion entry is not displayed, the procedure is probably not finished. Click Refresh
periodically until the completion event is displayed.
Monitoring Cisco Secure ACS Reports
Accounting
Monitoring Cisco Secure ACS Reports Accounting
Cisco Secure ACS features several options for maintaining accounting logs when multiple AAA
servers are deployed:
Log the accounting records locally.
Log the accounting records locally and on the primary Cisco Secure ACS.
Log the accounting records only on the primary Cisco Secure ACS.
Log the accounting records to an Open Database Connectivity (ODBC) database.
Do extended combinations of the above.
Tom has selected to record the accounting records only on the primary Cisco Secure ACS
system. If multiple Cisco Secure ACS systems are later deployed to support local users in their
regions, Tom can enable the AAA servers to centralize their accounting logs to his primary Cisco
Secure ACS system. (This feature is found under the System Configuration task; then select
Logging.)
These accounting logs will provide Tom with a wealth of information, including a user logged-in
list, detailing session length, IP and Media Access Control (MAC) addresses, and also failed login
attempts. In addition, all of Toms accounting logs will be in a comma-separated value (CSV)
format. This format was configured earlier in the System Configuration settings. Using this
format, Tom can export this data into a graphing tool or spreadsheet.
Thank You!
We hope that you have enjoyed using the Cisco Secure ACS application and have found its
features to be an important part of your network security toolkit.
Cisco Systems
Chapter 4
Installation and
Troubleshooting
Guidelines
Installation Requirements
AAA Server
AAA Client
Installation Tips
Troubleshooting Tips
This chapter provides highlights and important facts on installing the Cisco Secure Access
Control Server (Cisco Secure ACS) v3.0 application, and also discusses some troubleshooting
tips and techniques.
For more detailed instructions on the actual installation steps, refer to the Cisco Secure ACS v3.0
Installation Guide. Additional troubleshooting tips can also be found in the user guide and
release notes.
A link to the Cisco.com online documentation can be found in Chapter 5.
Installation
Requirements
AAA Server
System Requirements
Performance Considerations
AAA Client
Supported Devices

Windows Environment
System hardware 550-MHz Intel Pentium III or better
Graphics card (800 x 600, 256 colors), color monitor, CD ROM, network interface card
Operating system Windows NT Server 4.0 with Service Pack 6a
Windows 2000 Server with Service Pack 1 or 2
Windows 2000 Advanced Server * with Service Pack 1 or 2
Windows 2000 Datacenter Server * with Service Pack 1 or 2

System can be a domain controller or a member server
ODBC Jet Driver v2.6 (MDAC v2.5)
English language version of operating system
*Provided that Microsoft Clustering Services are not installed

Disk Space

250-MB system software
2-GB database environment

NTFS file system format
RAM 256-MB RAM
Third Party Software

Netscape Navigator or Communicator * v4.76 or
Microsoft Internet Explorer * v5.0 or v5.5

*Java and JavaScript enabled

AAA Server Requirements - Windows Only
Cisco Secure ACS v3.0
Cisco Secure ACS v3.0 Systems Requirements
The table above illustrates the important system requirements for the platform hosting the Cisco Secure
ACS v3.0 application.
The Cisco Secure ACS software application must be installed on Windows NT Server Version 4.0 or
Windows 2000 Server with the appropriate Microsoft service packs. Cisco Secure ACS can also be hosted
by Windows 2000 Advanced Server and Windows 2000 Datacenter Server, provided that the Microsoft
Clustering Services are not installed. The Windows platform can be configured as a domain controller or a
member server. Obtain the appropriate Windows service pack from Microsoft. (To determine which service
pack is currently installed, from Windows, click the Start > Run menu item; then type winver.) The service
packs can be applied either before or after installing Cisco Secure ACS.
The Cisco Secure ACS application should be installed on a Pentium III 550-MHz or better system. The
amount of RAM should be maximized when possible and should be no less than 256 MB. The virtual
memory should be optimized to at least twice the size of physical memory. The platform should have at
least 250 MB of disk storage for the installation and 2 GB or more for future data storage. Do not install the
software on a partition configured with a FAT file system; FAT file systems do not support file security. Use
NTFS to save disk space, add file security, and improve performance.
The Cisco Secure ACS installation program tests for the presence and proper functionality of the Open
Database Connectivity (ODBC) components needed by Cisco Secure ACS. If the installation program does
not find them, or if they are not functioning properly, abort the installation program and install the necessary
ODBC components by running the Microsoft Data Access Components (MDAC) v2.5 program located on the
Cisco Secure ACS CD, or download the latest version from Microsofts Web site. Rerun the Cisco Secure
ACS installation program after the ODBC components have been successfully installed.
The Cisco Secure ACS server must also have a compatible Web browser installed, such as Microsoft
Internet Explorer or Netscape Navigator. Both Java and JavaScript must be enabled in the Web browsers.
Cisco Secure ACS Server Performance
Considerations
Cisco Secure ACS is a high-
performance AAA server
Factors that may affect
performance:
Number of users to authenticate
Number of requests per user
Number of AAA clients supported
Location of AAA server, AAA
client, and database
Use of external user database
Cisco Secure ACS v3.0 Performance Considerations
The performance capabilities of Cisco Secure ACS are largely dependent upon the Windows
server that it is installed upon, the network topology, the selection of user databases, the type of
aAuthentication, authorization, and accounting (AAA) clients and other factors. For example,
Cisco Secure ACS can perform many more authentications per second if it is running on a 1.4-
GHz Pentium IV server with Windows 2000 Server hosted on a local 1-GB Ethernet backbone than
it can if it is running on a 200-MHz Pentium II server with Windows NT 4.0 hosted on a 10-MB LAN
located remotely across the WAN. The performance of Cisco Secure ACS in your network
depends on your specific environment and AAA requirements.
Consider the following when sizing your Cisco Secure ACS platform:
Maximum users supported by the Cisco Secure user databaseThere is no theoretical limit to the
number of users the Cisco Secure user database can support. The software has been successfully
tested with databases in excess of 100,000 users. The practical limit for a single Cisco Secure ACS
server authenticating against all its databases, internal and external, is approximately 300,000 to
500,000 users. This number increases significantly if the authentication load is spread across a
number of replicated Cisco Secure ACS servers.
Transactions per second per number of usersAssuming 10,000 users in the Cisco Secure user
database, a single processor 300-MHz Pentium II server provides 80 Remote Acces Dial-In User
Service (RADIUS) full login cycles (authentication, accounting start, and accounting stop) per
second and approximately 40 TACACS+ logins per second. As the database grows, this
performance declines approximately proportionately.
Maximum number of AAA clients supportedCisco Secure ACS can support AAA services for
approximately 2000 network devices running a AAA client.
Cisco Secure ACS Server Performance
Considerations
Cisco Secure ACS is a high-
performance AAA server
Factors that may affect
performance:
Number of users to authenticate
Number of requests per user
Number of AAA clients supported
Location of AAA server, AAA
client, and database
Use of external user database
Location of the Cisco Secure ACS systems is a factor when using an external Windows NT
database. Location of the primary domain controllers (PDCs) with respect to the Cisco Secure
ACS may cause authentication delays. Cisco Secure ACS initially requests authentication service
from the PDC that serves the local domain in which the Cisco Secure ACS resides. If the user
does not exist in that PDC, the PDC requests authentication from its trusted neighbors, a situation
that could result in longer delays.
AAA Clients
Cisco Devices (Cisco IOS
Software Release 11.2 or higher)

Network Access Server (NAS)
Cisco AS5200, AS5300, AS5800
Cisco PIX
Firewall
Cisco VPN 3000, 5000 Concentrators
Cisco IOS Routers
Cisco 2509, 2511, 3620, 3640
Cisco Aironet
Access Point wireless devices

Cisco Catalyst
802.1 (RADIUS AAA support)

Third Party Network Devices
A third-party device must be configured with TACACS+ or
RADIUS.
AAA Clients
The AAA clients are the actual networked devices that an end user obtains network access from
or a networked device that an administrator is trying to log into for administrative purposes.
When a user attempts to access the network through an access device or log into a networked
device, and that device is configured for AAA, the device will contact the AAA server (Cisco
Secure ACS) for authentication and authorization services. The communication between the AAA
client and AAA server is either TACACS+ or RADIUS. Therefore, for full TACACS+ and RADIUS
support on Cisco IOS devices, make sure that the Cisco AAA clients are running Cisco IOS
Release 11.2 or later. Refer to the proper version of Cisco IOS or Cisco Catalyst Operating
System configuration guide for the exact AAA configuration commands. Cisco Secure ACS can
also provide AAA services for third-party devices, but they must support and be configured to use
TACACS+ or RADIUS.
The AAA clients (Cisco and third-party devices) that are supported by the Cisco Secure ACS
server are illustrated above.
Installation Tips
Cisco Secure ACS v3.0 Installation on
Windows
Read the release notes.
Back up the server, including Windows registry.
Ensure that all network cards in Cisco Secure ACS system are
enabled.
Make sure the system meets or exceeds hardware and
software requirements.
Make sure dial-up users can successfully access the network.
Prepare to answer the installation questions.
Install software as the local administrator.
Run install script or setup.exe.
Start the Cisco Secure ACS services.
Cisco Secure ACS v3.0 Windows Installation
Prior to installing the Cisco Secure ACS software, it is good practice to back up the Windows
platform, including the Windows registry. If the installation is an upgrade or a reinstallation of
Cisco Secure ACS, then back up the Cisco Secure ACS configuration and database; then copy the
Cisco Secure ACS backup file to a drive other than the one local to the Cisco Secure ACS server.
Prior to the installation, read the release notes and ensure that the Cisco Secure ACS platform
meets or exceeds the hardware and software system requirements. In addition, it is good practice
to ensure that dial-up users can successfully access the network prior to installing Cisco Secure
ACS. In doing so, it can help with troubleshooting. If Cisco Secure ACS is installed and dial-up
users are experiencing problems shortly thereafter, the problem can be pinpointed to the
installation of the Cisco Secure ACS server or the configuration of the Cisco Secure ACS server
and the AAA clients.
Cisco Secure ACS v3.0 can be installed only by using the local administrator account on a
Windows platform. During the installation, Cisco Secure ACS must have all network cards
enabled. If there is a disabled network card on the Cisco Secure ACS server, the installation will
proceed very slowly because of delays caused by the Microsoft CryptoAPI.
The installation procedure requires answers to several questions that the installer may not know
the answers to right away. Therefore, review the installation questions on the upcoming pages
before installing the software.
At the end of the installation script, the installer can elect to have the script start the Cisco Secure
ACS services. If the user does not select this option, the Cisco Secure ACS Web interface will not
be available until the Cisco Secure ACS server is rebooted or the CSAdmin service is started
manually in the Windows Control Panel.
Cisco Secure ACS v3.0 Installation
Questions
The user will be prompted for the following
information during the installation:
IP addresses of AAA server and a AAA client
Protocol used for AAA client (RADIUS,
TACACS+)
Shared key between AAA server and client
Continue
Cisco Secure ACS v3.0 Installation Questions
Review the following and be prepared to answer the questions prior to running the installation
script.
Question: What is the IP address of the Cisco Secure ACS server?
If the IP address of the Cisco Secure ACS server is unknown, type ipconfig at a
Command Prompt on the Cisco Secure ACS server platform.
Question: What is the name, IP address, AAA security protocol to use, and vendor-specific
attributes to implement for the first AAA client to be configured to use Cisco Secure ACS
?
The installation procedure will ask for information regarding a AAA client. It is not
imperative that you enter correct information for this first AAA client. Something must be
entered, but if unknown during the installation procedure, dont worry, the client
information can be deleted or edited after the installation.
Your choices for the AAA protocol will be: TACACS+ (Cisco IOS
Software) or
RADIUS (Cisco Aironet
devices, Building Broadband Solutions Manager [BBSM], Cisco

IOS
Software/Cisco PIX
Firewall, Cisco VPN 3000, Cisco VPN 5000, or third-party

IETF, Ascend, Juniper, Nortel).
Question: What is the TACACS+ or RADIUS key (shared secret) between the AAA client and the
Cisco Secure ACS server?
To ensure proper function and encrypted communication between the AAA client and
Cisco Secure ACS, the shared key must be identical to the key configured on the AAA
client. Remember, these keys are case sensitive. Also, if the key is unknown during
the installation procedure, dont worry, the client information can be deleted or edited
after the installation.
Cisco Secure ACS v3.0 Installation
Questions
The user is prompted for the following
information during the installation:
Support for external database authentication
Autoconfiguration of Cisco IOS
Software
Just say no!
Cisco Secure ACS v3.0 Installation Questions continued
Question: How are users authenticated?
Your options are to use the Cisco Secure ACS database only, a Windows 2000/NT Security
Access Manager (SAM) user database only, or a Windows 2000 Active Directory user database
in addition to the Cisco Secure ACS user database. If selecting both the Cisco Secure ACS
database and an external Windows database authentication method, the administrator has the
option to use the Windows Dial-in Permission features. Cisco Secure ACS can apply the users
Windows dial-in permissions to determine whether to grant the user access to the network.
If the user installing the software elects to use only the Cisco Secure ACS database, the user
can still configure authentication support for all external databases at a later date; however,
electing this option during the installation step saves several setup procedures in configuring the
Windows database.
Authentication using the Cisco Secure ACS database is preferred for performance reasons.
Question: Would you like to have the Cisco IOS Software for the previously entered AAA client
automatically configured now?
If the installer specified a TACACS+ (Cisco IOS Software) or RADIUS (Cisco IOS Software/PIX
Firewall) as the AAA protocol for the first AAA client, the installation script asks the user if the
script should automatically configure the AAA functionality on the Cisco IOS network device. It is
recommended that for Cisco Secure ACS v3.0, the user clear the Yes, I want to configure Cisco
IOS software now check box. This feature assumes that the Cisco IOS Router is running Cisco
IOS 11.2 or later, but does not work well for devices running Cisco IOS 12.x.
Postinstallation Tasks or Options
Cisco Secure ACS Application
installed on a member server
Verify domain membership
Verify ownership of Cisco Secure ACS services
Service pack requirements
Windows NTService Pack 6a
Windows 2000 Service Pack 1 or 2
External authentication database
support
Configure within Cisco Secure ACS HTML interface
Cisco Secure ACS Postinstallations Tasks or Options
Depending upon your options or your environment, additional tasks may need to be performed following the
successful installation of Cisco Secure ACS.
If you install Cisco Secure ACS on a Windows member server and want to authenticate users with a Windows
Security Account Manager user database or an Active Directory user database, the installer must perform the
following Windows configuration steps to ensure that Windows permits authentication to occur from the member
server.
1. Verifying domain membershipOne common configuration error that prevents Windows authentication is the
erroneous assignment of the member server to a workgroup with the same name as the Windows domain
that is used to authenticate users. Although this may seem obvious, it is recommend that the installer verify
that the Cisco Secure ACS server is a member of the correct domain.
2. Services running from the administrative account of the domain controllerIf Cisco Secure ACS is installed
on a member server, the server must pass Windows authentication requests to a domain controller. For
these requests to succeed, the member server must run the Cisco Secure ACS services using the
administrative account of the domain controller.
If Cisco Secure ACS is reinstalled, this step must be repeated after each installation.
(Refer to the Cisco Secure ACS installation guide for the exact steps for verifying the domain membership and the
ownership of the Cisco Secure ACS services.)
If the Cisco Secure ACS server is using Windows NT, some features of Cisco Secure ACS depend upon Service
Pack 6a. The installation program checks for Service Pack 6a. If it determines that Service Pack 6a has not been
applied to the operating system, a warning message is displayed; continue the installation and then install the
required service pack before starting user authentication.
After Cisco Secure ACS has been installed, authentication services can be configured for all supported external
user database types in addition to Windows 2000/NT user databases. To configure the external user databases,
simply launch the Cisco Secure ACS HTML interface and select the External User Databases task.
Troubleshooting
Tips
Troubleshooting Guidelines
Online Documentation
Excellent guidelines
available in online
documentation
Information organized by
problem or condition
For each problem,
suggested recovery
actions provided
Online Documentation
As a first attempt to address potential problems, the network administrator should first review the
troubleshooting information found in the Online Documentation. Cisco has provided the user
with suggested recovery actions for common problems related to bringing up the Web browser or
HTML interface, users not being able to log in to the network or Cisco Secure ACS server,
authentication failures, installation errors, device configuration problems, and more.
User and System Logging
Type of Logs
Accounting Logs (HTML)
Dynamic Administration
Reports (HTML)
Cisco Secure ACS System
Logs (HTML)
Service Logs
(/<ACS Service>/Logs subdirectory)
User and System Logging
Cisco Secure ACS generates numerous logs that provide auditing information and can aid in
troubleshooting authentication and service problems. The logs are divided into four groups:
accounting logs, administration reports, system logs, and service logs. Briefly, these logs
provide the following.
Accounting logs contain information about the use of remote access services by users, such as:
user session start and stop times, username, caller-line identification, session duration, failed
attempts, successful authentication requests, and more.
Dynamic administration reports show the status of user accounts at that given moment.
System logs show the history of backups and restores, database synchronization activity, Cisco
Secure ACS administrator use activity, and list Cisco Secure ACS services start and stop times.
Service logs are considered diagnostic logs and are used for troubleshooting or debugging
purposes only. These logs are not intended for general use by Cisco Secure ACS administrators;
instead, they are mainly sources of information for Cisco support personnel. Service logs contain a
record of all Cisco Secure ACS service actions and activities. Cisco Secure ACS generates these
logs whenever you log in to Windows NT/2000 and the services are started, whether or not the
administrative interface is started, and whether or not you are using the service. The services
monitored are CSAdmin, CSAuth, CSDBSync, CSLog, CSMon, CSRadius, and CSTacacs.
The service logs are files located in the \<service name>\logs subdirectory of the Cisco Secure
ACS programs directory. The most recent debug log is named SERVICE.log, where SERVICE is
the name of the applicable service. Older debug logs are named with the year, month, and date
they were created.
The accounting, dynamic administration reports, and system logs can be viewed using the Cisco
Secure ACS HTML Web interface, as illustrated above.
Cisco Secure ACS Service Management
Cisco Secure ACS Service Management
The Cisco Secure ACS Active Service Management (CSMon) feature enables you to monitor all
Cisco Secure ACS services. Two areas can be configured using the Cisco Secure ACS Service
Management link in the System Configuration task: system monitoring and event logging.
The system monitoring process can be configured to test the login process every x minutes. If the
login process fails the test, the system can be configured to restart the Cisco Secure ACS ervices,
restart RADIUS/TACACS+, restart only the RADIUS or TACACS+ protocol, reboot the system on
which Cisco Secure ACS is running, or take no action. The System Monitoring process can also
be configured to send an e-mail to the administrator and log the event when a user attempts to log
in to a disabled account.
Event loggingThe administrator can configure Cisco Secure ACS to log all events to the
Windows NT/2000 Event Log. To view the Windows NT/2000 event log, simply click
Start>Administrative Tools>Event Viewer from the Windows desktop. For more detailed
information about an event, click the applicable event, and then click View>Details. When a Cisco
Secure ACS event that you selected in the System Monitoring section occurs, the administrator
can be notified via e-mail. Simply configure the administrators e-mail address and the Simple
Mail Transfer Protocol (SMTP) address of the sending mail server.
Thank You!
We hope that you have enjoyed using the Cisco Secure ACS application and have found its
features to be an important part of your network security toolkit.
Cisco Systems

Chapter 5
References

Access Control Server v3.0

Reference Materials
Many Cisco reference documents have been created to help users understand the Cisco Secure Access
Control Server (ACS) application. However, finding them can often be a challenge. This reference chapter
has been created to assist you in your pursuit of additional product information. Below are links to
documents and web pages that provide further details on the Cisco Secure ACS application.

! ACS v3.0 Product Information
" Online Documentation (CCO URL)
" Release Notes (PDF)
" Data Sheet (PDF)
" Frequently Asked Questions (PDF)
" Product Bulletin (Upgrade Information) (PDF)

! White Papers
" ACS and Catalyst Switching Deployment Guide (PDF)
" Guidelines for Placing ACS in the Network (PDF)
" External ODBC Authentication (PDF)
" Configuring LDAP (PDF)

! Miscellaneous References
" Comparison of TACACS+ and RADIUS (PDF)
" The RADIUS Specification (URL)
" The RADIUS Accounting Standard (URL)
" The RADIUS Attributes for Tunnel Protocol Support (URL)
" Cisco Aironet AP Software Configuration Guide (PDF) (URL)
" Configuring ACS v2.6 and Aironet for LEAP and MAC Authentication (PDF) (URL)
" Cisco Addresses WEP Vulnerabilities (PDF)
" Cisco Aironet Response to An Initial Security Analysis of the IEEE 802.1x standard (PDF)
Cisco Secure ACS v3.0 2002 Cisco Systems, Inc References 5-1

Ccna Security

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ccna Security

Загружено:

Авторское право:

Доступные форматы

Cisco Secure ACS v3.

0 2002 Cisco Systems, Inc 1

devices allow you to configure access lists (ACLs) to control access

routers, virtual private networks (VPNs), firewalls, dialup

Switch) is a Cisco Secure ACS

Firewall) enables you to pack commands sent to a Cisco IOS

ACL syntax and

ACL syntax and

devices for administration purposes

Software Release 11.2 or higher)

Access Point wireless devices

802.1 (RADIUS AAA support)

devices, Building Broadband Solutions Manager [BBSM], Cisco

Firewall, Cisco VPN 3000, Cisco VPN 5000, or third-party

Вам также может понравиться