Synchronous auditing is a new feature introduced in Siteminder R12.
This option prevents loss of audit data should the audit database server go down. However the feature must be used carefully, to prevent a Siteminder system outage.
This document details how to use synchronous auditing and how to manage outages of the audit database.
The Architecture of the Auditing function.
The architecture of Siteminder's auditing capabilities is in figure 1 (Below).
Figure 1 Auditing Architecture
- The transaction is logged by the policy server.
- The transactions are grouped together in a data block.
- When the data block becomes full the block is written to the SQL server.
- The audit data is inserted into the SQL database.
The difference between conventional and synchronous auditing.
While the SQL server (and Audit database) is functioning normally there is no difference between the auditing systems. However the auditing systems are fundamentally different when the policy server cannot access the Audit database.
As can be seen in the diagram below when synchronous auditing is disabled the policy server discards blocks that cannot be written to the database. This results in incomplete audit logs, but protects against over-use of the servers RAM by blocks.
In the Synchronous auditing model, if a block cannot be written it remains in the servers RAM and a new block is created. The number of blocks stored in the servers RAM therefore continues to increase until a database server becomes available. This ensures no auditing data is lost, however during a database server outage it could have a negative impact on policy server performance and in extreme cases cause the policy server to fail. These negative aspects however can be mitigated by appropriate planning and procedures.
Figure 2 The difference in auditing types.
The saving of blocks in memory by Synchronous auditing is designed to be a temporary solution to a short database outage (such as a database server reboot). Any extended system outages must be planned for to prevent performance impacts on the policy server.
If you expect an extensive outage to the SQL server you should follow the procedure bellow to switch from ODBC to text based storage. This procedure can also be used with conventional auditing if you wish to preserve data blocks that would normally be discarded.
- Start the
- Click the tab
- Select from the database dropdown.
- In the storage dropdown change the selection from ODBC to Text file.
- Specify a location for the text file.
- Click ok.
- Restart the policy server for the change to take effect.
After following this procedure the policy server will save audit data to the text file, allowing for an extended database server outage.
Once the database has been restored (and confirmed working) follow the same procedure to switch to text based to ODBC logging.
Enabling synchronous auditing
Synchronous auditing is enabled/disabled on a realm by realm basis, to do this follow the following procedure:
- Login to the WAM Administrative UI
- Select the policies tab
- Click domains
- Click Realm
- Click modify realm.
- Select the realm you wish to modify the auditing for.
- Scroll down to the Session section.
- Mark the "Synchronous Auditing" checkbox.
- Click to save the change.