Configuring DirX Audit

Common Audit Configuration:

Audit Message Broker:

Common Audit Managers Configuration:

Audit Manager Classic:

Audit Server:

Persistence configuration – Configure general persistence settings.

SMTP configuration – Configure emailing services.

Folder for persistent files – The full pathname to the folder for storing reports generated by users and user configuration.

Send emails – Whether (checked) or not (unchecked) the email notifications and scheduled reports are provided.

Authenticate – Whether (checked) or not (unchecked) the email sender is authenticated.

Test connection – Click to test the SMTP server connection. If the connection fails, an error message is displayed. In this case, you can continue with the configuration, but it is your responsibility to correct your settings later on.

Message Broker connectivity configuration – Configure the message broker connectivity.

Message Broker system service configuration – Configure the message broker system service.

Message Broker administrative credentials configuration – Configure the message broker internal technical accounts.

Enable SSL – Whether (checked) or not (unchecked) to enable using secure (SSL) connection globally. Includes secure connection to ActiveMQ console and JMS message broker. Communication over secure channels between components and services is recommended.

Enable OpenWire connector – The default transport for receiving audit messages over JMS. This field must be enabled if you don’t use SSL so that the OpenWire connector is used for local client connection.

OpenWire connector URI – The JMS message broker listen URI, in the format tcp://host:port, where host specifies the server name or IP address of the interfaces to which the server is to bind (listen on) and port specifies the server port number. The default host value is 0.0.0.0, which configures the server to listen on all available network interfaces. Be careful when setting specific IP addresses or host names; for example, remember that the locally-installed Audit Server JMS collector will most likely use the loop-back interface. The default port value is 30666.

Enable SSL connector – Whether (checked) or not (unchecked) to enable the connector using secured (SSL) connection.

SSL connector URI – The JMS message broker listen URI, in the format ssl://host:port, where host specifies the server name and port specifies the server port number. See the OpenWire connector URI format description for information about specifying the host value. The default port value is 30667.

Local client (connector) URI – The local client connection URI, in the format tcp://localhost:port, where localhost specifies your local server name and port specifies the server port number. The default port value depends on previous selection (30666 or 30667 for SSL). If the OpenWire connector is enabled, the default port for loop-back interface is used. The Configuration Wizard uses this URI as default value for the first Server JMS Collector configuration in the Tenant configuration.

Remote client (connector) URI – The remote client connection URI, in the format tcp://host:port or ssl://host:port, where host specifies your server name and port specifies the server port number. The default port value depends on previous selection (30666 or 30667 for SSL).

Keystore location – The path to the keystore which will be used for secure connection. Click the Open file browser button at the end of the line to find your location. If you followed our example for keystore preparation and you saved the created keystore to the default location, the keystore location should be: install_path/conf/crypto/stores/broker-ks.jks.
For more information, see the section “Preparing Truststores and Keystores for SSL Configuration” → “Preparing the Message Broker” in this guide.

Keystore password – The valid password for your keystore. Click the button at the end of the password field to view the password.

Truststore location – The path to the truststore which will be used for secure connection. Click the Open file browser button at the end of the line to find your location. If you followed our example for truststore preparation and you saved created truststore to the default location, the location should be: install_path/conf/crypto/stores/broker-ts.jks.
For more information, see the section “Preparing Truststores and Keystores for SSL Configuration” → “Preparing the Message Broker” in this guide.
If it is missing, the standard Java KeyStore (JKS) is assumed.

Truststore password – The valid password for your truststore. Click the button at the end of the password field to view the password.

Message repository – the folder where the queue data and messages will be stored.

(Re-)Install system service support – Whether (checked) or not (unchecked) to install or re-install support for running as a system service. This parameter is set (checked) and read-only on initial configuration.

Run as a system service – Whether (checked) or not (unchecked) to run the message broker as a system service.

Windows Instructions

Start system service now – Whether (checked) or not (unchecked) to start the message broker service after finishing the configuration.

System service name – The service name.

System service display name – The service display name.

System (system) – The password for the internal ActiveMQ system account for administration.

Enable JMX – Whether (checked) or not (unchecked) DirX Audit Message Broker monitoring with Java Management Extensions technology is enabled. It is enabled by default and has read-only access.

Enable Web Console – Whether (checked) or not (unchecked) Message Broker Web Console is enabled. It is enabled by default. JMX have to be enabled to enable Web Console.

(Re-)deploy Audit Manager Classic application – Whether (checked) or not (unchecked) to re-deploy the Manager Classic application with your changes.

Choose default tab – The default tab which is displayed in DirX Audit Manager Classic after user login.

Enable SSO – Whether (checked) or not (unchecked) to use SSO with header injection authentication.

User header – The name of the HTTP request header that conveys the user name.

Tenant header – The name of the HTTP request header that conveys the tenant name.

Kerberos file – The path to the Kerberos configuration file which contains the settings for Kerberos. For more details, see the chapter “Windows Authentication Using Kerberos Login Module” in the DirX Audit Administration Guide.

Time range for running scheduled jobs – The time range when you want to run scheduled jobs. The default values are at night 9 p.m. – 5 a.m.

Exclude range – When checked, the time range when scheduled jobs should not be run; for example, between 2 a.m. and 3 a.m. because time is shifting or your system backup is in progress.

Click Previous to change any settings you have made.

Click Next to start the Core configuration process.

Display current configuration log – To display information on the DirX Audit configuration you just performed, including thrown exceptions.

Display configurator log – To display information on the application status of the Configuration Wizard.

Next – To start the Tenant configuration.

Run Tenant Configuration – Whether (checked) or not (unchecked) to start the Tenant Configuration. At least one tenant must be configured if you configure a new installation.

Expected number of tenants – The number of tenants you want to configure. At least one tenant must be configured.

Click Finish to finish the Core configuration process and to start the Tenant configuration process.

Create New Tenant – To create a new tenant.

Modify Existing Tenant – To configure settings of an existing tenant.

Remove Existing Tenant – To remove a tenant.

Database Configuration

Authentication Configuration – Configure the required authentication parameters.

Audit Manager Application Configuration – Configure deployment of Audit Manager Application .

Authorization Configuration – Configure fine-grained access control method to be applied when accessing audit data.

Audit Server Application Configuration

DB Server type – The supported relational database management systems (RDBMS).

Authentication method – The supported authentication methods for the selected database server type. The available options are:

Driver class name – The full Java class name of the JDBC driver for the selected database. You can use the pre-defined value or replace it with the correct one.

Connection URL – The URL used for connecting to the Data DB. You can use the default pre-defined URL syntax and replace the hostname (the host name of the database server), port (the port number for the JDBC connection) and servicename or dbname with the current values in your environment.

Default syntax for SQL Server:
jdbc:sqlserver://hostname:port;databaseName=dbname;encrypt=false

Default syntaxes for Oracle Database:
jdbc:oracle:thin:@//hostname:port:servicename or
jdbc:oracle:thin:@//hostname:port:OracleSID

If you have problem with the validation of the server certificate, you can configure the driver to ignore the certificate validity and trust any provided server certificate by using the following URL. You should not use this option for productive environments (as it’s unsafe).

Username – The RDBMS technical account name for connection when Database Authentication with username and password is selected in Authentication method.
The Kerberos principal is in the form username@REALM; for example,
admin@MY-COMPANY.COM, when Kerberos Authentication with username and password is selected in Authentication method. The Kerberos realm name is always case-sensitive and by convention (best practice) uppercase. This parameter is not available when the Windows Authentication is selected in Authentication method.

Password – The password that belongs to Username. The password is saved in the Tenant configuration file and is encrypted using an installation-specific master encryption key. This master key is randomly generated during the first installation on a given host and is different on each installed host. Click the button at the end of the password field to view the password. This parameter is not available when the Windows Authentication is selected in Authentication method.

Save original audit messages – Whether (checked) or not (unchecked) the original audit message should be saved in the database. Possible values are true and false. If set to true, the original message is saved.

Use full-text search – Whether (checked) or not (unchecked) to use full-text for searching in selected fields (for example, Audit Event – Detail). Using full-text search is usually faster on bigger data. Important note: The full-text catalogs / indexes must be created in the selected database.

Test connection – Click to test the database connection. If the connection fails, an error message is displayed. In this case, you can continue with the configuration, but it is your responsibility to correct your settings later on. When Windows Authentication is selected in Authentication method, be sure that you use the same account to run the Configuration Wizard as is used to run DirX Audit Server and Apache Tomcat system services or the connection test can be misleading.

Validate DB – Click to validate the database schema. This action validates the existing schema, or if the database schema does not exist, the validation action creates it. A prerequisite is that the technical account used for the database connectivity has sufficient privileges for creating database objects like tables, views, materialized / indexed views, indexes and triggers. If your database schema is not valid, contact your support organization.

The same as data DB – Whether (checked) or not (unchecked) to use the same settings here as you used for the database containing audit messages.

DB Server type – The supported relational database management systems.

Authentication method – The supported authentication methods for the selected database server type. The available options are:

Driver class name – The full Java class name of the JDBC driver for the selected database. You can use the pre-defined value or replace it with the correct one.

Connection URL – The URL used for connecting to the Config DB. You can use the default pre-defined URL syntax and replace the hostname (the host name of the database server), port (the port number for the JDBC connection) and servicename or dbname with the current values in your environment.

Default syntax for SQL Server:
jdbc:sqlserver://hostname:port;databaseName=dbname;encrypt=false

Username – The RDBMS technical account name for connection when Database Authentication with username and password is selected in Authentication method.
The Kerberos principal is in the form username@REALM; for example,
admin@MY-COMPANY.COM, when Kerberos Authentication with username and password is selected in Authentication method. The Kerberos realm name is always case-sensitive and by convention (best practice) uppercase. This parameter is not available when the Windows Authentication is selected in Authentication method.

Password – The password that belongs to Username. The password is saved in the Tenant configuration file and is encrypted using an installation-specific master encryption key. This master key is randomly generated during the first installation on a given host and is different on each installed host. Click the button at the end of the password field to view the password. This parameter is not available when the Windows Authentication is selected in Authentication method.

Test connection – Click to test the database connection. If the connection fails, an error message is displayed. In this case, you can continue with the configuration, but it is your responsibility to correct your settings later on. When Windows Authentication is selected in Authentication method, be sure that you use the same account to run the Configuration Wizard as is used to run DirX Audit Server and Apache Tomcat system services or the connection test can be misleading.

Validate DB – Click to validate the database schema. This action validates the existing schema, or if the database schema does not exist, the validation action creates it. A prerequisite is that the technical account used for the database connectivity has sufficient privileges for creating database objects like tables, views, materialized / indexed views, indexes and triggers. If your database schema is not valid, contact your support organization.

The same as data DB – Whether (checked) or not (unchecked) to use the same settings here as you used for the database containing audit messages.

The same as config DB – Whether (checked) or not (unchecked) to use the same settings here as you used for the database containing configuration data.

DB Server type – The supported relational database management systems (RDBMS).

Authentication method – The supported authentication methods for the selected database server type. The available options are:

Driver class name – The full Java class name of the JDBC driver for the selected database. You can use the pre-defined value or replace it with the correct one.

Connection URL – The URL used for connecting to the History DB. You can use the default pre-defined URL syntax and replace the hostname (the host name of the database server), port (the port number for the JDBC connection) and servicename or dbname with the current values in your environment.

Username – The RDBMS technical account name for connection when Database Authentication with username and password is selected in Authentication method.
The Kerberos principal is in the form username@REALM; for example,
admin@MY-COMPANY.COM, when Kerberos Authentication with username and password is selected in Authentication method. The Kerberos realm name is always case-sensitive and by convention (best practice) uppercase. This parameter is not available when the Windows Authentication is selected in Authentication method.

Password – The password that belongs to Username. The password is saved in the Tenant configuration file and is encrypted using an installation-specific master encryption key. This master key is randomly generated during the first installation on a given host and is different on each installed host. Click the button at the end of the password field to view the password. This parameter is not available when the Windows Authentication is selected in Authentication method.

Test connection – Click to test the database connection. If the connection fails, an error message is displayed. In this case, you can continue with the configuration, but it is your responsibility to correct your settings later on. When Windows Authentication is selected in Authentication method, be sure that you use the same account to run the Configuration Wizard as is used to run DirX Audit Server and Apache Tomcat system services or the connection test can be misleading

Validate DB – Click to validate the database schema. This action validates the existing schema, or if the database schema does not exist, the validation action creates it. A prerequisite is that the technical account used for the database connectivity has sufficient privileges for creating database objects like tables, views, materialized / indexed views, indexes and triggers. If your database schema is not valid, contact your support organization.

Header SSO – Whether (checked) or not (unchecked) to use SSO with header injection authentication. The tenant configuration reads the checkbox status from the values saved by the Core Configurator Authentication dialog.

Windows SSO – Whether (checked) or not (unchecked) to use SSO authentication with SPNEGO mechanism using Kerberos authentication protocol.

Windows username and password – Whether (checked) or not (unchecked) to use Windows authentication with Kerberos realm\username credentials controlled with an Active Directory domain controller for logging in to DirX Audit Manager Classic.

LDAP username and password – mandatory/required LDAP authentication method used for the authentication when other methods are not configured.

Header SSO
Prerequisites:
In the Enabled authentication methods, Header SSO is checked.
The user accessed the DirX Audit Manager Classic with the following link:
https://hostname:port/AuditManager/ with HTTP request headers DXT_TENANT and DXT_USER. Header SSO is checked; the application is aware that the user is pre-authenticated and no additional authentication method is executed.

If the authentication is not successful, the application continues with the Windows SSO (if checked) and the username and password authentication methods.
If the user is authorized, the application is redirected to the protected area of the DirX Audit Manager Classic.
If the user is not authorized, the application is redirected to the logout page.

Windows SSO
Prerequisites:
The user is not authenticated with Header SSO and Windows SSO is checked in the Enabled authentication methods.
The user accessed the DirX Audit Manager Classic with the following link:
https://hostname:port/AuditManager/?tenant=tenantID

If Header SSO is checked in the Enabled authentication methods it is performed first. If the authentication is not successful, then the Windows SSO method is executed.
The application verifies if the user is logged in the Active Directory domain.
If the authentication is not successful, the application is redirected to the login page for user name and password authentication.
If the user is authorized, the application is redirected to the protected area of the DirX Audit Manager Classic.
If the user is not authorized, the application is redirected to the logout page.

Windows username and password
Prerequisites:
The user is not authenticated with Header SSO or Windows SSO and Windows username and password is checked in the Enabled authentication methods.
The user accessed the DirX Audit Manager Classic with the following link:
https://hostname:port/AuditManager/?tenant=tenantID

Specify the user name in the following format: [REALM\]username
Examples:
username – no realm predefined
MY-COMPANY.COM\username – with a realm

The [REALM] part is optional. It should be used only if the DNS name is not configured correctly or if the user is registered in a realm different from the DNS name.
The Windows username and password authentication is performed before the LDAP username and password authentication is performed. If the Windows username and password authentication is successful, the LDAP username and password authentication is skipped.
If the user is authorized, the application is redirected to the protected area of the DirX Audit Manager Classic.
If the user is not authorized, the application is redirected to the logout page.

LDAP username and password
Prerequisites:
The user is not authenticated with one of the previous methods.
The user accessed the DirX Audit Manager Classic with the following link:
https://hostname:port/AuditManager/?tenant=tenantID

The user with the specified user name and password is searched in the configured LDAP directory service. If it is found and if a valid password is provided, the user is authenticated.
If the user is authorized, the application is redirected to the protected area of the DirX Audit Manager Classic.
If the user is not authorized, the application is redirected to the logout page.

Keytab location – Specifies the keytab file location for the application service generated by an Active Directory administrator. For more details, see the “Configuring SSO (Single Sign-on) Web Authentication Using SPNEGO / Kerberos” chapter in the DirX Audit Administration Guide.

Service principal name – Specifies the service principal name, the unique application service name, configured in the Active Directory domain.

LDAP server host – The host name of the LDAP server.

Use SSL – Whether (checked) or not (unchecked) the LDAP connection is an SSL connection. Using an SSL connection is the default setting because we recommend communicating over secure channels between components and services.

LDAP server port – The port number for the LDAP connection.

Authentication type – The authentication type. Please keep the predefined value SIMPLE.

Domain – The DirX Identity domain. This value is used in the next LDAP authentication parameters and replaces the ${domain} placeholder.

Search account user DN – The Distinguished Name of the technical LDAP account for searching users and groups on authentication.

Search account password – The password of the technical account. The password is saved in the Tenant configuration file and is encrypted using an installation-specific master encryption key. This master key is randomly generated during the first installation on a given host and is different on each installed host. Click the button at the end of the password field to view the password.

Search base for users – The base for the LDAP search. Use this setting to limit the subtree where you search for the authenticating user.

Search filter for users – The LDAP filter to use to limit the result where the authenticating user is searched. Use %s to represent a string containing the user target naming attribute, the equal sign and the user name provided by the authentication form or an HTTP request header variable for a single sign on; for example, cn=Tinker Boris.

User target – The naming attribute of users. It is usually the cn attribute.

Search base for groups – The base for the LDAP search. Use this setting to limit the subtree where you search for the groups of which the authenticating user can be a member.

Search filter for groups – The LDAP filter to use to limit the result where the groups of which the authenticating user can be a member are searched. Use %d to represent a distinguished name (DN) of the authenticating user.

List of auditor groups – The list of LDAP groups (DNs) to be mapped to the Auditor role. Separate each group DN with a semicolon (;).

List of restricted auditor groups – The list of LDAP groups (DNs) to be mapped to the Restricted Auditor role. Separate each group DN with a semicolon (;).

List of audit administrators groups – The list of LDAP groups (DNs) to be mapped to the Audit Administrator role. Separate each group DN with a semicolon (;).

User identification attribute – The unique identifying attribute of users. Ensure that all entries in the authentication service have a non-empty value in this attribute and that these values are unique.

User email attribute – The LDAP attribute holding the user’s email address. The attribute value is used when the user configures scheduled reporting jobs.

Truststore location – The path to the truststore used for establishing secure SSL/TLS connections to the LDAP directory server. For more information about the default locations and how to prepare your own truststore, see the section “Preparing the LDAP Truststore for Authentication and LDAP Collector Configuration”. If you used the described example, the expected truststore file is named install_path/conf/crypto/stores/ldap-ts.jks. If the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location field can be left empty. If it is missing, the standard Java KeyStore (JKS) is assumed.

Truststore password – The password to access the truststore. Click the button at the end of the password field to view the password. If the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location and the password fields can be left empty.

Test connection – Click to test the LDAP connection.

(Re-)deploy Audit Manager application – Whether (checked) or not (unchecked) to re-deploy the Audit Manager application with your changes.

Use response cache – Whether (checked) or not (unchecked) to use the response cache. If checked, a valid cached response is used instead of accessing the DirX Access PDP repeatedly.
To disable caching, uncheck the option.

PEP Id – The identification of the PEP when communicating with the DirX Access Server.

Authorization service URL – The URL used for connecting to the DirX Access Server. You can use the default URL syntax and replace the hostname (the host name of the DirX Access Server) and port (the port number for connecting to DirX Access Server).
For DirX Access 8.9:
https://host:port/clientservice/sessioning/AuthorizationDecisionXacmlAction
For DirX Access 8.10:
https://host:port/odata4/sessioning/1_0_0/AuthorizationDecisionXacml
For DirX Access 9.0 and newer:
https://host:port/odata4/legacy/sessioning/1_0_0/AuthorizationDecisionXacml

Username – The user name for the authorization service.

Password – The password for the authorization service user. The password is saved in the configuration file and is encrypted using an installation-specific master encryption key. This master key is randomly generated during the first installation on a given host and is different on each installed host. Click the button at the end of the password field to view the password.

Truststore location – The path to the truststore used for establishing a secure SSL/TLS connection to the DirX Access Server. For more information, see the section “Preparing Truststores and Keystores for SSL Configuration” → “Preparing the DirX Access Server Secure Connection”. If you follow the instruction described there, the expected truststore file is install_path/conf/crypto/stores/ws-sec-comm.client.jks. If it is missing, the standard Java KeyStore (JKS) is assumed.

Truststore password – The password to access the truststore. Click the button at the end of the password field to view the password.

(Re-)Install system service support – Whether (checked) or not (unchecked) to install or re-install support for running as a system service. This parameter is set (checked) and read-only on initial configuration.

Run as a system service – Whether (checked) or not (unchecked) to run the server container as a system service.

Windows Instructions

Start system service now – Whether (checked) or not (unchecked) to start the server container service after finishing the configuration.

System service name – The service name that contains the tenant’s unique identification.

System service display name – The service display name that contains the tenant’s unique name.

Enable JMX – Whether (checked) or not (unchecked) DirX Audit Server monitoring with Java Management Extensions technology is enabled. It is enabled by default and has read-only access.

REST service port – The REST service port specific for each tenant for the REST interface. The value is selected by default from the range 30501 – 305xx.

Allow origins – Origins which will access REST Service. Origins should contain protocol, host and port of clients accessing resources via REST service. For example, if Audit Manager runs on domain https://localhost:8443, field Allow origins should contain this. Added origins can be set each on new line or separated by comma.

Session cookie domain – Session cookie domain field is optional. This value should be set if domain setting the cookie is different from domain reading the cookie. Domain should contain the host. For example, if Audit Manager runs on https://localhost:8443 and REST Service runs on https://localhost:30501 there is no need to set this attribute. If the REST Service runs on https://different-host:30501, the session cookie domain should be set to value different-host.

Enable caching – Whether (checked) or not (unchecked) to use the REST Service caches. To disable caching, uncheck the option.

Enable SSL – Whether (checked) or not (unchecked) the Audit Server should use SSL connection. Using an SSL connection is the default setting because we recommend communicating over secure channels between components and services.

Local client URI – The local connection URI for client connecting to this REST service locally, in the format http(s)://localhost:port/Tenants/tenantID/api/audit, where localhost specifies your local server name, port specifies the server port number and tenantID specifies your configured tenant ID. The default port value depends on previous selection (30501 – 305xx).

Remote client URI – The remote connection URI for client connecting to this REST service remotely, in the format http(s)://host:port/Tenants/tenantID/api/audit, where host specifies your server name, port specifies the server port number and tenantID specifies your configured tenant ID. The default port value depends on previous selection (30501 – 305xx). You should open these ports on firewalls on the machine where DirX Audit is installed.

LDAP authentication

OpenId Connect authentication

LDAP authentication
Prerequisites:
The user accessed the DirX Audit Manager with the following link:
https://hostname:port/audit-manager-tenantID
The user with the specified username and password is searched in the configured LDAP directory service. If it is found and if a valid password is provided, the user is authenticated.
If the user is authorized, the application is redirected to the protected area of the DirX Audit Manager.
If the user is not authorized, the application shows message that the user is unauthorized.

Use common authentication – Whether (checked) or not (unchecked) to use common authentication connectivity parameters saved in a previous Authentication Configuration dialog. If you choose common authentication, the parameters below are read-only.

LDAP server host – The host name of the LDAP server.

Use SSL – Whether (checked) or not (unchecked) the LDAP connection is an SSL connection. Using an SSL connection is the default setting because we recommend communicating over secure channels between components and services.

LDAP server port – The port number for the LDAP connection.

Authentication type – The authentication type. Please keep the predefined value SIMPLE.

Domain – The DirX Identity domain. This value is used in the next LDAP authentication parameters and replaces the ${domain} placeholder.

Search account user DN – The Distinguished Name of the technical LDAP account for searching users and groups on authentication.

Search account password – The password of the technical account. The password is saved in the Tenant configuration file and is encrypted using an installation-specific master encryption key. This master key is randomly generated during the first installation on a given host and is different on each installed host. Click the button at the end of the password field to view the password.

Search base for users – The base for the LDAP search. Use this setting to limit the subtree where you search for the authenticating user.

Search filter for users – The LDAP filter to use to limit the result where the authenticating user is searched. Use %s to represent a string containing the user target naming attribute, the equal sign and the user name provided by the authentication form or an HTTP request header variable for a single sign on; for example, cn=Tinker Boris.

User target – The naming attribute of users. It is usually the cn attribute.

Search base for groups – The base for the LDAP search. Use this setting to limit the subtree where you search for the groups of which the authenticating user can be a member.

Search filter for groups – The LDAP filter to use to limit the result where the groups of which the authenticating user can be a member are searched. Use %d to represent a distinguished name (DN) of the authenticating user.

List of auditor groups – The list of LDAP groups (DNs) to be mapped to the Auditor role. Separate each group DN with a semicolon (;).

List of restricted auditor groups – The list of LDAP groups (DNs) to be mapped to the Restricted Auditor role. Separate each group DN with a semicolon (;).

List of audit administrators groups – The list of LDAP groups (DNs) to be mapped to the Audit Administrator role. Separate each group DN with a semicolon (;).

Mapping of LDAP attributes that should be accessible for user authenticated in Audit Manager.

Truststore location – The path to the truststore used for establishing secure SSL/TLS connections to the LDAP directory server. For more information about the default locations and how to prepare your own truststore, see the section “Preparing the LDAP Truststore for Authentication and LDAP Collector Configuration”. If you used the described example, the expected truststore file is named install_path/conf/crypto/stores/ldap-ts.jks. If the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location field can be left empty. If it is missing, the standard Java KeyStore (JKS) is assumed.

Truststore password – The password to access the truststore. Click the button at the end of the password field to view the password. If the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location and the password fields can be left empty.

Inactive session lifetime (m) – The time in minutes representing the lifetime of an inactive session after which the inactive session is timed out.

Maximum session lifetime (m) – The time in minutes representing the maximum lifetime of a session cookie after which the session cookie is invalidated and new session cookie must be created.

Test connection – Click to test the LDAP connection.

Use custom truststore – Whether (checked) or not (unchecked) use the custom truststore.

OpenID Configuration – OpenID Connect configuration on OAuth authentication server,
for example https://oauth-provider-hostname:port/oauth-provider/.well-known/openid-configuration

Specific configuration values – you can use Load values from service button to load values from OpenID Connect configuration service.

Client ID – Unique identifier of client application.

Redirect URI – URI to be redirected to after authorizing on authorization server.
For example, https://localhost:8443/audit-manager-tenantID/dirx-dxt-app-manager

The list of roles to be mapped to the specific role:

Claims mapping – Names of claims contained in JSON web token that should be accessible for user authenticated in Audit Manager.

Test connection – Click to test the OpenID connection.

DirX Audit (base) – Selects the generic collectors for collecting audit messages in the DirX Audit format.

DirX Identity – Selects the collectors for collecting audit messages in the DirX Identity format.

DirX Access – Selects the collectors for collecting audit messages from DirX Access.

Error handling – Check to enable and configure the components that handle errors during audit messages processing.

File collectors – Check to enable and configure the collectors that load audit messages from files.

JMS collectors – Check to enable and configure the collectors that load audit messages from a queue of the Message Broker.

LDAP collectors – Check to enable and configure the collectors that load audit messages from an LDAP server.

Do not cleanup the server container even if stopped – Check to prevent immediate server container cleanup when changes are configured.

Errors folder – The folder path at which to store audit messages with errors. Note that the folder name is configurable. When you enter only a folder name instead of the full path, the Configurator creates the folder in the following default path:
install_path/server_container/tenants/tenantID/.
The folder path must be unique and must not conflict with other folder paths of the same or other tenants to prevent mixing data originating from different sources. If the folder does not exist at DirX Audit Server service start-up, it is created automatically

Server host – The host name or IP address of the LDAP server.

Use SSL – Whether (checked) or not (unchecked) the connection is an SSL connection. Using an SSL connection is the default setting because we recommend communicating over secure channels between components and services.

Port – The port number for the LDAP/LDAPs connection.

Domain – The DirX Identity domain. This value is used in the next LDAP Collector authentication parameters and replaces the ${domain} placeholder.

User name – The LDAP technical account name for connection.

Password – The password of the technical account. Click the button at the end of the password field to view the password.

Search base – The base for the LDAP search. Use this parameter to specify the subtree from which you want to get the audit messages.

Repeat interval – The time in milliseconds between runs. If there is a collector running when the timer is triggered, it is ignored.

Send record count –The number of messages to be sent together in one enterprise service bus (ESB) message. Use this parameter to reduce ESB traffic and improve performance.

Truststore location – The path to the truststore used for establishing secure SSL/TLS connections to the LDAP collector. For more information about default locations and how to prepare your own truststore, see the section “Preparing the LDAP Truststore for Authentication and LDAP Collector Configuration” in the chapter “Installation Configurations”. If you used the same LDAP server as you are using for authentication, you can use the truststore you created. If you followed our example, the expected truststore file is named install_path/conf/crypto/stores/ldap-ts.jks. In the event that the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location field can be left empty. If it is missing, the standard Java KeyStore (JKS) is assumed.

Truststore password – The truststore password. Click the button at the end of the password field to view the password. In the event that the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location and the password fields can be left empty.

Test connection – Click to test the LDAP connection. If invalid values are provided an error message is displayed. In this case, you can continue with the configuration but it is your responsibility to correct your settings later on.

Custom Message Broker – Whether (checked) or not (unchecked) to use a custom Message Broker. Using a custom Message Broker means specifying a separate installation already configured outside of DirX Audit. If you want to use a custom Message Broker, you will enter only already configured settings for Reader:

If you use DirX Audit Message Broker, you can see or configure:

Custom Message Broker – Whether (checked) or not (unchecked) to use a custom Message Broker. Using a custom Message Broker means specifying a separate installation already configured outside of DirX Audit. If you want to use a custom Message Broker, you will enter only already configured settings for Reader:

If you use DirX Audit Message Broker, you can see or configure:

Custom Message Broker – Whether (checked) or not (unchecked) to use a custom Message Broker. Using a custom Message Broker means specifying a separate installation already configured outside of DirX Audit. If you want to use a custom Message Broker, you will enter only already configured settings for Reader:

If you use DirX Audit Message Broker, you can see or configure:

Reader:

Writer:

Input folder – The path to the folder to be monitored for audit messages. All files stored in this folder are processed except the ones that do not match the file mask; see the parameter File mask. Note that this folder name is configurable and is not hard coded. When you enter only a folder name instead of the full path, the Configurator creates the folder in the following default path: install_path/server_container/tenants/tenantID. The folder path must be unique and must not conflict with other folder paths of the same or other tenants to prevent the mixing of data originating from different sources.

Automatically create the folder – Whether (checked) or not (unchecked) to create the input directory automatically. When checked, the input directory is created automatically on DirX Audit Server service start-up. When unchecked, it must already exist.

File mask – The filter that defines the files to be processed. Only files that match this filter will be processed. You can use the asterisk (*) and the question mark (?) as wildcards.

Recursive – Whether (checked) or not (unchecked) to monitor all of the subfolders within the folder specified in Input folder.

Period – The time delay between runs in milliseconds.

Delay – The initial delay (before the first run) in milliseconds.

Input folder – the path to the folder to be monitored for audit messages. All files stored in this folder are processed except the ones that do not match the file mask (see the parameter File mask). Note that this folder name is configurable and is not hard coded. When you enter only a folder name instead of the full path, the Configurator creates the folder in the following default path: install_path/server_container/tenants/tenantID. The folder path must be unique and must not conflict with other folder paths of the same or other tenants to prevent the mixing of data originating from different sources.

Automatically create the folder – Whether (checked) or not (unchecked) to create the input directory automatically. When checked, the input directory is created automatically on DirX Audit Server service start-up. When unchecked, it must already exist.

File mask – The filter that defines the files to be processed. Only files that match this filter will be processed. You can use the asterisk (*) and the question mark (?) as wildcards.

Recursive – Whether (checked) or not (unchecked) to monitor all subfolders within the folder specified in Input folder.

Period – The time delay between runs in milliseconds.

Delay – The initial delay (before the first run) in milliseconds.

Input folder – The path to the folder to be monitored for audit messages. All files stored in this folder are processed except for the ones that do not match the file mask; see the parameter File mask. Note that this folder name is configurable and is not hard coded. When you enter only a folder name instead of the full path, the Configurator creates the folder in the following default path: install_path/server_container/tenants/tenantID. The folder path must be unique and must not conflict with other folder paths of the same or other tenants to prevent the mixing of data originating from different sources.

Automatically create the folder – Whether (checked) or not (unchecked) to create the input directory automatically. When checked, the input directory is created automatically on DirX Audit Server service start-up. When unchecked, it must already exist.

File mask – The filter that defines the files to be processed. Only files that match this filter will be processed. You can use the asterisk (*) and the question mark (?) as wildcards.

Recursive – Whether (checked) or not (unchecked) to monitor all subfolders within the folder specified in Input folder.

Period – The time delay between runs in milliseconds.

Delay – The initial delay (before the first run) in milliseconds.

Recommended time range – The time range when the server runs scheduled jobs. The Tenant configuration reads the values saved by the Core Configurator Server Container dialog. You can use the Fill in recommended values button to fill all schedules in recommended time range.

Scheduled reports – Whether (checked) or not (unchecked) to schedule the job. The default value is 0/30+*+*+?+*+* which starts the Synchronization scheduled reports job every 30 seconds.

Context records calculation – Whether (checked) or not (unchecked) to schedule the job. The default value is 0+0/5+*+?+*+* which starts the job every 5 minutes. The message limit per run field for this job controls the number of messages processed in a run of the context records calculation job. Specify the value as a positive nonzero integer; the recommended range for the value is between 100 and 1000. The higher the value, the less frequent the execution should be. The default value for message limit per run is set to 100 and the default frequency at which the job is run corresponds to this value.

History DB update – Whether (checked) or not (unchecked) to schedule the job. The default value is 0+0+21+?+*+* which starts the History post–processing job at 21:00.

Fact population – Whether (checked) or not (unchecked) to schedule the job. The default value is 0+40+23+?+*+* which starts the Fact population job at 23:40.

History entries data purge job configuration – Checkout to enable schedule configuration for delete expired history entries data.

Audit messages data purge job configuration – Checkout to enable schedule configuration for delete complete audit messages, including message additions and original messages.

Original audit messages data purge job configuration – Checkout to enable schedule configuration for delete only original messages. You cannot select this type unless Save original audit messages is selected in the Data DB Configuration dialog.

Enable history entries data purge – Whether (checked) or not (unchecked) to activate the DirX Audit Server job that deletes this type of DirX Audit data. If you enable history entries data purge, you can set:

Enable export for data to be purged – Whether (checked) or not (unchecked) to export and save the data to be purged.
If you enable export you must select Purged data export folder and the DirX Audit Server job exports data before it is deleted.
You can use it only if history entries data purge is enabled.

Whether the job should run daily or monthly, and if monthly, the day of the month on which it should run, and the time of day at which it should be run.
Alternatively, you can check Set with CRON expression and specify the schedule as a CRON expression.
For example, the expression 0+0+10+?+*+1#1 starts the job at 10am on the first Sunday of each month.
For more information on how to set up a CRON expression, see http://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html.

Enable audit messages data purge – Whether (checked) or not (unchecked) to activate the DirX Audit Server job that deletes this type of DirX Audit data. If you enable audit messages data purge, you can set:

Enable export for data to be purged – Whether (checked) or not (unchecked) to export and save the data to be purged.
If you enable export you must select Purged data export folder and the DirX Audit Server job exports data before it is deleted.
You can use it only if audit message data purge is enabled.

Whether the job should run daily or monthly, and if monthly, the day of the month on which it should run, and the time of day at which it should be run.
Alternatively, you can check Set with CRON expression and specify the schedule as a CRON expression.
For example, the expression 0+0+10+?+*+1#1 starts the job at 10am on the first Sunday of each month. For more information on how to set up a CRON expression, see http://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html.

Enable original audit messages data purge – Whether (checked) or not (unchecked) to activate the DirX Audit server job that deletes this type of DirX Audit data. If you enable original audit messages data purge, you can set:

Use common authentication – Whether (checked) or not (unchecked) to use common authentication connectivity parameters saved in a previous Authentication Configuration dialog. If you choose common authentication, the parameters below are read-only. Only the Page size can be modified.

LDAP server host – The host name of the LDAP server.

Use SSL – Whether (checked) or not (unchecked) the LDAP connection is an SSL connection. Using an SSL connection is the default setting because we recommend communicating over secure channels between components and services.

LDAP server port – The port number for the LDAP connection.

Authentication type – The authentication type. Please keep the predefined value SIMPLE.

Domain – The DirX Identity domain. This value is used in the next LDAP authentication parameters and replaces the ${domain} placeholder.

Search account user DN – The Distinguished Name of the technical LDAP account for searching users and groups on authentication.

Search account password – The password of the technical account. The password is saved in the Tenant configuration file and is encrypted using an installation-specific master encryption key. This master key is randomly generated during the first installation on a given host and is different on each installed host. Click the button at the end of the password field to view the password.

Page size – The maximum number of entries per page when LDAP paging is used for iterating through results. The default is 100 and should be modified only when needed.

Truststore location – The path to the truststore used for establishing secure SSL/TLS connections to the LDAP directory server. For more information about the default locations and how to prepare your own truststore, see the section “Preparing the LDAP Truststore for Authentication and LDAP Collector Configuration”. If you used the described example, the expected truststore file is named install_path/conf/crypto/stores/ldap-ts.jks. If the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location field can be left empty. If it is missing, the standard Java KeyStore (JKS) is assumed.

Truststore password – The password to access the truststore. Click the button at the end of the password field to view the password. If the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location and the password fields can be left empty.

Test connection – Click to test the LDAP connection.

LDAP server host – The host name of the LDAP server where discontinued DirX Identity synchronization workflows for the DirX Audit History Database may be used and configured.

Use SSL – Whether (checked) or not (unchecked) the LDAP connection is an SSL connection. Using an SSL connection is the default setting because we recommend communicating over secure channels between components and services.

LDAP server port – The port number for the LDAP connection.

Authentication type – The authentication type. Please keep the predefined value SIMPLE.

Domain – The DirX Identity domain where discontinued DirX Identity synchronization workflows for the DirX Audit History Database may be used and configured.

Admin account user DN – The Distinguished Name of the technical LDAP account for searching workflows, attributes, and their subsequent deactivation.

Admin account password – The password of the technical account. The password is saved in the Tenant configuration file and is encrypted using an installation-specific master encryption key. This master key is randomly generated during the first installation on a given host and is different on each installed host. Click the button at the end of the password field to view the password.

Workflows folder – Name of folder containing the Discontinued DirX Identity Synchronization Workflows. If the field is left empty all Discontinued DirX Identity Synchronization Workflows will be taken into consideration.

Truststore location – The path to the truststore used for establishing secure SSL/TLS connections to the LDAP directory server. For more information about the default locations and how to prepare your own truststore, see the section “Preparing the LDAP Truststore for Authentication and LDAP Collector Configuration”. If you used the described example, the expected truststore file is named install_path/conf/crypto/stores/ldap-ts.jks. If the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location field can be left empty. If it is missing, the standard Java KeyStore (JKS) is assumed.

Truststore password – The password to access the truststore. Click the button at the end of the password field to view the password. If the requested certificates are part of certificates imported in the Java Runtime Environment, the truststore location and the password fields can be left empty.

Test connection – Click to test the LDAP connection.

Migrate workflows – Whether (checked) or not (unchecked) to migrate the discontinued workflows configuration (entry type and its attribute mapping) to the new DirX Audit History Synchronization.

Exclude all large attributes – Whether (checked) or not (unchecked) to exclude all large attributes configured in discontinued DirX Identity synchronization workflows for the DirX Audit History Database from the new DirX Audit History Synchronization. See the DirX Audit History Synchronization Guide for more details about excluded attributes.

Deactivate workflows – Whether (checked) or not (unchecked) the discontinued workflows should be automatically deactivated on DirX Identity.

Check if the discontinued DirX Identity synchronization workflows used for audit entries synchronization to the DirX Audit History Database are disabled on DirX Identity.

Check if DirX Identity Store is configured as required by History Synchronization, see the “Preparing the DirX Identity Store” in the DirX Audit History Synchronization Guide for details.

Check the default History Synchronization attribute configuration. You need to decide whether it is sufficient to synchronize only the attributes defined in the default tenant configuration (install_path/conf/defaults/tenant/configuration.cfg) or if you need to change or extend the list of synchronized attributes. If you want to modify the list of synchronized attributes, you must modify them in the tenant-specific configuration file created after the first tenant configuration (install_path/conf/tenants/tenantID/configuration.cfg). See the DirX Audit History Synchronization Guide for details on how to configure attributes for synchronized entry types.

Modify job for migration

Delete job for migration

Enable / disable (E) – Whether the configured job is enabled (checked) or disabled (unchecked).

Synchronization job modification – Click on the drop-down list to change the job name and its configuration. Specify the parameters:

Remove (R) – Click the minus button to remove the job from configuration.

Click Previous to change any settings you have made.

Click Next to start the Tenant configuration process.

Display current configuration log – To display information on the DirX Audit Tenant configuration you just performed, including thrown exceptions.

Next – To continue with the Tenant configuration.

Run Tenant Configuration - Whether (checked) or not (unchecked) you want to start the Tenant configuration procedure again to keep creating or modifying new or existing tenants.

Click Finish to complete the Tenant configuration process.

Import history entries from DirX Identity at least once. See the “History Synchronization LDAP Configuration” and “Scheduled History Synchronization Jobs Configuration” dialogs description in this chapter for details how to run DirX Audit History Synchronization job. See the DirX Audit History Synchronization Guide for details on how to configure the History Synchronization jobs.

Run the history post-processing server job at least once. For details on how to adapt the schedule for updating the foreign keys in the DirX Audit History Database, see the chapter “Managing History Database Tables” in the DirX Audit Administration Guide. The default schedule you specified in the Scheduled Jobs Configuration dialog usually starts the job once per night.

Run the DirX Audit Configuration Wizard for Tenant configuration.

Go to the REST Service Authentication Configuration step in the wizard.

Check Use SSL.

Enter the LDAP server SSL port. The default value is 636.

Enter the path and credentials for the truststore file that contains the relevant DirX Directory Server and trusted CA certificates. See the section “Preparing the LDAP Truststore for Authentication and LDAP Collector Configuration” in the chapter “Installation Configurations” for details.

Enter other settings as necessary.

Finish the configuration.

Run the DirX Audit Configuration Wizard for Tenant configuration.

Go to the Authentication Configuration step in the wizard.

Check Use SSL.

Enter the LDAP server SSL port. The default value is 636.

Enter the path and credentials for the truststore file that contains the relevant DirX Directory Server and trusted CA certificates. See the section “Preparing the LDAP Truststore for Authentication and LDAP Collector Configuration” in the chapter “Installation Configurations” for details.

Enter other settings as necessary.

Finish the configuration.

Run the DirX Audit Configuration Wizard for Tenant configuration.

Go to the Server LDAP Collector for DirX Identity Format step in the wizard.

Check Is SSL.

Enter the SSL port. The default value is 636.

Enter the path and credentials for the truststore file that contains the relevant DirX Directory Server and trusted CA certificates. See the section “Preparing the LDAP Truststore for Authentication and LDAP Collector Configuration” in the chapter “Installation Configurations” for details.

Enter other settings as necessary.

Finish the configuration.

DirX Audit Message Broker 9.0

DirX Audit Server tenant_display_name 9.0 (a separate instance of DirX Audit Server is created for every tenant)

The Apache Tomcat service where you deployed DirX Audit Managers

Some minutes after start-up, DirX Audit Server tries to connect to the DirX Audit Message Broker and the LDAP server. Once the server has audit messages to import, it connects to the DirX Audit database. If something fails, you should see error messages in the log file install_path/server_container/tenants/tenantID/logs/dirxaudit-server.log.

Log in to the DirX Audit Manager to test whether you can authenticate. For error messages, check the console output in your browser (use the Developer Tools) or see the REST error messages in the server log file install_path/server_container/tenants/tenantID/logs/dirxaudit-server.log.

Log in to the DirX Audit Manager Classic to test whether you can authenticate to LDAP and connect to the DirX Audit database. For error messages, check the log file tomcat_install_path/logs/dirxaudit-manager.log.