Cisco Secure ACS 3.0 for Windows 2000/NT Servers User Guide
Cisco Secure ACS Internal Architecture
Download this chapter
Cisco Secure ACS Internal ArchitectureCisco Secure ACS Internal Architecture
give_us_feedback

Table of Contents

Cisco Secure ACS
Internal Architecture
Windows NT/2000 Environment Overview
 Cisco Secure ACS Web Server
 CSAdmin
 CSAuth
 CSDBSync
 CSLog
 CSMon
 CSTacacs and CSRadius

Cisco Secure ACS
Internal Architecture

Cisco Secure Access Control Server for Windows NT/2000 Servers Version 3.0 (Cisco Secure ACS) is designed to be modular and flexible to fit the needs of both simple and large networks. This chapter describes the Cisco Secure ACS architectural components. Cisco Secure ACS includes the following service modules:

  • CSAdmin
  • CSAuth
  • CSDBSync
  • CSLog
  • CSMon
  • CSTacacs
  • CSRadius

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. Each module can operate independently, but this limits functionality.

Windows NT/2000 Environment Overview

This section gives a brief overview of essential Windows NT/2000 concepts that relate to Cisco Secure ACS as a service of Windows NT/2000.

Windows NT/2000 Services

All Cisco Secure ACS services can be started, stopped, and restarted from the Windows NT/2000 Services window. The Cisco Secure ACS services are preceded by the letters CS. The sorting mechanism within Windows NT/2000 Services lists services alphabetically. All Cisco Secure ACS services should be displayed in one area of the list.

Windows NT/2000 Registry

The Windows NT/2000 Registry is a tree-like storage area for all application information.

Note   We recommend that you do not modify this file unless you have enough knowledge and experience to edit the file without destroying any existing data in the file. Always back up the Windows Registry before editing.

The Cisco Secure ACS information is located in the following Windows Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\CISCO

Cisco Secure ACS Web Server

Cisco Secure ACS has a built-in web server for support using a hypertext markup language (HTML) interface. This eliminates the necessity of installing another web server on the Windows NT/2000 server running Cisco Secure ACS. Because the Cisco Secure ACS web server uses port 2002, you can use another web server on the same machine to provide other web services.

CSAdmin

CSAdmin is the service for the internal web server. Cisco Secure ACS does not require the presence of a third-party web server; it is equipped with its own internal server. After Cisco Secure ACS is installed, you must configure it from its HTML interface. This means that CSAdmin must be running when you configure Cisco Secure ACS.

Although you can start and stop services from within the Cisco Secure ACS HTML interface, this does not include starting or stopping CSAdmin. If CSAdmin stops abnormally because of an external action, you cannot access Cisco Secure ACS from any machine other than the Windows NT/2000 server on which it is running. You can start or stop CSAdmin from the Windows NT/2000 Service menu.

CSAdmin is a multithreaded application that enables several administrators to access it at the same time. Therefore, CSAdmin is best for distributed, multiprocessor, and clustered environments.

Note   When you access CSAdmin from a browser, a new port is assigned for that session of the browser. This increases security and helps with session management. Therefore, when a firewall is used with authentication forwarding, you must exclude the server IP address:2002 port.

CSAuth

CSAuth is the authentication and authorization service. Its primary purpose is the authentication and authorization of requests to permit or deny access to users. CSAuth determines if access should be granted and defines the privileges for a particular user. CSAuth is the database manager.

Cisco Secure ACS can access several different databases for authentication. When a request for authentication arrives, Cisco Secure ACS checks the database that is configured for that user. If the user is unknown, Cisco Secure ACS checks the database(s) configured for unknown users.

Cisco Secure ACS can check the user database to authenticate first-time logins. If the username is not in the CiscoSecure user database, Cisco Secure ACS does not deny authentication yet; it forwards the request to the configured unknown user database to see if it can authenticate the user. If it can, authentication is granted.

Note   With unknown user databases such as Windows NT/2000 and Novell NDS, only PAP passwords are supported.

There are several user database options:

  • CiscoSecure user database—The first database option provides the fastest response time for authentication. Locating the username and checking the password against the local CiscoSecure user database is a single step. Because this occurs internally to Cisco Secure ACS, there is no delay while Cisco Secure ACS waits for a response from an external user database.
  • Windows NT/2000 user database—This option makes use of the work invested in the Windows NT/2000 user database. CSAuth passes the username and password to Windows NT/2000 for authentication. Windows NT/2000 then provides a response approving or denying validation. If the response is approval, CSAuth knows that the user should be allowed to authenticate.

If the response is denial and the username was submitted to Cisco Secure ACS in an unqualified format (that is, without a domain name preceding the username), CSAuth tries each Windows NT domain in the order they are configured in the Domain List list box in External User Databases: Windows NT/2000: Configure.

  • Novell NDS option—This option allows Cisco Secure ACS to use the Novell NDS service to authenticate users. Cisco Secure ACS supports one Tree, but the Tree can have multiple Containers and Contexts. To support this compatibility, the Novell requester must be installed on the same Windows NT/2000 server as Cisco Secure ACS.
  • Third-party token servers—Cisco Secure ACS supports several third-party token servers, such as RSA SecurID, SafeWord AXENT, and any hexadecimal X.909 token card such as CRYPTOCard. For some token servers, Cisco Secure ACS acts as a client to the token server. For others, it uses the token server's RADIUS interface for authentication requests. As with the Windows NT/2000 database, after the username is located in the CiscoSecure user database, CSAuth can check the selected token server to verify the username and token-card password. The token server then provides a response approving or denying validation. If the response is approval, CSAuth knows that authentication should be granted for the user.
  • Generic LDAP—Cisco Secure ACS supports authentication of users against records kept in a directory server through the Lightweight Directory Access Protocol (LDAP). Cisco Secure ACS interacts with the most popular directory servers, including Novell and Netscape. Both PAP and CHAP passwords can be used when authenticating against the LDAP database. Cisco Secure ACS logs these transactions and displays their results in the Reports & Activity section of the Cisco Secure ACS HTML interface.
  • ODBC—Cisco Secure ACS supports authentication via an Open Database Connectivity (ODBC)-compliant SQL database. ODBC is a standardized API that was first developed by Microsoft and is now used by most major database vendors. ODBC follows the specifications of the SQL Access Group. The benefit of ODBC in a web-based environment is easy access to data storage programs such as Microsoft Access and SQL Server.
  • UNIX passwords—Cisco Secure ACS includes a password import utility you can use to import passwords from a UNIX database. From the Cisco Secure ACS directory, type the following command:
CSUtil.exe -i filename

where filename is the name of a text file that contains the following line for each user:

ADD:username:UNIX:DES-encrypted password

For example:

ADD:roger:UNIX:kk/amz1NUJrlM

For more information on CSUtil.exe, see "Cisco Secure ACS Command-Line Database Utility."

When a user has authenticated using one of the described methods, Cisco Secure ACS obtains a set of authorizations from the user profile and the group to which the user is assigned. This information is stored with the username in the CiscoSecure user database. Some of the authorizations included are the services to which the user is entitled, such as IP over PPP, IP pools from which to draw an IP address, access lists, and password aging information. The authorizations, with the approval of authentication, are then passed to the CSTacacs or CSRadius modules to be forwarded to the requesting device.

CSDBSync

CSDBSync is the service used to synchronize the Cisco Secure ACS database with third-party RDBMS systems and is an alternative to using the ODBC dynamic link library (DLL). Starting with Version 2.4, CSDBSync synchronizes AAA client, AAA server, network device groups (NDGs) and Proxy Table information. For information on relational database management system (RDBMS) synchronization, see the "RDBMS Synchronization" section.

CSLog

CSLog is the service used to capture and place logging information. CSLog gathers data from the TACACS+ or RADIUS packet and CSAuth, and then manipulates the data to be placed into the comma-separated value (CSV) files. By default, the CSV files are created daily at midnight, but beginning with Version 2.3, the CSV files can be created daily, weekly, monthly, or by file size. The CSV files can be imported into spreadsheets that support this format.

CSV files are stored in the default subdirectory \Program Files\Cisco Secure ACS vx.x\Logs\. There are 10 subdirectories that contain CSV files:

  • AdminAudit—Contains the log files of administrator activity
  • Backup and Restore—Contains the log files of ACS system backup and restore activity
  • DBReplicate—Contains the log files of database replication activity
  • DbSync—Contains the log files of RDBMS synchronization activity
  • Failed Attempts—Contains the log files of failed authentication attempts information
  • RADIUS Accounting—Contains the log files of successful authentication and authorization activity for RADIUS users
  • Service Monitoring—Contains the log files of service activities
  • TACACS+ Accounting—Contains the log files of successful authentication and authorization activity for TACACS+ users
  • TACACS+ Administration—Contains the log files of TACACS+ administration events
  • VoIP Accounting—Contains the log files of successful authentication and authorization activity for Voice over IP (VoIP) users

CSMon

CSMon is a service provided as a part of Cisco Secure ACS that facilitates minimum down time in a remote access network environment. CSMon performs four basic activities:

  • Monitoring—Monitors the overall status of Cisco Secure ACS and the system on which it is running
  • Recording—Records and reports all exceptions to a special log file
  • Notification—Alerts the administrator to potential problems and real events regarding Cisco Secure ACS and records all such problems
  • Response—Attempts to automatically and intelligently fix detected problems

CSMon works for both TACACS+ and RADIUS and automatically detects which protocols are in use.

Note   CSMon is not intended as a replacement for system, network, or application management applications but is provided as an application-specific utility that can be used with other, more generic system management tools.

Monitoring

CSMon actively monitors three basic sets of system parameters:

  • Generic host system state—Windows NT/2000 itself provides several built-in utilities, such as the Event Log and Performance Monitor, to monitor overall system health, and there are several commercial applications available. CSMon monitors a small number of additional key system thresholds:
  • Available space on the system hard disk (the drive with the Windows NT/2000 directory).
  • Available space on Cisco Secure ACS installation drive
  • Processor utilization
  • Physical memory utilization

All events related to generic host system state are categorized as "warning events".

  • Application-specific performance—
    • Application viability—CSMon periodically performs a test login using a special built-in test account (the default period is one minute). Problems with this authentication can be used to determine if the ACS service has been compromised.
    • Application performance thresholds—CSMon monitors and records the latency of each test authentication request (the time it takes to receive a positive response). Each time this is performed, CSMon updates a variable containing the average response time value. Additionally, it records whether retries were necessary to achieve a successful response. By tracking the average time for each test authentication, CSMon can build up a "picture" of expected response time on the system in question. CSMon can therefore detect whether excess re-tries are required for each authentication or if response times for a single authentication exceed a percentage threshold over the average.
  • System resource consumption by Cisco Secure ACS—CSMon periodically monitors and records the usage by Cisco Secure ACS of a small set of key system resources and compares it against predetermined thresholds for indications of atypical behavior. The parameters monitored include the following:
  • Handle counts
  • Memory utilization
  • Processor utilization
  • Thread used
  • Failed log-on attempts

CSMon cooperates with CSAuth to keep a track of user accounts being disabled by exceeding their failed attempts count maximum. This feature is more oriented to security and user support than system viability. If configured, it provides immediate warning of "brute force" attacks by alerting the administrator to a large number of accounts becoming disabled. In addition, it facilitates a support help desk to anticipate problems with individual users gaining access.

Recording

CSMon records all exception events in logs that you can use to diagnose problems. CSMon puts the logs in two places, sends notification(s), and responds:

  • CSMon Log—Like the other Cisco Secure ACS components, CSMon maintains a CSV log of its own for diagnostic and error logging. Because this logging consumes relatively small amounts of resources, CSMon logging cannot be disabled.
  • Windows NT/2000 Event Log—In addition to the native CiscoSecure service logging, CSMon logs all messages to the Windows NT/2000 Event Log. Logging to the Windows NT/2000 Event Log is enabled by default but can be disabled.
  • Notification—CSMon can be configured to notify system administrators in the following cases:
  • Exception events (including the current state of Cisco Secure ACS)
  • Response
  • Outcome of the response (including the current state of Cisco Secure ACS)

The default notification method is simple mail-transfer protocol (SMTP) e-mail, but you can create scripts to enable other methods.

  • Response—CSMon detects exception events that affect the integrity of the service. Monitored events are listed above. These events are application-specific and hard-coded into Cisco Secure ACS. There are two types of responses:
    • Warning events—Service is maintained but some monitored threshold is breached
    • Failure events—One or more Cisco Secure ACS components stop providing service

CSMon responds to the event by logging the event, sending notifications (if configured) and, if the event is a failure, taking action. There are two types of actions:

  • Predefined actions—These actions are hard-coded into the program and are always carried out when a triggering event is detected. Because these actions are hard-coded, they are integral to the application and do not need to be configured. These actions include running the CSSupport utility, which captures most of the parameters dealing with the state of the system at the time of the event.

If the event is a warning event, it is logged and the administrator is notified. No further action is taken. CSMon also attempts to fix the cause of the failure after a sequence of re-tries and individual service restarts.

  • User Definable Actions—If the predefined actions built into CSMon do not fix the problem, CSMon can execute an external program or script. A number of sample scripts are provided to perform such functions as application restart, or you can create your own.

Sample Scripts

The following scripts are provided with CSMon:

  • RESTART_ALL_SERVICES.BAT—Restarts all Cisco Secure ACS services
  • RESTART_PROTOCOL_MODULES.BAT—Restarts just the protocol modules (CSTacacs+ and CSRadius)
  • REBOOT.BAT—Reboots the Cisco Secure ACS system

Configuration

You can configure the following items through CSAdmin:

  • Test login frequency—Defines the frequency with which CSMon attempts to perform its built-in test authentication. The default period is every 60 seconds. You can disable test authentications or set the frequency higher; however, the overhead generated by this feature is small and there is no real benefit from setting it higher.
  • Script to execute in the event of a failure event—These scripts are normally standard Windows NT/2000 .BAT batch command files, but you can use any executable in the Program Files\CiscoSecure ACS v2.6\CSMon\Scripts directory.
  • Windows NT/2000 Event Log enable/disable—By default, CSMon logs events to the Windows NT/2000 Event Log, but you can disable this function. CSV logging cannot be disabled.
  • Simple mail-transfer protocol (SMTP) server and administrator e-mail account details—To enable Cisco Secure ACS to send e-mail notification of error conditions, you must fill in these fields. You can enter any valid e-mail account (joe@company.com). The server details can be either a qualified host name or a valid IP address. CSMon does not verify delivery of notification e-mails, so make sure the information in these fields is correct. To disable notification, clear the check box.

CSTacacs and CSRadius

The CSTacacs and CSRadius services communicate between the CSAuth module and the access device that is requesting authentication and authorization services. For CSTacacs and CSRadius to work properly, the system must meet the following conditions:

  • CSTacacs and CSRadius services must be configured from CSAdmin.
  • CSTacacs and CSRadius services must communicate with access devices such as access servers, routers, switches, and firewalls.
  • The identical shared secret (key) must be configured both in Cisco Secure ACS and on the access device.
  • The access device IP address must be specified in Cisco Secure ACS.
  • The type of security protocol being used must be specified in Cisco Secure ACS.

CSTacacs is used to communicate with TACACS+ devices and CSRadius to communicate with RADIUS devices. Both services can run at the same time. When only one security protocol is used, only the applicable service needs to be running; however, the other service will not interfere with normal operation and does not need to be disabled. See "TACACS+ Attribute-Value Pairs" for more information on TACACS+ AV pairs, or "RADIUS Attributes" for more information on RADIUS+ AV pairs.