User Guide for Cisco Secure ACS for Windows Server 3.2
Internal Architecture

Table Of Contents

Internal Architecture

Windows Services

Windows Registry

CSAdmin

CSAuth

CSDBSync

CSLog

CSMon

Monitoring

Recording

Notification

Response

CSTacacs and CSRadius

Internal Architecture


This chapter describes the CiscoSecure ACS for WindowsServer architectural components. It includes the following topics:

Windows Services

Windows Registry

CSAdmin

CSAuth

CSDBSync

CSLog

CSMon

CSTacacs and CSRadius

Windows Services

CiscoSecure ACS is modular and flexible to fit the needs of both simple and large networks. This appendix describes the CiscoSecure ACS architectural components. CiscoSecure ACS includes the following service modules:

CSAdmin

CSAuth

CSDBSync

CSLog

CSMon

CSTacacs

CSRadius

You can stop or restart CiscoSecure ACS services as a group, except for CSAdmin, using the CiscoSecure ACS HTML interface. For more information, see Service Control.

Individual CiscoSecure ACS services can be started, stopped, and restarted from the Services window, available within the Windows Control Panel.

Windows Registry

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

HKEY_LOCAL_MACHINE\SOFTWARE\CISCO

Unless you are advised to do so by a Cisco representative, we strongly recommend that you do not modify Windows Registry settings pertaining to CiscoSecure ACS.


Warning Do not modify the Registry unless you have enough knowledge and experience to edit the file without destroying or corrupting crucial data.


CSAdmin

CSAdmin is the service that provides the web server for the CiscoSecure ACS HTML interface. After CiscoSecure ACS is installed, you must configure it from its HTML interface; therefore, CSAdmin must be running when you configure CiscoSecure ACS.

Because the CiscoSecure ACS web server uses port 2002 rather than the standard port 80 usually associated with HTTP traffic, you can use another web server on the same machine to provide other web services. We have not performed interoperability testing with other web servers, but unless a second web server is configured to use either port 2002 or one of the ports within the range specified in the HTTP Port Allocation feature, you should not encounter port conflicts for HTTP traffic. For more information about the HTTP Port Allocation feature, see Access Policy.


Note For more information about access to the HTML interface and network environments, see Network Environments and Administrative Sessions.


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

CSAdmin is multi-threaded, which enables several CiscoSecure ACS administrators to access it at the same time. Therefore, CSAdmin is well suited for distributed, multiprocessor environments.

CSAuth

CSAuth is the authentication and authorization service. It permits or denies access to users by processing authentication and authorization requests. CSAuth determines if access should be granted and defines the privileges for a particular user. CSAuth is the CiscoSecure ACS database manager.

To authenticate users, CiscoSecure ACS can use the internal user database or one of many external databases. 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. For more information about how CiscoSecure ACS handles authentication requests for unknown users, see Unknown User Processing.

For more information about the various database types supported by CiscoSecure ACS, see "User Databases"

When a user has authenticated, 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 synchronize the CiscoSecure ACS database with third-party relational database management system (RDBMS) systems. CSDBSync synchronizes AAA client, AAA server, network device groups (NDGs) and Proxy Table information with data from a table in an external relational database. For information on RDBMS Synchronization, see RDBMS Synchronization.

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. CSV files can be imported into spreadsheets that support this format.

For information about the logs generated by CiscoSecure ACS, see "Overview"

CSMon

CSMon is a service that helps minimize downtime in a remote access network environment. CSMon works for both TACACS+ and RADIUS and automatically detects which protocols are in use.

You can use the CiscoSecure ACS HTML interface to configure the CSMon service. The CiscoSecure ACS Active Service Management feature provides options for configuring CSMon behavior. For more information, see CiscoSecure ACS Active Service Management.


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.


CSMon performs four basic activities, outlined in the following topics:

Monitoring

Recording

Notification

Response

Monitoring

CSMon monitors the overall status of CiscoSecure ACS and the system on which it is running. CSMon actively monitors three basic sets of system parameters:

Generic host system state —CSMon monitors the following key system thresholds:

Available hard disk space

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 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 CiscoSecure ACS —CSMon periodically monitors and records the usage by CiscoSecure 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 track of user accounts being disabled by exceeding their failed attempts count maximum. This feature is more oriented to security and user support than to 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 helps support technicians anticipate problems with individual users gaining access.

Recording

CSMon records exception events in logs that you can use to diagnose problems.

CSMon Log —Like the other CiscoSecure ACS services, CSMon maintains a CSV log of its own for diagnostic recording and error logging. Because this logging consumes relatively small amounts of resources, CSMon logging cannot be disabled.

Windows Event Log —CSMon can log messages to the Windows Event Log. Logging to the Windows 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

Response

Outcome of the response

Notification for exception events and outcomes includes the current state of CiscoSecure ACS at the time of the message. 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. For information about monitored events, see Monitoring. These events are application-specific and hard-coded into CiscoSecure ACS. There are two 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 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.

Customer-Definable Actions —If the predefined actions built into CSMon do not fix the problem, CSMon can execute an external program or script.

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 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. For more information about TACACS+ AV pairs, see "TACACS+ Attribute-Value Pairs." For more information about RADIUS+ AV pairs, see "RADIUS Attributes."