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

Table Of Contents

System Configuration: Advanced

CiscoSecure Database Replication

About CiscoSecure Database Replication

Important Implementation Considerations

Database Replication Versus Database Backup

Database Replication Logging

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

RDBMS Synchronization Components

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

Configuring a System Data Source Name for RDBMS Synchronization

RDBMS Synchronization 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 CiscoSecure ACS for WindowsServer. 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 CiscoSecure 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 CiscoSecure ACSes

Configuring a Secondary CiscoSecure ACS

Replicating Immediately

Scheduling Replication

Disabling CiscoSecure Database Replication

Database Replication Event Errors

About CiscoSecure Database Replication

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

Database replication allows you to do the following:

Select the parts of the primary CiscoSecure ACS configuration to be replicated.

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

Export selected configuration items from the primary CiscoSecure ACS.

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

Update the secondary CiscoSecure ACSes to create matching configurations.

The following items cannot be replicated:

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

CiscoSecure ACS certificate and private key files.

External user database configuration.

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 external user database configurations.

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

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

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

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


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



Note All CiscoSecure ACSes involved in replication must run the same release of the CiscoSecure ACS software. For example, if the primary CiscoSecure ACS is running CiscoSecure ACS version3.2, all secondary CiscoSecure ACSes should be running CiscoSecure ACSversion3.2. Because patch releases can introduce significant changes to the CiscoSecure database, we strongly recommend that CiscoSecure 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 CiscoSecure ACS and each of its secondary CiscoSecure ACSes. The following steps occur in database replication:

1. The primary CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS contacts the secondary CiscoSecure ACS. In this initial connection, the following four events occur:

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


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


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

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

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

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

a. The primary CiscoSecure 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 CiscoSecure ACS failover to another CiscoSecure ACS.

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

c. The primary CiscoSecure ACS transmits the compressed, encrypted copy of its database components to the secondary CiscoSecure 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 CiscoSecure ACS, the database replication process continues on the secondary CiscoSecure ACS as follows:

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

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

c. The secondary CiscoSecure ACS resumes its authentication service.

CiscoSecure ACS can act as both a primary CiscoSecure ACS and a secondary CiscoSecure ACS. Figure9-1 shows a cascading replication scenario. Server 1 acts only as a primary CiscoSecure ACS, replicating to servers 2 and 3, which act as secondary CiscoSecure ACSes. After replication from server 1 to server 2 has completed, server 2 acts as a primary CiscoSecure ACS while replicating to servers 4 and 5. Similarly, server 3 acts as a primary CiscoSecure 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 CiscoSecure ACS with all CiscoSecure ACSes that will receive replicated database components, regardless of whether they receive replication directly or indirectly from the primary CiscoSecure ACS. In Figure9-1, server 1 must have an entry in its AAA Servers table for each of the other six CiscoSecure 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. CiscoSecure ACS cannot support such a configuration, known as bidirectional replication. To safeguard against this, a secondary CiscoSecure ACS aborts replication when its primary CiscoSecure ACS appears on its Replication list.

Figure 9-1 Cascading Database Replication

Replication Frequency

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

There is a cost to having frequent replications. The more frequent the replication, the higher the load on a multi-CiscoSecure 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 CiscoSecure ACS.


Note Regardless of how frequently replication is scheduled to occur, it only occurs when the database of the primary CiscoSecure 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 CiscoSecure 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:

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

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

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


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


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

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

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

Replication only occurs when the database of the primary CiscoSecure 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 CiscoSecure 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 CiscoSecure ACSes takes place sequentially in the order listed in the Replication list under Replication Partners on the CiscoSecure Database Replication page.

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

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

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 CiscoSecure ACSes, making sure that the RADIUS vendor slots that the user-defined RADIUS vendors occupy are identical on each CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS or the CiscoSecure database, see CiscoSecure ACS Backup, and "RDBMS Synchronization Import Definitions."


Database Replication Logging

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

For more information about CiscoSecure ACS reports, see "Overview"

Replication Options

The CiscoSecure 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 CiscoSecure ACS sends as a primary CiscoSecure ACS and the components that it receives as a secondary CiscoSecure ACS.


Note The CiscoSecure database components received by a secondary CiscoSecure ACS overwrite the CiscoSecure database components on the secondary CiscoSecure 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.

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 CiscoSecure ACS with all CiscoSecure ACSes that will receive replicated database components, regardless of whether they receive replication directly or indirectly from the primary CiscoSecure ACS. For example, if the primary CiscoSecure ACS replicates to two secondary CiscoSecure ACSes which, in turn, each replicate to two more CiscoSecure ACSes, the primary CiscoSecure ACS must have AAA server configurations for all six CiscoSecure 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 CiscoSecure ACS HTML interface.

Password validation settings —Replicate password validation settings.

If mirroring the entire database might send confidential information to the secondary CiscoSecure ACS, such as the Proxy Distribution Table, you can configure the primary CiscoSecure 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 CiscoSecure ACSes for this primary CiscoSecure 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 —CiscoSecure ACS does not perform automatic database replication.

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


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


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

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

Partner Options —You can specify the secondary CiscoSecure ACSes for this primary CiscoSecure ACS. The options that control the secondary CiscoSecure ACSes to which a primary CiscoSecure 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 CiscoSecure ACS available as a secondary CiscoSecure ACS, you must first add that CiscoSecure ACS to the AAA Servers table of the primary CiscoSecure ACS.


AAA Server —This list represents the secondary CiscoSecure ACSes that this primary CiscoSecure ACSdoes not send replicated components to.

Replication —This list represents the secondary CiscoSecure ACSes that this primary CiscoSecure ACSdoes send replicated components to.


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


Inbound Replication Options

You can specify the primary CiscoSecure ACSes from which a secondary CiscoSecure ACS accepts replication. This option appears in the Inbound Replication table on the CiscoSecure Database Replication page.

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

Any Known CiscoSecure ACS Server —If this option is selected, CiscoSecure ACS accepts replicated components from any CiscoSecure 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, CiscoSecure ACS accepts replicated components only from the CiscoSecure ACS specified.


Note CiscoSecure ACS does not support bidirectional database replication. A secondary CiscoSecure ACS receiving replicated components verifies that the primary CiscoSecure ACS is not on its Replication list. If not, the secondary CiscoSecure 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 CiscoSecure ACS configured to replicate only when it has received replicated components from another CiscoSecure ACS acts both as a primary CiscoSecure ACS and as a secondary CiscoSecure ACS. First, it acts as a secondary CiscoSecure ACS while it receives replicated components, and then it acts as a primary CiscoSecure ACS while it replicates components to other CiscoSecure ACSes. For an illustration of cascade replication, see Figure9-1.

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


Step1 On each secondary CiscoSecure 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 .

Step2 On the primary CiscoSecure 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 CiscoSecure ACS with all CiscoSecure ACSes that will receive replicated database components, regardless of whether they receive replication directly or indirectly from the primary CiscoSecure ACS. For example, if the primary CiscoSecure ACS replicates to two secondary CiscoSecure ACSes which, in turn, each replicate to two more CiscoSecure ACSes, the primary CiscoSecure ACS must have AAA server configurations for all six CiscoSecure 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 CiscoSecure ACSes to act as secondary CiscoSecure ACSes. The components that a secondary CiscoSecure ACS is to receive must be explicitly specified, as must be its primary CiscoSecure ACS.

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


Caution The CiscoSecure database components received by a secondary CiscoSecure ACS overwrite the CiscoSecure database components on the secondary CiscoSecure 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 CiscoSecure ACS. This secondary CiscoSecure ACS must have an entry in its AAA Servers table for each of its primary CiscoSecure ACSes. Also, the AAA Servers table entry for each primary CiscoSecure ACS must have the same shared secret that the primary CiscoSecure 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 CiscoSecure ACS to be a secondary CiscoSecure ACS, follow these steps:


Step1 Log in to the HTML interface on the secondary CiscoSecure ACS.

Step2 In the navigation bar, click System Configuration .

Step3 Click CiscoSecure Database Replication .

The Database Replication Setup page appears.

Step4 In the Replication Components table, select the Receive check box for each database component to be received from a primary CiscoSecure ACS.

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

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


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


Step6 If the secondary CiscoSecure ACS is to receive replication components from only one primary CiscoSecure ACS, from the Accept replication from list, select the name of the primary CiscoSecure ACS.

The primary CiscoSecure 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 CiscoSecure ACS and all secondary CiscoSecure ACSes, the AAA Servers table entries for the primary CiscoSecure ACS must have identical shared secrets.


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

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


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


Step8 Click Submit .

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


Replicating Immediately

You can manually start database replication.


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


Before You Begin

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

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

To initiate database replication immediately, follow these steps:


Step1 Log in to the HTML interface on the primary CiscoSecure ACS.

Step2 In the navigation bar, click System Configuration .

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

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

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


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



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


Step6 At the bottom of the browser window, click Replicate Now .

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


Note Replication only occurs when the database of the primary CiscoSecure 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 CiscoSecure ACS sends its replicated database components to a secondary CiscoSecure ACS. For more information about replication scheduling options, see Outbound Replication Options.


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


Before You Begin

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

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

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


Step1 Log in to the HTML interface on the primary CiscoSecure ACS.

Step2 In the navigation bar, click System Configuration .

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

Step4 To specify which CiscoSecure database components the primary CiscoSecure ACS should send to its secondary CiscoSecure 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.

Step5 To have the primary CiscoSecure ACS send replicated database components to its secondary CiscoSecure 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 CiscoSecure ACS should perform replication (up to 7 characters).


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


Step6 If you want to schedule times at which the primary CiscoSecure ACS sends its replicated database components to its secondary CiscoSecure 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.


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


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


Step8 You must specify the secondary CiscoSecure ACSes that this CiscoSecure ACS should replicate to. To do so, follow these steps:


Note CiscoSecure ACS does not support bidirectional database replication. A secondary CiscoSecure ACS receiving replicated database components verifies that the primary CiscoSecure ACS is not on its Replication list. If not, the secondary CiscoSecure 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 CiscoSecure 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 CiscoSecure 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.

Step9 Click Submit .

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


Step1 Log in to the HTML interface on the primary CiscoSecure ACS.

Step2 In the navigation bar, click System Configuration .

Step3 Click CiscoSecure Database Replication .

The Database Replication Setup page appears.

Step4 In the Replication Components table, clear all check boxes.

Step5 In the Outbound Replication table, select the Manually option.

Step6 Click Submit .

CiscoSecure ACS does not permit any replication to or from this CiscoSecure 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 CiscoSecure ACS System Logs.

RDBMS Synchronization

This section provides information about the RDBMS Synchronization feature, including procedures for implementing this feature, within both CiscoSecure 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

CiscoSecure 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, CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS can update the internal databases of other CiscoSecure ACSes, so that you only need configure RDBMS Synchronization on one CiscoSecure ACS. CiscoSecure ACSes listen on TCP port 2000 for synchronization data. RDBMS Synchronization communication between CiscoSecure 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), CiscoSecure 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 number26.

You can define up to ten custom RADIUS vendors. CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 Figure9-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. 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 CiscoSecure 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 CiscoSecure ACS and the third-party system attempt to access the accountActions table simultaneously.

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

C:\Program Files\CiscoSecure ACS vx.x\CSDBSync\Databases
The Databases directory contains the following subdirectories:

Access —Contains the file CiscoSecureTransactions.mdb.

CiscoSecureTransactions.mdb contains a preconfigured accountActions table. When you install CiscoSecure 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 CiscoSecure 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 accountactions and schema.ini.

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.

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

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.

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

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.

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

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 CiscoSecure 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 CiscoSecure ACS System Logs. For more information about the CSDBSync service log, see Service Logs.

During manual synchronizations, CiscoSecure 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 CiscoSecure ACS before you configure the RDBMS Synchronization feature within CiscoSecure 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:


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

Step2 Create your accountActions table.

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

Step4 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 Step5 and Step6.


Step5 Set up a system DSN on the CiscoSecure ACS. For steps, see Configuring a System Data Source Name for RDBMS Synchronization.

Step6 Schedule RDBMS synchronization in CiscoSecure ACS. For steps, see Scheduling RDBMS Synchronization.

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

Step8 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 CiscoSecure 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 CiscoSecure ACS and to CiscoSecure 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:


Step1 Rename the accountactions CSV file installed on the computer running CiscoSecure ACS to accountactions.csv.

Assuming a default installation of CiscoSecure 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 CiscoSecure ACS.

Step2 Edit the Windows Registry:

a. Access the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\CiscoAAAvx.x\CSDBSync

b. Change the OdbcUpdateTable value from AccountActions to accountactions.csv.


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


c. Save your changes to the Registry.

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

Step3 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 CiscoSecure ACS, a system DSN must exist for CiscoSecure ACS to access the accountActions table. If you plan to use the CiscoSecureTransactions.mdb Microsoft Access database provided with CiscoSecure ACS, you can use the CiscoSecureDBSync system DSN rather than create one.

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

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


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


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

Step3 Click Add .

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

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

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

Step7 Click OK .

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

Step8 Close the ODBC window and Windows Control Panel.

The system DSN to be used by CiscoSecure ACS to access your accountActions table is created on your CiscoSecure 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 CiscoSecure ACS accesses the accountActions table. It contains the following options:

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

Username —Specifies the username CiscoSecure 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 CiscoSecure 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 —CiscoSecure ACS does not perform automatic RDBMS synchronization.

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

At specific times... —CiscoSecure 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 CiscoSecure 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 CiscoSecure ACSdoes not perform RDBMS synchronization.

Synchronize —This list represents the AAA servers configured in the AAA Servers table in Network Configuration for which the CiscoSecure ACSdoes perform RDBMS synchronization.

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:


Step1 In the navigation bar, click System Configuration .

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

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

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


Step4 For each CiscoSecure ACS that you want this CiscoSecure ACS to update with data from the accountActions table, select the CiscoSecure ACS in the AAA Servers list, and then click --> (right arrow button).

The selected CiscoSecure ACS appears in the Synchronize list.

Step5 To remove CiscoSecure ACSes from the Synchronize list, select the CiscoSecure ACS in the Synchronize list, and then click <-- (left arrow button).

The selected CiscoSecure ACS appears in the AAA Servers list.

Step6 At the bottom of the browser window, click Synchronize Now .

CiscoSecure 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 CiscoSecure ACS performs RDBMS synchronization.

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


Step1 In the navigation bar, click System Configuration .

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

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

Step4 To have this CiscoSecure 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 CiscoSecure ACS should perform synchronization (up to 7 characters).

Step5 To schedule times at which this CiscoSecure 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.


Step6 For each CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS server. For more information about the AAA Servers table, see AAA Server Configuration.


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

The selected CiscoSecure ACS moves to the Synchronize list.


Note At least one CiscoSecure 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.


Step7 Click Submit .

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


Step1 In the navigation bar, click System Configuration .

Step2 Click RDBMS Synchronization .

The RDBMS Synchronization Setup page appears.

Step3 Under Synchronization Scheduling, select the Manually option.

Step4 Click Submit .

CiscoSecure 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, CiscoSecure 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 CiscoSecure 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, CiscoSecure 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 CiscoSecure ACS to have IP pools with names identical to the IP pools defined on the primary CiscoSecure 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

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


Step1 In the navigation bar, click System Configuration .

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

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

CiscoSecure ACS allows overlapping IP pool address ranges.

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

CiscoSecure ACS already allows overlapping IP pool address ranges.

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

CiscoSecure ACS already does not permit overlapping IP pool address ranges.

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

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


Step1 In the navigation bar, click System Configuration .

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

Step3 Click Refresh .

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


Step1 In the navigation bar, click System Configuration .

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

Step3 Click Add Entry .

The New Pool table appears.

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

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


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

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


Step1 In the navigation bar, click System Configuration .

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

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

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

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


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

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


Step1 In the navigation bar, click System Configuration .

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

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

Step4 Click Reset .

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

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


Step1 In the navigation bar, click System Configuration .

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

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

Step4 Click Delete .

CiscoSecure ACS displays a dialog box to confirm you want to delete the IP pool.

Step5 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 CiscoSecure ACS to reclaim the IP addresses correctly.

Enabling IP Pool Address Recovery

To enable IP pool address recovery, follow these steps:


Step1 In the navigation bar, click System Configuration .

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

Step3 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 CiscoSecure ACS should recover assigned, unused IP addresses.

Step4 Click Submit .

CiscoSecure ACS implements the IP pools address recovery settings you made.