|
|
Two utilities, Database Replication and Remote Database Management System (RDBMS) Synchronization, are provided with the CiscoSecure Access Control Server (ACS). These utilities help automate the process of keeping your CiscoSecure ACS database and network configuration current. A third utility, CSUtil.exe, allows database backup and restore functionality. CSUtil.exe is described in the Appendix "CiscoSecure ACS Database Utilities."
While their functions are somewhat similar, RDBMS Synchronization is provided to allow the CiscoSecure ACS to tightly integrate with other RDBMS data sources, not to build fault-tolerant multiserver installations (although, in some configurations, it can be used to provide this).
In order to use Database Replication and/or RDBMS Synchronization, they must first be enabled in Interface Configuration: Advanced Options.
Database Replication is a powerful feature designed to simplify the construction of a fault-tolerant authentication, authorization, and accounting (AAA) service environment based on the CiscoSecure ACS 2.1 for Windows NT. The primary purpose of Database Replication is to provide the facility to replicate various parts of the setup on a CiscoSecure ACS master server to one or more CiscoSecure ACS client systems, allowing the administrator to automate the creation of mirror systems. These mirror systems can then be used to provide server redundancy as fallback or secondary servers to support fault-tolerant operation in the event of the failure of the master or primary system.
Database Replication automates the following procedures during the creation of a mirror system:
Do not confuse Database Replication with Database/System Backup. Database Replication is not a complete replacement for Database Backup. While dealing with much the same problem set (protection from partial or complete server loss), the two processes deal with the issues in a different way.
DB Backup allows the archiving of important data from a single machine into a defined backup format that can be used to later restore the configuration after a system failure or the corruption of the user data. The backup data is normally stored on nonvolatile media, such as tape, and removed from the system for long-term storage. Normally, multiple generations of the database backup are stored for some appropriate time period. This type of backup regime provides protection not only against overall system hardware failure, but also the possibility of application database corruption (provided that a suitable backup regime has been implemented).
Although unlikely, Database Replication could potentially propagate a corrupted database to its backup clients while performing a backup to its secondary systems. It is therefore strongly recommended that administrators of the CiscoSecure ACS's systems in mission-critical environments implement an adequate backup regime regardless of whether Database Replication is employed or not. See the section "Database Backup and Restore Utility" in the Appendix "CiscoSecure ACS Database Utilities" for more information on backup.
While Database Replication provides fairly comprehensive facilities for replication of the CiscoSecure ACS servers, it does not provide replication facilities for all of the CiscoSecure ACS setup. More importantly, all configuration relating to external authentication sources is not covered by Database Replication. This part of the configuration is not covered because the CiscoSecure ACS functionality relies on the installation of a number of communication dynamic link libraries (DLLs). Because installation of these DLLs is determined manually by the system administrator for each case, Database Replication cannot rely on the necessary DLLs being present. Replication of these parts of the CiscoSecure ACS configuration must be done manually. Because this data is relatively static, this does not represent a great deal of overhead.
The following items for configuring Database Replication are configured in the CiscoSecure ACS HTML user interface:
Database Replication allows you to select only some of the configuration data elements to be transferred to the client system. However, to create a mirror system, all items must be selected. The following items can be replicated:
For each item, there are two check boxes, one labeled Send and the other labeled Receive. For configuration of the master (source of data) system, only the Send box is relevant; the Receive checkbox refers to Client setup (see below).
You can configure Database Replication to perform replication in one of the following ways:
To select the desired mode of operation, check the appropriate radio button and configure the parameters as appropriate.
Database Replication can be configured to categorically send specific database information to another CiscoSecure ACS in cases where mirroring the database with another CiscoSecure ACS might provide information considered confidential from the primary AAA server's site (such as Distribution Tables).
This setting can have very important implications for overall AAA service performance; the administrator must make an appropriate trade-off. You should be aware of the trade-offs in system performance. With shorter frequencies, the currency of the backup AAA server with the primary server is higher, allowing a more current backup to be maintained if the primary system fails, and a more current view of the CiscoSecure ACS user database. Unfortunately, the greater the currency, the higher the load exerted on other aspects of the overall AAA system and network environment. First, network load/traffic is consequently much higher, because the data is being transferred more often. Second, the processing load on the synchronizing systems is increased as the process is undertaken more often. Obviously, this process consumes system resources, and the more often the process is repeated, the greater the impact on the AAA server's authentication/authorization performance.
This issue becomes more apparent with very large databases, very dynamic databases (there are a lot of changes on the database taking place all the time), or both. Database Replication is a non-incremental or destructive backup. In other words, it completely replaces the database and configuration on the client system every time it is run. Therefore, if the database being transferred is very large, the amount of data being transferred can be substantial, and the processing overhead can also be large.
During the replication and synchronization processes, the authentication service is halted briefly on both machines (although not at the same time). On the sender AAA server, service is halted while the appropriate files and registry information are collated and prepared for sending. On the receiver AAA server, service is halted when the incoming file and registry set is restored. Service is normal while the replication set is being transmitted between servers.
Database Replication supports replication to one or more target or client CiscoSecure ACS systems. To select client systems for replication, follow these steps:
Step 2 In the Replication Partners section in the AAA Servers column, click the name of the system you want to be the target.
Step 3 Click the right arrow button to move the selection into the Replication column.
Step 4 Repeat this process as required.
To deselect a replication target, reverse the above procedure using the left arrow button to move the server name into the AAA Servers column.
1. Only Database Replication to other CiscoSecure ACS hosts is supported, and to cooperate in this scheme, all master and client systems must be CiscoSecure ACS Release 2.1.
2. Only suitably configured valid CiscoSecure ACS hosts are presented for selection as Database Replication clients. To addition replication targets, select the applicable AAA server from the AAA Server Table in the Network Configuration window. When one or more CiscoSecure ACS hosts have been added to the Hosts Table, they will automatically appear for selection as Database Replication clients in the Replication Partners: AAA Servers column.
3. Replication of clients takes place sequentially in the order listed.
4. The client or target system must also be configured to accept Database Replication from the master system; otherwise, Database Replication fails. To set a client system to accept Database Replication instructions, see the next section "Client System Database Replication Configuration."
Database Replication uses a sophisticated client/server relationship to provide strong security and control to sites using this facility. For Database Replication to work, both the server and client must be correctly configured; if the client is not configured to receive replication instructions, it rejects them. The client's receive configuration is set using the same user interface pages as the server. To configure a client to receive replication, follow these steps:
Step 2 In the Replication Components section, check the Receive checkbox for each of the fields in which to accept data.
Step 3 Set the information in the Replication Scheduling section to match the information configured on the AAA server that is to be the master.
Step 4 In the Replication Partners section, in the Accept Replication From drop-down box, click the name of the AAA server that is to be the master.
Because system replication is a critical process, Database Replication provides visual alerts and logging to notify the system administrator of any problems that occurred during a replication event.
If replication fails, the CiscoSecure ACS displays an error message in red at the top of the Database Replication page. In addition to notification of errors, the message also informs the operator of the error code generated by the last unsuccessful run and suggests that the operator check the error log messages generated for previous failures. To dismiss the message and remove it from the screen, click OK.
Event logging is provided in two logs, the Windows NT Event Log and a dedicated comma-separated value (CSV) log file, for Database Replication that the CiscoSecure ACS maintains. All events are logged, whether they are successful or not. To view the Windows NT Event Log, use the Windows NT administration utilities. To view the Database Replication Event log, click Reports and Activity: Database Replication and click the name of the file to view.
To disable replication completely, follow these steps:
Step 2 In the Replication Components section, clear all the checkboxes
Step 3 In the Replication Scheduling section, click Manually. This prevents any automated replication from being performed.
Step 4 In the Replication Partners section, if there are any AAA servers listed in the Replication column, click their names and click the left arrow button to move them back into the AAA Servers column.
RDBMS Synchronization is a powerful integration feature designed to simplify integration of the CiscoSecure ACS 2.1 for Windows NT with a third-party RDBMS application.
RDBMS Synchronization automates the synchronization with another RDBMS data source by providing the following functions:
The RDBMS Synchronization feature consists of two components:
RDBMS Synchronization operates by processing each record in the Open DataBase Compliance (ODBC) Import Table and then deleting the record after it is processed. The ODBC import table can therefore be considered a transaction queue and the data placed in it transient. This means that RDBMS Synchronization takes no responsibility for the maintenance of a transaction log/audit trail and that if such a facility is required, the responsibility for its creation is with the external RDBMS application. Unless the external RDBMS application has the facility to recreate the entire transaction history into the ODBC Import Table, it is strongly advised that a transaction log file be constructed for disaster recovery purposes. This can be easily achieved by mirroring all transactions in the ODBC Import Table to a second table under the external RDBMS application's control.
If the database is large, it is not feasible to recreate the CiscoSecure ACS database by replaying the transaction log for the entire history of the system. Instead, you can create regular checkpoint backups of the CiscoSecure ACS database. In this case, simply replay the transaction logs from the time of the checkpoint to bring the CiscoSecure ACS's database back up to date (that is, in sync with the external RDBMS application's database.) See the section "Database Backup and Restore Utility" in the Appendix "CiscoSecure ACS Database Utilities" for details on creating a checkpoint backup file.
Replaying transaction logs that slightly predate the checkpoint will not damage the CiscoSecure ACS database, although some transactions might be invalid and reported as errors. As long as the entire transaction log is replayed, the CiscoSecure ACS database attains a state consistent with the external RDBMS application's database.
The user interface page provided in CSAdmin for configuring RDBMS Synchronization provides control of the following items:
RDBMS Synchronization provides control of the following System DSN parameters:
To configure RDBMS Synchronization to use a particular DSN, click the desired system DSN in the pull-down list of available DSNs and enter the appropriate username and password into the fields provided.
RDBMS Synchronization takes its data from a valid ODBC data source. To be available for selection from the CiscoSecure ACS User Interface, the data source must be correctly installed from the Windows NT ODBC Control Panel applet before the CiscoSecure ACS can access the RDBMS Synchronization configuration pages. To simplify usage, a Microsoft Access database file (CSDB Sync.MDB) for use by RDBMS Synchronization is supplied with the CiscoSecure ACS. This ODBC data source is added to the available System DSNs with the name "CiscoSecure DBSync" during the CiscoSecure ACS installation process. No further ODBC data source configuration is required to make use of this data source, because it is installed as the default System DSN for RDBMS Synchronization. By default, the username and password parameters are set to null and should be changed for increased data security after installation.
To use a different file or database, such as Microsoft SQL Server or Oracle, you must define a System DSN defined for this data source for RDBMS Synchronization to use. SQL scripts are provided to help you generate a table in the correct format for both Microsoft SQL Server and Oracle's Oracle8 RDBMS servers.
RDBMS Synchronization can be scheduled to synchronize in one of three ways:
To select the desired mode of operation, click the appropriate radio button and configure the parameters as appropriate.
By default, RDBMS Synchronization is disabled.
RDBMS Synchronization supports synchronization to one or more target CiscoSecure ACS systems.
To select a target system for synchronization, click the desired target system in the left list box and press the right arrow button to move the selection into the right list box of configured target systems. Repeat this process as required.
To deselect a synchronization target, reverse the above procedure using the left arrow button.
Because RDBMS Synchronization is a critical process, CSDB Sync provides visual alerts and logging to notify the system administrator of any problems that occurred during a synchronization event.
This section provides the information you need to prepare your ODBC-compliant database, such as Microsoft Access or Oracle, for importing to a CiscoSecure ACS database.
A single table is used to import user/group information into one or more ACS servers. The CSAccupdate service processes the table and updates local/remote ACS installations according to its configuration.
Due to the nature of the "flat" structure, not all the fields in the table are required for every type of transaction. In the following sections the tables specify which fields must be present for each transaction type (or action).
The following fields are mandatory:
Therefore, these fields are not included when discussing per-action mandatory fields
Any modification to database format or the value set that can be assigned to a user or group must be made with reference to this section; otherwise incorrect user information might be set by third-party account information systems.
CSAccupdate will attempt to open an ODBC System DSN called "CiscoSecureImport." This DSN should contain a table named "accountActions." The Update table will have the following fields. The database that contains the table can be from any vendor, provided that the ODBC drivers are suitable for use with multithreaded services.
Records are read from the table ordered by Sequence ID (ascending) and priority (ascending). Most systems writing to this table will do so in batch mode, with priority = 0. This allows a STAT user addition to occur ahead of the queue if an online user addition is required. Some care is required when changing transaction priorities, because the order of processing can become incorrect; for example, changing a user's password before the user has been created.
Table 7-2 lists the valid action codes. The required column indicates which fields should be completed via the field Mnemonic name—excluding the mandatory fields, which are assumed. Where an action can be applied to either a user or group, "UN|GN" is given. To make the action affect a user, leave the group name empty.
Despite the many actions available, adding a user requires only one transaction: ADD_USER. All other user attributes can safely be left with their default actions. Table 7-3 describes the defaults for both users and groups. The term "NULL" is distinct from simply an empty string and means the value cannot or will not be processed.
| Attribute | Default |
|---|---|
User defaults
Posted: Tue Jan 21 00:22:41 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.