User Guide for Cisco Secure ACS for Windows Server Version 3.3
System Configuration: Advanced

Table Of Contents

System Configuration: Advanced

CiscoSecure Database Replication

About CiscoSecure Database Replication

Replication Process

Replication Frequency

Important Implementation Considerations

Database Replication Versus Database Backup

Database Replication Logging

Replication Options

Replication Components Options

Outbound Replication Options

Inbound Replication Options

Implementing Primary and Secondary Replication Setups on Cisco Secure ACSes

Configuring a Secondary Cisco Secure ACS

Replicating Immediately

Scheduling Replication

Disabling CiscoSecure Database Replication

Database Replication Event Errors

RDBMS Synchronization

About RDBMS Synchronization

Users

User Groups

Network Configuration

Custom RADIUS Vendors and VSAs

RDBMS Synchronization Components

About CSDBSync

About the accountActions Table

Cisco Secure ACS Database Recovery Using the accountActions Table

Reports and Event (Error) Handling

Preparing to Use RDBMS Synchronization

Considerations for Using CSV-Based Synchronization

Preparing for CSV-Based Synchronization

Configuring a System Data Source Name for RDBMS Synchronization

RDBMS Synchronization Options

RDBMS Setup Options

Synchronization Scheduling Options

Synchronization Partners Options

Performing RDBMS Synchronization Immediately

Scheduling RDBMS Synchronization

Disabling Scheduled RDBMS Synchronizations

IP Pools Server

About IP Pools Server

Allowing Overlapping IP Pools or Forcing Unique Pool Address Ranges

Refreshing the AAA Server IP Pools Table

Adding a New IP Pool

Editing an IP Pool Definition

Resetting an IP Pool

Deleting an IP Pool

IP Pools Address Recovery

Enabling IP Pool Address Recovery


System Configuration: Advanced


This chapter addresses the CiscoSecure Database Replication and RDBMS Synchronization features found in the System Configuration section of Cisco Secure ACS for Windows Server. It contains the following sections:

This chapter contains the following topics:

CiscoSecure Database Replication

RDBMS Synchronization

IP Pools Server

IP Pools Address Recovery

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

Replication Process

Replication Frequency

Important Implementation Considerations

Database Replication Versus Database Backup

Database Replication Logging

Replication Options

Replication Components Options

Outbound Replication Options

Inbound Replication Options

Implementing Primary and Secondary Replication Setups on Cisco Secure ACSes

Configuring a Secondary Cisco Secure ACS

Replicating Immediately

Scheduling Replication

Disabling CiscoSecure Database Replication

Database Replication Event Errors

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:

Select the parts of the primary Cisco Secure ACS configuration to be replicated.

Control the timing of the replication process, including creating schedules.

Export selected configuration items from the primary Cisco Secure ACS.

Securely transport selected configuration data from the primary Cisco Secure ACS to one or more secondary Cisco Secure ACSes.

Update the secondary Cisco Secure ACSes to create matching configurations.

The following items cannot be replicated:

IP pool definitions (for more information, see About IP Pools Server).

Cisco Secure ACS certificate and private key files.

All external user database configurations, including Network Admission Control (NAC) databases.

Unknown user group mapping configuration.

User-defined RADIUS dictionaries (for more information, see Important Implementation Considerations).

Settings on the ACS Service Management page in the System Configuration section.

All logging configurations.

RDBMS Synchronization settings.

Third-party software, such as Novell Requestor or RSA ACE client software.

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

Primary Cisco Secure ACS—A Cisco Secure ACS that sends replicated CiscoSecure database components to other Cisco Secure ACSes.

Secondary Cisco Secure ACS—A Cisco Secure ACS that receives replicated CiscoSecure database components from a primary Cisco Secure ACS. In the HTML interface, these are identified as replication partners.

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 a 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.2, all secondary Cisco Secure ACSes should be running Cisco Secure ACS version 3.2. 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. The following steps occur in database replication:

1. The primary Cisco Secure ACS determines if its database has changed since the last successful replication. If it has, replication proceeds. If it has not, replication is aborted. No attempt is made to compare the databases of the primary and secondary Cisco Secure ACSes.


Tip You can force replication to occur by making one change to a user or group profile, such as changing a password or modifying a RADIUS attribute.


2. The primary Cisco Secure ACS contacts the secondary Cisco Secure ACS. In this initial connection, the following four events occur:

a. The two Cisco Secure ACSes perform mutual authentication based upon the shared secret of the primary Cisco Secure ACS. If authentication fails, replication fails.


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.


b. The secondary Cisco Secure ACS verifies that it is not configured to replicate to the primary Cisco Secure ACS. If it is, replication is aborted. Cisco Secure ACS does not support bidirectional replication, wherein a Cisco Secure ACS can act as both a primary and a secondary Cisco Secure ACS to the same remote Cisco Secure ACS.

c. The primary Cisco Secure ACS verifies that the version of Cisco Secure ACS that the secondary Cisco Secure ACS is running is the same as its own version of Cisco Secure ACS. If not, replication fails.

d. The primary Cisco Secure ACS compares the list of database components it is configured to send with the list of database components the secondary Cisco Secure ACS is configured to receive. If the secondary Cisco Secure ACS is not configured to receive any of the components that the primary Cisco Secure ACS is configured to send, the database replication fails.

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

a. The primary Cisco Secure ACS stops its authentication and creates a copy of the CiscoSecure database components that it is configured to replicate. During this step, if AAA clients are configured properly, those that usually use the primary Cisco Secure ACS failover to another Cisco Secure ACS.

b. The primary Cisco Secure ACS resumes its authentication service. It also compresses and encrypts the copy of its database components for transmission to the secondary Cisco Secure ACS.

c. The primary Cisco Secure ACS transmits the compressed, encrypted copy of its database components to the secondary Cisco Secure ACS. This transmission occurs over a TCP connection, using port 2000. The TCP session uses a 128-bit encrypted, Cisco-proprietary protocol.

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

a. The secondary Cisco Secure ACS receives the compressed, encrypted copy of the CiscoSecure database components from the primary Cisco Secure ACS. After transmission of the database components is complete, the secondary Cisco Secure ACS decompresses the database components.

b. The secondary Cisco Secure ACS stops its authentication service and replaces its database components with the database components it received from the primary Cisco Secure ACS. During this step, if AAA clients are configured properly, those that usually use the secondary Cisco Secure ACS failover to another Cisco Secure ACS.

c. The secondary Cisco Secure ACS resumes its authentication service.

Cisco Secure ACS can act as both a primary Cisco Secure ACS and a secondary Cisco Secure ACS. Figure 9-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.


Note If you intend to use cascading replication to replicate network configuration device tables, you must configure the primary Cisco Secure ACS with all Cisco Secure ACSes that will receive replicated database components, regardless of whether they receive replication directly or indirectly from the primary Cisco Secure ACS. In Figure 9-1, server 1 must have an entry in its AAA Servers table for each of the other six Cisco Secure ACSes. If this is not done, after replication, servers 2 and 3 do not have servers 4 through 7 in their AAA Servers tables and replication will fail.


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.

Figure 9-1 Cascading Database Replication

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


Note Regardless of how frequently replication is scheduled to occur, it only occurs when the database of the primary Cisco Secure ACS has changed since the last successful replication.


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:

Cisco Secure ACS only supports database replication to other Cisco Secure ACSes. All Cisco Secure ACSes participating in CiscoSecure database replication must run the same version of Cisco Secure ACS. We strongly recommend that Cisco Secure ACSes involved in replication use the same patch level, too.

You must ensure correct configuration of the AAA Servers table in all Cisco Secure ACSes involved in replication.

In its AAA Servers table, a primary Cisco Secure ACS must have an accurately configured entry for each secondary Cisco Secure ACS.


Note If you intend to use cascading replication to replicate network configuration device tables, you must configure the primary Cisco Secure ACS with all Cisco Secure ACSes that will receive replicated database components, regardless of whether they receive replication directly or indirectly from that primary Cisco Secure ACS. For example, if the primary Cisco Secure ACS replicates to two secondary Cisco Secure ACSes which, in turn, each replicate to two more Cisco Secure ACSes, the primary Cisco Secure ACS must have AAA server configurations for all six Cisco Secure ACSes that will receive replicated database components.


In its AAA Servers table, a secondary Cisco Secure ACS must have an accurately configured entry for each of its primary Cisco Secure ACSes.

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

Only suitably configured, valid Cisco Secure ACSes can be secondary Cisco Secure ACSes. To configure a secondary Cisco Secure ACS for database replication, see Configuring a Secondary Cisco Secure ACS.

Replication only occurs when the database of the primary Cisco Secure ACS has changed since the last successful replication, regardless of how frequently replication is scheduled to occur. When a scheduled or manually started replication begins, the primary Cisco Secure ACS automatically aborts replication if its database has not changed since the last successful replication.


Tip You can force replication to occur by making one change to a user or group profile, such as changing a password or modifying a RADIUS attribute.


Replication to secondary Cisco Secure ACSes takes place sequentially in the order listed in the Replication list under Replication Partners on the CiscoSecure Database Replication page.

A secondary Cisco Secure ACS receiving replicated components must be configured to accept database replication from the primary Cisco Secure ACS. To configure a secondary Cisco Secure ACS for database replication, see Configuring a Secondary Cisco Secure ACS.

Cisco Secure ACS does not support bidirectional database replication. The secondary Cisco Secure ACS receiving the 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.

If you replicate user accounts, be sure to name external database configurations identically on primary and secondary Cisco Secure ACSes. A replicated user account retains its association with the database assigned to provide authentication or posture validation service, regardless of whether a database configuration of the same name exists on the secondary Cisco Secure ACS. For example, if user account is associated with a database named "WestCoast LDAP" on the primary Cisco Secure ACS, the replicated user account on all secondary Cisco Secure ACSes remains associated with an external user database named "WestCoast LDAP" even if you have not configured an LDAP database instance of that name.

If you replicate NAC policies, secondary Cisco Secure ACSes associate policies to NAC databases by the order in which the NAC databases were created, not by the database name. For example, if the primary Cisco Secure ACS has the following NAC database and policy configuration:

"NAC DB One" with "Policy One" selected.

"NAC DB Two" with "Policy Two" selected.

and if a secondary Cisco Secure ACS is configured first with a NAC database named "NAC DB Two" and second with a NAC database named "NAC DB One", then the following policy selection results after replication occurs:

"NAC DB One" with "Policy Two" selected.

"NAC DB Two" with "Policy One" selected.

To replicate user and group settings that use user-defined RADIUS vendor and VSAs, you must manually add the user-defined RADIUS vendor and VSA definitions on primary and secondary Cisco Secure ACSes, making sure that the RADIUS vendor slots that the user-defined RADIUS vendors occupy are identical on each Cisco Secure ACS. After you have done so, replication of settings using user-defined RADIUS vendors and VSAs is supported. For more information about user-defined RADIUS vendors and VSAs, see Custom RADIUS Vendors and VSAs.

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 "CSUtil Database Utility".

Database Replication Logging

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

The Windows Event Log

The Database Replication report

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

Replication Options

The Cisco Secure ACS HTML interface provides three sets of options for configuring CiscoSecure Database Replication, documented in this section.

This section contains the following topics:

Replication Components Options

Outbound Replication Options

Inbound Replication Options

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:

User and group database—Replicate information for groups and users. Using this option excludes the use of the "Group database only" option.

Group database only—Replicate information for groups, but not for users. Using this option excludes the use of the "User and group database" option.

Network Configuration Device tables—Replicate the AAA Servers tables and the AAA Clients tables in the Network Configuration section. This also controls whether NDGs are replicated.


Note If you intend to use cascading replication to replicate network configuration device tables, you must configure the primary Cisco Secure ACS with all Cisco Secure ACSes that will receive replicated database components, regardless of whether they receive replication directly or indirectly from the primary Cisco Secure ACS. For example, if the primary Cisco Secure ACS replicates to two secondary Cisco Secure ACSes which, in turn, each replicate to two more Cisco Secure ACSes, the primary Cisco Secure ACS must have AAA server configurations for all six Cisco Secure ACSes that will receive replicated database components.


Distribution table—Replicate the Proxy Distribution Table in the Network Configuration section.

Interface configuration—Replicate Advanced Options settings, RADIUS settings, and TACACS+ settings from the Interface Configuration section.

Interface security settings—Replicate administrators and security information for the Cisco Secure ACS HTML interface.

Password validation settings—Replicate password validation settings.

EAP-FAST master keys and policies—Replicate active and retired master keys and policies for EAP-FAST.

CNAC policies—Replicate NAC local policies, external policies, and attribute definitions.

If mirroring the entire database might send confidential information to the secondary Cisco Secure ACS, 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.

Scheduling Options—You can specify when CiscoSecure database replication occurs. The options that control when replication occurs appear in the Scheduling section of Outbound Replication table and are as follows:

Manually—Cisco Secure ACS does not perform automatic database replication.

Automatically Triggered Cascade—Cisco Secure ACS performs database replication to the configured list of secondary Cisco Secure ACSes when database replication from a primary Cisco Secure ACS completes. This enables you to build a propagation hierarchy of Cisco Secure ACS, relieving a primary Cisco Secure ACS from the burden of propagating the replicated components to every other Cisco Secure ACS. For an illustration of cascade replication, see Figure 9-1.


Note If you intend to use cascading replication to replicate network configuration device tables, you must configure the primary Cisco Secure ACS with all Cisco Secure ACSes that will receive replicated database components, regardless of whether they receive replication directly or indirectly from the primary Cisco Secure ACS. For example, if the primary Cisco Secure ACS replicates to two secondary Cisco Secure ACSes which, in turn, each replicate to two more Cisco Secure ACSes, the primary Cisco Secure ACS must have AAA server configurations for all six Cisco Secure ACSes that will receive replicated database components.


Every X minutes—Cisco Secure ACS performs, on a set frequency, database replication to the configured list of secondary Cisco Secure ACSes. The unit of measurement is minutes, with a default update frequency of 60 minutes.

At specific times...—Cisco Secure ACS performs, at the time specified in the day and hour graph, database replication to the configured list of secondary Cisco Secure ACSes. The minimum interval is one hour, and the replication takes place on the hour selected.

Partner Options—You can specify the secondary Cisco Secure ACSes for this primary Cisco Secure ACS. The options that control the secondary Cisco Secure ACSes to which a primary Cisco Secure ACS replicates appear in the Partners section of the Outbound Replication table.


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.


AAA Server—This list represents the secondary Cisco Secure ACSes that this primary Cisco Secure ACS does not send replicated components to.

Replication—This list represents the secondary Cisco Secure ACSes that this primary Cisco Secure ACS does send replicated components to.

Replication timeout—Use this text box to specify the number of minutes that this primary Cisco Secure ACS continues replicating to a secondary Cisco Secure ACS. When the timeout value is exceeded, Cisco Secure ACS terminates replication to the secondary Cisco Secure ACS is was attempting to replicate to and then it restarts the CSAuth service. The replication timeout feature helps prevent loss of AAA services due to stalled replication communication, which can occur when the network connection between the primary and secondary Cisco Secure ACS is abnormally slow or when a fault occurs within either Cisco Secure ACS. The default value is five minutes.


Tip The size of the components replicated affects the time required for replication. For example, replicating a user database containing 80,000 user profiles takes more time than replicating a user database containing 500 user profiles. You may need to monitor successful replication events to determine a reasonable timeout value for your implementation.



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.


Inbound Replication Options

You can specify the primary Cisco Secure ACSes from which a secondary Cisco Secure ACS accepts replication. 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:

Any Known CiscoSecure ACS Server—If this option is selected, Cisco Secure ACS accepts replicated components from any Cisco Secure ACS configured in the AAA Servers table in Network Configuration.

Other AAA servers—The list displays all the AAA servers configured in the AAA Servers table in Network Configuration. If a specific AAA server name is selected, Cisco Secure ACS accepts replicated components only from the Cisco Secure ACS specified.


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.


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 ACSes. For an illustration of cascade replication, see Figure 9-1.

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


Step 1 On each secondary Cisco Secure ACS, follow these steps:

a. In the Network Configuration section, add the primary Cisco Secure ACS to the AAA Servers table.

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

b. Configure the secondary Cisco Secure ACS to receive replicated components. For instructions, see Configuring a Secondary Cisco Secure ACS.

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

a. In the Network Configuration section, add each secondary Cisco Secure ACS to the AAA Servers table.


Note If you intend to use cascading replication to replicate network configuration device tables, you must configure the primary Cisco Secure ACS with all Cisco Secure ACSes that will receive replicated database components, regardless of whether they receive replication directly or indirectly from the primary Cisco Secure ACS. For example, if the primary Cisco Secure ACS replicates to two secondary Cisco Secure ACSes which, in turn, each replicate to two more Cisco Secure ACSes, the primary Cisco Secure ACS must have AAA server configurations for all six Cisco Secure ACSes that will receive replicated database components.


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

b. If you want to replicate according to a schedule, at intervals, or whenever the primary Cisco Secure ACS has received replicated components from another Cisco Secure ACS, see Scheduling Replication.

c. If you want to initiate replication immediately, see Replicating Immediately.


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. Select the Distributed System Settings check box if not already selected.


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 1 Log in to the HTML interface on the secondary Cisco Secure ACS.

Step 2 In the navigation bar, click System Configuration.

Step 3 Click CiscoSecure Database Replication.

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 name of the primary Cisco Secure ACS.

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.

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

Ensure correct configuration of the primary and secondary Cisco Secure ACSes. For detailed steps, see Implementing Primary and Secondary Replication Setups on Cisco Secure ACSes.

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

To initiate database replication immediately, follow these steps:


Step 1 Log in to the HTML interface on the primary Cisco Secure ACS.

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. Select the Distributed System Settings check box if not already selected.


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 to replicate its select components to, select the secondary Cisco Secure ACS 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 In the Replication timeout text box, specify how long this Cisco Secure ACS will perform replication to each of its secondary Cisco Secure ACS before terminating the replication attempt and restarting the CSAuth service.

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

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


Note Replication only occurs when the database of the primary Cisco Secure ACS has changed since the last successful replication. You can force replication to occur by making one change to a user or group profile, such as changing a password or RADIUS attribute.



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

Ensure correct configuration of the primary and secondary Cisco Secure ACSes. For detailed steps, see Implementing Primary and Secondary Replication Setups on Cisco Secure ACSes.

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.

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


Step 1 Log in to the HTML interface on the primary Cisco Secure ACS.

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. Select the Distributed System Settings check box if not already selected.


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.


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:

a. In the Outbound Replication table, select the At specific times option.

b. In the day and hour graph, click the times at which you want Cisco Secure ACS to perform replication.


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 to this Cisco Secure ACS; 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.


a. In the Outbound Replication table, from the AAA Servers list, select the name of a secondary Cisco Secure ACS to which you want the primary Cisco Secure ACS to send its selected replicated database components.


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.


b. Click --> (right arrow button).

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

c. Repeat Step a and Step b for each secondary Cisco Secure ACS to which you want the primary Cisco Secure ACS to send its selected replicated database components.

Step 9 In the Replication timeout text box, specify how long this Cisco Secure ACS will perform replication to each of its secondary Cisco Secure ACS before terminating the replication attempt and restarting the CSAuth service.

Step 10 Click Submit.

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 1 Log in to the HTML interface on the primary Cisco Secure ACS.

Step 2 In the navigation bar, click System Configuration.

Step 3 Click CiscoSecure Database Replication.

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.

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

Users

User Groups

Network Configuration

Custom RADIUS Vendors and VSAs

RDBMS Synchronization Components

About CSDBSync

About the accountActions Table

Cisco Secure ACS Database Recovery Using the accountActions Table

Reports and Event (Error) Handling

Preparing to Use RDBMS Synchronization

Considerations for Using CSV-Based Synchronization

Preparing for CSV-Based Synchronization

Configuring a System Data Source Name for RDBMS Synchronization

RDBMS Synchronization Options

RDBMS Setup Options

Synchronization Scheduling Options

Synchronization Partners Options

Performing RDBMS Synchronization Immediately

Scheduling RDBMS Synchronization

Disabling Scheduled RDBMS Synchronizations

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:

Adding users.

Deleting users.

Setting passwords.

Setting user group memberships.

Setting Max Sessions parameters.

Setting network usage quota parameters.

Configuring command authorizations.

Configuring network access restrictions.

Configuring time-of-day/day-of-week access restrictions.

Assigning IP addresses.

Specifying outbound RADIUS attribute values.

Specifying outbound TACACS+ attribute values.


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


User Groups

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

Setting Max Sessions parameters.

Setting network usage quota parameters.

Configuring command authorizations.

Configuring network access restrictions.

Configuring time-of-day/day-of-week access restrictions.

Specifying outbound RADIUS attribute values.

Specifying outbound TACACS+ attribute values.


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


Network Configuration

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

Adding AAA clients.

Deleting AAA clients.

Setting AAA client configuration details.

Adding AAA servers.

Deleting AAA servers.

Setting AAA server configuration details.

Adding and configuring Proxy Distribution Table entries.


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


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 If you intend to replicate user-defined RADIUS vendor and VSA configurations, user-defined RADIUS vendor and VSA definitions to be replicated must be identical on the primary and secondary Cisco Secure ACSes, including the RADIUS vendor slots that the user-defined RADIUS vendors occupy. For more information about database replication, see CiscoSecure Database Replication.


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:

CSDBSync—A dedicated Windows  service that performs automated user and group account management services for Cisco Secure ACS.

accountActions Table—The data object that holds information used by CSDBSync to update the CiscoSecure user database.

About CSDBSync

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

Figure 9-2 RDBMS Synchronization

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. In a distributed environment, a single Cisco Secure ACS, known as the senior synchronization partner, accesses the accountActions table and sends synchronization commands to its synchronization partners. In Figure 9-2, Cisco Secure Access Control Server 1 is the senior synchronization partner and the other two Cisco Secure ACSes are its synchronization partners.


Note The senior synchronization partner must have AAA configurations for each Cisco Secure ACS that is a synchronization partners. In turn, each of the synchronization partners must have a AAA server configuration for the senior partner. Synchronization commands from the senior partner are ignored if the Cisco Secure ACS receiving the synchronization commands does not have a AAA server configuration for the senior partner.


CSDBSync both reads and writes (deletes records) in the accountActions table. After CSDBSync processes each record, it deletes the record from the 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 "Overview".

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 if 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:

Access—Contains the file C:\Program Files\CiscoSecure ACS v.

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.


CSV—Contains the files CiscoSecure Transactions.mdb and accountactions.

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

Oracle 7—Contains the files schema.ini and accountActions.sql.

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

Oracle 8—Contains the files testData.sql and accountActions.sql.

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

SQL Server 6.5—Contains the files testData.sql and accountActions.sql.

The testData.sql file contains the Microsoft SQL Server 6.5 SQL procedure needed to generate an accountActions table. The accountActions.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 1 Determine where you want to create the accountActions table and in what format. For more information about the accountActions table, see About the accountActions Table. For details on the format and content of the accountActions table, see "RDBMS Synchronization Import Definitions".

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 that your third-party system 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 6 and Step 7.


Step 5 If you have a distributed AAA environment and want to synchronize multiple Cisco Secure ACSes, follow these steps:

a. Determine which Cisco Secure ACS you want to use to communicate with the third-party system. This is the senior synchronization partner, which you will later configure to send synchronization data to its synchronization partners, which are the other Cisco Secure ACSes needing synchronization.

b. On the senior synchronization partner, verify that there is a AAA server configuration for each synchronization partner. Add AAA server configuration for each missing synchronization partner. For detailed steps about adding a AAA server, see Adding a AAA Server.

c. On all the other synchronization partners, verify that there is a AAA server configuration for the senior synchronization partner. If no AAA server configuration for the senior synchronization partner exists, create one. For detailed steps about adding a AAA server, see Adding a AAA Server.

Synchronization between the senior synchronization partner and the other synchronization partners is enabled.

Step 6 Set up a system DSN on the senior synchronization partner (the Cisco Secure ACS that will communicate with the third-party system). For steps, see Configuring a System Data Source Name for RDBMS Synchronization.

Step 7 Schedule RDBMS synchronization on the senior synchronization partner. For steps, see Scheduling RDBMS Synchronization.

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

Step 9 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:


Step 1 Rename the accountactions CSV file installed on the computer running Cisco Secure ACS to testData.sql.

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:

a. Access the following key:

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

b. Change the OdbcUpdateTable value from accountactions.csv to C:\Program Files\CiscoSecure ACS v.


Note You cannot perform synchronization using a relational database table rather than a CSV file when the OdbcUpdateTable value is HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\CiscoAAAv. To do so, you must change the OdbcUpdateTable value back to AccountActions.


c. Save your changes to the Registry.

Cisco Secure ACS is configured to perform CSV-based synchronization only, using a file named accountactions.csv.

Step 3 At a DOS prompt, follow these steps:

a. Type:

net stop CSDBSync 

and then press Enter.

b. Type:

net start CSDBSync 

and then press Enter.

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 accountactions.csv Microsoft Access database provided with Cisco Secure ACS, you can use the accountactions.csv system DSN rather than create one.

For more information about the AccountActions file, see Preparing to Use RDBMS Synchronization.

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


Step 1 From Windows Control Panel, open the ODBC Data Source Administrator window.


Tip In Windows 2000, the ODBC Data Sources icon is located in the Administrative Tools folder.


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.

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.

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

Step 8 Close the ODBC window and Windows Control Panel.

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 RDBMS Synchronization feature. It contains three tables whose options are described in this section.

This section contains the following topics:

RDBMS Setup Options

Synchronization Scheduling Options

Synchronization Partners Options

RDBMS Setup Options

The RDBMS Setup table defines how Cisco Secure ACS accesses the accountActions table. It contains the following options:

Data Source—Specifies which of all the system DSNs available on the Cisco Secure ACS is to be used to access the accountActions table.

Username—Specifies the username Cisco Secure ACS should use to access the database that contains the accountActions table.


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


Password—Specifies the password Cisco Secure ACS uses to access the database that contains the accountActions table.

Synchronization Scheduling Options

The Synchronization Scheduling table defines when synchronization occurs. It contains the following scheduling options:

Manually—Cisco Secure ACS does not perform automatic RDBMS synchronization.

Every X minutes—Cisco Secure ACS performs synchronization on a set frequency. The unit of measurement is minutes, with a default update frequency of 60 minutes.

At specific times...—Cisco Secure ACS performs synchronization at the time specified in the day and hour graph. The minimum interval is one hour, and the synchronization takes place on the hour selected.

Synchronization Partners Options

The Synchronization Partners table defines which Cisco Secure ACSes are synchronized with data from the accountActions table. It provides the following options:

AAA Server—This list represents the AAA servers configured in the AAA Servers table in Network Configuration for which the Cisco Secure ACS does not perform RDBMS synchronization.

Synchronize—This list represents the AAA servers configured in the AAA Servers table in Network Configuration for which the Cisco Secure ACS does perform RDBMS synchronization. The AAA servers on this list are the synchronization partners of this Cisco Secure ACS. During synchronization, communication between this Cisco Secure ACS and its synchronization partners is 128-bit encrypted with a Cisco-proprietary protocol. The synchronization partners receive synchronization data on TCP port 2000.


Note Each synchronization partner must have a AAA server configuration in its Network Configuration section that corresponds to this Cisco Secure ACS; otherwise, the synchronization commands this Cisco Secure ACS sends to it are ignored.


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 1 In the navigation bar, click System Configuration.

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.


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.


a. From the Data Source list, select the system DSN you configured to communicate with the database that contains your accountActions table.

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

b. In the Username box, type the username for a database user account that has read/write access to the accountActions table.

c. In the Password box, type the password for the username specified in the Step b.

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

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

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

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

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 1 In the navigation bar, click System Configuration.

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.


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.


a. From the Data Source list, select the system DSN you configured to communicate with the database that contains your accountActions table.

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

b. In the Username box, type the username for a database user account that has read/write access to the accountActions table.

c. In the Password box, type the password for the username specified in the Step b.

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:

a. Under Synchronization Scheduling, select the At specific times option.

b. In the day and hour graph, click the times at which you want Cisco Secure ACS to perform replication.


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.


a. In the Synchronization Partners table, from the AAA Servers list, select the name of a Cisco Secure ACS that you want this Cisco Secure ACS to update with data from the accountActions table.


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.


b. Click --> (right arrow button).

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.

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 1 In the navigation bar, click System Configuration.

Step 2 Click RDBMS Synchronization.

The RDBMS Synchronization Setup page appears.

Step 3 Under Synchronization Scheduling, select the Manually option.

Step 4 Click Submit.

Cisco Secure ACS does not perform scheduled RDBMS synchronizations.


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

Allowing Overlapping IP Pools or Forcing Unique Pool Address Ranges

Refreshing the AAA Server IP Pools Table

Adding a New IP Pool

Editing an IP Pool Definition

Resetting an IP Pool

Deleting an IP Pool

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

Allow Overlapping Pool Address Ranges—Indicates that overlapping IP pool address ranges are not allowed. Clicking this button allows IP address ranges to overlap between pools.

Force Unique Pool Address Range—Indicates that overlapping IP pool address ranges are allowed. Clicking this button prevents IP address ranges from overlapping between pools.

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


Step 1 In the navigation bar, click System Configuration.

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.


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:

a. If the Allow Overlapping Pool Address Ranges button appears, click that button.

Cisco Secure ACS allows overlapping IP pool address ranges.

b. If the Force Unique Pool Address Range button appears, do nothing.

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:

a. If the Allow Overlapping Pool Address Ranges button appears, do nothing.

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

b. If the Force Unique Pool Address Range button appears, click that button.

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 1 In the navigation bar, click System Configuration.

Step 2 Click IP Pools Server.

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.

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 1 In the navigation bar, click System Configuration.

Step 2 Click IP Pools Server.

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.

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.

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 1 In the navigation bar, click System Configuration.

Step 2 Click IP Pools Server.

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.

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.

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 1 In the navigation bar, click System Configuration.

Step 2 Click IP Pools Server.

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.

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.

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

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

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 1 In the navigation bar, click System Configuration.

Step 2 Click IP Pools Server.

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.

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.

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.

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 1 In the navigation bar, click System Configuration.

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.


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.

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