The dump and load utilities enable you to export database records in a format that (unlike text files) you can import into the database. For more information, see the UNIX Installation Guide.
Recovery Procedures
In the event of an Authentication Manager hardware failure or database problem, use the following procedures to recover or replace the failed hardware or database.
Some steps in the procedures depend on whether your system uses Push DB Assisted Recovery. RSA Security recommends that you enable this feature. For more
information, see “Push DB Assisted Recovery” on page 23.
To configure your system to use Push DB Assisted Recovery, start the Database Administration application, click System > System Configuration > Edit System Parameters, and select Allow Push DB Assisted Recovery.
Determining Which Database is Most Up-To-Date
If you have an RSA Authentication Manager Advanced license and are using multiple Replicas, whenever you are instructed to use the most up-to-date database, use the following procedure to make that determination. If the Primary hardware is still functioning, check the syslog on the Primary. If the Primary hardware is no longer functioning, check the syslog on each of the Replicas.
7: Database Maintenance (UNIX) 145 To determine the most up-to-date database:
On the Authentication Manager, check the syslog for the most recent successful replication.
• On the Primary, look for the following message:
Primary Successfully Received Replica Records
This message includes a date and time, and the IP address of a Replica. The Replica indicated by the IP address in the most recent message contains the most up-to-date database.
• On a Replica, look for the following message:
Replica Successfully Reconciled Databases
This message includes a date and time, and the IP address of the Primary. Check the syslog on each of the Replicas. The Replica that contains the most recent message contains the most up-to-date database.
Replacing a Replica Database
If the database on a Replica needs to be replaced, you must create a new Replica Package on the Primary and specify that the Replica requires a new database.
To replace the database on a Replica:
1. Log on the Primary as root or as the owner of the RSA Authentication Manager files.
2. Stop all RSA Authentication Manager programs and database brokers running on the Replica and on the Primary. Change to the ACEPROG directory and type the following commands at a command prompt:
aceserver stop sdconnect stop
3. On the Primary, create a Replica Package. Type:
ACEPROG/sdsetup -package
4. At the Name of replica prompt, type the full name of the same Replica and press RETURN.
5. At the Confirm prompt, type y and press RETURN again.
6. Repeat Steps 4 and 5 for each database that needs to be replaced. When you have entered all the Replicas, press RETURN at the Name of replica prompt, and press RETURN again at the Have you entered all the Replicas you would like included in this package (y/n/q) [y]: prompt.
If your RSA Authentication Manager System Parameters are set to enable Push DB Assisted Recovery, the Primary will push the database files to the Replica when you restart the Primary and Replica in the next step.
If the System Parameters are not set to enable Push DB Assisted Recovery, copy the files in the ACEDATA/replica_package/database directory on the Primary to the ACEDATA directory on the Replica.
RSA Authentication Manager 6.1 Administrator’s Guide
146 7: Database Maintenance (UNIX)
7. Start the RSA Authentication Manager and database brokers on both the Primary and Replica. On each system, type the following commands at a command prompt:
ACEPROG/sdconnect start ACEPROG/aceserver start
If Push DB Assisted Recovery is enabled, the Primary begins the assisted recovery process by pushing the new database to the Replica.
If Push DB Assisted Recovery is not enabled, the recovery process is complete.
Replacing Replica Hardware
If a Replica experiences a hardware failure and is no longer able to function, you must replace the Replica in the database with another machine. Use the Replica
Management utility to replace Replica hardware. The utility prompts you to enter the name and IP address of the Replica that you want to replace, and then prompts you to enter the name and IP address of the new Replica.
To replace Replica hardware:
1. Select a network machine to use as the replacement Replica.
2. Log on the Primary as root or as the owner of the RSA Authentication Manager files.
3. Stop all RSA Authentication Manager programs and database brokers running on the Primary. Change to the ACEPROG directory and type the following at a command prompt:
aceserver stop sdconnect stop
4. On the Primary, run the replica management utility and replace the failed Replica.
Type:
ACEPROG/sdsetup -repmgmt replace
5. At the prompt, type the full name of the Replica you want to replace and press RETURN.
6. At the prompt, enter the new system name and IP address, and press RETURN.
A replica package is generated in the ACEDATA/replica_package directory on the Primary.
7. Start the RSA Authentication Manager and database brokers on the Primary by entering the following commands at a command prompt:
ACEPROG/sdconnect start ACEPROG/aceserver start
8. Copy the replica package directory to the new Replica. If your System Parameters are configured to allow Push DB Assisted Recovery, you need to copy only the license directory. If your System Parameters are not configured to allow Push DB Assisted Recovery, you need to copy both the license and database directories.
7: Database Maintenance (UNIX) 147 9. Perform a new installation of the Replica software on the new Replica using the
new replica package. See the UNIX Installation Guide for full instructions on installing a Replica.
If Push DB is enabled, the Primary begins the assisted recovery process by pushing the new database to the replica.
If Push DB is not enabled, restart the RSA Authentication Manager services and database brokers on the Replica.
Repeat this procedure for any additional Replicas that need to be replaced.
Replacing the Primary Database
If the database on the Primary is corrupted, you must replace the Primary database with the most up-to-date Replica copy of the database, and create a new Replica Package that will be distributed to all other Replicas.
To replace the Primary database:
1. Log on the Primary as root or as the owner of the RSA Authentication Manager files.
2. Dump the database from one of the Replicas. On the Replica, change to the ACEPROG directory and type:
sddump -s
The dump utility creates the sdserv.dmp file in the ACEDATA directory. Any existing dump file is overwritten.
3. Copy the sdserv.dmp file to the Primary.
4. Stop all RSA Authentication Manager programs and database brokers running on the Primary. Change to the ACEPROG directory and type:
aceserver stop sdconnect stop
5. Create a new, empty database on the Primary. Type:
sdnewdb server
6. Load the dump file into the new database. Type:
sdload -s -f pathname/sdserv.dmp For pathname enter the location of the dump file.
7. On the Primary, create a Replica Package. Type:
ACEPROG/sdsetup -package
8. At the Name of replica prompt, type the full name of the Replica and press RETURN.
9. At the Confirm prompt, type y and press RETURN again.
10. Repeat Steps 7 and 8 for each Replica. When you have entered all the Replicas, press RETURN at the Name of replica prompt, and press RETURN again at the Have you entered all the Replicas you would like included in this package (y/n/q) [y]: prompt.
RSA Authentication Manager 6.1 Administrator’s Guide
148 7: Database Maintenance (UNIX)
11. Start the RSA Authentication Manager and database brokers on the Primary.
Type:
ACEPROG/sdconnect start ACEPROG/aceserver start
If Push DB is enabled, the Primary begins the assisted recovery process by pushing the new database to the replica.
If Push DB Assisted Recovery is not enabled, copy the files in the
/replica_package/database directory to each Replica. On the Replica, stop all RSA Authentication Manager programs and database brokers, move the database files to the ACEDATA directory, and restart the RSA Authentication Manager and database brokers.
Nominating a Replica to Replace Primary Hardware
If your Primary hardware fails, you can nominate an existing Replica to the Primary.
You must first select a Replica that you intend to nominate. Then, on the selected Replica, click the Nominate button in the Replica Management interface and automatically convert the Replica to the Primary. An updated Replica Package is created in the ACEDATA\replica_package directory of the new Primary.
Note: If you want to replace a functional Primary with newer hardware, you can add the new hardware as a Replica and then nominate it as the Primary. Then you can take the old Primary offline. However, you must follow a specific procedure to do this:
first, stop the current Primary, add the new machine as a Replica, and generate a Replica package for the new machine. Restart the current Primary, and let the Replicas fully reconcile. Now you can complete the standard nominating procedure for the new Replica, as documented in the following subsections.
Before Nominating a Replica
Before you nominate a Replica, you must assess the condition of the failed Primary hardware. If the failed Primary will be inoperable for a prolonged period, you need to nominate a Replica. If the necessary repairs can be completed in a short amount of time, you may decide that you do not need to nominate a Replica, and that instead, you will repair the original Primary. In either of these scenarios, each of the Replicas will continue to process authentication requests during the time that the Primary is not working. If you repair the original Primary, you will most likely want to inform all Quick Admin and remote administrators of the situation, and explain to them that neither Quick Admin nor Remote Administration of any machine in the realm will be possible until the Primary has been restored.
Note: RSA Security recommends that you select the Replica that contains the most up-to-date database. For more information, see “Determining Which Database is Most Up-To-Date” on page 144.
7: Database Maintenance (UNIX) 149 To nominate a Replica:
1. On the Replica, type:
ACEPROG/sdsetup -repmgmt nominate
2. Type y and press RETURN to nominate the Replica as the new Primary.
3. Start the RSA Authentication Manager services and database brokers on the new Primary.
If your RSA Authentication Manager System Parameters are set to enable Push DB Assisted Recovery, the updated Replica Package is automatically distributed to each Replica. When you restart the new Primary, the recovery process is complete.
If Push DB Assisted Recovery is not enabled, repeat steps 5, 6, and 7 on each Replica.
4. Stop all RSA Authentication Manager services and database brokers on the Replica.
5. Copy the files in the ACEDATA/replica_package/database directory and then in the ACEDATA/replica_package/license directory on the new Primary to a directory outside of ACEDATA on the Replica.
6. Apply the Replica Package. On the Replica, type:
ACEPROG/sdsetup -apply_package pathname The following message is displayed.
Replica Package was successfully applied.
Note: If you repair the old Primary and bring it back on to your network, it is automatically added as a Replica. If you want to restore it as the Primary, you must nominate it.
When you replace damaged Primary hardware by either nominating a Replica or installing the Primary on a new machine, be aware that there are resulting implications for Quick Admin, RADIUS servers, Agent Hosts, and Remote Administration. In order that these features function properly with a new Primary, perform the following tasks, referring to the appropriate instructions.
Note: RSA Security recommends that you use Remote Administration to perform these tasks so that, where necessary, you may view associated Help topics. To enable Remote Administration, you must first perform task 1 on the Primary. Then, on a Remote Administration machine, you can perform task 2 through task 7 in any order.
1. For all Remote Administration machines, copy the sdconf.rec and the server.cer files from the ACEDATA directory on the Primary to the Remote Administration machine, remove the Primary from the Remote Administration machine, and then add the Primary using the new sdconf.rec file. For more information, see the Windows Installation Guide.
RSA Authentication Manager 6.1 Administrator’s Guide
150 7: Database Maintenance (UNIX)
2. If Quick Admin is installed, you must reconfigure the Quick Admin settings with the name and IP address of the new Primary. For instructions, see “Reconfiguring Quick Admin” on page 51.
3. If the Authentication Manager is specified as a Local Realm Authentication Manager or a Remote Realm Authentication Manager for cross-realm
authentication, edit the realm record in the database, and in the Remote realm database to reflect the new name or IP address. For more information, see the Help topic “Edit Realm.”
4. If the failed Primary was specified as a RADIUS server, you can either install the RADIUS server on the new Primary, another Replica, or a separate host machine.
So as not to impact the administrative capability of the new Primary,
RSA Security recommends that you enable RADIUS on another Replica. Be sure to
• Add the Authentication Manager you choose to use as the RADIUS server to the database as an Agent Host. For more information, see “Adding Servers as Agent Hosts to the Primary Database” in the Windows Installation Guide.
• If you opt to use the new Primary as the RADIUS server, update the RADIUS Server configuration settings so that they are identical to those that were on the old Primary.
• Configure all RADIUS clients to use the appropriate name and IP address of the designated RSA RADIUS server. See the NAS device manual for specific configuration instructions.
5. If the Authentication Manager is specified as an Acting Server for legacy Agent Hosts, generate new sdconf.rec files for all legacy Agent Hosts that use this Server as an Acting Master or Acting Slave, and distribute the sdconf.rec file to the Agent Hosts. For more information, see the Help topic “Assign Acting Servers.”
6. If the Authentication Manager was previously set up with LDAP synchronization jobs that use SSL to connect to the LDAP server, make sure that the new Primary has the required cert7.db file in the ACEDATA/ldapjobs/sslcerts directory.
Otherwise, when LDAP synchronization runs, you will see the error:
LDAP connection error - Failed to initialize LDAP session For information about setting up the cert7.db file, see “Using SSL” on page 114.
7. If the Authentication Manager is specified in any sdopts.rec files for version 5.0 Agent Hosts, edit the sdopts.rec file on the Agent Host to reflect the new name or IP address of the Authentication Manager.
7: Database Maintenance (UNIX) 151
Maintaining Customer-Defined Data (Extension Records)
The RSA Authentication Manager extension records enable you to define and manage database information that is useful to your organization although it is not required to run RSA Authentication Manager programs. This customer-defined information is called extension data.
The RSA Authentication Manager Database Administration application, which you run on your Remote Administration machine, provides menu options that you can use to access and process extension records.
The following table shows each type of extension data you can manage, the database table where it is stored, the menu you use to manage it, and a place to find further information.
To create reports based on customer-defined data, click Extension Data on the Report menu.
Note: For additional information about extension fields and about creating custom administration programs, see the Administration Toolkit Reference Guide
(authmgr_admin_toolkit.pdf in the ACEDOC directory).
Managing Log Extension Data
This section explains how to create, modify, and delete log-related extension data. You can find information on managing other kinds of extension data through the table in the preceding section, “Maintaining Customer-Defined Data (Extension Records).”
You can add information to existing log entries in log entry extension fields. This information can then be used to select the log entries for a report.
Extension Data Database Table Menu See Page
RSA Authentication Manager system-related
CustSystemExtension System 215
Agent Host-related CustClientExtension Agent Host 57
Group-related CustGroupExtension Group 122
Log entry-related CustLogExtension Log 152
Site-related CustSiteExtension Site 135
Token-related CustTokenExtension Token 120
User-related CustUserExtension User See the Help
RSA Authentication Manager 6.1 Administrator’s Guide
152 7: Database Maintenance (UNIX)
To edit log extension data:
1. Start the Database Administration application on your Remote Administration machine.
2. Click Log > Edit Log Extension Data.
3. Select the type of log message to which the extension data is related: Activity, Exception, or Incident.
The Log Entry Selection Criteria dialog box opens.
4. Enter specifications in one or more fields. For an explanation of the fields, see
“Selection Criteria for Report Content” on page 164.
To reset all selection criteria to the default values, click Clear.
5. After choosing the selection criteria, click OK.
The Select Log Entry dialog box opens and displays only log records that meet all the specifications you entered.
For each entry, the dialog box shows the time (Coordinated Universal Time and local time), the user for whom the activity was recorded, and the log message. The selection values remain in effect until you or another administrator changes them or until you end the current administration session.
6. Select the log entry to which the extension data is related, and click Edit Log Extension data.
The Edit Log Extension Data dialog box opens and displays the log entry and the records defined for this entry. Each record consists of a secondary key (up to 48 characters) and data (up to 80 characters).
7. You can add, modify, or delete these records. You can create more than one record with the same key, but you cannot create duplicate records (records having the same key and the same data values) in one extension database table.
• To change an existing record, select the record, modify the information displayed in the Key or Data fields, and click Save. (The Save button is unavailable until you make an entry in one of these fields.)
To clear the fields without changing the record, click Clear.
• To create a new record, click Clear if necessary to clear the Key and Data fields, enter the information for the new record, and click Save.
• To delete a record, select the record, and click Delete. Click OK to confirm.
8. Click Exit to close the Edit Log Extension Data dialog box.
7: Database Maintenance (UNIX) 153
Running External 4GL Procedures
If you are comfortable programming in 4GL, you can run custom 4GL procedures to process RSA Authentication Manager data directly from the Database Administration application. To run a procedure that updates RSA Authentication Manager data, you must be a realm administrator or be assigned the Run Custom 4GL task.
CAUTION: A 4GL procedure can overwrite or delete valid data, such as log records or
CAUTION: A 4GL procedure can overwrite or delete valid data, such as log records or