Creating queries for audit events

In addition to the predefined queries for audit events, you can create your own queries based on the criteria you define. Audit events are recorded for many activities, including both successful and failed operations. For example, you can search for events that are recorded when users attempt to log on and authentication fails or when users run commands or use applications with a role that grants elevated privileges. Audit trail events are also recorded when there are changes to the auditing infrastructure, and when there are changes to Delinea zones.

To specify the search criteria for a new audit event query:

  1. Open Audit Analyzer, select Audit Events, right-click, then select Query Audit Events.

  2. Type the query name and, optionally a description for the query.

  3. Type a user name if you want to filter the event query by user name.

    You can specify one or more user names in userPrincipalName format (user@domain). Use semi-colons (;) to separate multiple user names. For example, to limit the search for audit events to events recorded for actions taken by the users ben, maya, and fred, you could type the following:

    ben;maya;fred

  4. Type a computer name if you want to filter the event query by computer.

    You can specify multiple computer names separated by semi-colons.

  5. Select the Event time option if you want to specify a time frame to filter the query based on when the event occurred.

    If you select this option, you can search for events that occurred:

    • before, not before, after, not after, between, or not between specific dates and times.
    • in or not in the last specified number of days, hours, or minutes.
    • during the specified period of time.
  6. Select the Type option to search for events based on the type of activity performed.

    If you select this option, you must click > to view and select the event categories in which you are interested. For details about the type of events recorded in each category, select the category and review the Description displayed for that category.

  7. Select the Result option to search for events based on the result of the activity performed.

    For example, you can use this option in combination with other options to search for only successful or failed operations.

  8. Select the Role option, then a role name and zone if you want to filter the event query by role.

  9. Select the Parameter option if you want to filter the query based on a specific parameter.

    If you select this option, you must click > to view and select the event parameters that are currently available and in which you are interested.

  10. Click OK to save and run the new query.

After you create a new query, you can export the query definition or its results, email it to others, or modify its properties.

How Access Manager Roles Affect Audit Trail Events

If you only enable auditing without access control and privilege management features, audit trail events are recorded for all successful and failed operations on audited computers. The events are stored in the audit store database and can be returned in response to queries. These events are not associated with roles, so you should not use the Role filter in your query definition.

If you enable auditing with access control and privilege management, however, user activity is only recorded when a role with “auditing required” or “audit if possible” setting is used to perform one or more tasks. In most cases, roles that allow users to perform tasks using elevated privileges or in a restricted shell environment are configured with one of these audit settings. By default, the Windows Login and UNIX Login roles are also configured to “audit if possible” to capture all audit trail events on the computers where the auditing service is running. If a role is configured with audit not requested or required, only audit trail events are recorded.

If the auditing service is running on the computer where the user logs on or where the administrative tasks are performed, the audit trail event is collected and transferred to the audit store database. Only the audit trail events that are captured and stored in the audit store database can be returned in response to audit event queries. Therefore, from Audit Analyzer, you can only query and report on audit trail events that are stored in the audit store database while a user performs tasks in an audited role on an audited computer.

Querying by Audit Event Type or by Role

In many cases, querying for audit trail events by event type produces more predictable results than querying for events by role. For example, to query for successful and failed login attempts, select Type, then select the Login Event category. In this particular case, the Windows Login and UNIX Login roles do not—as a user’s effective role—capture successful and failed login attempts, so they should not be used as filters for querying successful and failed login events.

If you query using the Role filter, Audit Analyzer only returns the audit trail events associated with the selected role. In some cases, this might be the information you are looking for—for example, to review the execution of commands using a role with elevated privileges. On UNIX computers, however, many audit trail events are not linked directly to the actions taken with a specific role. For example, on a Linux or UNIX computer with the auditing service running, many command-line activities record audit trail events. These events are stored in the audit store database and can be queried, but are not associated with any role and not reported if you select a role filter.

Populating and Deleting the Roles Available

The list of roles available for querying is based on the roles you have defined using Access Manager. If you add a role definition, the new role displays in the list of roles when an audit trail about the role is generated.

If you delete a role from all zones, however, it will remain in the list until the last session that has events associated with that role is deleted or the audit store database is detached.