5.1. Access Log Content
The Directory Server access log contains detailed information about client connections to the directory. A connection is a sequence of requests from the same client with the following structure:
Connection record, which gives the connection index and the IP address of the client.
Bind record.
Bind result record.
Sequence of operation request/operation result pairs of records (or individual records in the case of connection, closed, and abandon records).
Unbind record.
Closed record.
Every line begins with a timestamp — [21/Apr/2007:11:39:51 -0700] — the format of which may vary depending on the platform. -0700 indicates the time difference in relation to GMT. Apart from the connection, closed, and abandon records, which appear individually, all records appear in pairs, consisting of a request for service record followed by a result record. These two records frequently appear on adjacent lines, but this is not always the case.
This section presents the different levels of access logging available with Directory Server, then describes the default access logging content, and ends with a description of the additional access logging level content.
Directory Server provides a script which can analyze access logs to extract usage statistics and count the occurrences of significant events. For details about this script, see Section 7.4.7, “logconv.pl (Log Converter)”.
Different levels of access logging exist, and changing the value of the nsslapd-accesslog-level configuration attribute sets the exact type of logging required. See Section 2.3.1.2, “nsslapd-accesslog-level” for full details on access log levels.
This section describes the access log content in detail based on the default access logging level extract shown below.
[21/Apr/2007:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.51 to 192.18.122.139
[21/Apr/2007:11:39:51 -0700] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[21/Apr/2007:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[21/Apr/2007:11:39:51 -0700] conn=11 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=bjensen)"
[21/Apr/2007:11:39:51 -0700] conn=11 op=1 RESULT err=0 tag=101 nentries=1 etime=1000 notes=U
[21/Apr/2007:11:39:51 -0700] conn=11 op=2 UNBIND
[21/Apr/2007:11:39:51 -0700] conn=11 op=2 fd=608 closed - U1
[21/Apr/2007:11:39:52 -0700] conn=12 fd=634 slot=634 connection from 207.1.153.51 to 192.18.122.139
[21/Apr/2007:11:39:52 -0700] conn=12 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[21/Apr/2007:11:39:52 -0700] conn=12 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[21/Apr/2007:11:39:52 -0700] conn=12 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=bjensen)"
[21/Apr/2007:11:39:52 -0700] conn=12 op=2 ABANDON targetop=1 msgid=2 nentries=0 etime=0
[21/Apr/2007:11:39:52 -0700] conn=12 op=3 UNBIND
[21/Apr/2007:11:39:52 -0700] conn=12 op=3 fd=634 closed - U1
[21/Apr/2007:11:39:53 -0700] conn=13 fd=659 slot=659 connection from 207.1.153.51 to 192.18.122.139
[21/Apr/2007:11:39:53 -0700] conn=13 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[21/Apr/2007:11:39:53 -0700] conn=13 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[21/Apr/2007:11:39:53 -0700] conn=13 op=1 EXT oid="2.16.840.1.113730.3.5.3"
[21/Apr/2007:11:39:53 -0700] conn=13 op=1 RESULT err=0 tag=120 nentries=0 etime=0
[21/Apr/2007:11:39:53 -0700] conn=13 op=2 ADD dn="cn=Sat Apr 21 11:39:51 MET DST 2007, dc=example,dc=com"
[21/Apr/2007:11:39:53 -0700] conn=13 op=2 RESULT err=0 tag=105 nentries=0 etime=0 csn=3b4c8cfb000000030000
[21/Apr/2007:11:39:53 -0700] conn=13 op=3 EXT oid="2.16.840.1.113730.3.5.5"
[21/Apr/2007:11:39:53 -0700] conn=13 op=3 RESULT err=0 tag=120 nentries=0 etime=0
[21/Apr/2007:11:39:53 -0700] conn=13 op=4 UNBIND
[21/Apr/2007:11:39:53 -0700] conn=13 op=4 fd=659 closed - U1
[21/Apr/2007:11:39:55 -0700] conn=14 fd=700 slot=700 connection from 207.1.153.51 to 192.18.122.139
[21/Apr/2007:11:39:55 -0700] conn=14 op=0 BIND dn="" method=saslversion=3 mech=DIGEST-MD5
[21/Apr/2007:11:39:55 -0700] conn=14 op=0 RESULT err=14 tag=97nentries=0 etime=0, SASL bind in progress
[21/Apr/2007:11:39:55 -0700] conn=14 op=1 BINDdn="uid=jdoe,dc=example,dc=com" method=sasl version=3
mech=DIGEST-MD5
[21/Apr/2007:11:39:55 -0700] conn=14 op=1 RESULT err=0 tag=97nentries=0 etime=0 dn="uid=jdoe,dc=
example,dc=com"
[21/Apr/2007:11:39:55 -0700] conn=14 op=2 UNBIND
[21/Apr/2007:11:39:53 -0700] conn=14 op=2 fd=700 closed - U1
Every external LDAP request is listed with an incremental connection number, in this case conn=11, starting at conn=0 immediately after server startup.
[21/Apr/2007:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.51 to 192.18.122.139
Internal LDAP requests are not recorded in the access log by default. To activate the logging of internal access operations, specify access logging level 4 on the nsslapd-accesslog-level configuration attribute (see Section 2.3.1.2, “nsslapd-accesslog-level” ).
Every connection from an external LDAP client to Directory Server requires a file descriptor or socket descriptor from the operating system, in this case fd=608. fd=608 indicates that it was file descriptor number 608 out of the total pool of available file descriptors which was used.
[21/Apr/2007:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.51 to 192.18.122.139
The slot number, in this case slot=608, is a legacy part of the access log which has the same meaning as file descriptor. Ignore this part of the access log.
[21/Apr/2007:11:39:51 -0700] conn=11 fd=608 slot=608 connection from 207.1.153.51 to 192.18.122.139
To process a given LDAP request, Directory Server will perform the required series of operations. For a given connection, all operation request and operation result pairs are given incremental operation numbers beginning with op=0 to identify the distinct operations being performed.
[21/Apr/2007:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0
In Section 5.1.2, “Default Access Logging Content”, we have op=0 for the bind operation request and result pair, then op=1 for the LDAP search request and result pair, and so on. The entry op=-1 in the access log generally means that the LDAP request for this connection was not issued by an external LDAP client but, instead, initiated internally.
The method number, in this case method=128, indicates which LDAPv3 bind method was used by the client.
[21/Apr/2007:11:39:51 -0700] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3
There are three possible bind method values:
0 for authentication
128 for simple bind with user password
sasl for SASL bind using external authentication mechanism
The version number, in this case version=3, indicates the LDAP version number (either LDAPv2 or LDAPv3) that the LDAP client used to communicate with the LDAP server.
[21/Apr/2007:11:39:51 -0700] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3
The error number, in this case err=0, provides the LDAP result code returned from the LDAP operation performed. The LDAP error number 0 means that the operation was successful. For a more comprehensive list of LDAP result codes, see Section 5.3, “LDAP Result Codes”.
[21/Apr/2007:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0
The tag number, in this case tag=97, indicates the type of result returned, which is almost always a reflection of the type of operation performed. The tags used are the BER tags from the LDAP protocol.
[21/Apr/2007:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0
| Tag | Description |
|---|---|
| tag=97 | A result from a client bind operation. |
| tag=100 | The actual entry being searched for. |
| tag=101 | A result from a search operation. |
| tag=103 | A result from a modify operation. |
| tag=105 | A result from an add operation. |
| tag=107 | A result from a delete operation. |
| tag=109 | A result from a moddn operation. |
| tag=111 | A result from a compare operation. |
| tag=115 | A search reference when the entry on which the search was performed holds a referral to the required entry. Search references are expressed in terms of a referral. |
| tag=120 | A result from an extended operation. |
tag=100 and tag=115 are not result tags as such, and so it is unlikely that they will be recorded in the access log.
nentries shows the number of entries, in this case nentries=0, that were found matching the LDAP client's request.
[21/Apr/2007:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0
etime shows the elapsed time, in this case etime=1000, or the amount of time (in seconds) that it took the Directory Server to perform the LDAP operation.
[21/Apr/2007:11:39:51 -0700] conn=11 op=0 RESULT err=0 tag=97 nentries=0 etime=0
An etime value of 0 means that the operation actually took milliseconds to perform. To have microsecond resolution for this item in the access log, enter a value of 131328 (256+131072) in the nsslapd-accesslog-level configuration attribute.
The LDAP request type indicates the type of LDAP request being issued by the LDAP client. Possible values are:
SRCH for search
MOD for modify
DEL for delete
ADD for add
MODDN for moddn
EXT for extended operation
ABANDON for abandon operation
If the LDAP request resulted in sorting of entries, then the message SORT serialno will be recorded in the log, followed by the number of candidate entries that were sorted. For example:
[04/May/2007:15:51:46 -0700] conn=114 op=68 SORT serialno (1)
The number enclosed in parentheses specifies the number of candidate entries that were sorted, which in this case is 1.
The LDAP response type indicates the LDAP response being issued by the LDAP client. There are three possible values:
RESULT
ENTRY
REFERRAL, an LDAP referral or search reference
The unindexed search indicator, notes=U, indicates that the search performed was unindexed, which means that the database itself had to be directly searched instead of the index file. Unindexed searches occur in three scenarios:
When the nsslapd-idlistscanlimit was reached within the index file used for the search.
When no index file existed.
When the index file was not configured in the way required by the search.
An unindexed search indicator is often accompanied by a large etime value, as unindexed searches are generally more time consuming.
When a search involves virtual list views (VLVs), appropriate entries are logged in the access log file. Similar to the other entries, VLV-specific entries show the request and response information side by side:
VLV RequestInformation ResponseInformation
RequestInformation has the following form:
beforeCount:afterCount:index:contentCount
If the client uses a position-by-value VLV request, the format for the first part, the request information would be beforeCount: afterCount: value.
ResponseInformation has the following form:
targetPosition:contentCount(resultCode)
The example below highlights the VLV-specific entries:
[07/May/2007:11:43:29 -0700] conn=877 op=8530 SRCH base="(ou=People)" scope=2 filter="(uid=*)"
[07/May/2007:11:43:29 -0700] conn=877 op=8530 SORT uid
[07/May/2007:11:43:29 -0700] conn=877 op=8530 VLV 0:5:0210 10:5397 (0)
[07/May/2007:11:43:29 -0700] conn=877 op=8530 RESULT err=0 tag=101 nentries=1 etime=0
In the above example, the first part, 0:5:0210, is the VLV request information:
The beforeCount is 0.
The afterCount is 5.
The value is 0210.
The second part, 10:5397 (0), is the VLV response information:
The targetPosition is 10.
The contentCount is 5397.
The (resultCode) is (0).
The entry scope=n defines the scope of the search performed, and n can have a value of 0, 1, or 2.
0 for base search
1 for one-level search
2 for subtree search
For more information about search scopes, see "Using ldapsearch" in Appendix B, "Finding Directory Entries", in the Red Hat Directory Server Administration Guide.
An extended operation OID, in this case either EXT oid="2.16.840.1.113730.3.5.3" or EXT oid="2.16.840.1.113730.3.5.5", provides the OID of the extended operation being performed. The following table provides a partial list of LDAPv3 extended operations and their OIDs supported in Directory Server.
| Extended Operation Name | Description | OID |
|---|---|---|
| Directory Server Start Replication Request | Sent by a replication initiator to indicate that a replication session is requested. | 2.16.840.1.113730.3.5.3 |
| Directory Server Replication Response | Sent by a replication responder in response to a Start Replication Request Extended Operation or an End Replication Request Extended Operation. | 2.16.840.1.113730.3.5.4 |
| Directory Server End Replication Request | Sent to indicate that a replication session is to be terminated. | 2.16.840.1.113730.3.5.5 |
| Directory Server Replication Entry Request |
Carries an entry, along with its state information (csn and UniqueIdentifier) and is used to perform a replica initialization.
|
2.16.840.1.113730.3.5.6 |
| Directory Server Bulk Import Start | Sent by the client to request a bulk import together with the suffix being imported to and sent by the server to indicate that the bulk import may begin. | 2.16.840.1.113730.3.5.7 |
| Directory Server Bulk Import Finished | Sent by the client to signal the end of a bulk import and sent by the server to acknowledge it. | 2.16.840.1.113730.3.5.8 |
The change sequence number, in this case csn=3b4c8cfb000000030000, is the replication change sequence number, indicating that replication is enabled on this particular naming context.
The abandon message indicates that an operation has been aborted.
[21/Apr/2007:11:39:52 -0700] conn=12 op=2 ABANDON targetop=1 msgid=2 nentries=0 etime=0
nentries=0 indicates the number of entries sent before the operation was aborted, etime=0 value indicates how much time (in seconds) had elapsed, and targetop=1 corresponds to an operation value from a previously initiated operation (that appears earlier in the access log).
There are two possible log ABANDON messages, depending on whether the message ID succeeds in locating which operation was to be aborted. If the message ID succeeds in locating the operation (the targetop) then the log will read as above. However, if the message ID does not succeed in locating the operation or if the operation had already finished prior to the ABANDON request being sent, then the log will read as follows:
[21/Apr/2007:11:39:52 -0700] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2
targetop=NOTFOUND indicates the operation to be aborted was either an unknown operation or already complete.
The message ID, in this case msgid=2, is the LDAP operation identifier, as generated by the LDAP SDK client. The message ID may have a different value than the operation number but identifies the same operation. The message ID is used with an ABANDON operation and tells the user which client operation is being abandoned.
[21/Apr/2007:11:39:52 -0700] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2
The Directory Server operation number starts counting at 0, and, in the majority of LDAP SDK/client implementations, the message ID number starts counting at 1, which explains why the message ID is frequently equal to the Directory Server operation number plus 1.
In Directory Server, logging for multi-stage binds is explicit. Each stage in the bind process is logged, and, where appropriate, the progress statement SASL bind in progress is included.
In logging a SASL bind, the sasl method is followed by the LDAP version number (see Section 5.1.2.6, “Version Number”) and the SASL mechanism used, as shown below with the GSS-API mechanism.
[21/Apr/2007:12:57:14 -0700] conn=32 op=0 BIND dn=""method=saslversion=3mech=GSSAPI
The authenticated DN (the DN used for access control decisions) is now logged in the BIND result line as opposed to the bind request line, as was previously the case:
[21/Apr/2007:11:39:55 -0700] conn=14 op=1 RESULT err=0 tag=97 nentries=0 etime=0
dn="uid=jdoe,dc=example,dc=com"
For SASL binds, the DN value displayed in the bind request line is not used by the server and, as a consequence, is not relevant. However, given that the authenticated DN is the DN which, for SASL binds, must be used for audit purposes, it is essential that this be clearly logged. Having this authenticated DN logged in the bind result line avoids any confusion as to which DN is which.
This section presents the additional access logging levels available in the Directory Server access log. In the following example, access logging level 4, which logs internal operations, is enabled.
[12/Jul/2007:16:45:46 +0200] conn=Internal op=-1
SRCH base="cn=\22dc=example,dc=com\22,cn=mapping tree,cn=config"scope=0
filter="objectclass=nsMappingTree"attrs="nsslapd-referral" options=persistent
[12/Jul/2007:16:45:46 +0200] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1etime=0
[12/Jul/2007:16:45:46 +0200] conn=Internal op=-1
SRCH base="cn=\22dc=example,dc=com\22,cn=mapping tree,cn=config"scope=0
filter="objectclass=nsMappingTree" attrs="nsslapd-state"
[12/Jul/2007:16:45:46 +0200] conn=Internal op=-1 RESULT err=0 tag=48 nentries=1etime=0
Access log level 4 enables logging for internal operations, which log search base, scope, filter, and requested search attributes, in addition to the details of the search being performed.
In the following example, access logging level 768 is enabled (512 + 256), which logs access to entries and referrals. In this extract, six entries and one referral are returned in response to the search request, which is shown on the first line.
[12/Jul/2007:16:43:02 +0200] conn=306 fd=60 slot=60 connection from 127.0.0.1 to 127.0.0.1 \
[12/Jul/2007:16:43:02 +0200] conn=306 op=0 SRCH base="dc=example,dc=com" \
scope=2 filter="(description=*)" attrs=ALL
[12/Jul/2007:16:43:02 +0200] conn=306 op=0 ENTRY dn="ou=Special
[12/Jul/2007:16:43:02 +0200] conn=306 op=0 ENTRY dn="cn=Accounting Managers,ou=groups,dc=example,dc=com"
[12/Jul/2007:16:43:02 +0200] conn=306 op=0 ENTRY dn="cn=HR Managers,ou=groups,dc=example,dc=com"
[12/Jul/2007:16:43:02 +0200] conn=306 op=0 ENTRY dn="cn=QA Managers,ou=groups,dc=example,dc=com"
[12/Jul/2007:16:43:02 +0200] conn=306 op=0 ENTRY dn="cn=PD Managers,ou=groups,dc=example,dc=com"
[12/Jul/2007:16:43:02 +0200] conn=306 op=0 ENTRY dn="ou=Red Hat Servers,dc=example,dc=com"
[12/Jul/2007:16:43:02 +0200] conn=306 op=0 REFERRAL
The connection description, in this case conn=Internal, indicates that the connection is an internal connection. The operation number op=-1 also indicates that the operation was initiated internally.
[12/Jul/2007:16:45:46 +0200] conn=Internal op=-1
ENTRY dn="cn=\22dc=example,dc=com\22, cn=mapping tree, cn=config"
The options description, in this case options=persistent, indicates that a persistent search is being performed. Persistent searches can be used as a form of monitoring and configured to return changes to given configurations as changes occur.
[12/Jul/2007:16:45:46 +0200] conn=Internal op=-1
SRCH base="cn=\22dc=example,dc=com\22,cn=mapping tree,cn=config"scope=0
filter="objectclass=nsMappingTree"attrs="nsslapd-referral" options=persistent
In this example, both access logging level 512 and 4 are enabled, which results in both internal access operations and entry access and referrals being logged.