Before Deployment

You use the audit policies of a DirX Identity domain to control the audit events and their content. Use Audit Policies in the Audit Trail folder of the Auditing view in DirX Identity’s Provisioning view group to manage these policies.

An audit policy must be active for each entry type to be audited. The entries are identified either by their object description name for service layer components or by LDAP object class and optionally dxrType. Each object requires an audit object type. Please do not change the default types! They are evaluated in subsequent processes; for example, to calculate the digest, which is a business summary of the audit event.

The list of audited attributes controls when an audit event is produced: always when one of these attributes has been changed. If none of these attributes is changed, no event is generated.

When an event is produced, the list of identifying attributes is always entered into the event. Identifying attributes help to:

Fewer audited entries, fewer audited attributes and fewer identifying attributes reduce the total size of the DirX Audit Database.

The above audit policies apply when entries in the DirX Identity Store are changed. They do not apply to changes in connected systems by the Provisioning workflows. They write audit events only when the flag “Write Audit Log” is set for the controller of the join activity of the workflow. As lot of the attributes in the connected systems are different, only a standard set of identifying attributes can be inserted into an audit event and only if its attributes contain these standard names.

Please also pay attention to the channel names of the Provisioning workflows. They are used as the audit object type in the audit event, so they appear, for example, as dimension values in charts next to the standard types like user, role, account, and group. As mentioned before, they also affect the digest generation. This is especially important for accounts and groups. The channel names in the Provisioning workflow configuration should at least contain the string “account” or “group” respectively.

Use DirX Access Manager’s Audit Service configuration section to control the number of audit events produced by DirX Access. You can configure the auditing subsystem to push a substantial number of audit events to auditing sinks. Carefully consider individual auditing levels based on the planned server characteristics and the expected audit messages usage.

For more information, see “Auditing” in the DirX Access Administration Guide.

You must decide which entry types and which of their attribute types are stored in the DirX Audit History Database. Note that invalidated entries and invalidated attribute values remain in the DirX Audit History Database even after they have been deleted from the DirX Identity domain; they receive a VALID_TO timestamp to indicate the end of their lifetime.

DirX Identity entry types are represented in DirX Audit History Database by entry type definitions. Each type definition in a DirX Audit tenant properties file contains an entry type name in the DirX Audit History Database and LDAP search base and a search filter that defines a set of synchronized entries from DirX Identity. There are predefined types for all standard entry types in DirX Identity. LDAP History Synchronization jobs are scheduled for one or more entry types.

The first thing to consider is which entry types you need to have synchronized in the DirX Audit History Database. Important entries are users, target systems with accounts and groups, roles, and permissions, if they are used. Also important are request (approval) workflow instances, but what about their definitions? Do you work with tickets, which are change orders to be executed at a future due date? Do you use certification campaigns? Is it important that you have delegations or configuration objects in the DirX Audit History Database?

Once you select the entry types to be stored, you must select which of their attributes are stored. Some attributes that should not be stored in the DirX Audit History Database are already excluded; for example, dxrHistory or passwords. You can also exclude attributes that are not important for you. For details, see the section “Excluding Attributes from the Synchronization“ in the DirX Audit History Synchronization Guide.

Over time, the DirX Audit History Database size will grow as new entries and attributes are added, but nothing is deleted automatically. Typically, entries and attributes invalidated more than perhaps one year ago are no longer relevant. Consider removing them with the DirX Audit dxthistdbtool tool. See the section "Remove Old Data" in the chapter “Day-to-Day Management” in this guide for details. Note that this tool can also archive data. In a subsequent version, it will allow you to re-import the archived data later when necessary.

DirX Identity entry attributes are stored in small, link, and large attributes database tables. The configuration of attribute mapping to tables is in the DirX Audit tenant properties file. See the section “Configuring and Customizing DirX Audit History Synchronization Jobs“ in the DirX Audit History Synchronization Guide for details. The table for small attributes can only take values with a maximum size of 850 characters. If History Synchronization jobs try to insert an attribute value longer than this, DirX Audit Server logs a warning and only the truncated value is stored in the DirX Audit History Database.

Attributes with a value longer than the limit should be stored in the large attributes table. Note that large attributes are not currently displayed in DirX Audit Manager, so storing them in the DirX Audit History Database is not of much value and thus they are excluded from History Synchronization jobs by default. See the section “Customizing Attribute Mapping“ in the DirX Audit History Synchronization Guide for information on modifying attribute mapping.

Attributes that are links to other entries, for example, DN and dxrGroupMember* are synchronized to the link attributes table. This table shares maximum attribute size restrictions with the small attributes table. Attribute values exceeding the limit are stored truncated.

There are two types of History Synchronization jobs:

Normally it is sufficient to run Modify job for all entry types that you need to have in your DirX Audit History Database once a day before running other DirX Audit History Database jobs. You should schedule one Modify job for all synchronized entry types. If you have one entry type in DirX Identity that is frequently modified, you should consider running Modify job for the type more often.

Generally, DirX Identity entries are not frequently deleted. It should be sufficient to run Delete History Synchronization job for all your synchronized entry types once a week.

You must consider the History Synchronization jobs schedule and adjust it to your needs. Keep in mind that it is not possible to run more than one Modify or Delete job at a time. This situation is indicated in the DirX Audit Server log. If you try to start a DirX Audit History Synchronization job while another History Synchronization job is running, the second job will not start.

The folder install_path/webapps contains default web applications that should not publicly be available in productive deployments. Especially remove the documentation, examples and root applications. If you decide to allow remote administration and keep the Manager or Host Manager applications, secure them appropriately.

Some default components like the Error Report Valve include Tomcat server version info in their responses. Eliminate that by setting appropriate information in the Server Info properties:

Create the file ServerInfo.properties in the folder install_path/lib/org/apache/catalina/util with the following content:

server.info=Apache Tomcat

When an auditor logs in to DirX Audit Manager, the Manager reads the user’s groups from LDAP to find the right DirX Audit application role for the auditor. If there are a lot of groups that match the group search criteria, this operation can take a very long time.

We recommend refining the search criteria and if possible, moving the auditor groups to a separate subfolder in LDAP. Adapt the search base and search filter accordingly using the Authentication Configuration in the Configuration Wizard for the Tenant Configuration.

As of Java 1.8.181, the endpoint identification for LDAPS (secure LDAP over TLS) connections is enabled by default. If the certificate doesn’t contain the right host (hostname or IP address) of the LDAP server (in SAN = subject alternative name), the Java runtime cannot set up the TLS connection.

The best solution is to add the host to the certificate. If this is not possible, you can disable endpoint identification by setting the following Java system property when starting the JVM:

-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true