User Guide for Cisco Secure ACS Windows Server 3.1
Overview of Cisco Secure ACS
Download this chapter
Overview of Cisco Secure ACSOverview of Cisco Secure ACS
Download the complete book
User Guide for Cisco Secure ACS 3.1 for Windows ServerUser Guide for Cisco Secure ACS 3.1 for Windows Server (PDF - 6 MB)
give_us_feedback

Table of Contents

Overview of Cisco Secure ACS
The Cisco Secure ACS Paradigm
 Cisco Secure ACS Specifications
 AAA Server Functions and Concepts
 Cisco Secure ACS HTML Interface

Overview of Cisco Secure ACS

This chapter provides an overview of Cisco Secure Access Control Server (Cisco Secure ACS) for Windows Server version 3.1. It contains the following sections:

The Cisco Secure ACS Paradigm

Cisco Secure ACS provides authentication, authorization, and accounting (AAA—pronounced "triple A") services to network devices that function as AAA clients, such as a network access server, PIX Firewall, or router. The AAA client in Figure 1-1 represents any such device that provides AAA client functionality and uses one of the AAA protocols supported by Cisco Secure ACS.


Figure 1-1   A Simple AAA Scenario


Cisco Secure ACS centralizes access control and accounting, in addition to router and switch access management. With Cisco Secure ACS, network administrators can quickly administer accounts and globally change levels of service offerings for entire groups of users. Although the external user database shown in Figure 1-1 is optional, support for many popular user repository implementations enables companies to put to use the working knowledge gained from and the investment already made in building their corporate user repositories.

Cisco Secure ACS supports Cisco AAA clients such as the Cisco 2509, 2511, 3620, 3640, AS5200 and AS5300, AS5800, the Cisco PIX Firewall, Cisco Aironet Access Point wireless networking devices, Cisco VPN 3000 Concentrators, and Cisco VPN 5000 Concentrators. It also supports third-party devices that can be configured with the Terminal Access Controller Access Control System (TACACS+) or the Remote Access Dial-In User Service (RADIUS) protocol. Cisco Secure ACS treats all such devices as AAA clients. Cisco Secure ACS uses the TACACS+ and RADIUS protocols to provide AAA services that ensure a secure environment. For more information about support for TACACS+ and RADIUS in Cisco Secure ACS, see AAA ProtocolsTACACS+ and RADIUS.

Cisco Secure ACS Specifications

This section provides information about Cisco Secure ACS performance specifications and the Windows services that compose Cisco Secure ACS.

System Performance Specifications

The performance capabilities of Cisco Secure ACS are largely dependent upon the Windows server it is installed upon, your network topology and network management, the selection of user databases, and other factors. For example, Cisco Secure ACS can perform many more authentications per second if it is using its internal user database and running on a 2.1-GHz Pentium IV server on a 1 GB Ethernet backbone than it can if it is using an external user database and running on a 550-MHz Pentium III server on a 10 MB LAN.

For more information about the expected performance of Cisco Secure ACS in your network setting, contact your Cisco sales representative. The following items are general answers to common system performance questions. The performance of Cisco Secure ACS in your network depends on your specific environment and AAA requirements.

  • Maximum users supported by the CiscoSecure user database—There is no theoretical limit to the number of users the CiscoSecure user database can support. We have successfully tested Cisco Secure ACS with databases in excess of 100,000 users. The practical limit for a single Cisco Secure ACS authenticating against all its databases, internal and external, is 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—Authentication and authorization transactions per second is dependent on many factors, most of which are external to Cisco Secure ACS. For example, high network latency in communication with an external user database lowers the transactions per second that Cisco Secure ACS can perform.
  • Maximum number of AAA clients supported—Cisco Secure ACS can support AAA services for approximately 5000 AAA client configurations. This limitation is primarily a limitation of the Cisco Secure ACS HTML interface. Performance of the HTML interface degrades when Cisco Secure ACS has more than approximately 5000 AAA client configurations. However, a AAA client configuration in Cisco Secure ACS can represent more than one physical network device, provided that the network devices use the same AAA protocol and use the same shared secret. If you make use of this ability, the number of actual AAA clients supported approaches 20,000.

If your network has several thousand AAA clients, we recommend using multiple Cisco Secure ACSes and assigning no more than 5000 AAA clients to each Cisco Secure ACS. For example, if you have 20,000 AAA clients, you could use four Cisco Secure ACSes and divide the AAA client load among them so that no single Cisco Secure ACS manages more than 5000 AAA client configurations. If you use replication to propagate configuration data among Cisco Secure ACSes, limit replication of AAA client data to Cisco Secure ACSes that serve the same set of AAA clients.

Cisco Secure ACS Windows Services

Cisco Secure ACS operates as a set of Windows 2000 services and controls the authentication, authorization, and accounting of users accessing networks.

When you install Cisco Secure ACS on your server, the installation adds several Windows services. The services provide the core of Cisco Secure ACS functionality. For a full discussion of each service, see "Cisco Secure ACS Internal Architecture." The Cisco Secure ACS services on your Cisco Secure ACS server include the following:

  • CSAdmin—Provides the HTML interface for administration of Cisco Secure ACS.
  • CSAuth—Provides authentication services.
  • CSDBSync—Provides synchronization of the CiscoSecure user database with an external RDBMS application.
  • CSLog—Provides logging services, both for accounting and system activity.
  • CSMon—Provides monitoring, recording, and notification of Cisco Secure ACS performance, and includes automatic response to some scenarios.
  • CSTacacs—Provides communication between TACACS+ AAA clients and the CSAuth service.
  • CSRadius—Provides communication between RADIUS AAA clients and the CSAuth service.

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. For information about stopping and starting Cisco Secure ACS services, see Service Control.

AAA Server Functions and Concepts

Cisco Secure ACS is a AAA server, providing authentication, authorization, and accounting services to network devices that can act as AAA clients.

As a AAA server, Cisco Secure ACS incorporates many technologies to render AAA services to AAA clients. Understanding Cisco Secure ACS requires knowledge of many of these technologies. To address the most significant aspects, this section contains the following topics:

Cisco Secure ACS and the AAA Client

A AAA client is software running on a network device that enables the network device to defer authentication, authorization, and logging (accounting) of user sessions to a AAA server. AAA clients must be configured to direct all end-user client access requests to Cisco Secure ACS for authentication of users and authorization of service requests. Using the TACACS+ or RADIUS protocol, the AAA client sends authentication requests to Cisco Secure ACS. Cisco Secure ACS verifies the username and password using the user databases it is configured to query. Cisco Secure ACS returns a success or failure response to the AAA client, which permits or denies user access, based on the response it receives. When the user authenticates successfully, Cisco Secure ACS sends a set of authorization attributes to the AAA client. The AAA client then begins forwarding accounting information to Cisco Secure ACS.

When the user has successfully authenticated, a set of session attributes can be sent to the AAA client to provide additional security and control of privileges, otherwise known as authorization. These attributes might include the IP address pool, access control list, or type of connection (for example, IP, IPX, or Telnet). More recently, networking vendors are expanding the use of the attribute sets returned to cover an increasingly wider aspect of user session provisioning.

AAA Protocols—TACACS+ and RADIUS

Cisco Secure ACS can use both the TACACS+ and RADIUS AAA protocols. Table 1-1 compares the two protocols.

Table 1-1   TACACS+ and RADIUS Protocol Comparison

Point of Comparison TACACS+ RADIUS

Transmission Protocol

TCP—connection-oriented transport layer protocol, reliable full-duplex data transmission

UDP—connectionless transport layer protocol, datagram exchange without acknowledgments or guaranteed delivery

Ports Used

49

Authentication and Authorization: 1645 and 1812

Accounting: 1646 and 1813

Encryption

Full packet encryption

Encrypts only passwords up to 16 bytes

AAA Architecture

Separate control of each service: authentication, authorization, and accounting

Authentication and authorization combined as one service

Intended Purpose

Device management

User access control

TACACS+

Cisco Secure ACS conforms to the TACACS+ protocol as defined by Cisco Systems in draft 1.77. For more information, refer to the Cisco IOS software documentation or Cisco.com (http://www.cisco.com).

RADIUS

Cisco Secure ACS conforms to the RADIUS protocol as defined in draft April 1997 and in the following Requests for Comments (RFCs):

  • RFC 2138, Remote Authentication Dial In User Service
  • RFC 2139, RADIUS Accounting
  • RFC 2865
  • RFC 2866
  • RFC 2867
  • RFC 2868

The ports used for authentication and accounting have changed in RADIUS RFC documents. To support both the older and newer RFCs, Cisco Secure ACS accepts authentication requests on port 1645 and port 1812. For accounting, Cisco Secure ACS accepts accounting packets on port 1646 and 1813.

In addition to support for standard IETF RADIUS attributes, Cisco Secure ACS includes support for RADIUS vendor-specific attributes (VSAs). We have predefined the following RADIUS VSAs in Cisco Secure ACS:

  • Cisco IOS/PIX
  • Cisco VPN 3000
  • Cisco VPN 5000
  • Ascend
  • Juniper
  • Microsoft
  • Nortel

Cisco Secure ACS also supports up to 10 RADIUS VSAs that you define. After you define a new RADIUS VSA, you can use it as you would one of the RADIUS VSAs that come predefined in Cisco Secure ACS. In the Network Configuration section of the Cisco Secure ACS HTML interface, you can configure a AAA client to use a user-defined RADIUS VSA as its AAA protocol. In Interface Configuration, you can enable user-level and group-level attributes for user-defined RADIUS VSAs. In User Setup and Group Setup, you can configure the values for enabled attributes of a user-defined RADIUS VSA.

For more information about creating user-defined RADIUS VSAs, see Custom RADIUS Vendors and VSAs.

Authentication

Authentication determines user identity and verifies the information. Traditional authentication uses a name and a fixed password. More modern and secure methods use technologies such as CHAP and one-time passwords (OTPs). Cisco Secure ACS supports a variety of these authentication methods.

There is a fundamental implicit relationship between authentication and authorization. The more authorization privileges granted to a user, the stronger the authentication should be. Cisco Secure ACS supports this relationship by providing various methods of authentication.

Authentication Considerations

Username and password is the most popular, simplest, and least expensive method used for authentication. No special equipment is required. This is a popular method for service providers because of its easy application by the client. The disadvantage is that this information can be told to someone else, guessed, or captured. Simple unencrypted username and password is not considered a strong authentication mechanism but can be sufficient for low authorization or privilege levels such as Internet access.

To reduce the risk of password capturing on the network, use encryption. Client and server access control protocols such as TACACS+ and RADIUS encrypt passwords to prevent them from being captured within a network. However, TACACS+ and RADIUS operate only between the AAA client and the access control server. Before this point in the authentication process, unauthorized persons can obtain clear-text passwords, such as the communication between an end-user client dialing up over a phone line or an ISDN line terminating at a network access server, or over a Telnet session between an end-user client and the hosting device.

Network administrators who offer increased levels of security services, and corporations that want to lessen the chance of intruder access resulting from password capturing, can use an OTP. Cisco Secure ACS supports several types of OTP solutions, including PAP for Point-to-Point Protocol (PPP) remote-node login. Token cards are considered one of the strongest OTP authentication mechanisms.

Authentication and User Databases

Cisco Secure ACS supports a variety of user databases. It supports the CiscoSecure user database and several external user databases, including the following:

  • Windows NT/2000 User Database
  • Generic LDAP
  • Novell NetWare Directory Services (NDS)
  • Open Database Connectivity (ODBC)-compliant relational databases
  • CRYPTOCard token server
  • SafeWord token server
  • PassGo token server
  • RSA SecureID token server
  • ActivCard token server
  • Vasco token server

In addition to the token servers listed above, Cisco Secure ACS supports any token server that provides a RADIUS server interface. For more information about token server support, see Token Server User Databases.

Authentication Protocol-Database Compatibility

The various password protocols supported by Cisco Secure ACS for authentication are supported unevenly by the various databases supported by Cisco Secure ACS. Table 1-2 provides a reference of the password protocols supported by the various databases. For more information about the password protocols supported by Cisco Secure ACS, see Passwords.

Table 1-2   Authentication Protocol and User Database Compatibility

Database ASCII PAP CHAP ARAP MS- CHAP v.1 MS- CHAP v.2 LEAP EAP -MD5 EAP-TLS PEAP (EAP-GTC)

Cisco Secure ACS

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Windows SAM

Yes

Yes

No

No

Yes

Yes

Yes

No

No

Yes

Windows AD

Yes

Yes

No

No

Yes

Yes

Yes

No

Yes

Yes

LDAP

Yes

Yes

No

No

No

No

No

No

Yes

Yes

Novell NDS

Yes

Yes

No

No

No

No

No

No

No

Yes

ODBC

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Yes

LEAP Proxy RADIUS Server

Yes

Yes

No

No

Yes

Yes

Yes

No

No

No

RSA

Yes

Yes

No

No

No

No

No

No

No

Yes

ActivCard

Yes

Yes

No

No

No

No

No

No

No

Yes

CRYPTOCard

Yes

Yes

No

No

No

No

No

No

No

Yes

PassGo

Yes

Yes

No

No

No

No

No

No

No

Yes

Safeword

Yes

Yes

No

No

No

No

No

No

No

Yes

Vasco

Yes

Yes

No

No

No

No

No

No

No

Yes

RADIUS Token Server

Yes

Yes

No

No

No

No

No

No

No

Yes

Passwords

Cisco Secure ACS supports many common password protocols:

  • ASCII/PAP
  • CHAP
  • MS-CHAP
  • LEAP
  • EAP-MD5
  • EAP-TLS
  • PEAP(EAP-GTC)
  • ARAP

Passwords can be processed using these password authentication protocols based on the version and type of security control protocol used (for example, RADIUS or TACACS+) and the configuration of the AAA client and end-user client. The following sections outline the different conditions and functions of password handling.

In the case of token servers, Cisco Secure ACS acts as a client to the token server, using either its proprietary API or its RADIUS interface, depending on the token server. For more information, see About Token Servers and Cisco Secure ACS.

Different levels of security can be concurrently used with Cisco Secure ACS for different requirements. The basic user-to-network security level is PAP. Although it represents the unencrypted security, PAP does offer convenience and simplicity for the client. PAP allows authentication against the Windows NT/2000 database. With this configuration, users need to log in only once. CHAP allows a higher level of security for encrypting passwords when communicating from an end-user client to the AAA client. You can use CHAP with the CiscoSecure user database. ARAP support is included to support Apple clients.

Comparing PAP, CHAP, and ARAP

PAP, CHAP, and ARAP are authentication protocols used to encrypt passwords. However, each protocol provides a different level of security.

  • PAP—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.
  • CHAP—Uses 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 CiscoSecure user database for authentication, you can use either PAP or CHAP. CHAP does not work with the Windows NT/2000 user database.
  • ARAP—Uses 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.
MS-CHAP

Cisco Secure ACS supports Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) for user authentication. Differences between MS-CHAP and standard CHAP are the following:

  • The MS-CHAP Response packet is in a format compatible with Microsoft Windows NT/2000, Windows 95/98/ME/XP, and LAN Manager 2.x. The MS-CHAP format does not require the authenticator to store a clear-text or reversibly encrypted password.
  • MS-CHAP provides an authentication-retry mechanism controlled by the authenticator.
  • MS-CHAP provides additional failure codes in the Failure packet Message field.

For more information on MS-CHAP, refer to RFC draft-ietf-pppext-mschap-00.txt, RADIUS Attributes for MS-CHAP Support.

EAP Support

The Extensible Authentication Protocol (EAP), based on the IETF 802.1x, is an end-to-end framework that allows the creation of authentication types without the necessity of changing the implementation of the AAA clients. For more information about EAP, go to PPP Extensible Authentication Protocol (EAP) RFC 2284.

Cisco Secure ACS supports the following varieties of EAP:

  • EAP-MD5—An EAP protocol that does not support mutual authentication.
  • EAP-TLS—EAP incorporating Transport Layer Security. For more information, see EAP-TLS Deployment Guide for Wireless LAN Networks and About the EAP-TLS Protocol.
  • LEAP—A Network-EAP protocol that supports mutual authentication.
  • PEAP—Protected EAP, which is implemented with EAP-Generic Token Card (GTC). For more information, see About the PEAP Protocol.

The architecture of Cisco Secure ACS is extensible with regard to EAP; additional varieties of EAP will be supported as those protocols mature.

Basic Password Configurations

There are several basic password configurations:

Note   These configurations are all classed as inbound authentication.
  • Single password for ASCII/PAP/CHAP/MS-CHAP/ARAP—This is the most convenient method for both the administrator when setting up accounts and the user when obtaining authentication. However, because the CHAP password is the same as the PAP password, and the PAP password is transmitted in clear text during an ASCII/PAP login, there is the chance that the CHAP password can be compromised.
  • Separate passwords for ASCII/PAP and CHAP/MS-CHAP/ARAP—For a higher level of security, users can be given two separate passwords. If the ASCII/PAP password is compromised, the CHAP/ARAP password can remain secure.
  • External user database authentication—For authentication by an external user database, the user does not need a password stored in the CiscoSecure user database. Instead, Cisco Secure ACS records which external user database it should query to authenticate the user.
Advanced Password Configurations

Cisco Secure ACS supports the following advanced password configurations:

  • Inbound passwords—Passwords used by most Cisco Secure ACS users. These are supported by both the TACACS+ and RADIUS protocols. They are held internally to the CiscoSecure user database and are not usually given up to an external source if an outbound password has been configured.
  • Outbound passwords—The TACACS+ protocol supports outbound passwords that can be used, for example, when a AAA client has to be authenticated by another AAA client and end-user client. Passwords from the CiscoSecure user database are then sent back to the second AAA client and end-user client.
  • Token caching—When token caching is enabled, ISDN users can connect (for a limited time) a second B Channel using the same OTP entered during original authentication. For greater security, the B-Channel authentication request from the AAA client should include the OTP in the username value (for example, Fredpassword) while the password value contains an ASCII/PAP/ARAP password. The TACACS+ and RADIUS servers then verify that the token is still cached and validate the incoming password against either the single ASCII/PAP/ARAP or separate CHAP/ARAP password, depending on the configuration the user employs.

The TACACS+ SENDAUTH feature enables a AAA client to authenticate itself to another AAA client or an end-user client via outbound authentication. The outbound authentication can be PAP, CHAP, or ARAP. With outbound authentication, the Cisco Secure ACS password is given out. By default, ASCII/PAP or CHAP/ARAP password is used, depending on how this has been configured; however, we recommend that the separate SENDAUTH password be configured for the user so that Cisco Secure ACS inbound passwords are never compromised.

If you want to use outbound passwords and maintain the highest level of security, we recommend that you configure users in the CiscoSecure user database with an outbound password that is different from the inbound password.

Password Aging

With Cisco Secure ACS you can choose whether and how you want to employ password aging. Control for password aging may reside either in the CiscoSecure user database, or in a Windows NT/2000 user database. Each password aging mechanism differs as to requirements and setting configurations.

The password aging feature controlled by the CiscoSecure user database enables you force users to change their passwords under any of the following conditions:

  • After a specified number of days.
  • After a specified number of logins.
  • The first time a new user logs in.

For information on the requirements and configuration of the password aging feature controlled by the CiscoSecure user database, see Enabling Password Aging for the CiscoSecure User Database.

The Windows NT/2000-based password aging feature enables you to control the following password aging parameters:

  • Maximum password age in days.
  • Minimum password age in days.

The methods and functionality of Windows password aging differ according to whether you are using Windows NT or Windows 2000 and whether you employ Active Directory (AD) or Security Accounts Manager (SAM). For information on the requirements and configuration of the Windows-based password aging feature, see Enabling Password Aging for Users in Windows Databases.

User-Changeable Passwords

With Cisco Secure ACS, you can install a separate program that enables users to change their passwords by using a web-based utility. For more information about installing user-changeable passwords, see the Installation and User Guide for Cisco Secure ACS User-Changeable Passwords.

Other Authentication-Related Features

In addition to the authentication-related features discussed in this section, the following features are provided by Cisco Secure ACS:

Authorization

Authorization determines what a user is allowed to do. Cisco Secure ACS can send user profile policies to a AAA client to determine the network services the user can access. You can configure authorization to give different users and groups different levels of service. For example, standard dial-up users might not have the same access privileges as premium customers and users. You can also differentiate by levels of security, access times, and services.

The Cisco Secure ACS access restrictions feature enables you to permit or deny logins based on time-of-day and day-of-week. For example, you could create a group for temporary accounts that can be disabled on specified dates. This would make it possible for a service provider to offer a 30-day free trial. The same authorization could be used to create a temporary account for a consultant with login permission limited to Monday through Friday, 9 A.M. to 5 P.M.

You can restrict users to a service or combination of services such as PPP, AppleTalk Remote Access (ARA), Serial Line Internet Protocol (SLIP), or EXEC. After a service is selected, you can restrict Layer 2 and Layer 3 protocols, such as IP and IPX, and you can apply individual access lists. Access lists on a per-user or per-group basis can restrict users from reaching parts of the network where critical information is stored or prevent them from using certain services such as File Transfer Protocol (FTP) or Simple Network Management Protocol (SNMP).

One fast-growing service being offered by service providers and adopted by corporations is a service authorization for Virtual Private Dial-Up Networks (VPDNs). Cisco Secure ACS can provide information to the network device for a specific user to configure a secure tunnel through a public network such as the Internet. The information can be for the access server (such as the home gateway for that user) or for the home gateway router to validate the user at the customer premises. In either case, Cisco Secure ACS can be used for each end of the VPDN.

Max Sessions

Max Sessions is a useful feature for organizations that need to limit the number of concurrent sessions available to either a user or a group:

  • User Max Sessions—For example, an Internet service provider can limit each account holder to a single session.
  • Group Max Sessions—For example, an enterprise administrator can allow the remote access infrastructure to be shared equally among several departments and limit the maximum number of concurrent sessions for all users in any one department.

In addition to simple User and Group Max Sessions control, Cisco Secure ACS enables the administrator to specify a Group Max Sessions value and a group-based User Max Sessions value; that is, a User Max Sessions value based on the group membership of the user. For example, an administrator can allocate a Group Max Sessions value of 50 to the group "Sales" and also limit each member of the "Sales" group to 5 sessions each. This way no single member of a group account would be able to use more than 5 sessions at any one time, but the group could still have up to 50 active sessions.

For more information about the Max Sessions feature, see Setting Max Sessions for a User Group, and Setting Max Sessions Options for a User.

Dynamic Usage Quotas

Cisco Secure ACS enables you to define network usage quotas for users. Using quotas, you can limit the network access of each user in a group or of individual users. You define quotas by duration of sessions or the total number of sessions. Quotas can be either absolute or based on daily, weekly, or monthly periods. To grant access to users who have exceeded their quotas, you can reset session quota counters as needed.

To support time-based quotas, we recommend enabling accounting update packets on all AAA clients. If update packets are not enabled, the quota is updated only when the user logs off and the accounting stop packet is received from the AAA client. If the AAA client through which the user is accessing your network fails, the session information is not updated. In the case of multiple sessions, such as with ISDN, the quota would not be updated until all sessions terminate, which means that a second channel will be accepted even if the first channel has exhausted the quota allocated to the user.

For more information about usage quotas, see Setting Usage Quotas for a User Group, and Setting User Usage Quotas Options.

Shared Profile Components

Cisco Secure ACS provides a means for specifying authorization profile components that you can apply to multiple user groups and users. For example, you may have multiple user groups that have identical network access restrictions. Rather than configuring the network access restrictions several times, once per group, you can configure a network access restriction set in the Shared Profile Components section of the HTML interface, and then configure each group to use the network access restriction set you created.

For information about the types of shared profile components supported by Cisco Secure ACS, see About Shared Profile Components.

Support for Cisco Device-Management Applications

Cisco Secure ACS supports Cisco device-management applications, such as Management Center for PIX Firewall, by providing command authorization for network users who are using the management application to configure managed network devices. Support for command authorization for management application users is accomplished by using unique command authorization set types for each management application configured to use Cisco Secure ACS for authorization.

Cisco Secure ACS uses TACACS+ to communicate with management applications. For a management application to communicate with Cisco Secure ACS, the management application must be configured in Cisco Secure ACS as a AAA client that uses TACACS+. Also, you must provide the device-management application with a valid administrator name and password. When a management application initially communicates with Cisco Secure ACS, these requirements ensure the validity of the communication. For information about configuring a AAA client, see AAA Client Configuration. For information about administrator accounts, see Administrator Accounts.

Additionally, the administrator used by the management application must have the Create New Device Command Set Type privilege enabled. When a management application initially communicates with Cisco Secure ACS, it dictates to Cisco Secure ACS the creation of a device command set type, which appears in the Shared Profile Components section of the HTML interface. It also dictates a custom service to be authorized by TACACS+. The custom service appears on the TACACS+ (Cisco IOS) page in the Interface Configuration section of the HTML interface. For information about enabling TACACS+ services, see Protocol Configuration Options for TACACS+. For information about device command-authorization sets for management applications, see Command Authorization Sets.

After the management application has dictated the custom TACACS+ service and device command-authorization set type to Cisco Secure ACS, you can configure command-authorization sets for each role supported by the management application and apply those sets to user groups that contain network administrators or to individual users who are network administrators. For information about configuring a command-authorization set, see Command Authorization Sets Configuration. For information about applying a shared device command-authorization set to a user group, see Configuring Device-Management Command Authorization for a User Group. For information about applying a shared device command-authorization set to a user, see Configuring Device Management Command Authorization for a User.

Other Authorization-Related Features

In addition to the authorization-related features discussed in this section, the following features are provided by Cisco Secure ACS:

Accounting

AAA clients use the accounting functions provided by the RADIUS and TACACS+ protocols to communicate relevant data for each user session to the AAA server for recording. Cisco Secure ACS writes accounting records to a comma-separated value (CSV) log file or ODBC database, depending upon your configuration. You can easily import these logs into popular database and spreadsheet applications for billing, security audits, and report generation. Among the types of accounting logs you can generate are the following:

  • TACACS+ Accounting—Lists when sessions start and stop; records AAA client messages with username; provides caller line identification information; records the duration of each session.
  • RADIUS Accounting—Lists when sessions stop and start; records AAA client messages with username; provides caller line identification information; records the duration of each session.
  • Administrative Accounting—Lists commands entered on a network device with TACACS+ command authorization enabled.

For more information about Cisco Secure ACS logging capabilities, see "Working with Logging and Reports."

Other Accounting-Related Features

In addition to the accounting-related features discussed in this section, the following features are provided by Cisco Secure ACS:

  • Centralized logging, allowing several Cisco Secure ACS servers to forward their accounting data to a remote Cisco Secure ACS server (see Remote Logging).
  • Configurable supplementary user ID fields for capturing additional information in logs (see User Data Configuration Options).
  • Configurable logs, allowing you to capture as much information as needed (see Accounting Logs).

Administration

To configure, maintain, and protect its AAA functionality, Cisco Secure ACS provides a flexible administration scheme. You can perform nearly all administration of Cisco Secure ACS through its HTML interface.

You can access the HTML interface from computers other than the Cisco Secure ACS server. This enables remote administration of Cisco Secure ACS. For more information about the HTML interface, including steps for accessing the HTML interface, see Cisco Secure ACS HTML Interface.

HTTP Port Allocation for Remote Administrative Sessions

The HTTP port allocation feature allows you to configure the range of TCP ports used by Cisco Secure ACS for remote administrative HTTP sessions (that is, administrative sessions conducted by a browser running on a computer other than the Cisco Secure ACS server). Narrowing this range with the HTTP port allocation feature reduces the risk of unauthorized access to your network by a port open for administrative sessions.

We do not recommend that you administer Cisco Secure ACS through a firewall. Doing so requires that you configure the firewall to permit HTTP traffic over the range of HTTP administrative session ports that Cisco Secure ACS uses. While narrowing this range reduces the risk of unauthorized access, a greater risk of attack remains if you allow administration of Cisco Secure ACS from outside a firewall. A firewall configured to permit HTTP traffic over the Cisco Secure ACS administrative port range must also permit HTTP traffic through port 2002, because this is the port a remote web browser must access to initiate an administrative session.

Note   A broad HTTP port range could create a security risk. To prevent accidental discovery of an active administrative port by unauthorized users, keep the HTTP port range as narrow as possible. Cisco Secure ACS tracks the IP address associated with each remote administrative session. An unauthorized user would have to impersonate, or "spoof", the IP address of the legitimate remote host to make use of the active administrative session HTTP port.

For information about configuring the HTTP port allocation feature, see Access Policy.

Network Device Groups

With a network device group (NDG), you can view and administer a collection of AAA clients and AAA servers as a single logical group. To simplify administration, you can assign each group a convenient name that can be used to refer to all devices within that group. This creates two levels of network devices within Cisco Secure ACS—discrete devices such as an individual router, access server, AAA server, or PIX Firewall, and NDGs, which are named collections of AAA clients and AAA servers.

A network device can belong to only one NDG at a time.

Using NDGs enables an organization with a large number of AAA clients spread across a large geographical area to logically organize its environment within Cisco Secure ACS to reflect the physical setup. For example, all routers in Europe could belong to a group named Europe; all routers in the United States could belong to a US group; and so on. This would be especially convenient if the AAA clients in each region were administered along the same divisions. Alternatively, the environment could be organized by some other attribute such as divisions, departments, business functions, and so on.

You can assign a group of users to an NDG. For more information on NDGs, see Network Device Group Configuration.

Other Administration-Related Features

In addition to the administration-related features discussed in this section, the following features are provided by Cisco Secure ACS:

Cisco Secure ACS HTML Interface

This section discusses the Cisco Secure ACS HTML interface and provides procedures for using it. This section contains the following topics:

About the Cisco Secure ACS HTML Interface

After installing Cisco Secure ACS, you configure and administer it through the HTML interface. The HTML interface enables you to easily modify Cisco Secure ACS configuration from any connection on your LAN or WAN.

The Cisco Secure ACS HTML interface is designed to be viewed using a web browser. The design primarily uses HTML, along with some Java functions, to enhance ease of use. This design keeps the interface responsive and straightforward. The inclusion of Java requires that the browser used for administrative sessions supports Java. For a list of supported browsers, see the Release Notes. The latest revision to the Release Notes is posted on Cisco.com (http://www.cisco.com).

The HTML interface not only makes viewing and editing user and group information possible, it also enables you to restart services, add remote administrators, change AAA client information, back up the system, view reports from anywhere on the network, and more. The reports track connection activity, show which users are logged in, list failed authentication and authorization attempts, and show administrators' recent tasks.

HTML Interface Security

Accessing the HTML interface requires a valid administrator name and password. The Cisco Secure ACS Login page encrypts the administrator credentials before sending them to Cisco Secure ACS.

Administrative sessions timeout after a configurable length of idle time. Regardless, we recommend that you log out of the HTML interface after each session. For information about logging out of Cisco Secure ACS, see Logging Off the HTML Interface. For information about configuring the idle timeout feature, see Access Policy.

You can enable secure socket layer (SSL) for administrative sessions. This ensures that all communication between the web browser and Cisco Secure ACS is encrypted. Your browser must support SSL. You can enable this feature on the Access Policy Setup page in the Administration Control section. For more information about enabling SSL for HTML interface security, see Access Policy.

HTML Interface Layout

The HTML interface has three vertical partitions, known as frames:

  • Navigation Bar—The gray frame on the left of the browser window, the navigation bar contains the task buttons. Each button changes the configuration area (see below) to a unique section of the Cisco Secure ACS application, such as the User Setup section or the Interface Configuration section. This frame does not change; it always contains the following buttons:
    • User Setup—Add and edit user profiles.
    • Group Setup—Configure network services and protocols for groups of users.
    • Shared Profile Components—Add and edit network access restriction and command authorization sets, to be applied to users and groups.
    • Network Configuration—Add and edit network access devices and configure distributed systems.
    • System Configuration—Configure database information and accounting.
    • Interface Configuration—Display or hide product features and options to be configured.
    • Administration Control—Define and configure access policies.
    • External User Databases—Configure external databases for authentication.
    • Reports and Activity—Display accounting and logging information.
    • Online Documentation—View the User Guide for Cisco Secure ACS for Windows Server.
  • Configuration Area—The frame in the middle of the browser window, the configuration area displays web pages that belong to one of the sections represented by the buttons in the navigation bar. The configuration area is where you add, edit, or delete information. For example, you configure user information in this frame on the User Setup Edit page.
Note    Most pages have a Submit button at the bottom. Click Submit to confirm your changes. If you do not click Submit, changes are not saved.
  • Display Area—The frame on the right of the browser window, the display area shows one of the following options:
    • Online Help—Displays basic help about the page currently shown in the configuration area. This help does not offer in-depth information, rather it gives some basic information about what can be accomplished in the middle frame. For more detailed information, click Section Information at the bottom of the page to go to the applicable part of Online Documentation.
    • Reports or Lists—Displays lists or reports, including accounting reports. For example, in User Setup you can show all usernames that start with a specific letter. The list of usernames beginning with a specified letter is displayed in this section. The usernames are hyperlinks to the specific user configuration, so clicking the name enables you to edit that user.
    • System Messages—Displays messages after you click Submit if you have typed in incorrect or incomplete data. For example, if the information you entered in the Password box does not match the information in the Confirm Password box in the User Setup section, Cisco Secure ACS displays an error message here. The incorrect information remains in the configuration area so that you can retype and resubmit the information correctly.

Uniform Resource Locator for the HTML Interface

The HTML interface is available by web browser at one of the following uniform resource locators (URLs):

where IP address is the dotted decimal IP address of the computer running Cisco Secure ACS and hostname is the hostname of the computer running Cisco Secure ACS.

From the server on which Cisco Secure ACS is installed, you can also use the following URLs:

where hostname is the hostname of the computer running Cisco Secure ACS.

Network Environments and Remote Administrative Sessions

We recommend that remote administrative sessions take place without the use of an HTTP proxy server, without a firewall between the remote browser and Cisco Secure ACS, and without a NAT gateway between the remote browser and Cisco Secure ACS. Because these limitations are not always practical, we included the following topics regarding these remote administration scenarios:

Remote Administrative Sessions and HTTP Proxy

Cisco Secure ACS does not support HTTP proxy for remote administrative sessions. If the browser used for a remote administrative session is configured to use a proxy server, Cisco Secure ACS sees the administrative session originating from the IP address of the proxy server rather than from the actual address of the remote workstation. Remote administrative session tracking assumes each browser resides on a workstation with a unique IP.

Also, IP filtering of proxied administrative sessions has to be based on the IP address of the proxy server rather than the IP address of the workstation. This conflicts with administrative session communication that does use the actual IP address of the workstation. For more information about IP filtering of remote administrative sessions, see Access Policy.

For these reasons, we do not recommend performing administrative sessions using a web browser that is configured to use a proxy server. Administrative sessions using a proxy-enabled web browser is not tested. If your web browser is configured to use a proxy server, disable HTTP proxying when attempting remote Cisco Secure ACS administrative sessions.

Remote Administrative Sessions through Firewalls

In the case of firewalls that do not perform network address translation (NAT), remote administrative sessions conducted across the firewall can require additional configuration of Cisco Secure ACS and the firewall. This is because Cisco Secure ACS assigns a random HTTP port at the beginning of a remote administrative session.

To allow remote administrative sessions from browsers outside a firewall that protects Cisco Secure ACS, the firewall must permit HTTP traffic across the range of ports that Cisco Secure ACS is configured to use. You can control the HTTP port range using the HTTP port allocation feature. For more information about the HTTP port allocation feature, see HTTP Port Allocation for Remote Administrative Sessions.

While administering Cisco Secure ACS through a firewall that is not performing NAT is possible, we do not recommend that you administer Cisco Secure ACS through a firewall. For more information, see HTTP Port Allocation for Remote Administrative Sessions.

Remote Administrative Sessions through a NAT Gateway

We do not recommend conducting remote administrative sessions across a network device performing NAT. If the administrator runs a browser on a workstation behind a NAT gateway, Cisco Secure ACS receives the HTTP requests from the public IP address of the NAT device, which conflicts with the workstation private IP address, included in the content of the HTTP requests. Cisco Secure ACS does not permit this.

If Cisco Secure ACS is behind a NAT gateway and the URL used to access the HTML interface specifies the Windows 2000 server running Cisco Secure ACS by its hostname, remote administrative sessions operate correctly, provided that DNS is functioning correctly on your network or that workstations used to access the HTML interface have a hosts file entry for the Windows server that runs Cisco Secure ACS.

If the URL used to access the HTML interface specifies the Windows 2000 server running Cisco Secure ACS by its IP address, you could configure the gateway to forward all connections to port 2002 to Cisco Secure ACS, using the same port. Additionally, all the ports allowed using the HTTP port allocation feature would have to be similarly mapped. We have not tested such a configuration and do not recommend implementing it.

Accessing the HTML Interface

Remote administrative sessions always require that you log in using a valid administrator name and password, as configured in the Administration Control section. If the Allow automatic local login check box is cleared on the Sessions Policy Setup page in the Administration Control section, Cisco Secure ACS requires a valid administrator name and password for administrative sessions accessed from a browser on the Cisco Secure ACS server.

To access the HTML interface, follow these steps:

Step 1   Open a web browser. For a list of supported web browsers, see the Release Notes for the version of Cisco Secure ACS you are accessing. The latest revision to the Release Notes is posted on Cisco.com (http://www.cisco.com).

Step 2   In the Address or Location bar in the web browser, type the applicable URL. For a list of possible URLs, see Uniform Resource Locator for the HTML Interface.

Step 3   If the Cisco Secure ACS for Windows 2000/NT Login page appears, follow these steps:

a. In the Username box, type a valid Cisco Secure ACS administrator name.

b. In the Password box, type the password for the administrator name you specified.

c. Click Login.

Result: The Cisco Secure ACS for Windows 2000 initial page appears.




Logging Off the HTML Interface

When you are finished using the HTML interface, we recommend that you log off. While Cisco Secure ACS can timeout unused administrative sessions, logging off prevents unauthorized access by someone using the browser after you or by unauthorized persons using the HTTP port left open to support the administrative session.

To log off the Cisco Secure ACS HTML interface, click the Logoff button.

Note   The Logoff button appears in the upper right corner of the browser window, except on the initial page, where it appears in the upper left of the configuration area.

Online Help and Online Documentation

We provide two sources of information in the HTML interface:

  • Online Help—Contains basic information about the page shown in the configuration area.
  • Online Documentation—Contains the entire user guide.

Using Online Help

Online help is the default content in the display area. For every page that appears in the configuration area, there is a corresponding online help page. At the top of each online help page is a list of topics covered by that page.

To jump from the top of the online help page to a particular topic, click the topic name in the list at the top of the page.

There are three icons that appear on many pages in Cisco Secure ACS:

  • Question Mark—Many subsections of the pages in the configuration area contain an icon with a question mark. To jump to the applicable topic in an online help page, click the question mark icon.
  • Section Information—Many online help pages contain a Section Information icon at the bottom of the page. To view an applicable section of the online documentation, click the Section Information icon.
  • Back to Help—Wherever you find a online help page with a Section Information icon, the corresponding page in the configuration area contains a Back to Help icon. If you have accessed the online documentation by clicking a Section Information icon and want to view the online help page again, click the Back to Help icon.

Using the Online Documentation

The Cisco Secure ACS online documentation is the user guide for Cisco Secure ACS. The user guide provides information about the configuration, operation, and concepts of Cisco Secure ACS. The information presented in the online documentation is as current as the release date of the Cisco Secure ACS version you are using. For the most up-to-date documentation about Cisco Secure ACS, please go to http://www.cisco.com.

Tip Click Section Information on any online help page to view online documentation relevant to the section of the HTML interface you are using.

To access online documentation, follow these steps:

Step 1   In the Cisco Secure ACS HTML interface, click Online Documentation.

Tip To open the online documentation in a new browser window, right-click Online Documentation, and then click Open Link in New Window (for Microsoft Internet Explorer) or Open in New Window (for Netscape Navigator).

Result: The table of contents opens in the configuration area.

Step 2   If you want to select a topic from the table of contents, scroll through the table of contents and click the applicable topic.

Result: The online documentation for the topic selected appears in the display area.

Step 3   If you want to select a topic from the index, follow these steps:

a. Click [Index].

Result: The index appears in the display area.

b. Scroll through the index to find an entry for the topic you are researching.

Tip Use the lettered shortcut links to jump to a particular section of the index.

Result: Entries appear with numbered links after them. The numbered links lead to separate instances of the entry topic.

c. Click an instance number for the desired topic.

Result: The online documentation for the topic selected appears in the display area.

Step 4   If you want to print the online documentation, click in the display area, and then click Print in the navigation bar of your browser.