Server audit log settings

Edit online

Audit logging is used to improve the security of the directory server. A default audit plug-in is provided with the server. Depending on the audit configuration parameters, this plug-in might log an audit entry in the default or specified audit log for each LDAP operation the server processed.

The administrator can use the activities that are stored in the audit log to check for suspicious patterns of activity in an attempt to detect security violations. If security is violated, the audit log can be used to determine how and when the problem occurred and perhaps the amount of damage done. This information is useful, both for recovery from the violation and, possibly, in the development of better security measures to prevent future problems. You can also write your own audit plug-ins to either replace, or add more processing to, the default audit plug-in. For more information about plug-ins, see the Server Plug-ins Reference.

Note: Failed connection attempts are audited only if they fail after reaching the LDAP server. Connections that fail in the SSL layer, network, or operating system layer are not audited.
The following server events are audited if auditing is enabled:
  • Auditing started
  • Audited stopped
  • Audit configuration changed
  • Server started
  • Server stopped
Server events are audited in the following format: 
<Time>—<Message Text in local code page>
For example: 
2023-06-06T16:19:48.243277 GLPSRV009I 11.0.1.<fixlevel> server started.
The audit log displays log entries chronologically. Each non-message entry contains a general information header followed by operation-specific data. For example, 
2023-03-23-16:01:01.345-06:00--V3 Bind--bindDN:cn=root
--client:9.1.2.3:12345--
ConnectionID:12--received:2000-03-23-16:01:01.330-06:00
--success 
name:cn=root
authenticationChoice: simple
If the audit version is version 2 the header contains "AuditV2--". 
AuditV2--2003-07-22-09:39:54.421-06:00DST--V3 Bind--bindDN: cn=root--client: 127
.0.0.1:8196--connectionID: 3--received: 2003-07-22-09:39:54.421-06:00DST--Success
If the audit version is version 3 the header contains "AuditV3--" 
AuditV3--2003-07-22-09:39:54.421-06:00DST--V3 Bind--bindDN: cn=root--client: 127
.0.0.1:8196--connectionID: 3--received: 2003-07-22-09:39:54.421-06:00DST--Success
UniqueID:
If the audit version is set to 1, no extra information is audited.
If the audit version is set to 2 or greater, then the following condition is TRUE:
  • If the control is a Proxy authorization control, then the following extra information is audited:
    • ProxyDN: Proxy Auth DN
  • If the control is a Group authorization control, and audit is configured to audit the groups that are sent on a Group authorization control, then the following extra information is audited:
    • Group: Group Name
    • Group:Group Name 2 (repeat for each group)
    • Normalized:TRUE or FALSE
  • If the control is an Audit control, and audit is configured to audit the extra information in the Audit control, then the following extra information is audited:
    • RequestID: request ID 1
    • RequestID: request ID 2 (repeat for each extra request ID)
    • ClientIP: client IP sent in the audit control
  • If the control is a Replication update ID control, and audit is configured to audit the Replication update ID control, then the following extra information is audited:
    • value: value that is sent in the control
.
Note: For an operation, one of the following types is printed:
  • Unknown
  • Bind
  • Unbind
  • Search
  • Add
  • Modify
  • Delete
  • ModifyDN
  • event notification: registration
  • event notification: unregister
  • extended operation
  • Compare
The header is in the following format:
Timestamp 1 "--"
The local time the entry is logged, that is, the time the request was processed. The timestamp is in the format YYYY-MM-DD-HH:MM:SS.mmm=(or-)HH:MM. The =(or=)HH:MM is UTC offset. mmm is milliseconds.
Version number+[SSL|TLS]+[unauthenticated or anonymous] Operation "--"
Shows the LDAP request that was received and processed. Version number is either V2 or V3. SSL displays only when SSL was used for the connection. TLS displays only when TLS is used for the connection. unauthenticated or anonymous displays to indicate whether the request was from an unauthenticated or anonymous client. Neither unauthenticated or anonymous display if the request is from an authenticated client.
bindDN:
Shows the bind DN. For V3 unauthenticated or anonymous requests, this field is <*CN=NULLDN*>.
client:Client IP address:Port number "--"
Shows the client IP address and port number.
ConnectionID: xxxx "--"
Is used to group all the entries that are received in the same connection, meaning between the bind and unbind, together.
received: Timestamp 2 "--"
Is the local time when the request was received, or to be more specific, the beginning time when the request was processed. Its format is the same as Timestamp 1.
Result or Status string
Shows the result or status of the LDAP operation. For the result string, the textual form of the LDAP resultCode is logged, for example, success or operationsError, instead of 0 or 1.
UniqueID
The uniqueID is the unique request ID to store in the control. The clientIP is the client's original IP to store in the control. If critical is true, the criticality of the control is set to true; if false, the criticality is set to false.
Operation-specific data follows the header and displays operation-specific data, for example,
  • Bind:
    • name: <bindDN string>
    • authenticationChoice: unknown, simple, krbv42LDAP, krbv42DSA, sasl
    • authenticationMechanism: CRAM-MD5
    • Admin Acct Status: Not Locked, Locked, or Lock Cleared
    • username: adminusername (for DIGEST-MD5 only)
    • mappedname: cn=root (for DIGEST-MD5 w/ authzid only)
    • authzId: u: username (for DIGEST-MD5 with authzid only)
  • Search:
    • base: o=ibm_us, c=us
    • scope: unknown, baseObject, singleLevel, or wholeSubtree
    • derefAliases: unknown, neverDerefAliases, derefInSearching, derefFindingBaseObj, or derefAlways
    • typesOnly: FALSE
    • filter: (&(cn=c*)(sn=a*))
    • attributes: cn, sn, title (this item is not present if there are no attributes)
  • Compare:
    • entry: cn=Joe Smith, o=ibm_us, c=us
    • attribute: cn
    Note: The attribute value is not written.
  • Add:
    • entry: cn=Joe Smith, o=ibm_us, c=us
    • attributes: cn, sn
    Note: The attribute value is not written.
  • Modify:
    • object: cn=Joe Smith, o=ibm_us, c=us
    • add: mail
    • delete: title
    • replace: telphonenumber (repeat for each operation/attribute pair)
    Modify can be one of the following types:
    • unknown
    • add
    • delete
    • replace
  • Delete:
    • entry: cn=Joe Smith, o=ibm_us, c=us
  • ModifyDN:
    • entry: cn=Joe Smith, ou=Austin, o=ibm_us, c=us
    • newrdn: Joe S. Smith
    • deleteoldrdn: true
    • newSuperior: ou=rochester(this item is not present if there is no newSuperior value)
  • Event Notification: Event Registration:
    • eventID: LDAP_change
    • base: o=ibm_us, c=us
    • scope: wholeSubtree
    • type: unknown, changeAdd, changeDelete, changeModify, or changeModDN
  • Event Notification: Unregistered Event:
    • ID: hostname.uuid

By default the audit log is disabled.

Note: Members of the administrative group can view the audit log and settings but not modify them. Only the administrator is enabled to access, change, or clear the audit log files.

To enable audit logging and modify logging settings, use one of the following methods. Iindividual log settings override the Default log settings.