Table of Contents
CiscoSecure ACS 2.3 for Windows NT Architecture
Cisco Secure ACS 2.3 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
- CSMon
- CSTacacs
- CSRadius
- CSDBSync
- CSLog
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.
This section gives a brief overview of essential Windows NT concepts that relate to CiscoSecure ACS as a service of Windows NT.
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.
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
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 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 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. 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.
- 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 in "CiscoSecure ACS Command-Line Database Utility."
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.
CSMon is a service provided as a part of CiscoSecure ACS that facilitates minimum down time in a remote access network environment. CSMon performs 4 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.
CSMon actively monitors 3 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:
- Available space on the system hard disk (the drive with the Windows NT directory).
- Available space on CiscoSecure ACS installation drive
- Processor utilization
- Physical memory utilization
- 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:
- 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" 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.
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:
- Exception events (including the current state of CiscoSecure ACS)
- Response
- Outcome of the response (including the current state of CiscoSecure 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 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.
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
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.3\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.
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.
- A 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.
CSDBSync is the service used to archive important data from a single machine into a defined format that can be used to later restore the configuration after a system failure or the corruption of the user data, providing protection from partial or complete server loss.
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.3\Logs\. There are 9 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
Posted: Mon Feb 1 13:36:19 PST 1999
Copyright 1989-1999©Cisco Systems Inc.
