Initial Deployment

This chapter highlights the key decisions and setup tasks that matter during the initial deployment of DirX Audit and the first production configuration.

Initial Load of Audit Messages

Before switching to continuous audit message processing, an initial load of existing audit messages can be performed. This allows existing audit data to be imported into the DirX Audit Database and made available for reporting and analysis from the beginning.

For the initial load, audit messages are archived in XML files and imported using file-based collectors. The collector to use depends on the origin of the audit messages:

  • Audit messages originating in DirX Identity are imported by the File collector for DirX Identity format.

  • Audit messages originating in DirX Access are imported by the File collector for DirX Access format.

The XML archive files must be copied to the input folder configured for the respective file collector. The collectors process the files and import the contained audit messages into the DirX Audit Database.

For a step-by-step example of importing audit messages from XML files with file collectors, see “Loading the Sample Data from the DirX Identity Source” in the DirX Audit Tutorial.

When preparing the initial load, consider the following recommendations:

  • Ensure that archive files are complete and are no longer being written to before copying them to the collector input folder.

  • Separate DirX Identity and DirX Access audit archives so that each collector processes only the files intended for it.

  • Import the archived audit messages before enabling the regular JMS- or file-based collection for new audit messages.

  • After the import has completed, verify that the expected number of audit messages has been loaded before deleting the archive files.

For ongoing audit message collection after the initial load, we recommend using the JMS collectors as described in the following section.

Use the JMS Collectors

Several event collectors for importing audit events into the DirX Audit Database are provided. For DirX Identity, the LDAP collector is mandatory: it reads the audit events from the dxrHistory attribute of the LDAP entries.

For DirX Access and the additional DirX Identity audit messages, you must choose between the JMS collector and the File collector. For both cases, we recommend selecting the JMS collector. The disadvantages to using the File collector are:

  • Audit files must be moved to the input folder of the File collector. Make sure that they are moved only after the provider (DirX Identity / DirX Access) has closed them.

  • There is a risk of inadvertently copying files repeatedly to the import folder and thereby provoking error logs of duplicate import.

  • The amount of disk space required to store the files is typically greater than what the Message Broker requires; with the Message Broker, the messages are processed immediately and are then automatically removed from the Message Broker repository.

Decide Whether to Store Original Messages

Before audit messages are transformed into the DirX Audit internal format, they are delivered by DirX Identity and DirX Access as XML documents. During processing, a transformation converts these source-specific XML documents into the unified DirX Audit message format.

Optionally, the original XML document can also be persisted in the DirX Audit Database together with the transformed audit message. The XML document is stored in compressed form to reduce the required database space:

  • In Microsoft SQL Server, the compressed data is stored in a varbinary(max) column.

  • In Oracle Database, the compressed data is stored in a BLOB column.

If original message storage is enabled, users can view the original source XML document in DirX Audit Manager when analyzing audit messages.

Before deployment, decide whether the benefits of retaining the original XML messages outweigh the additional database storage requirements.

Advantages of Storing Original Messages

  • Complete audit traceability. The exact message received from DirX Identity or DirX Access is preserved.

  • Easier troubleshooting. Administrators can compare the original XML document with the transformed DirX Audit representation when investigating data mapping or transformation issues.

  • Simplified verification of transformations. The original source data remains available for analysis without requiring access to the source system.

  • Support for future investigations. Additional information contained in the original XML document may be useful even if it is not currently mapped to DirX Audit fields.

  • Convenient access. The original message can be viewed directly in DirX Audit Manager.

Disadvantages of Storing Original Messages

  • Increased database size. Even though the XML documents are compressed, they still consume additional storage space.

  • Longer backup and restore operations due to the larger database volume.

  • Higher database maintenance costs, especially in environments with a high audit message volume and long retention periods.

  • Additional I/O during message import because both the transformed audit message and the original XML document must be persisted.

For more information about configuring the storage of original messages, see “Configuring DirX Audit” in the DirX Audit Installation Guide.

Exclude Unused Fact Tables

The DirX Audit Server fact population job regularly computes a lot of facts and then stores them in fact tables whose names start with FCT_. Your company may not use some of these tables. If you exclude these unused tables from processing, the fact population job is faster and the database requires less disk space.

The default fact tables along with the configuration for dimensions and facts are configured in the folder install_path/conf/defaults/fact_configuration. The configuration of the fact tables themselves is in the file confFactTables.xml. If you want to customize them, copy these files to the tenant-specific folder:

install_path/conf/tenants/tenantID/fact_configuration

and then adapt them. For more detailed information about this task, see the section “Managing Fact and Dimension Tables” in the DirX Audit Administration Guide and the section “Configuring Fact Tables” in the DirX Audit Customization Guide.

If you do not have DirX Access installed, consider dropping the fact table for authorizations:

  • FCT_AUTHORIZATIONS

If you do not have the license for the History feature installed, consider dropping the fact tables based on history entries; the names of these fact tables start with FCT_HST_.

Schedule Post-Processing Jobs in Logical Order

The DirX Audit Server hosts several data post-processing jobs that extend audit messages and history entries. History entries are imported into the DirX Audit History Database by History Synchronization jobs running on DirX Audit Server. All these jobs have a logical order of execution as some jobs process data that have been updated by other jobs.

We recommend scheduling them in the following order:

  1. DirX Audit History Synchronization jobs – imports the history entries from the DirX Identity domain into the DirX Audit Database. You can schedule Modify or Delete job for multiple entry types. They execute sequentially one by one.

  2. History DB update – adds virtual attributes to history entries that support subsequent dimension and fact calculation. Especially it adds the database foreign keys to link table attributes and thereby establishes the references between history entries.

  3. Fact population – fills the dimension tables (DIM_) and then the fact tables (FCT_). Lots of fact tables are based on the history entries and especially on their references and virtual attributes.

Schedule the following DirX Audit jobs to be repeated short term:

  • Context records calculation – calculates relations between audit messages that were caused by the same core event; they are considered to be in the same context. The job processes only audit messages not yet associated to a context. If it is scheduled every 5 minutes (the default), there is only a small number of events and it finishes quickly.

Reports are scheduled individually. In order to get up-to-date data, they should be scheduled after the respective jobs have run. For example, if they display history entries, they should be scheduled after the history update job. If they use facts from fact tables, they should be scheduled after the fact population job.

Additional scheduling considerations include the following:

  • The jobs generate high load both in the DirX Audit Server and in the database server. If your configuration has multiple tenants, the jobs for the tenants should not all run at the same time.

  • The jobs update database tables and during this time block them for other updates and sometimes also for parallel reading.

  • Indexes should be reorganized or rebuilt from time to time as the content of the table changes. During an index update, the database server locks the corresponding table. The need for index update depends on the number of changed records, namely those in the tables for audit messages and history entries. As a rule of thumb, update indexes and statistics once per week and outside of business hours. For more information on indexes, see the section “Maintain Database Indexes” in chapter “Day-to-Day Management” of this guide.