Cisco Systems 3.3 Manual De Usuario

be running Cisco Secure ACS version 3.2. Because patch releases can introduce 
significant changes to the CiscoSecure database, we strongly recommend that 
Cisco Secure ACSes involved in replication use the same patch level, too.

This topic describes the process of database replication, including the interaction 
between a primary Cisco Secure ACS and each of its secondary Cisco Secure 
ACSes. The following steps occur in database replication:

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

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.

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

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

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

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