Initial Deployment

This chapter describes topics that you should consider when installing DirX Audit and running the initial configuration.

Use the JMS Audit Event Collector

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 import folder of the DirX Audit 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.

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.

  • Scheduled reports – produces and sends the requested reports. It checks not only regularly scheduled reports, for example daily or weekly, but also those that are started in DirX Audit Manager to be generated “as soon as possible”. Therefore, the job should run frequently; the default is every 30 seconds.

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.