Table of Contents

Establishing Cisco Secure ACS System Configuration

This chapter addresses the features found in the System Configuration section of Cisco Secure Access Control Server (Cisco Secure ACS) for Windows Server version 3.1.

It contains the following topics:

Service Control

Cisco Secure ACS uses several Windows services. The Service Control page provides basic status information about the services, and enables you to configure the service log files and to stop or restart the services. For more information about Cisco Secure ACS services, see "Cisco Secure ACS Internal Architecture."

This section contains detailed procedural information regarding the following activities:

You can also configure Cisco Secure ACS service logs. For more information, see Configuring Service Logs.

Determining the Status of Cisco Secure ACS Services

You can determine whether Cisco Secure ACS services are running or stopped by accessing the Service Control page.

To determine the status of Cisco Secure ACS services, follow these steps:

Step 2   Click Service Control.

Result: The status of the services appears in the CiscoSecure ACS on hostname table, where hostname is the name of the Cisco Secure ACS.

Stopping, Starting, or Restarting Services

You can stop, start, or restart Cisco Secure ACS services as needed. This achieves the same result as starting and stopping Cisco Secure ACS services from within Windows Control panel. This procedure stops, starts, or restarts the Cisco Secure ACS services except for CSAdmin, which is responsible for the HTML interface.

Note   If the CSAdmin service needs to be restarted, you can do so using the Control Panel Services applet; however, it is best to allow Cisco Secure ACS to handle the services because there are dependencies in the order in which the services are started.

To stop, start, or restart Cisco Secure ACS services, follow these steps:

Step 2   Click Service Control.

Result: The status of the services appears in the CiscoSecure ACS on hostname table, where hostname is the name of the Cisco Secure ACS.

If the services are running, the Restart and Stop buttons appear at the bottom of the page.

If the services are stopped, the Start button appears at the bottom of the page.

Step 3   Click Stop, Start, or Restart, as applicable.

Result: The status of Cisco Secure ACS services changes to the state appropriate to the button you clicked.

Logging

You can configure Cisco Secure ACS to generate logs for administrative and accounting events, depending on the protocols and options you have enabled. For more information, including configuration steps, see "Working with Logging and Reports."

Date Format Control

Cisco Secure ACS allows for one of two possible date formats in its logs, reports, and administrative interface. You can choose either a month/day/year format or a day/month/year format.

Setting the Date Format

Note   If you have reports that were generated before you changed the date format, be sure to move or rename them to avoid conflicts. For example, if you are using the month/day/year format, Cisco Secure ACS assigns the name 2001-07-12.csv to a report generated on July 12, 2001. If you subsequently change to the day/month/year format, on December 7, 2001, Cisco Secure ACS creates a file also named 2001-07-12.csv and overwrites the existing file.

To set the date format, follow these steps:

Step 2   Click Date Format Control.

Result: Cisco Secure ACS displays the Date Format Selection table.

Step 3   Select a date format option.

Step 4   Click Submit & Restart.

Result: Cisco Secure ACS restarts its services and implements the date format you selected.

---

Note    For the new date format to be seen in the HTML interface reports, you must restart the connection to the Cisco Secure ACS. Click the Logoff button (a button with an X) in the upper-right corner of the browser window.

---

Local Password Management

You use the Local Password Management page to configure settings that apply to managing passwords stored in the CiscoSecure user database. It contains the following three sections:

---

Note    Password validation options apply only to user passwords stored in the CiscoSecure user database. They do not apply to passwords in user records kept in external user databases nor do they apply to enable or admin passwords for Cisco IOS network devices.

---

The password validation options are listed below:

The remote change password options are listed below:

This feature depends upon having the CiscoSecure Database Replication feature configured properly; however, replication scheduling does not apply to propagation of changed password information. Cisco Secure ACS sends changed password information immediately, regardless of replication scheduling.

Changed password information is replicated only to Cisco Secure ACSes that are properly configured to receive replication data from this Cisco Secure ACS. The automatically triggered cascade setting for the CiscoSecure Database Replication feature does not cause Cisco Secure ACSes that receive changed password information to send it to their replication partners.

For more information about CiscoSecure Database Replication, see CiscoSecure Database Replication.

The log file management options for the User Password Changes Log are listed below:

Configuring Local Password Management

To configure password validation options, follow these steps:

Step 2   Click Local Password Management.

Result: The Local Password Management page appears.

Step 3   Under Password Validation Options, follow these steps:

Step 4   Under Remote Change Password, follow these steps:

Tip The Cisco Secure ACSes that receive the changed password information list below the "Upon remote user password change, immediately propagate the change to selected replication partners" check box.

Step 5   If you want Cisco Secure ACS to generate a new User Password Changes log file at a regular interval, select one of the following options:

Step 6   If you want Cisco Secure ACS to generate a new User Password Changes log file when the current file reaches a specific size, select the When size is greater than X KB option and type the file size threshold, in kilobytes, in the X box.

Step 7   If you want to manage which User Password Changes log files Cisco Secure ACS keeps, follow these steps:

Step 8   Click Submit.

Result: Cisco Secure ACS restarts its services and implements the settings you specified.

CiscoSecure Database Replication

This section provides information about the CiscoSecure Database Replication feature, including procedures for implementing this feature and configuring the Cisco Secure ACSes involved. This section contains the following topics:

About CiscoSecure Database Replication

Database replication creates mirror systems of Cisco Secure ACSes by duplicating parts of the primary Cisco Secure ACS setup to one or more secondary Cisco Secure ACSes. You can configure your AAA clients to use these secondary Cisco Secure ACSes if the primary Cisco Secure ACS fails or is unreachable. With a secondary Cisco Secure ACS whose CiscoSecure database is a replica of the CiscoSecure database on the primary Cisco Secure ACS, if the primary Cisco Secure ACS goes out of service, incoming requests are authenticated without network downtime, provided that your AAA clients are configured to failover to the secondary Cisco Secure ACS.

Database replication allows you to do the following:

The following items cannot be replicated:

With regard to database replication, we make the following distinctions about Cisco Secure ACSes:

A Cisco Secure ACS can be both a primary Cisco Secure ACS and a secondary Cisco Secure ACS, provided that it is not configured to be a secondary Cisco Secure ACS to a Cisco Secure ACS for which it performs as a primary Cisco Secure ACS.

Note   Bidirectional replication, wherein an Cisco Secure ACS both sends database components to and receives database components from the same remote Cisco Secure ACS, is not supported. Replication fails if an Cisco Secure ACS is configured to replicate to and from the same Cisco Secure ACS.

Note   All Cisco Secure ACSes involved in replication must run the same release of the Cisco Secure ACS software. For example, if the primary Cisco Secure ACS is running Cisco Secure ACS version 3.0, all secondary Cisco Secure ACSes should be running Cisco Secure ACS version 3.0. Because patch releases can introduce significant changes to the CiscoSecure database, we strongly recommend that Cisco Secure ACSes involved in replication use the same patch level, too.

Replication Process

This topic describes the process of database replication, including the interaction between a primary Cisco Secure ACS and each of its secondary Cisco Secure ACSes.

1. The database replication process begins when the primary Cisco Secure ACS contacts the secondary Cisco Secure ACS. In this initial connection, the following four events occur:

---

Note    On the secondary Cisco Secure ACS, the AAA Servers table entry for the primary Cisco Secure ACS must have the same shared secret that the primary Cisco Secure ACS has for itself in its own AAA Servers table entry. The secondary Cisco Secure ACS's shared secret is irrelevant.

---

2. After the primary Cisco Secure ACS has determined which components to send to the secondary Cisco Secure ACS, the replication process continues on the primary Cisco Secure ACS as follows:

3. After the preceding events on the primary Cisco Secure ACS, the database replication process continues on the secondary Cisco Secure ACS as follows:

Cisco Secure ACS can act as both a primary Cisco Secure ACS and a secondary Cisco Secure ACS. Figure 8-1 shows a cascading replication scenario. Server 1 acts only as a primary Cisco Secure ACS, replicating to servers 2 and 3, which act as secondary Cisco Secure ACSes. After replication from server 1 to server 2 has completed, server 2 acts as a primary Cisco Secure ACS while replicating to servers 4 and 5. Similarly, server 3 acts as a primary Cisco Secure ACS while replicating to servers 6 and 7.

If server 2 were configured to replicate to server 1 in addition to receiving replication from server 1, replication to server 2 would fail. Cisco Secure ACS cannot support such a configuration, known as bidirectional replication. To safeguard against this, a secondary Cisco Secure ACS aborts replication when its primary Cisco Secure ACS appears on its Replication list.

Replication Frequency

The frequency with which your Cisco Secure ACSes replicate can have important implications for overall AAA performance. With shorter replication frequencies, a secondary Cisco Secure ACS is more up-to-date with the primary Cisco Secure ACS. This allows for a more current secondary Cisco Secure ACS if the primary Cisco Secure ACS fails.

There is a cost to having frequent replications. The more frequent the replication, the higher the load on a multi-server Cisco Secure ACS architecture and on your network environment. If you schedule frequent replication, network traffic is much higher. Also, processing load on the replicating systems is increased. Replication consumes system resources and briefly interrupts authentication; thus the more often replication is repeated, the greater the impact on the AAA performance of the Cisco Secure ACS.

This issue is more apparent with databases that are large or that frequently change. Database replication is a non-incremental, destructive backup. In other words, it completely replaces the database and configuration on the secondary Cisco Secure ACS every time it runs. Therefore, a large database results in substantial amounts of data being transferred, and the processing overhead can also be large.

Important Implementation Considerations

You should consider several important points when you implement the CiscoSecure Database Replication feature:

Database Replication Versus Database Backup

Do not confuse database replication with system backup. Database replication does not replace System Backup. While both features protect against partial or complete server loss, each feature addresses the issue in a different way.

System Backup archives data into a format that you can later use to restore the configuration if the system fails or the data becomes corrupted. The backup data is stored on the local hard drive and can be copied and removed from the system for long-term storage. You can store several generations of database backup files.

CiscoSecure Database Replication enables you to copy various components of the CiscoSecure database to other Cisco Secure ACSes. This can help you plan a failover AAA architecture and can reduce the complexity of your configuration and maintenance tasks. While it is unlikely, it is possible that CiscoSecure Database Replication can propagate a corrupted database to the Cisco Secure ACSes that generate your backup files.

Caution   Because the possibility of replicating a corrupted database always exists, we strongly recommend that you implement a backup plan, especially in mission-critical environments. For more information about backing up Cisco Secure ACS or the CiscoSecure database, see Cisco Secure ACS Backup, and "Cisco Secure ACS Command-Line Database Utility."

Database Replication Logging

Cisco Secure ACS logs all replication events—whether successful or not—in two files:

To view the Windows Event Log, use the Windows administration utilities. You can view recent reports in the Reports and Activity section of Cisco Secure ACS.

For more information about Cisco Secure ACS reports, see "Working with Logging and Reports."

Replication Options

The Cisco Secure ACS HTML interface provides three sets of options for configuring CiscoSecure Database Replication:

Replication Components Options

You can specify both the CiscoSecure database components that a Cisco Secure ACS sends as a primary Cisco Secure ACS and the components that it receives as a secondary Cisco Secure ACS.

Note   The CiscoSecure database components received by a secondary Cisco Secure ACS overwrite the CiscoSecure database components on the secondary Cisco Secure ACS. Any information unique to the overwritten database component is lost.

The Replication Components table on the CiscoSecure Database Replication page presents the options that control which components are replicated; these options are as follows:

If mirroring the entire database with a secondary Cisco Secure ACS might send confidential information, such as the Proxy Distribution Table, you can configure the primary Cisco Secure ACS to send only a specific category of database information.

Outbound Replication Options

In the Outbound Replication table on the CiscoSecure Database Replication page, you can schedule outbound replication and you can specify the secondary Cisco Secure ACSes for this primary Cisco Secure ACS.

---

Note    The items in the AAA Server and Replication lists reflect the AAA servers configured in the AAA Servers table in Network Configuration. To make a particular Cisco Secure ACS available as a secondary Cisco Secure ACS, you must first add that Cisco Secure ACS to the AAA Servers table of the primary Cisco Secure ACS.

---

Inbound Replication Options

You can specify the primary Cisco Secure ACSes for which a secondary Cisco Secure ACS. This option appears in the Inbound Replication table on the CiscoSecure Database Replication page.

The Accept replication from list controls which Cisco Secure ACSes the current Cisco Secure ACS does accept replicated components from. The list contains the following options:

For more information about the AAA Servers table in Network Configuration, see AAA Server Configuration.

Implementing Primary and Secondary Replication Setups on Cisco Secure ACSes

If you implement a replication scheme that uses cascading replication, the Cisco Secure ACS configured to replicate only when it has received replicated components from another Cisco Secure ACS acts both as a primary Cisco Secure ACS and as a secondary Cisco Secure ACS. First, it acts as a secondary Cisco Secure ACS while it receives replicated components, and then it acts as a primary Cisco Secure ACS while it replicates components to other Cisco Secure ACS servers. For an illustration of cascade replication, see Figure 8-1.

To implement primary and secondary replication setups on Cisco Secure ACSes, follow these steps:

For more information about adding entries to the AAA Servers table, see AAA Server Configuration.

Step 2   On the primary Cisco Secure ACS, follow these steps:

For more information about adding entries to the AAA Servers table, see AAA Server Configuration.

Configuring a Secondary Cisco Secure ACS

Note   If this feature does not appear, click Interface Configuration, click Advanced Options, and select the CiscoSecure ACS Database Replication check box. Also, verify that the Distributed System Settings check box is selected; if not, select the Distributed System Settings check box.

The CiscoSecure Database Replication feature requires that you configure specific Cisco Secure ACSes to act as secondary Cisco Secure ACSes. The components that a secondary Cisco Secure ACS is to receive must be explicitly specified, as must be its primary Cisco Secure ACS.

Replication is always initiated by the primary Cisco Secure ACS. For more information about sending replication components, see Replicating Immediately, or Scheduling Replication.

Caution   The CiscoSecure database components received by a secondary Cisco Secure ACS overwrite the CiscoSecure database components on the secondary Cisco Secure ACS. Any information unique to the overwritten database component is lost.

Before You Begin

Ensure correct configuration of the AAA Servers table in the secondary Cisco Secure ACS. This secondary Cisco Secure ACS must have an entry in its AAA Servers table for each of its primary Cisco Secure ACSes. Also, the AAA Servers table entry for each primary Cisco Secure ACS must have the same shared secret that the primary Cisco Secure ACS has for its own entry in its AAA Servers table. For more information about the AAA Servers table, see AAA Server Configuration.

To configure a Cisco Secure ACS to be a secondary Cisco Secure ACS, follow these steps:

Step 2   In the navigation bar, click System Configuration.

Step 3   Click CiscoSecure Database Replication.

Result: The Database Replication Setup page appears.

Step 4   In the Replication Components table, select the Receive check box for each database component to be received from a primary Cisco Secure ACS.

For more information about replication components, see Replication Components Options.

Step 5   Make sure that no Cisco Secure ACS that the secondary Cisco Secure ACS is to receive replicated components from is included in the Replication list. If so, select the primary Cisco Secure ACS in the Replication list and click the <-- (left arrow) to move it to the AAA Servers list.

---

Note    Cisco Secure ACS does not support bidirectional database replication. A secondary Cisco Secure ACS receiving replicated components verifies that the primary Cisco Secure ACS is not on its Replication list. If not, the secondary Cisco Secure ACS accepts the replicated components. If so, it aborts replication.

---

Step 6   If the secondary Cisco Secure ACS is to receive replication components from only one primary Cisco Secure ACS, from the Accept replication from list, select the other Cisco Secure ACS name.

The primary Cisco Secure ACSes available in the Accept replication from list are determined by the AAA Servers table in the Network Configuration section. For more information about the AAA Servers table, see AAA Server Configuration.

---

Note    On the primary Cisco Secure ACS and all secondary Cisco Secure ACSes, the AAA Servers table entries for the primary Cisco Secure ACS must have identical shared secrets.

---

Step 7   If the secondary Cisco Secure ACS is to receive replication components from more than one primary Cisco Secure ACS, from the Accept replication from list, select Any Known CiscoSecure ACS Server.

The Any Known CiscoSecure ACS Server option is limited to the Cisco Secure ACSes listed in the AAA Servers table in Network Configuration.

---

Note    For each primary Cisco Secure ACS for this secondary Cisco Secure ACS, on both the primary and secondary Cisco Secure ACS, the AAA Servers table entries for the primary Cisco Secure ACS must have identical shared secrets.

---

Step 8   Click Submit.

Result: Cisco Secure ACS saves the replication configuration, and at the frequency or times you specified, Cisco Secure ACS begins accepting the replicated components from the other Cisco Secure ACSes you specified.

Replicating Immediately

You can manually start database replication.

Note   Replication cannot occur until you have configured at least one secondary Cisco Secure ACS. For more information about configuring a secondary Cisco Secure ACS, see Configuring a Secondary Cisco Secure ACS.

Before You Begin

For each secondary Cisco Secure ACS that this Cisco Secure ACS is to send replicated components to, ensure that you have completed the steps in Configuring a Secondary Cisco Secure ACS.

Ensure correct configuration of the AAA Servers table in the primary Cisco Secure ACS. This primary Cisco Secure ACS must have an accurately configured entry in its AAA Servers table for each of its secondary Cisco Secure ACSes. For more information about the AAA Servers table, see AAA Server Configuration.

To initiate database replication immediately, follow these steps:

Step 2   In the navigation bar, click System Configuration.

Step 3   Click CiscoSecure Database Replication.

---

Note    If this feature does not appear, click Interface Configuration, click Advanced Options, and select the CiscoSecure ACS Database Replication check box. Also, verify that the Distributed System Settings check box is selected; if not, select the Distributed System Settings check box.

---

Result: The Database Replication Setup page appears.

Step 4   For each CiscoSecure database component you want to replicate to a secondary Cisco Secure ACS, under Replication Components, select the corresponding Send check box.

Step 5   For each secondary Cisco Secure ACS that you want the primary Cisco Secure ACS server to replicate its select components to, select the secondary Cisco Secure ACS server from the AAA Servers list, and then click --> (right arrow button).

Tip If you want to remove a secondary Cisco Secure ACSes from the Replication list, select the secondary Cisco Secure ACS in the Replication list, and then click <-- (left arrow button).

---

Note    Cisco Secure ACS does not support bidirectional database replication. A secondary Cisco Secure ACS receiving replicated components verifies that the primary Cisco Secure ACS is not on its Replication list. If not, the secondary Cisco Secure ACS accepts the replicated components. If so, it rejects the components.

---

Step 6   At the bottom of the browser window, click Replicate Now.

Result: Cisco Secure ACS saves the replication configuration. Cisco Secure ACS immediately begins sending replicated database components to the secondary Cisco Secure ACSes you specified.

Scheduling Replication

You can schedule when a primary Cisco Secure ACS sends its replicated database components to a secondary Cisco Secure ACS. For more information about replication scheduling options, see Outbound Replication Options.

Note   Replication cannot occur until the secondary Cisco Secure ACSes are configured properly. For more information, see Configuring a Secondary Cisco Secure ACS.

Before You Begin

For each secondary Cisco Secure ACS of this primary Cisco Secure ACS, ensure that you have completed the steps in Configuring a Secondary Cisco Secure ACS.

Ensure correct configuration of the AAA Servers table of this primary Cisco Secure ACS. For each secondary Cisco Secure ACS of this primary Cisco Secure ACS, this Cisco Secure ACS must have an accurately configured entry in its AAA Servers table. For more information about the AAA Servers table, see AAA Server Configuration.

To schedule when a primary Cisco Secure ACS replicates to its secondary Cisco Secure ACSes, follow these steps:

Step 2   In the navigation bar, click System Configuration.

Step 3   Click CiscoSecure Database Replication.

---

Note    If this feature does not appear, click Interface Configuration, click Advanced Options, and select the CiscoSecure ACS Database Replication check box. Also, verify that the Distributed System Settings check box is selected; if not, select the Distributed System Settings check box.

---

Result: The Database Replication Setup page appears.

Step 4   To specify which CiscoSecure database components the primary Cisco Secure ACS should send to its secondary Cisco Secure ACSes, under Replication Components, select the corresponding Send check box for each database component to be sent.

For more information about replicated database components, see Replication Components Options.

Step 5   To have the primary Cisco Secure ACS send replicated database components to its secondary Cisco Secure ACSes at regular intervals, under Replication Scheduling, select the Every X minutes option and in the X box type the length of the interval at which Cisco Secure ACS should perform replication (up to 7 characters).

---

Note    Because Cisco Secure ACS is momentarily shut down during replication, a short replication interval may cause frequent failover of your AAA clients to other Cisco Secure ACSes. If AAA clients are not configured to failover to other Cisco Secure ACSes, the brief interruption in authentication service may prevent users from authenticating. For more information, see Replication Frequency, page 8-14.

---

Step 6   If you want to schedule times at which the primary Cisco Secure ACS sends its replicated database components to its secondary Cisco Secure ACSes, follow these steps:

Tip Clicking times of day on the graph selects those times; clicking again clears them. At any time you can click Clear All to clear all hours, or you can click Set All to select all hours.

Step 7   If you want to have this Cisco Secure ACS send replicated database components immediately upon receiving replicated database components from another Cisco Secure ACS, select the Automatically triggered cascade option.

---

Note    If you specify the Automatically triggered cascade option, you must configure another Cisco Secure ACS to act as a primary Cisco Secure ACS server to this server; otherwise, this Cisco Secure ACS never replicates to its secondary Cisco Secure ACSes.

---

Step 8   You must specify the secondary Cisco Secure ACSes that this Cisco Secure ACS should replicate to. To do so, follow these steps:

---

Note    Cisco Secure ACS does not support bidirectional database replication. A secondary Cisco Secure ACS receiving replicated database components verifies that the primary Cisco Secure ACS is not on its Replication list. If not, the secondary Cisco Secure ACS accepts the replicated database components. If so, it rejects the components. For more information about replication partners, see Inbound Replication Options.

---

---

Note    The secondary Cisco Secure ACSes available in the AAA Servers list are determined by the AAA Servers table in Network Configuration. For more information about the AAA Servers table, see AAA Server Configuration.

---

Result: The selected secondary Cisco Secure ACS moves to the Replication list.

Step 9   Click Submit.

Result: Cisco Secure ACS saves the replication configuration you created.

Disabling CiscoSecure Database Replication

You can disable scheduled CiscoSecure database replications without losing the schedule itself. This allows you to cease scheduled replications temporarily and later resume them without having to re-enter the schedule information.

To disable CiscoSecure database replication, follow these steps:

Step 2   In the navigation bar, click System Configuration.

Step 3   Click CiscoSecure Database Replication.

Result: The Database Replication Setup page appears.

Step 4   In the Replication Components table, clear all check boxes.

Step 5   In the Outbound Replication table, select the Manually option.

Step 6   Click Submit.

Result: Cisco Secure ACS does not permit any replication to or from this Cisco Secure ACS server.

Database Replication Event Errors

The Database Replication report contains messages indicating errors that occur during replication. For more information about the Database Replication report, see Cisco Secure ACS System Logs.

RDBMS Synchronization

This section provides information about the RDBMS Synchronization feature, including procedures for implementing this feature, within both Cisco Secure ACS and the external data source involved. This section contains the following topics:

About RDBMS Synchronization

The RDBMS Synchronization feature enables you to update the CiscoSecure user database with information from an ODBC-compliant data source. The ODBC-compliant data source can be the RDBMS database of a third-party application. It can also be an intermediate file or database that a third-party system updates. Regardless of where the file or database resides, Cisco Secure ACS reads the file or database via the ODBC connection. You can also regard RDBMS Synchronization as an API—much of what you can configure for a user, group, or device through the Cisco Secure ACS HTML interface, you can alternatively maintain through this feature. RDBMS Synchronization supports addition, modification, and deletion for all data items it can access.

You can configure synchronization to occur on a regular schedule. You can also perform synchronizations manually, updating the CiscoSecure user database on demand.

Synchronization performed by a single Cisco Secure ACS can update the internal databases of other Cisco Secure ACSes, so that you only need configure RDBMS Synchronization on one Cisco Secure ACS. Cisco Secure ACSes listen on TCP port 2000 for synchronization data. RDBMS Synchronization communication between Cisco Secure ACSes is encrypted using 128-bit encrypted, proprietary algorithm.

The topics in this section provide an overview of the kinds of configuration that RDBMS Synchronization can automate. You specify the actions in a relational database table or text file named accountActions. For more information about accountActions, see About the accountActions Table. For specific information about all actions that RDBMS Synchronization can perform, see "RDBMS Synchronization Import Definitions."

Users

Among the user-related configuration actions that RDBMS Synchronization can perform are the following:

User Groups

Among the group-related configuration actions that RDBMS Synchronization can perform are the following:

Network Configuration

Among the network device-related configuration actions that RDBMS Synchronization can perform are the following:

Custom RADIUS Vendors and VSAs

RDBMS Synchronization enables you to configure custom RADIUS vendors and VSAs. In addition to supporting a set of predefined RADIUS vendors and vendor-specific attributes (VSAs), Cisco Secure ACS supports RADIUS vendors and VSAs that you define. Vendors you add must be IETF-compliant; therefore, all VSAs that you add must be sub-attributes of IETF RADIUS attribute number 26.

You can define up to ten custom RADIUS vendors. Cisco Secure ACS allows only one instance of any given vendor, as defined by the unique vendor IETF ID number and by the vendor name.

Note   For specific information about all actions that RDBMS Synchronization can perform, see "RDBMS Synchronization Import Definitions."

RDBMS Synchronization Components

The RDBMS Synchronization feature comprises two components:

About CSDBSync

The CSDBSync service uses an ODBC system data source name (DSN) to access the accountActions table. See Figure 8-2. This service looks specifically for a table named "accountActions". Synchronization events fail if CSDBSync cannot access the accountActions table.

CSDBSync reads each record from the accountActions table and updates the CiscoSecure user database as specified by the action code in the record. For example, a record could instruct CSDBSync to add a user or change a user password. After CSDBSync processes each record, it deletes the record from the table.

CSDBSync both reads and writes (deletes records) in the accountActions table. This requires that the database user account that you configure the system DSN to use must have both read and write privileges.

For more information about CSDBSync or other Windows services used by Cisco Secure ACS, see "Cisco Secure ACS Internal Architecture."

About the accountActions Table

The accountActions table contains a set of rows that define actions CSDBSync is to perform in the CiscoSecure user database. Each row in the accountActions table holds user, user group, or AAA client information. Each row also contains an action field and several other fields. These fields provide CSDBSync with the information it needs to update the CiscoSecure user database. For full details of the accountActions table format and available actions, see "RDBMS Synchronization Import Definitions."

The database containing the accountActions table must support a multi-threaded ODBC driver. This is required to prevent problems in the event that Cisco Secure ACS and the third-party system attempt to access the accountActions table simultaneously.

Cisco Secure ACS includes files to help you create your accountActions table for several common formats. You can find these files on the Cisco Secure ACS in the following location, assuming a default installation of Cisco Secure ACS:

C:\Program Files\CiscoSecure ACS vx.x\CSDBSync\Databases

The Databases directory contains the following subdirectories:

CiscoSecure Transactions.mdb contains a preconfigured accountActions table. When you install Cisco Secure ACS, the installation routine creates a system DSN named CiscoSecure DBSync. This system DSN is configured to communicate with CiscoSecure Transactions.mdb.

---

Note    By default, the username and password for the CiscoSecure Transactions.mdb database are set to null. To increase the security of RDBMS synchronizations performed using this database, change the username and password, both in the CiscoSecure Transactions.mdb database and in Cisco Secure ACS. Any other processes that access the CiscoSecure Transactions.mdb database should be changed to use the new username and password, too.

---

The accountactions file is the accountActions table in a comma-separated value file. The schema.ini file provides the Microsoft ODBC text file driver with the information it needs to access the accountactions file.

The accountActions.sql file contains the Oracle 7 SQL procedure needed to generate an accountActions table. The testData.sql file contains Oracle 7 SQL procedures for updating the accountActions table with sample transactions that CSDBSync can process.

The accountActions.sql file contains the Oracle 8 SQL procedure needed to generate an accountActions table. The testData.sql file contains Oracle 8 SQL procedures for updating the accountActions table with sample transactions that CSDBSync can process.

The accountActions.sql file contains the Microsoft SQL Server 6.5 SQL procedure needed to generate an accountActions table. The testData.sql file contains Microsoft SQL Server 6.5 SQL procedures for updating the accountActions table with sample transactions that CSDBSync can process.

Cisco Secure ACS Database Recovery Using the accountActions Table

Because the RDBMS Synchronization feature deletes each record in the accountActions table after processing the record, the accountActions table can be considered a transaction queue. The RDBMS Synchronization feature does not maintain a transaction log/audit trail. If a log is required, the external system that adds records to the accountActions table must create it. Unless the external system can recreate the entire transaction history in the accountActions table, we recommend that you construct a transaction log file for recovery purposes. To do this, create a second table that is stored in a safe location and backed up regularly. In that second table, mirror all the additions and updates to records in the accountActions table.

If the database is large, it is not practical to replay all transaction logs to synchronize the CiscoSecure user database with the third-party system. Instead, create regular backups of the CiscoSecure user database and replay the transaction logs from the time of most recent backup to bring the CiscoSecure user database back in synchronization with the third-party system. For information on creating backup files, see Cisco Secure ACS Backup.

Replaying transaction logs that slightly predate the checkpoint does not damage the CiscoSecure user database, although some transactions might be invalid and reported as errors. As long as the entire transaction log is replayed, the CiscoSecure user database is consistent with the database of the external RDBMS application.

Reports and Event (Error) Handling

The CSDBSync service provides event and error logging. For more information about the RDBMS Synchronization log, see Cisco Secure ACS System Logs. For more information about the CSDBSync service log, see Service Logs.

During manual synchronizations, Cisco Secure ACS provides visual alerts to notify you of problems that occurred during synchronization.

Preparing to Use RDBMS Synchronization

Synchronizing the CiscoSecure user database using data from the accountActions table requires that you complete several steps external to Cisco Secure ACS before you configure the RDBMS Synchronization feature within Cisco Secure ACS. If you are planning to use a CSV file as your accountActions table, also see Considerations for Using CSV-Based Synchronization.

To prepare to use RDBMS Synchronization, follow these steps:

Step 2   Create your accountActions table.

Step 3   Configure your third-party system to generate records and update the accountActions table with them. This will most likely involve creating stored procedures that write to the accountActions table at a triggered event; however, the mechanism for maintaining your accountActions table is unique to your implementation. If the third-party system you are using to update the accountActions table is a commercial product, for assistance, refer to the documentation supplied by your third-party system vendor.

For information about the format and content of the accountActions table, see "RDBMS Synchronization Import Definitions."

Step 4   Validate your third-party system to ensure that it updates the accountActions table properly. Rows generated in the accountActions table must be valid. For details on the format and content of the accountActions table, see "RDBMS Synchronization Import Definitions."

---

Note    After testing that the third-party system updates the accountActions table properly, discontinue updating the accountActions table until after you have completed Step 5 and Step 6.

---

Step 5   Set up a system DSN on the Cisco Secure ACS. For steps, see Configuring a System Data Source Name for RDBMS Synchronization.

Step 6   Schedule RDBMS synchronization in Cisco Secure ACS. For steps, see Scheduling RDBMS Synchronization.

Step 7   Configure your third-party system to begin updating the accountActions table with information to be imported into the CiscoSecure user database.

Step 8   Confirm that RDBMS synchronization is operating properly by monitoring the RDBMS Synchronization report in the Reports and Activity section. For more information about the RDBMS Synchronization log, see Cisco Secure ACS System Logs.

Also, monitor the CSDBSync service log. For more information about the CSDBSync service log, see Service Logs.

Considerations for Using CSV-Based Synchronization

The behavior of the Microsoft ODBC driver for text files creates additional considerations if you are planning to use a CSV-based accountActions table. The Microsoft ODBC driver for text files always operates in a read-only mode. It cannot delete records from a CSV accountActions table. Because of this, synchronization events initiated or scheduled in the HTML interface never release the CSV file, so the updates to the accountActions table from your third-party system fail.

The solution is to initiate synchronization events from a script, such as a DOS batch file. In the script, RDBMS synchronization is initiated with the CSDBSync -run command.

Assuming a default installation, CSDBSync.exe is installed at:

C:\Program Files\CiscoSecure ACS vx.x\CSDBSync

You can write a script that uses the CSDBsync command. You can schedule times when the script is run by using the Windows at command. For information about the at command, please refer to your Microsoft Windows documentation.

Also, due to limitations of the Microsoft ODBC text file driver, using the CSV format requires a change to the accountactions CSV file shipped with Cisco Secure ACS and to Cisco Secure ACS configuration. For more information, see Preparing for CSV-Based Synchronization.

Preparing for CSV-Based Synchronization

If you want to use a CSV file for your accountActions table, some additional configuration is necessary. This is because the Microsoft ODBC CSV driver cannot access the accountActions table unless the file has a .csv file extension.

To prepare for RDBMS synchronization using a CSV file, follow these steps:

Assuming a default installation of Cisco Secure ACS, the accountactions file is at the following location:

C:\Program Files\CiscoSecure ACS vx.x\CSDBSync\Databases\CSV

Where x.x refers to the version of your Cisco Secure ACS.

Step 2   Edit the Windows Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\CiscoAAAvx.x\CSDBSync

Step 3   At a DOS prompt, follow these steps:

and than press Enter.

and then press Enter.

Result: The Microsoft ODBC CSV driver can now access the accountActions CSV file properly.

Configuring a System Data Source Name for RDBMS Synchronization

On the Cisco Secure ACS, a system DSN must exist for Cisco Secure ACS to access the accountActions table. If you plan to use the CiscoSecure Transactions.mdb Microsoft Access database provided with Cisco Secure ACS, you can use the CiscoSecure DBSync system DSN rather than creating one.

For more information about the CiscoSecure Transactions.mdb file, see Preparing to Use RDBMS Synchronization.

To create a system DSN for use with RDBMS synchronization, follow these steps:

Step 2   In the ODBC Data Source Administrator window, click the System DSN tab.

Step 3   Click Add.

Step 4   Select the driver you need to use with your new DSN, and then click Finish.

Result: A dialog box displays fields requiring information specific to the ODBC driver you selected.

Step 5   In the Data Source Name box, type a descriptive name for the DSN.

Step 6   Complete the other fields required by the ODBC driver you selected. These fields may include information such as the IP address of the server on which the ODBC-compliant database runs.

Step 7   Click OK.

Result: The name you assigned to the DSN appears in the System Data Sources list.

Step 8   Close the ODBC window and Windows Control Panel.

Result: The system DSN to be used by Cisco Secure ACS to access your accountActions table is created on your Cisco Secure ACS.

RDBMS Synchronization Options

The RDBMS Synchronization Setup page, available from System Configuration, provides control of the following items:

RDBMS Setup Options

The RDBMS Synchronization feature provides the following RDBMS setup options:

---

Note    The database user account specified by the username must have sufficient privileges to read and write to the accountActions table.

---

Synchronization Scheduling Options

The RDBMS Synchronization feature provides the following scheduling options:

Synchronization Partners Options

The RDBMS Synchronization feature provides the following synchronization partners options:

For more information about the AAA Servers table in Network Configuration, see AAA Server Configuration.

Performing RDBMS Synchronization Immediately

You can manually start an RDBMS synchronization event.

To perform manual RDBMS synchronization, follow these steps:

Step 2   Click RDBMS Synchronization.

---

Note    If this feature does not appear, click Interface Configuration, click Advanced Options, and then select the RDBMS Synchronization check box.

---

Result: The RDBMS Synchronization Setup page appears.

Step 3   To specify options in the RDBMS Setup table, follow these steps:

---

Note    For more information about RDBMS setup, see RDBMS Setup Options.

---

For more information about configuring a system DSN for use with RDBMS Synchronization, see Configuring a System Data Source Name for RDBMS Synchronization.

Result: Cisco Secure ACS has the information necessary to access the accountActions table.

---

Note    You do not have to select Manually under Replication Scheduling. For more information, see Disabling Scheduled RDBMS Synchronizations.

---

Step 4   For each Cisco Secure ACS that you want this Cisco Secure ACS to update with data from the accountActions table, select the Cisco Secure ACS in the AAA Servers list, and then click —> (right arrow button).

Result: The selected Cisco Secure ACS appears in the Synchronize list.

Step 5   To remove Cisco Secure ACSes from the Synchronize list, select the Cisco Secure ACS in the Synchronize list, and then click <— (left arrow button).

Result: The selected Cisco Secure ACS appears in the AAA Servers list.

Step 6   At the bottom of the browser window, click Synchronize Now.

Result: Cisco Secure ACS immediately begins a synchronization event. To check the status of the synchronization, view the RDBMS Synchronization report in Reports and Activity.

Scheduling RDBMS Synchronization

You can schedule when a Cisco Secure ACS performs RDBMS synchronization.

To schedule when a Cisco Secure ACS performs RDBMS synchronization, follow these steps:

Step 2   Click RDBMS Synchronization.

---

Note    If this feature does not appear, click Interface Configuration, click Advanced Options, and then select the RDBMS Synchronization check box.

---

Result: The RDBMS Synchronization Setup page appears.

Step 3   To specify options in the RDBMS Setup table, follow these steps:

---

Note    For more information about RDBMS setup, see RDBMS Setup Options.

---

For more information about configuring a system DSN for use with RDBMS Synchronization, see Configuring a System Data Source Name for RDBMS Synchronization.

Step 4   To have this Cisco Secure ACS perform RDBMS synchronization at regular intervals, under Synchronization Scheduling, select the Every X minutes option and in the X box type the length of the interval at which Cisco Secure ACS should perform synchronization (up to 7 characters).

Step 5   To schedule times at which this Cisco Secure ACS performs RDBMS synchronization, follow these steps:

Tip Clicking times of day on the graph selects those times; clicking again clears them. At any time you can click Clear All to clear all hours, or you can click Set All to select all hours.

Step 6   For each Cisco Secure ACS you want to synchronize with data from the accountActions table, follow these steps:

---

Note    For more information about synchronization targets, see Inbound Replication Options.

---

---

Note    The Cisco Secure ACSes available in the AAA Servers list is determined by the AAA Servers table in Network Configuration, with the addition of the name of the current Cisco Secure ACS server. For more information about the AAA Servers table, see AAA Server Configuration.

---

Result: The selected Cisco Secure ACS moves to the Synchronize list.

---

Note    At least one Cisco Secure ACS must be in the Synchronize list. This includes the server on which you are configuring RDBMS Synchronization. RDBMS Synchronization does not automatically include the internal database of the current server.

---

Step 7   Click Submit.

Result: Cisco Secure ACS saves the RDBMS synchronization schedule you created.

Disabling Scheduled RDBMS Synchronizations

You can disable scheduled RDBMS synchronization events without losing the schedule itself. This allows you to end scheduled synchronizations and resume them later without having to re-create the schedule.

To disable scheduled RDBMS synchronizations, follow these steps:

Step 2   Click RDBMS Synchronization.

Result: The RDBMS Synchronization Setup page appears.

Step 3   Under Synchronization Scheduling, select the Manually option.

Step 4   Click Submit.

Result: Cisco Secure ACS does not perform scheduled RDBMS synchronizations.

Cisco Secure ACS Backup

This section provides information about the Cisco Secure ACS Backup feature, including procedures for implementing this feature. This section contains the following topics:

About Cisco Secure ACS Backup

The ACS Backup process backs up your Cisco Secure ACS system information to a file on the local hard drive. You can manually back up the Cisco Secure ACS system. You can also establish automated backups that occur at regular intervals or at selected days of the week and times. Maintaining backup files can minimize downtime if system information becomes corrupt or is misconfigured. We recommend copying the files to the hard drive on another system in case the hardware fails on the primary system.

For information about using a backup file to restore Cisco Secure ACS, see Cisco Secure ACS System Restore.

Backup File Locations

The default directory for backup files is the following:

drive:\path\CSAuth\System Backups

where drive is the local drive where you installed Cisco Secure ACS and path is the path from the root of drive to the Cisco Secure ACS directory. For example, if you installed Cisco Secure ACS version 3.0 in the default location, the default backup location would be c:\Program Files\CiscoSecure ACS v3.0\CSAuth\System Backups.

The filename given to a backup is determined by Cisco Secure ACS. For more information about filenames assigned to backup files generated by Cisco Secure ACS, see Backup File Names and Locations.

Directory Management

You can configure the number of backup files to keep and the number of days after which backup files are deleted. The more complex your configuration and the more often you back up the system, the more diligent we recommend you be about clearing out old databases from the Cisco Secure ACS hard drive.

Components Backed Up

The ACS System Backup utility backs up the Cisco Secure ACS user database and information from the Windows Registry that is relevant to Cisco Secure ACS. The user database backup includes all user information, such as username, password, and other authentication information, including server certificates and the certificate trust list. The Windows Registry information includes any system information that is stored in the Windows Registry, such as NDG information, AAA client configuration, and administrator accounts.

Reports of Cisco Secure ACS Backups

When a system backup takes place, whether it was manually generated or scheduled, the event is logged in the Administration Audit report and the ACS Backup and Restore report. You can view recent reports in the Reports and Activity section of Cisco Secure ACS.

For more information about Cisco Secure ACS reports, see "Working with Logging and Reports."

Backup Options

The ACS System Backup Setup page contains the following configuration options:

Performing a Manual Cisco Secure ACS Backup

You can backup Cisco Secure ACS whenever you want, without scheduling the backup.

To perform an immediate backup of Cisco Secure ACS, follow these steps:

Step 2   Click ACS Backup.

Result: The ACS System Backup Setup page appears.

Step 3   In the Directory box under Backup Location, type the drive and path to the directory on a local hard drive where you want the backup file to be written.

Step 4   Click Backup Now.

Result: Cisco Secure ACS immediately begins a backup.

Scheduling Cisco Secure ACS Backups

You can schedule Cisco Secure ACS backups to occur at regular intervals or on selected days of the week and times.

To schedule the times at which Cisco Secure ACS performs a backup, follow these steps:

Step 2   Click ACS Backup.

Result: The ACS System Backup Setup page appears.

Step 3   To schedule backups at regular intervals, under ACS Backup Scheduling, select the Every X minutes option and in the X box type the length of the interval at which Cisco Secure ACS should perform backups.

---

Note    Because Cisco Secure ACS is momentarily shut down during backup, if the backup interval is too frequent, users might be unable to authenticate.

---

Step 4   To schedule backups at specific times, follow these steps:

Tip Clicking times of day on the graph selects those times; clicking again clears them. At any time you can click Clear All to clear all hours, or you can click Set All to select all hours.

Step 5   To change the location where Cisco Secure ACS writes backup files, type the drive letter and path in the Directory box.

Step 6   To manage which backup files Cisco Secure ACS keeps, follow these steps:

Step 7   Click Submit.

Result: Cisco Secure ACS implements the backup schedule you configured.

Disabling Scheduled Cisco Secure ACS Backups

You can disable scheduled Cisco Secure ACS backups without losing the schedule itself. This allows you to end scheduled backups and resume them later without having to re-create the schedule.

To disable a scheduled backup, follow these steps:

Step 2   Click ACS Backup.

Result: The ACS System Backup Setup page appears.

Step 3   Under ACS Backup Scheduling, select the Manual option.

Step 4   Click Submit.

Result: Cisco Secure ACS does not continue any scheduled backups. You can still perform manual backups as needed.

Cisco Secure ACS System Restore

This section provides information about the Cisco Secure ACS System Restore feature, including procedures for restoring your Cisco Secure ACS from a backup file. This section contains the following topics:

About Cisco Secure ACS System Restore

The ACS System Restore feature enables you to restore your system configuration from backup files generated by the ACS Backup feature. This feature helps minimize downtime if Cisco Secure ACS system information becomes corrupted or is misconfigured.

The ACS System Restore feature only works with backup files generated by a Cisco Secure ACS running an identical Cisco Secure ACS version and patch level.

Backup File Names and Locations

The ACS System Restore feature restores the Cisco Secure ACS user database and Cisco Secure ACS Windows Registry information from a file that was created by the ACS Backup feature. Cisco Secure ACS writes backup files only on the local hard drive. You can restore from any backup file you select. For example, you can restore from the latest backup file, or if you suspect that the latest backup was incorrect, you can select an earlier backup file to restore from.

The backup directory is selected when you schedule backups or perform a manual backup. The default directory for backup files is the following:

drive:\path\CSAuth\System Backups

where drive is the local drive where you installed Cisco Secure ACS and path is the path from the root of drive to the Cisco Secure ACS directory. For example, if you installed Cisco Secure ACS version 3.0 in the default location, the default backup location would be:

c:\Program Files\CiscoSecure ACS v3.0\CSAuth\System Backups

Cisco Secure ACS creates backup files using the date and time format:

dd-mmm-yyyy hh-nn-ss.dmp

where:

For example, if Cisco Secure ACS started a backup on October 13, 1999, 11:41:35 a.m., Cisco Secure ACS would generate a backup file named:

13-Oct-1999 11-41-35.dmp

If you are not sure of the location of the latest backup file, check your scheduled backup configuration on the ACS Backup page.

Components Restored

You can select the components to restore: the user and group databases, the system configuration, or both.

Reports of Cisco Secure ACS Restorations

When a Cisco Secure ACS system restoration takes place, the event is logged in the Administration Audit report and the ACS Backup and Restore report. You can view recent reports in the Reports and Activity section of Cisco Secure ACS.

For more information about Cisco Secure ACS reports, see "Working with Logging and Reports."

Restoring Cisco Secure ACS from a Backup File

You can perform a system restoration of Cisco Secure ACS whenever needed.

Note   Using the Cisco Secure ACS System Restore feature restarts all Cisco Secure ACS services and logs out all administrators.

To restore Cisco Secure ACS from a backup file generated by the Cisco Secure ACS Backup feature, follow these steps:

Step 2   Click ACS Restore.

Result: The ACS System Restore Setup page appears.

The Directory box displays the drive and path to the backup directory most recently configured in the Directory box on the ACS Backup page.

Beneath the Directory box, Cisco Secure ACS displays the backup files in the current backup directory. If no backup files exist, <No Matching Files> appears in place of filenames.

Step 3   To change the backup directory, type the new drive and path to the backup directory in the Directory box, and then click OK.

Result: Cisco Secure ACS displays the backup files, if any, in the backup directory you specified.

Step 4   In the list below the Directory box, select the backup file you want to use to restore Cisco Secure ACS.

Step 5   To restore user and group database information, select the User and Group Database check box.

Step 6   To restore system configuration information, select the CiscoSecure ACS System Configuration check box.

Step 7   Click Restore Now.

Result: Cisco Secure ACS displays a confirmation dialog box indicating that performing the restoration will restart Cisco Secure ACS services and log out all administrators.

Step 8   To continue with the restoration, click OK.

Result: Cisco Secure ACS restores the system components specified using the backup file you selected. The restoration should require several minutes to complete, depending on which components you selected to restore and the size of your database.

When the restoration is complete, you can log in again to Cisco Secure ACS.

Cisco Secure ACS Active Service Management

ACS Active Service Management is an application-specific service monitoring tool that is tightly integrated with ACS. The ACS Active Service Management comprises two features:

System Monitoring

Cisco Secure ACS system monitoring enables you to determine how often Cisco Secure ACS tests its authentication and accounting processes, and to determine what automated actions it takes should tests detect a failure of these processes. Cisco Secure ACS accomplishes system monitoring with the CSMon service. For more information about the CSMon service, see CSMon.

System Monitoring Options

You have the following options for configuring system monitoring:

When this option is enabled, at the interval defined, Cisco Secure ACS tests authentication and accounting. If the test fails, after four unsuccessful re-tries Cisco Secure ACS performs the action identified in the If no successful authentications are recorded list and logs the event.

drive:\path\CSMon\Scripts

where drive is the local drive where you installed Cisco Secure ACS and path is the path from the root of drive to the Cisco Secure ACS directory.

Setting Up System Monitoring

To setup Cisco Secure ACS System Monitoring, follow these steps:

Step 2   Click ACS Service Management.

Result: The ACS Active Service Management Setup page appears.

Step 3   To have Cisco Secure ACS test the login process, follow these steps:

Step 4   To have Cisco Secure ACS generate a Windows event when a user attempts to log in to your network using a disabled account, select the Generate event when an attempt is made to log in to a disabled account check box.

Step 5   If you want to set up event logging, see Setting Up Event Logging.

Step 6   If you are done setting up Cisco Secure ACS Service Management, click Submit.

Result: Cisco Secure ACS implements the service management settings you made.

Event Logging

The Event Logging feature enables you to configure whether Cisco Secure ACS logs events to the Windows event log and whether Cisco Secure ACS generates an e-mail when an event occurs. Cisco Secure ACS uses the System Monitoring feature to detect the events to be logged. For more information about system monitoring, see System Monitoring Options.

Setting Up Event Logging

To view the Windows event log, choose Start > Programs > Administrative Tools > Event Viewer. For more information about the Windows event log or Event Viewer, refer to your Microsoft Windows documentation.

To setup Cisco Secure ACS event logging, follow these steps:

Step 2   Click ACS Service Management.

Result: The ACS Active Service Management Setup page appears.

Step 3   To have Cisco Secure ACS send all events to the Windows event log, select Log all events to the Windows Event log.

Step 4   To have Cisco Secure ACS send an e-mail when an event occurs, follow these steps:

---

Note    Do not use underscores in the e-mail addresses you type in this box.

---

---

Note    The SMTP mail server must be operational and must be available from the Cisco Secure ACS.

---

Step 5   If you want to set up system monitoring, see Setting Up System Monitoring.

Step 6   If you are done setting up Cisco Secure ACS Service Management, click Submit.

Result: Cisco Secure ACS implements the service management settings you made.

IP Pools Server

This section provides information about the IP Pools feature, including procedures for creating and maintaining IP pools. This section contains the following topics:

About IP Pools Server

If you are using VPNs you may have to overlap IP address assignments; that is, it may be advantageous for a PPTP tunnel client within a given tunnel to use the same IP address as that used by another PPTP tunnel client in a different tunnel. The IP Pools Server feature enables you to assign the same IP address to multiple users, provided that the users are being tunnelled to different home gateways for onward routing beyond the boundaries of your own network. This means you can conserve your IP address space without having to resort to using illegal addresses. When you enable this feature, Cisco Secure ACS dynamically issues IP addresses from the IP pools you have defined by number or name. You can configure up to 999 IP pools, for approximately 255,000 users.

If you are using IP pooling and proxy, all accounting packets are proxied so that the Cisco Secure ACS that is assigning the IP addresses can confirm whether an IP address is already in use.

Note   IP pool definitions are not replicated by the CiscoSecure Database Replication feature; however, user and group assignments to IP pools are replicated. By not replicating IP pool definitions, Cisco Secure ACS avoids inadvertently assigning an IP address that a replication partner has already assigned to a different workstation. To support IP pools in a AAA environment that uses replication, you must manually configure each secondary Cisco Secure ACS to have IP pools with names identical to the IP pools defined on the primary Cisco Secure ACS.

To use IP pools, the AAA client must have network authorization (in IOS, aaa authorization network) and accounting (in IOS, aaa accounting) enabled.

Note   To use the IP Pools feature, you must set up your AAA client to perform authentication and accounting using the same protocol—either TACACS+ or RADIUS.

For information on assigning a group or user to an IP pool, see Setting IP Address Assignment Method for a User Group, or Assigning a User to a Client IP Address.

Allowing Overlapping IP Pools or Forcing Unique Pool Address Ranges

Cisco Secure ACS provides automated detection of overlapping pools.

Note   To use overlapping pools, you must be using RADIUS with VPN, and you cannot be using Dynamic Host Configuration Protocol (DHCP).

You can determine whether overlapping IP pools are allowed by checking which button appears below the AAA Server IP Pools table:

To allow overlapping IP pools or to force unique pool address ranges, follow these steps:

Step 2   Click IP Pools Server.

---

Note    If this feature does not appear, click Interface Configuration, click Advanced Options, and then select the IP Pools check box.

---

Result: The AAA Server IP Pools table lists any IP pools you have configured, their address ranges, and the percentage of pooled addresses in use.

Step 3   If you want to allow overlapping IP pool address ranges, follow these steps:

Result: Cisco Secure ACS allows overlapping IP pool address ranges.

Cisco Secure ACS already allows overlapping IP pool address ranges.

Step 4   If you want to deny overlapping IP pool address ranges, follow these steps:

Cisco Secure ACS already does not permit overlapping IP pool address ranges.

Result: Cisco Secure ACS does not permit overlapping IP pool address ranges.

Refreshing the AAA Server IP Pools Table

You can refresh the AAA Server IP Pools table. This allows you to get the latest usage statistics for your IP pools.

To refresh the AAA Server IP Pools table, follow these steps:

Step 2   Click IP Pools Server.

Result: The AAA Server IP Pools table lists any IP pools you have configured, their address ranges, and the percentage of pooled addresses in use.

Step 3   Click Refresh.

Result: Cisco Secure ACS updates the percentages of pooled addresses in use.

Adding a New IP Pool

You can define up to 999 IP address pools.

To add an IP pool, follow these steps:

Step 2   Click IP Pools Server.

Result: The AAA Server IP Pools table lists any IP pools you have already configured, their address ranges, and the percentage of pooled addresses in use.

Step 3   Click Add Entry.

Result: The New Pool table appears.

Step 4   In the Name box, type the name (up to 31 characters) you want to assign to the new IP pool.

Step 5   In the Start Address box, type the lowest IP address (up to 15 characters) of the range of addresses for the new pool.

---

Note    All addresses in an IP pool must be on the same Class C network, so the first three octets of the start and end addresses must be the same. For example, if the start address is 192.168.1.1, the end address must be between 192.168.1.2 and 192.168.1.254.

---

Step 6   In the End Address box, type the highest IP address (up to 15 characters) of the range of addresses for the new pool.

Step 7   Click Submit.

Result: The new IP pool appears in the AAA Server IP Pools table.

Editing an IP Pool Definition

To edit an IP pool definition, follow these steps:

Step 2   Click IP Pools Server.

Result: The AAA Server IP Pools table lists any IP pools you have configured, their address ranges, and the percentage of pooled addresses in use.

Step 3   Click the name of the IP pool you need to edit.

Result: The name pool table appears, where name is the name of the IP pool you selected. The In Use field displays how many IP addresses in this pool are allocated to a user. The Available field displays how many IP addresses are unallocated to users.

Step 4   To change the name of the pool, in the Name box, type the name (up to 31 characters) to which you want to change the IP pool.

Step 5   To change the starting address of the pool range of IP addresses, in the Start Address box, type the lowest IP address (up to 15 characters) of the new range of addresses for the pool.

---

Note    All addresses in an IP pool must be on the same Class C network, so the first three octets of the start and end addresses must be the same. For example, if the start address is 192.168.1.1, the end address must be between 192.168.1.2 and 192.168.1.254.

---

Step 6   To change the ending address of the pool range of IP addresses, in the End Address box, type the highest IP address (up to 15 characters) of the new range of addresses for the pool.

Step 7   Click Submit.

Result: The edited IP pool appears in the AAA Server IP Pools table.

Resetting an IP Pool

The Reset function recovers IP addresses within an IP pool when there are "dangling" connections. A dangling connection occurs when a user disconnects and Cisco Secure ACS does not receive an accounting stop packet from the applicable AAA client. If the Failed Attempts log in Reports and Activity shows a large number of "Failed to Allocate IP Address For User" messages, consider using the Reset function to reclaim all allocated addresses in this IP pool.

Note   Using the Reset function to reclaim all allocated IP addresses in a pool can result in users being assigned addresses that are already in use.

To reset an IP pool and reclaim all its IP addresses, follow these steps:

Step 2   Click IP Pools Server.

Result: The AAA Server IP Pools table lists any IP pools you have configured, their address ranges, and the percentage of pooled addresses in use.

Step 3   Click the name of the IP pool you need to reset.

Result: The name pool table appears, where name is the name of the IP pool you selected. The In Use field displays how many IP addresses in this pool are assigned to a user. The Available field displays how many IP addresses are not assigned to users.

Step 4   Click Reset.

Result: Cisco Secure ACS displays a dialog box indicating the possibility of assigning users addresses that are already in use.

Step 5   To continue resetting the IP pool, click OK.

Result: The IP pool is reset. All its IP addresses are reclaimed. In the In Use column of the AAA Server IP Pools table, zero percent of the IP pool addresses are assigned to users.

Deleting an IP Pool

Note   If you delete an IP pool that has users assigned to it, those users cannot authenticate until you edit the user profile and change their IP assignment settings. Alternatively, if the users receive their IP assignment based on group membership, you can edit the user group profile and change the IP assignment settings for the group.

To delete an IP pool, follow these steps:

Step 2   Click IP Pools Server.

Result: The AAA Server IP Pools table lists any IP pools you have configured, their address ranges, and the percentage of pooled addresses in use.

Step 3   Click the name of the IP pool you need to delete.

Result: The name pool table appears, where name is the name of the IP pool you selected. The In Use column displays how many IP addresses in this pool are assigned to a user. The Available column displays how many IP addresses are not assigned to users.

Step 4   Click Delete.

Result: Cisco Secure ACS displays a dialog box to confirm that you want to delete the IP pool.

Step 5   To delete the IP pool, click OK.

Result: The IP pool is deleted. The AAA Server IP Pools table does not list the deleted IP pool.

IP Pools Address Recovery

The IP Pools Address Recovery feature enables you to recover assigned IP addresses that have not been used for a specified period of time. You must configure an accounting network on the AAA client for Cisco Secure ACS to reclaim the IP addresses correctly.

Enabling IP Pool Address Recovery

To enable IP pool address recovery, follow these steps:

Step 2   Click IP Pools Address Recovery.

---

Note    If this feature does not appear, click Interface Configuration, click Advanced Options, and then select the IP Pools check box.

---

Result: The IP Address Recovery page appears.

Step 3   Select the Release address if allocated for longer than X hours check box and in the X box type the number of hours (up to 4 characters) after which Cisco Secure ACS should recover assigned, unused IP addresses.

Step 4   Click Submit.

Result: Cisco Secure ACS implements the IP pools address recovery settings you made.

VoIP Accounting Configuration

The VoIP Accounting Configuration feature enables you to specify which accounting logs receive VoIP accounting data. There are three options for VoIP accounting:

Configuring VoIP Accounting

Note   The VoIP Accounting Configuration feature does not enable VoIP accounting. To enable VoIP accounting, see "Working with Logging and Reports."

To configure VoIP accounting, follow these steps:

Step 2   Click VoIP Accounting Configuration.

---

Note    If this feature does not appear, click Interface Configuration, click Advanced Options, and then select the Voice-over-IP (VoIP) Accounting Configuration check box.

---

Result: The VoIP Accounting Configuration page appears. The Voice-over-IP (VoIP) Accounting Configuration table displays the options for VoIP accounting.

Step 3   Select the VoIP accounting option you want.

Step 4   Click Submit.

Result: Cisco Secure ACS implements the VoIP accounting configuration you specified.

Cisco Secure ACS Certificate Setup

This section contains the following topics:

Background on Protocols and Certification

Cisco Secure ACS uses EAP-TLS and PEAP authentication protocols in combination with digital certification to ensure the protection and validity of authentication information. Digital certification, EAP-TLS, and PEAP are described in the topics that follow.

Digital Certificates

The ACS Certificate Setup section is used to install digital certificates to support EAP-TLS and PEAP authentication, as well as to support HTTPS protocol for secure access to the Cisco Secure ACS HTML interface. Cisco Secure ACS employs the X.509 v3 digital certificate standard. Certificate files must be in either Base64-encoded X.509 format or DER-encoded binary X.509 format. Also, Cisco Secure ACS supports manual certificate enrollment.

Digital certificates are useful because they do not require the sharing of secrets nor stored database credentials, can be scaled and trusted over large deployments, and can serve as a method of authentication that is stronger and more secure than shared secret systems. Mutual trust requires that Cisco Secure ACS have an installed certificate that can be verified by end-user clients.

About the EAP-TLS Protocol

EAP and TLS are both IETF RFC standards. The EAP protocol, an improvement over the point-to-point protocol (PPP), extends the network by providing new methods for carrying initial authentication information, specifically, EAPOL (the encapsulation of EAP over LANs as established by IEEE 802.1X).TLS provides a way to use certificates for both user authentication and for dynamic ephemeral session key generation. For more detailed information on EAP, TLS, and EAP-TLS, refer to the following IETF RFCs: PPP Extensible Authentication Protocol (EAP) RFC 2284, The TLS Protocol RFC 2246 and PPP EAP TLS Authentication Protocol RFC 2716.

A user who is authenticated using EAP-TLS can then be mapped to user or group authorization information kept in the CiscoSecure user database, or in a Windows 2000 or generic LDAP Directory Server.

Also, to accomplish secure Cisco Aironet connectivity, EAP-TLS generates a dynamic, per-user, per-connection, unique session key.

EAP-TLS requires support from both the end client and the AAA client. An example of an EAP-TLS client includes the Windows XP operating system; EAP-TLS compliant AAA clients include Cisco 802.1x-enabled switch platforms (such as the Catalyst 6000 product line), and Cisco Aironet Wireless solutions. To support EAP-TLS, Cisco Secure ACS must operate with an X.509 v3 digital certificate.

TLS authentications require two elements of trust. The first element of trust is when the TLS negotiation establishes end-user trust by validating, through RSA signature verifications, that the user possesses a keypair signed by a certificate. This verifies that the end user is the legitimate keyholder for a given digital certificate and the corresponding user identification contained in the certificate. However, trusting that a user possesses a certificate only provides a username/keypair binding. The second element of trust is to use a third-party signature (usually from a CA) that verifies the information in a certificate. This third-party binding is similar to the real world equivalent of the seal on a passport. You trust the passport because you trust the preparation and identity checking that the particular country's passport office made when creating that passport. You trust digital certificates by installing the root certificate CA signature.

If Cisco Secure ACS receives traffic from a wireless AP that has the wrong shared secret, the error message logged in to the failed attempts log reads "EAP request has invalid signature." Three conditions that might cause this to occur are the following:

After EAP-TLS authentication successfully concludes, Cisco Secure ACS must verify that the claimed identity (presented in the EAP Identity response) corresponds to the certificate presented by the user. Cisco Secure ACS can accomplish this verification in two ways:

---

Note    If you use certificate binary comparison, the user certificate must be stored in Active Directory or an LDAP server, using a binary format. Also, the attribute storing the certificate must be named "usercertificate".

---

When you set up EAP-TLS, you can select the criterion (one or both) that Cisco Secure ACS uses. For more information, see Configuring Authentication Options.

EAP-TLS Limitations

The Cisco Secure ACS implementation of EAP-TLS has the following limitations:

About the PEAP Protocol

The PEAP (Protected EAP) protocol is a client-server security architecture. PEAP provides stronger security, greater extensibility, and support for one-time token authentication. PEAP has been posted as an IETF Internet Draft by RSA, Cisco, and Microsoft and is available at http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-02.txt.

PEAP operates with two phrases. The first phase—server authentication—comprises a handshake and the establishment of and SSL tunnel. User authentication occurs in the second phase using a new EAP type that is protected by the SSL tunnel previously established.

PEAP uses TLS to authenticate the network infrastructure through the TLS Handshake protocol, to protect user credentials in transit by means of the TLS Record Protocol, and to generate cryptographic keying material using the TLS-defined pseudo-random function (PRF) functionality. PEAP uses the same encapsulation as EAP-TLS; however, whereas EAP-TLS ends after the TLS Handshake Protocol is complete, PEAP continues, encapsulating another EAP negotiation and authentication conversation within the TLS Record Protocol. This encapsulation ensures the cryptographic protection of the second EAP conversation. The authentication type negotiated during the second conversation may be any valid (for example, "Generic Token Card (GTC)") EAP type. After the second EAP conversation is complete, the EAP-Success (or EAP-Failure, as the case may be) message is returned to the end-user client in the clear. If authentication is successful, cryptographic keys are derived using the TLS PRF. Session keys never transit the network.

As compared to LEAP, PEAP is a major step forward in data security. After phase 1 of PEAP is established, all data is encrypted; this includes all username information that, with LEAP, is sent in cleartext. User identity is only sent through the secure (SSL) tunnel. The initial identity, which is sent in the clear, is the MAC address with the word "PEAP_" as a prefix. Further, by avoiding the requirement for MSCHAP usernames and passwords that is found in LEAP, PEAP can support a wider range of user databases.For more information regarding what protocols are compatible with the different databases, see Authentication Protocol-Database Compatibility.

PEAP Limitations

The Cisco Secure ACS implementation of PEAP has the following limitations:

---

Note    Unknown user processing can introduce large latencies during authentication. Be sure to configure the Unknown User Policy page to account for this possibility. For more information, see Database Search Order.

---

Installing a Cisco Secure ACS Server Certificate

Perform this procedure to install (that is, enroll) a server certificate for your Cisco Secure ACS. You can perform certificate enrollment to support EAP-TLS and PEAP authentication, as well as to support HTTPS protocol for GUI access to Cisco Secure ACS.

Before You Begin

You must have a server certificate for your Cisco Secure ACS before you can install it. With Cisco Secure ACS, certificate files must be in Base64-encoded X.509. If you do not already have a server certificate in storage, you can use the procedure in Generating a Certificate Signing Request, or any other means, to obtain a certificate for installation.

If you want to use a server certificate from local machine storage, we recommend that you read Extensible Authentication Protocol Transport Layer Security Deployment Guide for Wireless LAN Networks, available on the Cisco Secure ACS CD and at http://www.cisco.com/warp/public/cc/pd/sqsw/sq/
tech/index.shtml. This white paper provides information about how to add a certificate to machine storage and how to configure a Microsoft certification authority server for use with Cisco Secure ACS.

To install an existing certificate for use on Cisco Secure ACS, follow these steps:

Step 2   Click ACS Certificate Setup.

Step 3   Click Install ACS Certificate.

Result: Cisco Secure ACS displays the Install ACS Certificate page.

Step 4   You must specify whether Cisco Secure ACS reads the certificate from a specified file or uses a certificate already in storage on the local machine. Do one of the following:

Tip Type the certificate CN only; omit the cn= prefix.

Step 5   If you generated the request using Cisco Secure ACS, in the Private key file box, type the full directory path and name of the file that contains the private key.

---

Note    If the certificate was installed in storage with the private key, you do not have the private key file and do not need to type it.

---

Tip This is the private key associated with the server certificate.

Step 6   In the Private key password box, type the private key password.

Tip If you used Cisco Secure ACS to generate the certificate signing request, this is the value you entered in Private key password on the Generate Certificate Signing Request page. If the private key file is unencrypted, leave this box empty.

Step 7   Click Submit.

Result: To show that the certificate setup is complete, Cisco Secure ACS displays the Installed Certificate Information table, which contains the following certificate information:

Adding a Certificate Authority Certificate

Use this procedure to add new certificate authority (CA) certificates to Cisco Secure ACS's local certificate storage.

Note   If the clients and Cisco Secure ACS are getting their certificates from the same CA, you do not need to perform this procedure because Cisco Secure ACS automatically trusts the CA that issued its certificate.

When a user's certificate is from an unknown CA (that is, one that is different from the CA that certifies the Cisco Secure ACS), you must specifically configure Cisco Secure ACS to trust that CA or authentication fails. Until you perform this procedure to explicitly extend trust by adding another CA, Cisco Secure ACS only recognizes certificates from the CA that issued its own certificate.

Configuring Cisco Secure ACS to trust a specific CA is a two-step process that comprises both this procedure of adding a CA's certificate and the procedure in Editing the Certificate Trust List, where you signify that the particular CA is to be trusted. (Cisco Secure ACS comes preconfigured with a list of popular CAs, none of which are enabled until you explicitly signify trustworthiness.)

To add a certificate authority's certificate to your local storage, follow these steps:

Step 2   Click ACS Certificate Setup.

Step 3   Click ACS Certification Authority Setup.

Result: Cisco Secure ACS displays the CA Operations table on the Certification Authorities Setup page.

Step 4   In the CA certificate file box, type the full path and filename for the certificate you want to use.

Step 5   Click Submit.

Result: The new CA certificate is added to local certificate storage. And, if it is not already there, the name of the CA that issued the certificate is placed on the CTL.

Tip To use this new CA certificate to authenticate users, you must edit the certificate trust list to signify that this CA is trusted. For more information, see Editing the Certificate Trust List.

Editing the Certificate Trust List

Cisco Secure ACS uses the CTL to verify the client certificates. For a CA to be trusted by Cisco Secure ACS, its certificate must be installed, and the Cisco Secure ACS administrator must explicitly configure the CA as trusted by editing the CTL.

Note   The single exception to the requirement that a CA must be explicitly signified as trustworthy occurs when the clients and Cisco Secure ACS are getting their certificates from the same CA. You do not need to add this CA to the CTL because Cisco Secure ACS automatically trusts the CA that issued its certificate.

How you edit your CTL determines the type of trust model you have. Many use a restricted trust model wherein very few, privately controlled CAs are trusted. This model provides the highest level of security but restricts adaptability and scalability. The alternative, an open trust model, allows for more CAs or public CAs. This open trust model trades off increased security for greater adaptability and scalability.

We recommend that you fully understand the implications of your trust model before editing the CTL in Cisco Secure ACS.

Use this procedure to configure CAs on your CTL as trusted or not trusted. Before a CA can be configured as trusted on the CTL, you must have added the CA to the local machine certificate storage; for more information, see Adding a Certificate Authority Certificate. If a user's certificate is from a CA that you have not specifically configured Cisco Secure ACS to trust, authentication fails.

To edit the CTL, follow these steps:

Step 2   Click Cisco Secure ACS Certificate Setup.

Step 3   Click Edit Certificate Trust List.

Result: The Edit the Certificate Trust List (CTL) table appears.

Warning Adding a public CA, which you do not control, to your CTL, may reduce your system security.

Step 4   To configure a CA on your CTL as trusted, select the corresponding check box.

Tip You can select, or deselect, as many CAs as you want. Deselecting a CA's check box configures the CA as not trusted.

Step 5   Click Submit.

Result: Cisco Secure ACS configures the specified CA (or CAs) as trusted or not trusted in accordance with selecting or deselecting check boxes.

Generating a Certificate Signing Request

You can use Cisco Secure ACS to generate a certificate signing request (CSR). After you generate a CSR, you can submit it to a certificate authority (CA) to obtain your certificate. You perform this procedure to generate the CSR for future use with a certificate enrollment tool.

Note   If you already have a server certificate, you do not need to use this portion of the ACS Certificate Setup page.

To generate a certificate signing request, follow these steps:

Step 2   Click ACS Certificate Setup.

Step 3   Click Generate Certificate Signing Request.

Result: Cisco Secure ACS displays the Generate new request table on the Generate Certificate Signing Request page.

Step 4   In the Certificate subject box, type cn= followed by the name that you would like to use as subject name in this ACS certificate, for example, cn=ACSWireless.

Step 5   In the Private key file box, type the full directory path and name of the file in which the private key is saved, for example, c:\privateKeyFile.pem.

Step 6   In the Private key password box, type the private key password (that you have invented).

Step 7   In the Retype private key password box, retype the private key password.

Step 8   From the Key length list, select the length of the key to be used.

Tip The choices for Key length are 512 or 1024 bits. The default and more secure choice is 1024 bits.

Step 9   From the Digest to sign with list, select the digest (or hashing algorithm).

Tip The choices for Digest to sign with are MD2, MD5, SHA, and SHA1. The default is SHA1.

Step 10   Click Submit.

Result: Cisco Secure ACS displays a CSR in the display area, on the right, under a banner that reads: "Now your certificate signing request is ready. You can copy and paste it into any certification authority enrollment tool."

Tip You can copy and paste this certificate to the online enrollment tool of any CA.

Updating or Replacing a Cisco Secure ACS Certificate

Use this procedure to update or replace an existing Cisco Secure ACS certificate that is out-of-date or out-of-order.

Warning This procedure eliminates your existing Cisco Secure ACS certificate.

To install a new ACS certificate, follow these steps:

Step 2   Click ACS Certificate Setup.

Result: Cisco Secure ACS displays the Installed Certificate Information table on the ACS Certificate Setup page.

---

Note    If your Cisco Secure ACS has not already been enrolled with a certificate, you do not see the Installed Certificate Information table. Rather, you see the Install new certificate table. If this is the case, you can proceed to Step 5.

---

Step 3   Click Enroll New Certificate.

Result: A confirmation dialog box appears.

Step 4   To confirm that you intend to enroll a new certificate, click OK.

Result: The existing Cisco Secure ACS certificate is removed.

Step 5   You can now install the replacement certificate in the same manner as an original certificate. For detailed steps, see Installing a Cisco Secure ACS Server Certificate.

Global Authentication Setup

Use the Global Authentication Setup page to specify the settings for all EAP and MS-CHAP authentication requests.

Configuring Authentication Options

Use this procedure to select and configure how Cisco Secure ACS handles options for authentication. In particular, use this procedure to specify and configure the varieties of EAP that you allow, and to specify whether you allow either MS-CHAP Version 1 or MS-CHAP Version 2, or both.

For more information on the EAP-TLS Protocol, see About the EAP-TLS Protocol; for more information on the PEAP protocol, see About the PEAP Protocol. For details regarding how various password protocols are supported by the various databases, see Authentication Protocol-Database Compatibility.

To configure authentication options, follow these steps:

Step 2   Click Global Authentication Setup.

Result: Cisco Secure ACS displays the Global Authentication Setup page.

Step 3   If you want to allow PEAP, follow these steps:

Tip The PEAP client initial display message is the first challenge a user of a PEAP client sees when attempting authentication. It should direct the user on what to do next, for example, "Enter your passcode."

---

Note    PEAP supports a session resume feature. The session resume feature allows users to reauthenticate without entering a password provided that the session has not timed out. If the end-user client is restarted, the user must enter a password even if the session timeout interval has not ended.

---

Step 4   If you want to allow EAP-TLS, follow these steps:

---

Note    If you select Either comparison type, Cisco Secure ACS first compares the certificate name and, if necessary, then performs the certificate binary comparison.

---

Step 5   If you want to allow EAP-MD5, in the EAP Configuration table select the Allow EAP-MD5 check box.

Step 6   To enable MS-CHAP authentication, in the MS-CHAP Configuration table, select the check box(es) that correspond to each MS-CHAP version you want to use:

---

Note    You can select both check boxes to allow MS-CHAP authentication with either version; and likewise, at any time you can deselect one or both check boxes to disable the corresponding MS-CHAP authentication version.

---

Step 7   Click Submit + Restart.

Result: Cisco Secure ACS restarts its services and implements the authentication configuration options you selected.