20130329 audit logging for opendj - plembo/onemoretech GitHub Wiki

title: Audit logging for OpenDJ link: https://onemoretech.wordpress.com/2013/03/29/audit-logging-for-opendj/ author: phil2nc description: post_id: 4570 created: 2013/03/29 10:08:36 created_gmt: 2013/03/29 14:08:36 comment_status: closed post_name: audit-logging-for-opendj status: publish post_type: post

Audit logging for OpenDJ

This is a short piece on audit logging for OpenDJ.

What is audit logging?

OpenDJ provides a facility to log all changes made on the directory to a file called the audit log (in fact its name is simply "audit"). [Find the official doc covering audit logging in OpenDJ here] This is different from the access and error logs in that the actual command sequence to make the change is logged in the audit log, using standard LDIF format. Each change includes a timestamp (in Zulu time) and the dn of the entry making the change (for example "cn=Directory Manager"). An example:

# 28/Mar/2013:07:14:22 -0400; conn=0; op=1
dn: ds-task-id=20130328071422214,cn=Scheduled Tasks,cn=Tasks
changetype: add
objectClass: ds-task
objectClass: ds-task-export
objectClass: top
ds-task-export-ldif-file: /data/backup/ldap/prod.20130328071417.ldif
ds-task-export-backend-id: userRoot
ds-task-id: 20130328071422214
ds-task-export-include-branch: dc=example,dc=com
ds-task-class-name: org.opends.server.tasks.ExportTask
ds-task-scheduled-start-time: 20130328111422Z
entryUUID: 9e5d4e76-8cd7-4653-94d9-0425a2f3262f
createTimestamp: 20130328111422Z
creatorsName: cn=Directory Manager,cn=Root DNs,cn=config

In OpenDJ, the audit log is not enabled by default. This is actually more a hat tip of convenience to administrators who usually make substantial numbers of changes their directory data before turning an environment over into general release (a/k/a "production").

Having an audit log (or audit logs) in hand can be a huge benefit when trying to determine the origin of an unexplained change on the directory. The OpenDJ audit log records changes in LDIF format, just the way the replication Changelog does when enabled. The big difference is that while operations recorded in the Changelog are obsfuscated by special encoding, they are (except for password strings and encrypted data) in plain text in an audit log.

Checking audit log status

There are a few ways to do this. For example, you could just look under $DSHOME/logs to see if there's an "audit" file and then tail it to determine if it's being written to. The other way is to check the configuration, read on.

Replicated Environments

In a replicated environment it isn't necessary to have the audit logging enabled on both nodes. If audit logging is enabled on node 1 of a two node cluster, changes made on node 2 will be picked up by the audit log when the corresponding change is made on node 1.

Audit Log Configuration

You can check the logger configuration with an LDAP browser by connecting as an admin user (like "cn=Directory Manager") to "cn=config" and then drilling down to "cn=File-Based Audit Logger, cn=Loggers, cn=config". It will look something like this:

dn: cn=File-Based Audit Logger,cn=Loggers, cn=config
ds-cfg-retention-policy: cn=File Count Retention Policy,cn=Log Retention Policie
 s,cn=config
ds-cfg-rotation-policy: cn=24 Hours Time Limit Rotation Policy,cn=Log Rotation P
 olicies,cn=config
ds-cfg-rotation-policy: cn=Size Limit Rotation Policy,cn=Log Rotation Policies,c
 n=config
ds-cfg-suppress-internal-operations: true
ds-cfg-asynchronous: true
objectClass: ds-cfg-log-publisher
objectClass: ds-cfg-access-log-publisher
objectClass: top
objectClass: ds-cfg-file-based-audit-log-publisher
ds-cfg-suppress-synchronization-operations: false
cn: File-Based Audit Logger
ds-cfg-enabled: false
ds-cfg-java-class: org.opends.server.loggers.TextAuditLogPublisher
ds-cfg-log-file: logs/audit
ds-cfg-log-file-permissions: 640

Note that the shipping configuration for the audit logger is pretty reasonable and I usually don't modify it, unless there's a requirement to relocate where it's writing to. The last time I checked the ds-cfg-log-file-permissions parameter didn't do anything. Hopefully that will get fixed in a later version so that log file contents can at least be shared with the members of the directory server owner's group. Here are some dsconfig commands that provide information on how your logger is configured:

dsconfig get-log-publisher-prop 
-h localhost 
-p 5444 
-j $HOME/etc/pwd.txt 
--enabled 
--publisher-name "File-Based Audit Logger" 
--property retention-policy 
--property rotation-policy

Output will look something like this:

Property         : Value(s)
-----------------:-------------------------------------------------------------
enabled          : false
retention-policy : File Count Retention Policy
rotation-policy  : 24 Hours Time Limit Rotation Policy, Size Limit Rotation
                 : Policy

If the value for "enabled" is true, then the audit log is already turned on.

Enabling audit logging

This can be done either over LDAP or using dsconfig. To do it using LDAP either use your LDAP browser to change the value for ds-cfg-enabled to true or create an LDIF file that will do it:

dn: File-Based Audit Logger, cn=Loggers, cn=config
changetype: modify
replace: ds-cfg-enabled
ds-cfg-enabled: true

Here is the dsconfig syntax to accomplish the same result:

dsconfig set-log-publisher-prop 
--publisher-name "File-Based Audit Logger" 
--set enabled:true 
--h localhost 
--port 5444 
-j $HOME/etc/pwd.txt 
-X 
-n

See my OpenDJ Cheat Sheet for more info on using the dsconfig commands.

Customizing Logger Policies

The default configuration for the Audit Logger on OpenDJ uses the built-in 24-hour Log Rotation, 10 files Log Retention and 500 MB File Size Limit policies that can be inspected by following the dns appearing in the File Based Audit Logger object. Here are the three shipping policies that are used by default:

cn=File Count Retention Policy,cn=Log Retention Policies,cn=config
cn=24 Hours Time Limit Rotation Policy,cn=Log Rotation Policies,cn=config
cn=Size Limit Rotation Policy,cn=Log Rotation Policies,cn=config

If you want to customize the values provided in a policy do not modify the existing policy. Instead, create your own custom entry rooted in the appropriate policy container by using the built in entry as an example. Always remember to give your custom policy a unique cn in both its dn and the body of the entry.