CiscoSecure ACS Architecture

Windows NT Environment Overview

Windows NT Services

Windows NT Registry

CiscoSecure ACS Web Server

CSAdmin

CSAuth

CSDBSync

CSLog

CSMon

CSTacacs and CSRadius

CiscoSecure ACS Architecture

Cisco Secure ACS 2.4 for Windows NT Server is designed to be modular and flexible to fit the needs of both simple and large networks. This chapter describes the CiscoSecure ACS architectural components. CiscoSecure 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 CiscoSecure ACS browser interface. Each module can operate independently, but this limits functionality.

Windows NT Environment Overview

This section gives a brief overview of essential Windows NT concepts that relate to CiscoSecure ACS as a service of Windows NT.

Windows NT Services

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

Windows NT Registry

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

Note Cisco recommends 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 CiscoSecure ACS information is located in the Windows Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\CISCO

CiscoSecureACS Web Server

CiscoSecure 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 server running CiscoSecure ACS. Because the CiscoSecure 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. CiscoSecure ACS does not require the presence of a third party web server; it is equipped with its own internal server. After CiscoSecure ACS is installed, you must configure it from its HTML interface. This means that CSAdmin must be running when you configure CiscoSecure ACS.

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

CSAdmin is a multithreaded application that lets several administrators 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.

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

CiscoSecure ACS can check the user database to authenticate first-time logins. If the username is not in the CiscoSecure user database, CiscoSecure 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, then authentication is granted.

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

There are several user database options:

CiscoSecure ACS user database---The first database option provides the fastest response time for authentication, and that is the same CiscoSecure user database that was being used to locate the username. Therefore, locating the username and password against the local CiscoSecure user database will be a single step.
Windows NT user database---The second database option leverages the work already done when the database of users was created in Windows NT. After the username is located in the CiscoSecure user database, CSAuth compares the username and password against the Windows NT user database. CSAuth then simulates a login to Windows NT using the username and password provided by the client. The Microsoft login API then provides a response approving or denying validation. If the response is approval, CSAuth knows that the user should be allowed to authenticate and exits the connection with the Windows NT login by logging off.
Novell NDS option---This option allows CiscoSecure ACS to use the Novell NDS service to authenticate users. CiscoSecure 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 server as CiscoSecure ACS.
Third-party token-card servers---CiscoSecure ACS supports several third-party token-card servers, such as Security Dynamics SecurID, SafeWord AXENT, and any hexadecimal X.909 token card such as CRYPTOCard. CiscoSecure ACS is configured as a client to the token-card server. As with the Windows NT database, after the username is located in the CiscoSecure user database, CSAuth can check the selected token-card server to verify the username and token-card password. The token-card server then provides a response approving or denying validation. If the response is approval, CSAuth knows that authentication should be granted for the user.

: In the case of using a token-card server, CiscoSecure ACS manages communication, via TACACS+ or RADIUS, with the device where the client is requesting entry. Although token servers might offer some support of TACACS+ or RADIUS, that function is not being used, because CiscoSecure ACS maintains that communication. Therefore, TACACS+ or RADIUS should be disabled at the token-card server.

DS (LDAP)---CiscoSecure ACS supports authentication of users against records kept in a directory server through the Lightweight Directory Access Protocol (LDAP). CiscoSecure interacts with the most popular directory servers, including Novell and Netscape. Both PAP and CHAP passwords can be used when authenticating against the Directory Server. CiscoSecure ACS logs these transactions and displays their results in the Reports & Activity section of the CiscoSecure ACS HTML interface.
MCIS LDAP---CiscoSecure ACS supports the use of the Microsoft Commercial Internet System Lightweight Directory Access Protocol (MCIS LDAP). This option allows CiscoSecure ACS to use MCIS to authenticate users. As with the Windows NT database, after the username is located in the CiscoSecure user database, CSAuth can check the MCIS server to verify the username and password. The MCIS server then provides a response approving or denying validation. If the response is approval, CSAuth knows that authentication should be granted for the user.
ODBC---CiscoSecure 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---CiscoSecure ACS includes a password import utility you can use to import passwords from a UNIX database. From the CiscoSecure ACS directory, enter the following command:

: csutil -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, see the "Importing User Information from a Text File" section.

When a user has authenticated using one of the described methods, CiscoSecure 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 used to synchronize the CiscoSecure ACS database with third-party RDBMS systems and is an alternative to using the ODBC dynamic link library (DLL). Release 2.4 provides enhancements to CSDBSync that allow synchronization of NAS, 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, 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 Release 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\
CiscoSecure ACS v2.4\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 CiscoSecure ACS that facilitates minimum down time in a remote access network environment. CSMon performs four basic activities:

Monitoring---Monitors the overall status of CiscoSecure 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 CiscoSecure ACS and records all such problems.
Response---Attempts to automatically and intelligently fix detected problems.

CSMon works for both TACACS+ and RADIUS and will automatically detect 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 itself provides a number of 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:

: All events of this class 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 retries are required for each authentication or if response times for a single authentication exceed a percentage threshold over the normal average.
System resource consumption by CiscoSecure ACS---CSMon periodically monitors and records the usage by CiscoSecure ACS of a small set of key system resources and compares them against predetermined thresholds for indications of atypical behavior. The parameters monitored include:

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 CiscoSecure 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 Event Log---In addition to the native CiscoSecure service logging, CSMon logs all messages to the Windows NT Event Log. Logging to the Windows NT Event Log is enabled by default but can be disabled.
Notification---CSMon can be configured to notify system administrators in the following cases:

: 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 CiscoSecure ACS. There are 2 types of responses:
- Warning events---Service is maintained but some monitored threshold is breached
- Failure events---One or more CiscoSecure 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 2 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 retries 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 CiscoSecure ACS services
RESTART_PROTOCOL_MODULES.BAT---Restarts just the protocol modules (CSTacacs+ and CSRadius)
REBOOT.BAT---Reboots the CiscoSecure 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 very small and there is no real benefit from doing setting it higher.
Script to execute in the event of a failure event---These scripts are normally standard Windows NT .BAT batch command files, but you can use any executable in the Program Files\CiscoSecure ACS v2.4\CSMon\Scripts directory.
Windows NT Event Log enable/disable---By default, CSMon logs events to the Windows NT 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 allow CiscoSecure 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 the 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 CiscoSecure ACS and on the access device.
The access device IP address must be specified in CiscoSecure ACS.
The type of security protocol being used must be specified in CiscoSecure 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 Attribute-Value Pairs," for more information on RADIUS+ AV pairs.

Table of Contents

CiscoSecure ACS Architecture