DirX Audit Overview

Both DirX and third-party components can produce audit trails for consumption by DirX Audit:

DirX Audit Server hosts a number of components and services: audit trail collectors and transformers and services for enriching audit messages and history entries and for calculating aggregated data as a basis for charts as well as RESTful API services. These components and services store their data usually in the DirX Audit Database.

Collectors retrieve the audit trails from their respective sources and then pass them to services in the DirX Audit Server for transformation, enrichment and storage. DirX Audit collectors can be distinguished according to their technology and the format of the audit trails they are able to consume. They can retrieve audit trails from JMS queues in the DirX Audit Message Broker, from files or from an LDAP directory server.

The collectors forward their audit trails to transformers, which convert the audit trail producer’s native format (if necessary) to the generic format used by DirX Audit. A transformer is available for audit trails produced by DirX Identity. If the audit trail is already in the DirX Audit native format, no transformation is necessary.

The transformers forward the transformed audit trails to the persistence service, which stores them in the DirX Audit Database.

The data enrichment services:

The DirX Audit Server also controls several scheduled jobs:

The DirX Audit Server provides a RESTful API that allows the DirX Audit Manager to retrieve data from the DirX Audit Database. The API is used by DirX Audit Manager.

The DirX Audit Database is a relational database that works with popular relational database servers such as Microsoft SQL Server and Oracle Database.

The DirX Audit Database provides persistent storage for original and transformed audit trails along with their summary, the history entries imported from DirX Identity, the OLAP tables and the configuration for dashboards, event filters views, and reports. Audit messages, history entries and configuration data are logically partitioned and can be stored in separate databases if necessary.

To maximize the availability of aggregated audit data, DirX Audit supports different lifetimes for audit messages, audit events and OLAP fact tables: fact tables and their associated dimension tables have the longest lifetime, while the complete audit message with all the details has the shortest. As a result, you can delete the details of audit messages and the original messages after a few months, but you can still view the charts on the aggregated data and drill down to the audit event summaries. If disk space subsequently becomes an issue, you can delete the event summaries and still be able to view the charts on the aggregated data.

DirX Audit provides command-line tools that help administrators manage the content of the DirX Audit Database according to audit trail lifetime. For example, audit messages older than six months are automatically exported and/or deleted. All of these messages (or a subset) can be imported back into the DirX Audit Events Database (Data DB) later on if necessary.

DirX Audit Manager and DirX Audit Manager Classic provide a single, central web-based interface that offers different views of the audit trails and historical identity data stored in the DirX Audit Database.

The Dashboard view presents identity audit data that the DirX Audit Server has aggregated according to the various identity audit KPIs in graphical charts. DirX Audit provides a standard set of KPIs modeled as OLAP tables to allow for fast display of important aggregated data. Using the Dashboard, auditors can perform analysis, especially time-based trend analysis of selected KPI data – for example, the total number of users created from day to day over a given period of time – and then drill down to details about audit events as necessary.

Audit analysis works directly with audit events stored in the DirX Audit Database rather than with aggregated, OLAP-structured KPI data. The Audit analysis view displays page-through tables of audit events retrieved from the DirX Audit Database according to a given search filter. The difference between an audit message and an audit event is as follows: an audit message includes the operation, the "where from", "who" and "what" information extracted from the message and the original message in the native format as obtained from the audit producer (for example, DirX Identity). An audit event extends an audit message with one or more informational summaries of the operation recorded by the message and the objects on which it operated. For example, an audit message could cover a couple of group membership changes of one group or one account or it could be associated with a self-registration request workflow that includes the creation of a user along with several role assignments. In these cases, each account-group membership and each role assignment are associated with an extra audit event. As a result, you can have several audit events attached to the same audit message. The operation of an audit event normally contains higher-level, business-friendly information, for example: add assignment, accept add assignment, set password. Additional fields of the event show the object type (user, role, user to role, account to group) and detail information specific to the operation and the object type. For example, for a role assignment, the details contain the user name, the role name, start and end date of the role assignment as well as role parameters and the name of the approval workflow or the name of the approve activity. For a new account-group membership, it contains the names of the account, the group and the target system.

The History view allows an auditor to examine the status (snapshots) of identities and identity-related data at points in time in the past. The auditor can query for entries with their names and for a desired date. Alternatively, the auditor can select a "who" or "what" in the Audit analysis and then request its display in the History view. The History view then displays the entry’s attributes and relationships. In particular, it shows users with their privilege assignments, their accounts, and their risk score. By following the reference links, an auditor can view related entries – for example, the details of an associated role or account. The integrated timeline allows an auditor to compare the state of a selected entry at different points in time. Another tab shows – for a selected time interval – the related audit events on the actions the selected user has performed or the changes that have been applied to the selected entry. The auditor can also ask why the user has a selected privilege assignment. DirX Audit Manager then searches for and shows the root event for this assignment – regardless of whether it has been assigned manually, automatically or by inheritance.

The Reports view allows auditors to set up scheduled reports that can then be sent automatically via e-mail to selected recipients at regular intervals. The auditor defines one or more reports of several types – for example, Dashboard chart, Audit analysis audit events list, snapshot of history entries – associates them with a schedule and enters the mail recipients and text. The DirX Audit Server then manages the regular production of these reports and their delivery to the intended recipients.

Ad hoc reports can be created from all the DirX Audit Manager views based on the current query results and on pre-configured report templates. Reports can be saved to the file system for further distribution and processing. Supported output formats include HTML and PDF. Reports can also be generated in the background to avoid user idle time.

With its intuitive user interface and its access to normalized, centralized audit and history data, DirX Audit Manager simplifies and expedites the laborious, expensive and time-consuming process of sifting through obscurely formatted audit trails generated by many different applications.

Access to DirX Audit Manager or DirX Audit Manager Classic is only allowed for auditors using role-based access control. The role is assigned using either an LDAP group membership or OIDC role claim mapping (based on configured authentication method). DirX Audit distinguishes between audit administrators, normal and restricted auditors. Restricted auditors can only run and schedule reports tagged as restricted.