PingDirectory

Access and audit log

The access log provides information about operations processed within the server. The default access log file is written to logs/access, but multiple access loggers can be active at the same time, each writing to different log files and using different configurations.

By default, a single access log message is generated, which combines the elements of request, forward, and result messages. If an error is encountered while attempting to process the request, then one or more forward-failed messages can also be generated.

[01/Jun/2011:11:10:19.692 -0500] CONNECT conn=49 from="127.0.0.1" to="127.0.0.1"
  protocol="LDAP+TLS" clientConnectionPolicy="default"
[01/Jun/2011:11:10:19.764 -0500] BIND RESULT conn=49 op=0 msgID=1 version="3"
  dn="cn=Directory Manager" authType="SIMPLE" resultCode=0 etime=0.401
  authDN="cn=Directory Manager,cn=Root DNs,cn=config" clientConnectionPolicy="default"
[01/Jun/2011:11:10:19.769 -0500] SEARCH RESULT conn=49 op=1 msgID=2
  base="ou=People,dc=example,dc=com" scope=2 filter="(uid=1)" attrs="ALL"
  resultCode=0 etime=0.549 entriesReturned=1
[01/Jun/2011:11:10:19.788 -0500] DISCONNECT conn=49 reason="Client Unbind"

Each log message includes a timestamp indicating when it was written, followed by the operation type, the connection ID (which is used for all operations processed on the same client connection), the operation ID (which can be used to correlate the request and response log messages for the operation), and the message ID used in LDAP messages for this operation.

The remaining content for access log messages varies based on the type of operation being processed, and whether it is a request or a result message. Request messages generally include the most pertinent information from the request, but generally omit information that is sensitive or not useful.

Result messages include a resultCode element that indicates whether the operation was successful or if failed and an etime element that indicates the length of time in milliseconds that the server spent processing the operation. Other elements that might be present include the following:

  • origin=replication – Operation that was processed as a result of data synchronization (for example, replication) rather than a request received directly from a client.

  • message – Text that was included in the diagnosticMessage field of the response sent to the client.

  • additionalInfo – Additional information about the operation that was not included in the response sent back to the client.

  • authDN – DN of the user that authenticated to the server (typically only included in bind result messages).

  • authzDN – DN of an alternate authorization identify used when processing the operation (for example, if the proxied authorization control was included in the request).

  • authFailureID – Unique identifier associated with the authentication failure reason (only included in non-successful bind result messages).

  • authFailureReason – Information about the reason that a bind operation failed that might be useful to administrators but was not included in the response to the client for security reasons.

  • responseOID – OID included in an extended response returned to the client.

  • entriesReturned – Number of matching entries returned to the client for a search operation.

  • unindexed=true – Indicates that the associated search operation could not be sufficiently processed using server indexes and a significant traversal through the database was required.

Note that this is not an exhaustive list, and elements that are not listed here can also be present in access log messages. The LDAP SDK for Java provides an API for parsing access log messages and provides access to all elements that they can contain.

The server provides a second access log implementation called the audit log, which is used to provide detailed information about write operations (add, delete, modify, and modify DN) processed within the server. If the audit log is enabled, the entire content of the change is written to the audit log file (which defaults to logs/audit) in LDIF form.

The server also provides a very rich classification system that can be used to filter the content for access log files. This can be helpful when debugging problems with client applications, because it can restrict log information to operations processed only by a particular application (for example, based on IP address and/or authentication DN), only failed operations, or only operations taking a long time to complete, etc.