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
Preparing to Use 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 Appliance. 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
• Important Implementation Considerations
• Database Replication Versus Database Backup
• Database Replication Logging
• 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 helps make your AAA environment more fault tolerant. Database replication helps create 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 system.
•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.
Database replication does not support the following:
•IP pool definitions (for more information, see About IP Pools Server). Replicating IP pool definitions would create the potential for multiple CiscoSecure ACSes assigning the same IP address to different clients. You must manually create IP pool definitions on each CiscoSecure ACS. After you have done so, replication of user and group IP pools settings is supported.
•Replication between different versions of CiscoSecure ACS. Only replication between CiscoSecure ACSes using the same version is supported. We strongly recommend that CiscoSecure ACSes involved in replication use the same patch level, too.
•CiscoSecure ACS certificate and private key files. These must be installed on each CiscoSecure ACS.
•User-defined RADIUS vendors and vendor-specific attributes (VSAs). You must manually add user-defined RADIUS vendors and VSAs to each CiscoSecure ACS. After you have done so, replication of settings using user-defined RADIUS vendors and VSAs is supported.
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 a CiscoSecure ACS both sends database components to and receives database components from the same remote CiscoSecure ACS, is not supported.
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 provide protection from 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 offers the convenience of copying various components of the CiscoSecure database to other CiscoSecure ACSes. This can help you plan a failover AAA architecture and can help 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 The possibility of backing up a corrupted database exists regardless of whether you use CiscoSecure Database Replication. Because of this small risk, if you are using CiscoSecure ACS in mission-critical environments, we strongly recommend that you implement a backup plan that accounts for this possibility. For more information about backing up the CiscoSecure ACS system or the CiscoSecure database, see CiscoSecure ACS Backup.
Due to the necessity of local configuration, replication does not process IP pool definitions (however, IP pool assignments are replicated as part of the user and group profiles). Therefore, if applicable, common IP pool definitions must be manually configured in a manner that uses common pool names while establishing different address ranges. Certificate configuration is not replicated either, because certificate information is specific to each CiscoSecure ACS.
Also, network device group (NDG) settings, if employed, must remain constant between CiscoSecure ACSes. That is, you must guard against the primary CiscoSecure ACS sending a user or group profile that invokes an NDG that is not defined on the secondary CiscoSecure ACS.
Database Replication Logging
Regardless of whether replication events are successful or not, CiscoSecure ACS logs all replication events in the Database Replication report, available in the Reports and Activity section of the HTML interface. 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 options that control the components replicated appear in the Replication Components table on the CiscoSecure Database Replication page and are as follows:
•User and group database —Replicate the information for groups and users.
•Network Configuration Device tables —Replicate the AAA Servers tables, the AAA Clients tables, and the Remote Agent tables in the Network Configuration section.
•Distribution table —Replicate the Proxy Distribution Table in the Network Configuration section.
•Interface configuration —Replicate most of the Advanced Options settings from the Interface Configuration section.
•Interface security settings —Replicate the security information for the CiscoSecure ACS HTML interface.
•Password validation settings —Replicate the 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, page11-12.
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 File
• CiscoSecure ACS Database Recovery Using the accountActions Table
• Preparing to Use RDBMS Synchronization
• RDBMS Synchronization Options
– FTP 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 provides the ability to update the CiscoSecure user database with information from a text file on an FTP server. The text file can be generated by a third-party application. CiscoSecure ACS gets the file from the FTP server, reads the file, and performs the configuration actions specified in the file. 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. Communication between CiscoSecure ACSes for the purposes of RDBMS Synchronization occurs using an encrypted, Cisco-proprietary protocol. CiscoSecure ACSes listen on TCP port 2000 for synchronization data.
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 service that performs automated user and group account management services for CiscoSecure ACS.
•accountActions File —The file that holds information used by CSDBSync to update the CiscoSecure user database.
About CSDBSync
The CSDBSync service reads the accountActions file. While "accountActions.csv" is the default name for the accountActions file, you can name the file however you like. Synchronization events fail if CSDBSync cannot access the accountActions file.
CSDBSync reads each record from the accountActions file 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.
For more information about CSDBSync or other Windows services used by CiscoSecure ACS, see "Overview"
About the accountActions File
The accountActions file contains a set of rows that define actions CSDBSync is to perform in the CiscoSecure user database. Each row in the accountActions file holds user, user group, or AAA client information. Except for the first row (which is used for field headers and thus is ignored during synchronization), 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 file format and available actions, see "RDBMS Synchronization Import Definitions."
Cisco Secure ACS Database Recovery Using the accountActions Table
Combining all instances of accountActions files in the order they were processed by RDBMS Synchronization produces, in effect, a transaction queue. The RDBMS Synchronization feature does not maintain a transaction log/audit trail. If a log is required, the external system that generates accountActions files must create it. Unless the external system can recreate the entire transaction history in the accountActions file, we recommend that you construct a transaction log file for recovery purposes. To do this, create a transaction log file that is stored in a safe location and backed up on a regular basis. In that second file, mirror all the additions and updates to records in the accountActions file. The transaction log file would therefore be a concatenation of all actions recorded in the many instances of the accountActions file processed by RDBMS Synchronization.
If the database is large, it is not practical to recreate the CiscoSecure user database by replaying the transaction log for the entire history of the 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 external 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 system.
Preparing to Use RDBMS Synchronization
Synchronizing the CiscoSecure user database using data from a accountActions file requires that you complete several significant steps external to CiscoSecure ACS before configuring the RDBMS Synchronization feature within CiscoSecure ACS.
To prepare to use RDBMS Synchronization, follow these steps:
Step1 Determine the following items:
•How to create the accountActions file. For more information about the accountActions file, see About the accountActions File. For details on the format and content of the accountActions file, see "RDBMS Synchronization Import Definitions."
•The FTP server you want to use to make the accountActions file accessible to CiscoSecure ACS.
•How to copy the accountActions file to the applicable directory on the FTP server, if the accountActions file is generated in a directory different from the directory that CiscoSecure ACS is to get it from on the FTP server.
Step2 Configure your third-party system to generate the accountActions file periodically. The mechanism for maintaining your accountActions file is unique to your implementation. If the third-party system you are using to update the accountActions file 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 file, see "RDBMS Synchronization Import Definitions."
Step3 If needed, configure the mechanism that is to copy the accountAction file from where it is generated to the applicable directory on the FTP server.
Step4 Validate that your third-party system updates the accountActions file properly. Rows generated in the accountActions file must be valid. For details on the format and content of the accountActions file, see "RDBMS Synchronization Import Definitions."
Note After testing that the third-party system updates the accountActions file properly, discontinue updating the accountActions file until after you have completed Step5.
Step5 Schedule RDBMS synchronization in CiscoSecure ACS. For steps, see Scheduling RDBMS Synchronization.
Step6 Configure your third-party system to begin updating the accountActions file with information to be imported into the CiscoSecure user database. If needed, activate the mechanism that is to copy the accountActions file to the applicable directory on the FTP server.
Step7 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, page11-12.
Also, monitor the CSDBSync service log. For more information about the CSDBSync service log, see Service Logs, page11-25.
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:
• FTP Setup Options
• Synchronization Scheduling Options
• Synchronization Partners Options
FTP Setup Options
The FTP Setup For Account Actions Download table defines how CiscoSecure ACS accesses the accountActions table. It contains the following options:
•Actions File —The name of the accountActions file. The default name is "actions.csv". The filename provided must match the name of the accountActions file on the FTP server.
•FTP Server —The IP address or hostname of the FTP server that CiscoSecure ACS is to get the accountActions file from. If you specify a hostname, DNS must be enabled on your network.
•Directory —The relative path from the FTP server root directory to the directory where the accountActions file is. To specify the FTP root directory, enter a single period or "dot".
•Username —A valid username to enable CiscoSecure ACS to access the FTP server.
•Password —The password for the username provided in the Login box.
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.
The status of the CSDBSync service appears below the page title.
Step3 To specify options in the FTP Setup For Account Actions Download table, follow these steps:
Note For more information about FTP setup, see FTP Setup Options.
a. In the Actions Files box, type the name of the accountActions file that you want to use to update Cisco Secure ACS.
b. In the FTP Server box, type the IP address or hostname of the FTP server that you want Cisco Secure ACS to get the accountActions file from.
c. In the Directory box, type the relative path to the directory on the FTP server where the accountActions file is.
d. In the Username box, type a valid username to enable Cisco Secure ACS to access the FTP server.
e. In the Password box, type the password for the username provided in the Login box.
CiscoSecure ACS has the information necessary to get the accountActions file from the FTP server.
Note It is not necessary 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 using the actions in the accountActions file, select the CiscoSecure ACS in the AAA Servers list, and then click --> (right arrow button).
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 Options.
The selected CiscoSecure ACS appears in the Synchronize list.
Note At least one CiscoSecure ACS must be in the Synchronize list. This includes the CiscoSecure ACS on which you are configuring RDBMS Synchronization. RDBMS Synchronization does not automatically include the internal database of the current CiscoSecure ACS.
Step5 To remove CiscoSecure ACSes from 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 on 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.
The status of the CSDBSync service appears below the page title.
Step3 To specify options in the FTP Setup For Account Actions Download table, follow these steps:
Note For more information about FTP setup, see FTP Setup Options.
a. In the Actions Files box, type the name of the accountActions file that you want to use to update Cisco Secure ACS.
b. In the FTP Server box, type the IP address or hostname of the FTP server that you want Cisco Secure ACS to get the accountActions file from.
c. In the Directory box, type the relative path to the directory on the FTP server where the accountActions file is.
d. In the Username box, type a valid username to enable Cisco Secure ACS to access the FTP server.
e. In the Password box, type the password for the username provided in the Login box.
CiscoSecure ACS has the information necessary to get the accountActions file from the FTP server.
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 using the actions in the accountActions file, 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 file.
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 Options.
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 CiscoSecure ACS on which you are configuring RDBMS Synchronization. RDBMS Synchronization does not automatically include the internal database of the current CiscoSecure ACS.
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 that 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.
Feedback
