Troubleshooting

This chapter provides tips to track down and solve problems.

Checklist

Check that:

  • All services are running and are connected to the correct target system.

  • All required features share the same and correct configuration - distributed installation.

  • All required port connections are allowed in the firewall.

  • Target systems, components and applications are correctly configured and available.

  • All passwords are correct.

  • All services have administrative access to required repositories and disk folders.

  • Truststores and keystores are in place and have the correct certificates and passwords.

  • Connection configuration has been performed for the correct tenant.

Log Files

Location of log files:

  • For DirX Audit Manager (Apache Tomcat):
    tomcat_install_path/logs/dirxaudit-manager.log

  • For DirX Audit Server (Spring Boot):
    install_path/server_container/tenants/tenantID/logs/dirxaudit-server.log
    install_path/server_container/tenants/tenantID/logs/dirxaudit-server-errors.log
    install_path/server_container/tenants/tenantID/logs/security.log

  • For DirX Audit Message Broker (Apache ActiveMQ):
    install_path/message_broker/data/activemq.log

To manage logging, see the chapter “Configuring Logging” in the DirX Audit Administration Guide. If you need more detailed information in the logs, set the log level temporarily to DEBUG/TRACE (Log4j) or FINE/FINEST (Java Logging) depending on the logging framework in use. Don’t forget to reduce the log level to WARNING or INFO after you have finished debugging so that performance and disk space are not affected more than necessary.

DirX Audit Server

When you check the logs of DirX Audit Server, here is a list of error, warning, or information logs to which you should pay attention:

Slow Authentication Due to Many Groups

The authentication process checks that the authenticated user is in one of the configured auditor groups. This process may take too long if there are too many groups in the LDAP tree.

Try to refine the LDAP search for groups so that there are fewer matching entries. For example, move the auditor groups into a separate LDAP subfolder and take this folder as search base.

Reports Are Not Sent

When reports are not sent, check that:

  • Sending mails is enabled in the Common Configuration dialog in the DirX Audit Core Configuration Wizard.

  • The DirX Audit Server service is running.

  • The default email address and the SMTP server address are correctly entered.

  • The user who created the report has a correct email address LDAP attribute value (usually mail).

  • The attachment size does not exceed the target mail server limit.

  • The SMTP server is configured to allow relaying from the machine where DirX Audit is installed.

Unique Key Constraint Violation

A “unique key constraint violation” in audit collector logs indicates duplicate events. A collector tried to import an audit message that is already stored in the DirX Audit Database. That can occur, for example, if:

  • A file is put to the import folder that has already been imported previously

  • A dxrHistory LDAP attribute is read a second time after an LDAP server restore

  • An imported dxrHistory attribute value could not be deleted after a shutdown of the LDAP or the DirX Audit Server

The collector error handling stores such audit messages in a special subfolder of the error folder. You can ignore them. Just make sure that the folders are cleared regularly.

Resetting the DirX Audit Server

When the source for errors cannot be identified, sometimes it helps to restart the DirX Audit Server:

  • Stop the DirX Audit Server - Windows service or UNIX daemon.

  • Start the DirX Audit Server. No additional resetting steps are required, unlike some previous versions.

Truncating Long Values in the DirX Audit History Database

A “checkAttributeLength: Value 'attributeValue' too long for database table 'table' and column 'column'.“ in the DirX Audit Server History Synchronization job logs indicates that History Synchronization job detected a value that exceeded the database column size. Such a value is truncated to fit the DirX Audit History Database table and column and synchronized. You can consider changing the attribute mapping. See the section “Customizing Attribute Mapping“ in the DirX Audit History Synchronization Guide for details.

SQL Knowhow

This section gives some advice for working with the DirX Audit Database and lists some SQL query scripts that help to find more detailed information in the database when DirX Audit Manager and DirX Audit Manager Classic are not sufficient. The queries can be found in the folder:

install_path/conf/defaults/sql/common/adm.

Refreshing Materialized Views (Oracle)

To enhance performance, some materialized (or indexed) views are defined in the DirX Audit History Database. If reports or charts do not seem to contain up-to-date information, one of the reasons may be an inadequate refresh of these views.

In Oracle Database, a schedule must be configured for the view refresh. These views typically are about relationships with users, roles, permissions, groups, etc. They depend on foreign keys that are regularly calculated by the History DB job. Hence, the view refresh should run after the History Synchronization job finished.

To configure a schedule with Oracle SQL Developer, select Scheduler and navigate to DBMS Jobs >> Run Job.

The materialized views can be also refreshed manually on request.

Generating a List of Indexes

The queries get_indexes_MSSQL.sql and get_indexes_Oracle.sql lists all the indexes with the table and column to which they apply.

Searching a User in the History Entries Database

If you want to see details on a user, you can first find the user’s primary key (HST_ENTRIES_ID) with a search based, for example, on the family name and then query on all or specific attributes.

A sample query for finding a user based on the family name is in hst_user_search.sql; just replace the space holder with the searched family name (surname, sn).

To view all the link attributes of that user entry later than a certain day, use the following query and replace the values for the HST_ENTRIES_ID (primary key) and the VALID_FROM:

select
 *
from
 HST_LINK_ATTRS_IN_TIME
where
 HST_ENTRIES_ID = 15298
  and VALID_FROM >= '2019-01-01'

If you are only interested in particular attributes, add the following clause with the right attribute names:

  and ATTRIBUTE_NAME in ('dxrassignedaccounts')

If you are interested in other entry types, for example, accounts, replace the type in the hst_user_search.sql with the appropriate one; for example, Account. Find all the type names in the table HST_ENTRY_TYPES; they are the names that are configured in the corresponding History Synchronization job.

Listing Occurrences of dxrUids

The query list_dxruid.sql lists dxrUid values with their type and count. A count that is not equal to 1 indicates entries with duplicate dxrUid values.

Listing Duplicate dxrUids

The query get_duplicated_dxruid.sql lists duplicate entries with multiple unfinished records in the HST_ENTRIES_IN_TIME table and therefor duplicate dxrUID values for joining. Besides the dxrUid, it returns the entry type, DN, the number of occurrences and the time from when they are valid (VALID_FROM).