Trail Problems

This section describes solutions to potential external audit trail problems. These include audit trail overflow and recovery from catastrophic failures.

Audit Trail Overflow

Preventing Loss of Audit Data describes the potential for audit loss if the configured number of audit files are filled or disk space fills up and the audit trail is improperly configured.

Audit Options Configuration describes the three overflow configuration options for external audit trails:

• Archive audit file
• Disable record submission
• Disable event recording

The only option that prevents the loss of audit events (from audit overflow situations) is to disable record submission. With this setting, the server stops accepting externally generated events either when the current audit file has reached the Audit file maximum size or the server cannot write the current audit file (for example, it is out of disk space).

Procedure

Use the following steps to deal with audit trail overflow.

1. Log in as an auditor with sufficient rights to the external audit trail's Audit File object.

2. If you want to save the oldest audit file, and you haven't already backed it up, copy the oldest old audit file to offline storage (for example, a file in the server or workstation or removable media).

3. Reset the current external audit file, as described in Reset Audit Data File.

   This archives the current audit file (to an old audit file), deleting the oldest old audit file, and creates a new audit file.

4. If you want to save any audit files that you haven't already saved (including the newest of the old audit files), copy those audit files to offline storage.

The following pointers help prevent external audit trail overflow:

1. Review the status and size of the audit file frequently.
2. Manually reset the audit file before it overflows, if necessary.
3. Enable Automatic audit file archiving as described in Audit Options Configuration. Set the Audit file maximum size large enough and the Days between audit archives low enough that the audit file will not overflow.
4. Don't over audit.

WARNING:  If the external audit trail is full, the auditor's actions (for example, deleting data files, resetting the audit file) might not be audited. In this case, you must keep a manual log of your actions for use when generating a complete history of actions performed on the server. You will be informed via a message from the server to your workstation when this occurs.

When the audit trail reaches its configured threshold, you will receive the following notification on your workstation screen:

When the audit trail is completely full, you will receive the following notification on your workstation screen:

To avoid missing this message, you must not issue the SEND /A=N or SEND /A=P commands (or if using Windows and the NetWare User Tools, do not disable network warnings), as they would cause these messages to be suppressed.

Catastrophic Failure Recovery

This section describes what to do if a catastrophic failure destroys the volume containing the external audit data is destroyed. One such catastrophic failure would be hard disk failure. You will need to return the audit data to the state it was in before the failure.

This section also explains how to handle planned upgrades, such as moving a volume moved from a small disk to a larger disk.

There are several potential losses not addressed here:

• Loss of offline audit data. Your offline audit data (whether it's stored in server or workstation file systems or on removable media) should be backed up frequently enough that its loss would not be catastrophic.
• Loss of some, but not all copies of the Audit File object describing the external audit trail due to failure of one or more servers holding an NDS partition. In this case, NDS will automatically use whatever copies are available. If a server configured for the partition is brought back online, then it will automatically be updated with the Audit File object information.

There are two major catastrophic failures possible for external audit.

• Loss of all copies of the Audit File object describing the external audit trail. If all copies of the Audit File object are lost (for example, because there only was one copy, and the server it was on suffered a disk failure), then you might be able to recover the Audit File object from a backup of your Directory tree (presuming you have backed up your Directory tree). If so, then you can regain access to the existing online audit data. If not, then no access is possible to the online audit data. You must re-create the external audit trail using the procedures in Create External Audit Trail.
• Loss of the volume containing the external audit data (for example, because of a disk failure). Because external audit files are stored in an inaccessible directory which cannot be backed up, loss of the volume means that the online audit files (both the current audit file and any old audit files) are lost. You should use AUDITCON to perform regular backups of audit data to avoid loss of online audit data.

  In addition to loss of the online audit data, loss of the volume means that the server will no longer have the information it needs to accept additional audit records. If this occurs, you should enable auditing using the procedures in Create External Audit Trail.

Upgrade of a volume (for example, replacing it with a larger disk) is equivalent to recovering from a catastrophic disk failure. To do an upgrade, you must first back up the old volume, and then restore it on the new disk. This loses all audit data. Therefore, before performing a volume upgrade, you should also back up all external audit data. After the new disk is installed, you should enable the external audit trail using the procedures in Create External Audit Trail.

Immediacy of Changes

When you modify the external audit trail configuration (for example, to change the maximum size of the audit file), the change is made both to the Audit Policy property of the Audit File object and to the header of the current audit file. Both changes will usually occur immediately.

However, the effect of the change might not be immediate if the server holding the audit data is unavailable to receive the configuration change (for example, because it is down or the network has been split), even though the Audit File object can be modified. In this case, the delay depends on how long it takes before the two servers can synchronize their NDS replicas.

In addition, changes to the ACL of the Audit File object that represents the external audit trail do not affect any connections that have already been established. That is, if a workstation has already started uploading audit data to a server, changing the ACL will not affect that workstation's ability to perform uploads.

To force a workstation to stop uploading data immediately, you should break that workstation's connection to the server using the console MONITOR utility or the CLEAR STATION console command.

Similarly, if an auditor is performing audit trail management functions, changing the ACL will not affect the auditor's capabilities (either to increase or decrease them). An auditor's rights are recalculated every time he or she restarts AUDITCON and establishes access to an audit trail. To stop the auditor's actions immediately, you should break the auditor's connection to the server using the console MONITOR utility or the CLEAR STATION console command.