Setting Up Database Replication among CiscoSecure ACSes

CiscoSecure ACS 2.3 supports asynchronous database replication among multiple CiscoSecure ACS sites that use the Oracle 7.3.3 and later or Sybase 11.02 and later database engines to store their profile information. Two recommended database replication scenarios are:

•

Master-to-Snapshot or Primary-to-Replicate Replication—A scenario in which administrative changes are made to the profile database at a single master CiscoSecure ACS site and those changes are replicated to one or more secondary CiscoSecure ACS sites at fixed time intervals with snapshots from the master database.

•

Master-to-Master or Peer-to-Peer Replication—A scenario in which administrative changes can be made to the profile databases at two or more peer CiscoSecure ACS sites, which update one another at fixed time intervals.

Note CiscoSecure supports only asynchronous, not real-time, database replication.

This chapter provides example procedures for setting up Oracle and Sybase database systems to carry out replication of the CiscoSecure database among multiple CiscoSecure ACS sites.

Note If you have multiple existing CiscoSecure database sites that currently contain disparate data, all of which you wish to preserve when implementing replication, request your database administrator to merge your existing databases at one Master definition site before carrying out the procedures in this chapter.

Examples

Figure 21-1 illustrates an example of Master-to-Snapshot or Primary-to-Replicate database replication as applied to multiple CiscoSecure sites. In this scenario all administrative changes to the user profile database are made through the web-based console to one CiscoSecure ACS site. Then, at specified time intervals, those changes are replicated to all other sites on the network, enabling the ACSes to provide their authentication, authorization, and accounting services based on a common set of user profile data.

Figure 21-2 illustrates Master-to-Master or Peer-to-Peer database replication as applied to multiple CiscoSecure profile database sites. In this scenario local administrative changes to the user profile database can be made through the web-based consoles at two or more ACS peer sites. Then, at specified time intervals, each of these peer sites communicate their local changes to all other sites on the network. As with Master-to-Snapshot replication, the end result is that the ACSes are able to provide their authentication, authorization, and accounting services based on a common set of user profile data.

Integrating Oracle Database Replication with CiscoSecure

The following example procedure uses the Oracle Net8 Easy Config (or the Oracle 7 SQL Net Easy Config), Security Manager, Schema Manager, SQL*Plus, and Replication Manager programs run on a Windows 95 workstation console to integrate Oracle database replication with CiscoSecure.

Caution

Implementing Oracle database replication requires an in-depth knowledge of Oracle tools and database structure. Integrating database replication with CiscoSecure based on the following example procedures should be carried out by experienced Oracle Database Administrators only.

For specific instructions on how to use the above Oracle programs, please refer to Oracle manuals and online help.

Note The following example procedures assume that multiple Oracle server and tablespace sites have already been installed to service each CiscoSecure ACS site and that all CiscoSecure ACS sites have been installed. Refer to the CiscoSecure ACS Installation Guide for details.

A. Plan Your Oracle Database Server Distribution System

•

The Oracle Master-to-Snapshot replication scenario—Consists of one Master database site and one or more Snapshot database sites. Administrative changes are made to the Master profile database, and those changes are replicated as snapshots at fixed time intervals to the Snapshot sites.

If you are planning to implement Master-to-Snapshot Replication, decide which of your Oracle database servers will become the Master database site. The remainder of your Oracle servers will become Snapshot sites.

•

The Oracle Master-Definition-to-Master-Destination replication scenario—Consists of one Master Definition profile database and one or more Master Destination profile databases. Local administrative profile changes can be made to any of the databases. Local profile database changes at all the sites are periodically sent to and incorporated in the Master Definition profile database, which then updates the destination sites with the compiled changes.

If you are planning to implement Master-to-Master Replication, decide which of your Oracle Database servers will become the Master Definition site. The remainder of your servers will become Master Destination sites.

B. Create Connection Services from the Console to all Database Sites

•

From a console site, ping all target Oracle database sites to verify a connection.

•

At each Oracle database site involved in CiscoSecure database replication, use TNSPING to ensure connectivity with all other sites involved in the replication.

If you do not have connectivity, locate the tnsnames.ora file in the $ORACLE_HOME/network/admin directory and edit it, making sure that entries exist for all the other Oracle database sites involved in the replication.

•

Use the Oracle Net8 Easy Config utility (or the Oracle 7 SQL Net Easy Config utility) to establish a service name entry for each of the Oracle database sites assigned to support a CiscoSecure ACS. For each database site, specify the following:

–

For the service name (or Database Alias in Oracle 7) enter an arbitrary name.

–

For the host name (or TCPIP host name in Oracle 7) specify the host name of the Oracle database with which you want to connect. If the fully qualified domain name (FQDN) and host name differ, specify the FQDN.

–

If the port prompt is displayed, the default value for Oracle is 1521. This must match the port value assigned to the "listener" process on the system to which the console will connect.

Note

To support Oracle database replication, the SID for each database must be unique.

C. Create a Special User as the Replication Database Controller

For each service that you created in step B, use the Oracle Security Administrator to create a special user with special privileges to control database replication.

•

Using the Oracle Security Manager, log in as Oracle system manager to each of the database connection services that you created in step B. For service, enter the name that you entered in the Oracle Net8 Easy Config (or the Oracle 7 SQL Net Easy Config) program.

•

For each database connection service, configure a special user, a database replication controller, for each service as follows:

–

Create a special user, a database replication control user, to control database replication.

Caution

This user must not be the Oracle user that you specified as in charge of the DB account for CiscoSecure data during CiscoSecure install.

–

For the user's default tablespace, specify the Oracle tablespace that you set up for CiscoSecure before CiscoSecure installation.

Note

If you are configuring a Master-to-Updateable-Snapshot replication system, assign the database the EXECUTE privilege on the SYS.DBMS_DEFER PL/SQL object to the database replication control user.

•

Use the SQL*Plus utility to assign the appropriate privileges to the database replication control user.

–

When prompted for the Host String, enter the service name you created in step B.

where repadmn is the name of the database replication control user that you just created.

D. Create Links between Databases

Create two-way links between the databases. For each database instance, do as follows:

•

Using the Oracle Schema Manager, log in as the database replication controller user whom you created in step C to each database connection service that you created in step B.

•

For each database involved in the database replication, configure links with the following settings:

–

Create a link (or Database link in Oracle 7) to another database and name it the same as the SID that you specified for the destination database in the Oracle Net8 Easy Config (or Oracle 7 SQL Net Easy Config) in step B.

–

Assign as the fixed user (or Named link in Oracle 7), the database replication controller user.

–

Specify the service name (or Database Alias in Oracle 7) that you specified for the destination database in the Oracle Net8 Easy Config (or Oracle 7 SQL Net Easy Config) in step B.

–

Test the link by clicking on it, choosing Quick Edit, then clicking Test.

E. If You Are Configuring a Master-to-Snapshot Replication Scenario

Step 1

Using the SQL*Plus utility, log in to each database instance that you want to be a Snapshot site.

•

Log in specifying the CiscoSecure username. In the "Host String" prompt enter the service name that you created in the Oracle Net8 Easy Config utility (or the Oracle 7 SQL Net Easy Config utility) in step B.

•

Use the drop table command to delete the following 6 tables from the database assigned to CiscoSecure: cs_user_profile, cs_group_profile, cs_profile, cs_password, cs_privilege, cs_profile_blob.

Step 2

Using the Oracle Replication Manager, create a database connection for each database connection service that you set up in step B.

•

For administrator, specify the user who you set up as the replication database controller in step C.

•

For database (or TCP/IP Host Name in Oracle 7), specify the service name (or Database Alias in Oracle 7) you entered for this database in step B.

Step 3

Using the Oracle Replication Manager, select the database connection that you want to be the Master Definition site and create and configure the master group on this site as follows:

•

If you need to specify a propagator, specify the user you set up as the replication database controller in step C.

•

Use the Objects tab to add the schema that you set up for CiscoSecure and assign the following tables to the master group: cs_user_profile, cs_group_profile, cs_profile, cs_password, cs_privilege, cs_profile_blob.

•

When the Support for Group box appears, make sure that the Generate and Resume Replication Activity options are enabled.

•

Create snapshot logs for each of the tables that you assigned to the master group in this step.

Step 4

Using the Oracle Replication Manager, select and set up each database connection that you want to be a Snapshot site as follows:

•

Select the tables to replicate: cs_user_profile, cs_group_profile, cs_profile, cs_password, cs_privilege, cs_profile_blob.

Disabling the update option—causes the Snapshot site to be read-only. Configuring read-only Snapshot sites ensures that CiscoSecure administration can only be carried out at the Master site.

Note

However, a read-only Snapshot site also denies CiscoSecure users, even those with user-level web privilege, the ability to change their personal passwords via the user-level CiscoSecure ACS administrator web page, and disables the maximum failed login limitations at those CiscoSecure sites.

Enabling the update option—causes the Snapshot site to be updateable. Configuring updateable Snapshot sites allows CiscoSecure users with user-level web privilege to change their personal passwords and preserves the maximum failed login limitations.

Note

However, the presence of updateable Snapshot sites, means that exclusive CiscoSecure administration from the Master site is not ensured. Conflicting administrative information entered at different sites might require special steps to resolve. See the section, " Precautions Running Oracle Database Replication and CiscoSecure" later in this chapter.

From the refresh group properties menu, schedule the interval (for example, every 24 hours) when the update should occur.

•

To carry out initial replication and to verify your replication process so far, use the refresh now, or refresh immediately option to create the objects to be replicated from the Master Definition site.

Step 5

At the Master Definition database site, change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:

Note

The CSdbTool cache_trigger command line enables replication changes to the profile database of a CiscoSecure ACS to be incorporated in the profile cache of that ACS also. When the replication process updates a record in the profile database, the cache triggers write the updated records to the cs_trans_log table, which is read by the CiscoSecure dbserver module, which, in turn, incorporates the changed records in the ACS profile cache.

Step 6

At each Snapshot database site, change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:

Step 7

Before you create any new users, configure the Snapshot sites to prevent duplicate user profile names. At each Snapshot site, enter the following command:

CSdbTool ora_rep_indx_snap

Step 8

Edit the initsid.ora configuration file. At each Oracle site, do as follows:

•

In the Oracle server's $ORACLE_HOME/dbs directory, locate the configuration file: initsid.ora

minutes is the number of minutes between updates. This value must be equivalent to the update interval time that you set in the refresh group properties menu in the Oracle Replication Manager. (See step 4 in this section.)

number is the number of background processes allotted to the replication operations (must be at least 1).

•

Restart the Oracle server to have the changes to the inisid.ora file take effect.

Step 9

At the CiscoSecure server for the Master site, restore the listings for the CiscoSecure servers installed at Snapshot sites.

•

Start the Java-based CiscoSecure Administrator advanced configuration program and click the Servers tab.

Notice the that the IP listings for the CiscoSecure servers installed at Snapshot sites are not listed.

•

For each CiscoSecure server installed at a snapshot site, click New and enter the IP address of that server. Repeat this process until all CiscoSecure servers installed at Snapshot sites are listed.

•

Allow the restored CiscoSecure server listings to replicate throughout the network.

F. If You are Configuring a Master-to-Master Database Replication Scenario

If you are configuring Master-to-Master replication, follow the steps in this section. If you are configuring Master-to-Snapshot replication, ignore this section.

Step 1

Using the SQL*Plus utility, log in to each database instance that you want to be a Master Destination site.

•

Use the drop table command to delete the following 6 tables from the CiscoSecure database: cs_user_profile, cs_group_profile, cs_profile, cs_password, cs_privilege, cs_profile_blob.

Caution

Remember, delete the above tables from Master Destination sites only.

Step 2

For each database connection service, create a surrogate replication administrator.

•

For each database connection service, configure a special user, a surrogate replication administrator, for each service as follows:

(a) Create a special user, a surrogate replication administrator, to control database replication.

Caution

This user must not be the Oracle user that you specified as in charge of the DB account for CiscoSecure data during CiscoSecure install.

(b) For the user's Default table space, specify the Oracle tablespace that you set up for CiscoSecure before CiscoSecure installation.

Step 3

Using the SQL*Plus utility, assign the appropriate privileges to the database surrogate replication administrator at each Oracle site.

•

where surrogate_repadmn is the name of the surrogate replication administrator that you just created.

Step 4

Using the Oracle Replication Manager, create a database connection for each database connection service that you set up in step B.

•

For administrator, specify the user who you set up as the replication database controller in step C.

•

For database, specify the service name (or Database Alias in Oracle 7) you entered for this database in step B.

Step 5

Using the Oracle Replication Manager, select the database connection that you want to be the Master Definition site and create and configure the master group on this site as follows:

•

If you need to specify a propagator, specify the user you set up as the replication database controller in step C.

•

Use the Destinations tab to add the public database links for the master destination sites to the master group.

Step 6

After creating the master group, set up conflict resolution for each table in the group. Add a column group, give it an arbitrary name, select the PROFILE_TS column to this group, and select the latest time stamp resolution method for this group.

Step 7

Using the Oracle Replication Manager, select and set up the database connection that you want to be a Master Definition site as follows:

•

For Database Link, specify the database connection from which the Master Definition site will receive replicated data.

Step 8

Using the Oracle Replication Manager, select and set up each database connection that you want to be a Master Destination site as follows:

•

For Database Link, specify the database connection from which the Master Destination site will receive replicated data.

Step 9

Using the Oracle Replication Manager, carry out the initial replication of the master group in each connection that you set up. For each master group configuration, go to Admin Requests and select the option, Apply all Administrative requests now.

Step 11

In order to prevent two different CiscoSecure servers from assigning the same internal profile ID number to different user profiles, assign non-overlapping ranges of internal profile ID numbers to each Master Destination site as follows:

Note

Profile ID numbers are unique numbers internally assigned to user profiles by CiscoSecure for internal tracking. The absolute range of permissible profile ID numbers is between 1 and 2,147,483,647.

•

At the first master site, start SQL*Plus and use the update command to set a maximum range for internal profile ID numbers. For example:

•

At the second master site, start SQL*Plus and use the update command to set a non-overlapping minimum and maximum range for internal Profile ID numbers. For example:

•

Repeat the process for all the master sites, incrementing the values each time to avoid overlapping Profile ID numbers. For example:

Note

At each site, when setting minimum and maximum profile ID range, be sure to set a range sufficient to accommodate anticipated growth in the required profile ID numbers.

Step 12

After initial replication has occurred, and before you create any new users, configure the Master Destination sites to prevent duplicate user profile names. At each Master Destination site, enter the following command:

CSdbTool ora_rep_indx

Step 13

Edit the initsid.ora configuration file. At each Oracle site, do as follows:

•

In the Oracle server's <$ORACLE_HOME>/dbs directory, locate the configuration file: initsid.ora

minutes is the number of minutes between updates. This value must be equivalent to the intervals required when you created the scheduled links in Step 7 and Step 8 of step F.

number is the number of background processes allotted to the replication operations (must be at least one).

Step 14

Restart the Oracle server to have the changes to the inisid.ora file take effect.

Step 15

At the CiscoSecure server for the Master Definition site, restore the listings for the CiscoSecure servers installed at the Master Destination sites.

•

Start the Java-based CiscoSecure Administrator advanced configuration program and click the Servers tab.

Notice the that the IP listings for the CiscoSecure servers installed at Master Destination sites are not listed.

•

For each CiscoSecure server installed at a Master Destination site, click New and enter the IP address of that server. Repeat this process until all CiscoSecure servers installed at Master Destination sites are listed.

•

Allow the restored CiscoSecure server listings to replicate throughout the network.

Precautions Running Oracle Database Replication and CiscoSecure

In cases where Oracle Master-to-Master (or Master-to-Updateable-Snapshot) database replication has been implemented, the CiscoSecure system administrators must avoid updating the same CiscoSecure user profile at two or more different CiscoSecure ACS profile database sites during the same interval between database replication processes.

If updating of the same user profile at two different sites within the same interval between replications occurs, the user profile edits at neither site will be replicated or reconciled. The user profile will remain with unreconciled settings at both sites, and the following Oracle error message will appear at both sites within the "Local Errors" section of the Oracle Replication Manager tree:

ORA-01403 no data found error

The above error should rarely occur, because, in practice, no more than one administrator, administering from one CiscoSecure ACS site should be authorized to administer any one user profile anyway.

However, if this error does occur, you must fix the unreconciled user profile at both sites as follows:

Step 1

Use the web-based CiscoSecure ACS Administrator web pages or the Java-based CiscoSecure Administrator program to do the following:

Examine the user profile settings at each site. Determine which user profile is the one you want replicated and note the settings.

At one of the sites, create a new user profile with the same name as the profile you just deleted.

Step 2

Use the Oracle Replication Manager to force replication, or wait until the next scheduled replication.

Integrating Sybase Database Replication with CiscoSecure

The following example procedure uses the Sybase RS INIT, and rsmgen utilities run on the UNIX server, and Sybping, and Replication System Manager, running on a Windows 95 workstation console, to integrate Sybase database replication with CiscoSecure.

Caution

Implementing Sybase database replication requires an in-depth knowledge of Sybase tools and database structure. Integrating database replication with CiscoSecure based on the following example procedures should be carried out by experienced Sybase DBAs only.

For specific instructions on how to use the above Sybase programs, please refer to Sybase manuals and online help.

Note The following example procedures assume that multiple Sybase servers and database sites have already been installed to service each CiscoSecure ACS site and that all CiscoSecure ACS sites have been installed. Refer to the CiscoSecure ACS Installation Guide for details.

A. Plan Your Sybase Replication System

Sybase supports two types of database replication, Primary-Server-to-Replicate-Server, and Peer-Server-to-Peer-Server.

•

The Sybase Primary-Server-to-Replicate-Server scenario—Consists of one Primary profile database site and one or more Replicate profile database sites. Administrative changes are made to the Primary profile database site and periodically replicated to the Replicate sites.

If you are planning Primary-Server-to-Replicate-Server replication, decide which of your Sybase servers will become the Primary Server site. The remainder will become Replicate Server sites.

•

The Sybase Peer-to-Peer replication scenario—Consists of two or more Peer profile database sites. Local administrative changes to the profile database can be made at any site. Each site periodically replicates its local profile database changes to all of its peers.

If you are planning Peer-to-Peer replication, you should still select a Primary server on which to install the replication server software.

B. Install the Replication Server Modules

To carry out database replication, Sybase requires that you install a Replication Server at one of your Sybase database sites and a Replication Server Manager client module at a PC console.

Step 1

At your Primary site, make sure that the Sybase SQL server or Adaptive server module is installed and running.

Step 2

Install the Replication Server and Replication Server Manager modules.

Step 3

Install the Sybase SQL Manager and Replication Manager Client tools on a PC console.

C. Configure the Sybase Replication Server

The Sybase Replication Server executes replication among the Sybase database sites. Set it up by using the Sybase RS INIT program following the procedures outlined in your Sybase documentation. RS INIT settings that require specific input in order to integrate Sybase replication of the CiscoSecure database are noted below:

Step 1

Specify the Replication Server Information settings. Except for the settings listed below, accept the default values.

Step 2

Specify the Replication Server Interfaces Information settings. Except for the settings listed below, accept the default values.

•

Hostname/address—Specify the hostname or TCP/IP address of the SPARCstation where you are installing the Replication server.

Step 4

Specify the Replication Server System Database Information settings. Except for the settings listed below, accept the default values.

•

RSSD SQL Server name—Specify the SQL name of the server on which CiscoSecure is installed.

Note

In this context, the RSSD device is an area on a hard disk or some other storage device that you are reserving to store Replication System configuration data.

Step 5

Specify the RSSD Device Information settings. Except for the settings listed below, accept the default values.

•

RSSD log device physical name—Specify a path and filename of your choosing.

Step 6

Specify the Disk Partition Information settings. Except for the settings listed below, accept the default values.

•

Disk Partition path—Specify a path and filename. The file must already exist and be completely blank.

If this file does not already exist, use the UNIX touch utility to create it. When creating this file, you must be logged in as the Sybase user, rather than as root.

Note

The disk partition settings specify a partition area on which the actual profile database information to be replicated is stored.

•

Logical identifier for disk partition—Specify an identifier of your choosing.

•

Size of disk partition—Accept the default size of 20 MB, or specify a larger size if necessary (approximately 100 MB for 100,000 user profiles).

Step 7

Accept all default values for the Remote Site Connections Information settings.

D. Add the CiscoSecure Databases to the Replication

At each CiscoSecure database site run RS INIT to integrate the CiscoSecure database into the Sybase replication system. Set it up by using the Sybase RS INIT program following the procedures outlined in your Sybase documentation. RS INIT settings that require specific input in order to integrate Sybase Replication of the CiscoSecure database are noted below.

Step 1

Specify the Replication Server Information settings. Except for the bulleted settings listed below, accept the default values.

•

Replication Server name—Match the name you specified for this setting in step C.

Step 2

Specify the Database Information settings. Except for the bulleted settings listed below, accept the default values.

•

SQL Server name—Specify the SQL server name of the SPARCstation where you set up a database account for CiscoSecure before you installed CiscoSecure.

•

Database name—Specify the name of the CiscoSecure database that was set up through Sybase prior to CiscoSecure Installation.

•

Will the database require an LTM—Specify Yes if this is a Primary server site; No if this is a Replicate server site.

Step 3

At Primary and Peer database sites only, accept all the default Database Log Transfer Manager settings.

Step 4

At Primary and Peer database sites only, configure the LTM Interfaces Information settings. Except for the bulleted settings listed below, accept the default values.

E. Set Up the Replication Services Manager Server

Step 1

At the Primary server, use the Sybase DSEDIT utility to create an RSM server entry in the Sybase Interfaces file.

Step 3

When prompted for the RSM Server name, specify the name you entered in the Interfaces file.

F. Start the PC Replication Services Management Program

Step 1

Move to the Windows 95 or Windows NT workstation on which you installed the Replication Services Manager client and ping the hosts running all the Sybase servers involved in database replication to test the console-to-Sybase server TCP/IP connections.

Step 2

If the pings are successful, use the Windows-based SQLEDIT program to generate an Interface file on the PC. Point to the IP addresses and TCP/IP ports of the SQL or Adaptive Server, Replication Server, LTM server and RSM server.

Step 3

Use the Sybping utility to ping the Adaptive Server, Replication Server, LTM server, and RSM server modules and confirm the console-to-server Sybase connections.

Step 6

To create a RSM domain for your CiscoSecure profile databases, do the following:

•

For the Domain name field, specify the RSM server you set up on the UNIX machine.

•

Use the Edit > Insert server command to add the SQL or Adaptive Server, Replication Server, and each Sybase server involved in replication of the CiscoSecure database to the RSM domain you just created.

Step 7

On each Primary server or Peer server in the RSM Domain, configure replication definitions for each of its tables as follows:

•

For the Primary Replication Server field, specify the Interfaces file entry for the Replication server.

•

For the Primary Data server field, specify the Interfaces file entry for the SQL or Adaptive server.

•

For the Database, select the CiscoSecure database created prior to Sybase installation.

•

Select one of the tables displayed: cs_user_profile, cs_group_profile, cs_profile, cs_password, cs_privilege, cs_profile_blob; and assign a replication definition name of your choosing.

•

Repeat the above steps, configuring a replication definition for each of the tables listed on each Primary or Peer server.

G. If You Are Setting Up Primary-to-Replicate Server Replication

If you are configuring Primary-to-Replication server replication, follow the steps in this section. If you are configuring Peer-to-Peer replication, you can skip this section and go to the "H. If You Are Setting Up Peer-to-Peer Replication" section.

Step 1

For each Replicate server in the RSM domain, configure subscriptions to each of the six replication definitions configured in step F.

•

For the Replicate Replication Server field, specify the Replication server that you named in step C.

For the Replication definition, select the name of the replication definition that you want associated with this subscription. This will be one of the 6 replication definitions that you configured in step F.

•

For the Replicate Data Server, select the Replicate server for which you are currently configuring subscriptions.

•

For Replicate Data Base, specify the CiscoSecure database set up prior to the CiscoSecure installation.

•

For every Replicate server in the RSM domain, repeat this step six times, each time configuring a subscription to another of the six replication definitions defined in step F.

Step 2

At each of the CiscoSecure database sites, enable profile caching. Change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:

CSdbTool cache_trigger

Note

The CSdbTool cache_trigger command line enables replication changes to the profile database of a CiscoSecure ACS to be incorporated in the profile cache of that ACS. When the replication process updates a record in the profile database, the cache triggers write the updated records to the cs_trans_log table, which is read by the CiscoSecure dbserver module, which, in turn, incorporates the changed records in the ACS profile cache.

Step 3

At the CiscoSecure server for the Primary site, restore the listings for the CiscoSecure servers installed at the Replicate sites.

•

Start the Java-based CiscoSecure Administrator advanced configuration program and click the Servers tab.

Notice the that the IP listings for the CiscoSecure servers installed at Replicate sites are no longer listed.

•

For each CiscoSecure server installed at a Replicate site, click New and enter the IP address of that server. Repeat this process until all CiscoSecure servers installed at Replicate sites are listed.

•

Allow the restored CiscoSecure server listings to replicate throughout the network.

H. If You Are Setting Up Peer-to-Peer Replication

If you are configuring Peer-to-Peer replication, follow the steps in this section. If you are configuring Primary-to-Replicate server replication, ignore this section.

Step 1

Decide which of your Sybase sites will be the initial source Peer site.

When the first replication is run the initial source Peer site will be the site containing the original profile data structures that will be replicated to all the other sites.

Step 2

At each secondary peer site, delete the current CiscoSecure profile records.

Start the Sybase ISQL utility and use the delete command to empty the current CiscoSecure profile records. Enter:

delete from cs_profile

delete from cs_user_profile

delete from cs_group_profile

delete from cs_password

delete from cs_privilege

delete from cs_profile_blob

Step 3

At each secondary peer site, configure subscriptions to each of the replication definitions configured in step F. Use the Replication Services Manager Configure > Subscription option and click the Create tab.

•

For the Replicate Replication Server field, specify the Replication server that you named in step C.

•

For the Replication definition, select the name of the replication definition that you want associated with this subscription. This will be one of the six replication definitions that you configured in step F.

•

For the Replicate Data Server, select the Peer server for which you are currently configuring subscriptions.

For Replicate Data Base, specify the CiscoSecure database set up prior to the CiscoSecure installation.

•

For every secondary Peer server in the RSM domain, repeat this step six times, each time configuring a subscription to another of the six replication definitions defined in step F.

Step 4

At the initial source Peer site, configure subscriptions to each of the replication definitions configured in step F. Use the Replication Services Manager Configure > Subscription option and click the Define tab.

•

For the Replicate Replication Server field, specify the Replication server that you named in step C.

•

For the Replicate Data Server, select the Peer server for which you are currently configuring subscriptions.

•

For Replicate Data Base, specify the CiscoSecure database set up prior to the CiscoSecure installation.

•

Repeat this step six times, each time configuring a subscription to another of the six replication definitions defined in step F.

•

Use the Activate and Validate tabs to activate and validate subscriptions to the replicate definitions. This enables the initial source peer site to receive future updates without receiving back the data it originally sent out.

Step 5

At each CiscoSecure database site enable profile cache updating. Change to the CiscoSecure $BASEDIR/utils/bin directory and run the following CiscoSecure command line:

CSdbTool cache_trigger

Note

Step 6

Note

Profile ID numbers are numbers internally assigned to user profiles by CiscoSecure for internal tracking. The absolute range of permissible profile ID numbers is between 1 and 2147483647.

•

At the first Peer site, start the Sybase ISQL utility and use the update command to set a maximum range for internal profile ID numbers. For example:

•

At the second Peer site, start the Sybase ISQL utility and use the update command to increment the internal profile ID numbers for the existing user profiles and set a non-overlapping minimum and maximum range for the internal profile ID numbers as well. For example:

•

Repeat the process for all the Peer sites, incrementing the values each time to avoid overlapping Profile ID numbers. For example:

Note

At each site, when setting minimum and maximum profile ID range, be sure to set a range sufficient to accommodate anticipated growth in the required profile ID numbers.

Step 8

At the CiscoSecure server for either the initial or a secondary Peer site, restore the listings for the CiscoSecure servers installed at the secondary Peer sites.

•

Start the Java-based CiscoSecure Administrator advanced configuration program and click the Servers tab.

Notice the that the IP listings for the CiscoSecure servers installed at secondary Peer sites are no longer listed.

•

For each CiscoSecure server installed at a secondary Peer site, click New and enter the IP address of that server. Repeat this process until all CiscoSecure servers installed at secondary Peer sites are listed.

•

Allow the restored CiscoSecure server listings to replicate throughout the network.

Precautions Running Sybase Database Replication and CiscoSecure

In cases where Sybase Peer-to-Peer database replication has been implemented, the CiscoSecure system administrators must avoid updating the same CiscoSecure user profile at two or more different CiscoSecure ACS profile database sites during the same interval between database replication processes.

•

No more than one CiscoSecure administrator administering one database site should be authorized to configure the same user profile.

•

Sybase database replication takes place at frequent intervals, thus minimizing the chance of duplicate edits to the same user profile during the same time period between replications.

However, if the above error does occur, fix the unreconciled user profile as follows:

Step 1

Use the web-based CiscoSecure ACS Administrator web pages or the Java-based CiscoSecure Administrator program to do the following:

Examine the user profile settings at each site. Determine which user profile is the one you want replicated and note the settings down.

At one of the sites, create a new user profile with the same name as the profile you just deleted.

Table Of Contents