Audit Events have been part of DirectAudit for many major releases of Centrify Server Suite, Enterprise Edition, and the Audit Analyzer console allows auditors a convenient, central location to view audited sessions that contain audited events (or elevated privileged events). Not only can they utilize the predefined queries to quickly and efficiently find audit events, but they can create their own queries by defining search filters such as users, computers, event time, event type, and the session result.
Group Policy - Adjust Audit Trail Targets
In addition to the Audit Event framework in Audit Analyzer, there is also an obscure group policy that is available to customers called "Set Global Audit Trail Targets". This policy allows Centrify administrators to specify the target location for audit trail information, and from the Group Policy Management Editor, it is located at:
Computer Configuration > Policies > Administrative Templates > Centrify Audit Trail Settings
If you set this group policy to Not configured or Disabled, the destination of audit trail information depends on which version of DirectAudit is installed. If DirectAudit 3.2 or later is installed, audit trail information is sent to the local logging facility and DirectAudit. If a DirectAudit version earlier than 3.2 is installed, audit trail information is only sent to the local logging facility.
If you set this group policy to Enabled, you can specify the target for audit trail information. Possible settings are:
0 - Audit information is not sent.
1 - Audit information is sent to DirectAudit. This capability is supported by DirectAudit version 3.2 and later.
2 - Audit information is sent to the local logging facility (syslog on UNIX systems, Windows event log on Windows systems).
3 - Audit information is sent to both DirectAudit and the local logging facility.
NOTE: This group policy modifies the audittrail.targets setting in the centrifydc.conf agent configuration file.
When Centrify Server Suite 2015 was released, it included a new, convenient feature that documented all audit trail events into a single XML file called "AuditTrailEvents.xml", and it's located in the Centrify DirectManage installation directory on Windows. Not only were all of the events documented, they were catalogued, with each event having its own unique Event ID. Here is a short snippet of the current v2 file:
On Windows clients, the audit trail event is written in Windows Application Event Logs with the unique event ID as Event ID and a Windows Event Source called "Centrify AuditTrail V2". On Unix/Linux clients, the Event IDs are written to local syslog in the centrifyEventID field.
NOTE: Please refer to the Centrify Audit Trail Events XML documentation for a complete list of Audit Trail events and their corresponding unique Centrify Event IDs.
With the catalogued audit event file comes additional capabilities, allowing customers to use these audit events as input to their existing SIEM tools. And you can then provide alerting and notification from your monitoring tool-of-choice based on the specific event ID's that you want to query.
In a previous 4-part article
, Centrify Product Manager, Satish Veerapuneni, wrote extensively about how Centrify integrates indirectly with SIEM tools (as mentioned previously) or directly with the following 3 SIEM tools:
- HP ArcSight
- IBM QRadar
Taking the Splunk integration as one example, in order to view administrative events in the Splunk Enterprise console, you need to first install the following two Centrify apps:
Once you install these two apps, you can then begin receiving audit events from within the Splunk console. For example, when a Centrify administrator creates a new Child Zone inside of Access Manager, we can follow the lifecycle and see the end reporting result below: