Table of Contents

CiscoSecure  ACS  2.3 for Windows  NT Architecture

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.

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.

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

HKEY_LOCAL_MACHINE\SOFTWARE\CISCO

CiscoSecure  ACS 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.

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. 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.

• 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  2.3 for Windows  NT 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  2.3 for Windows  NT 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 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

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.

Monitoring

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.

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:
  
  
  • 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.
  
  

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.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.
  
  

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.
  
  
• 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

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

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