Chapter 11. Log files reference

Directory Server records events to log files that are essential for solving existing problems and predicting potential problems, which might result in failure or poor performance.

With log files you can achieve the following goals:

  • Troubleshoot problems.
  • Monitor the server activity.
  • Analyze the directory activity.

To monitor the directory effectively, you must understand the structure and content of the log files.

You do not find an exhaustive list of log messages in the chapter. Presented information serves as a good starting point to solve common problems and understand the records in the access, error, audit, audit fail, and secure logs.

Directory Server instances store logs in the /var/log/dirsrv/slapd-instance_name directory.

11.1. Access log reference

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:

  • A connection record which provides the connection index and the IP address of the client
  • A bind record
  • A bind result record
  • A sequence of operation request and operation result pairs of records, or individual records in the case of connection, closed, and abandon records
  • An unbind record
  • A closed record

Access log record example: 

[time_stamp] conn=1 op=73 SRCH base="dc=example,dc=com" scope=2 filter="(&(objectClass=top)(objectClass=ldapsubentry)(objectClass=passwordpolicy))" attrs="distinguishedName"
[time_stamp] conn=1 op=73 RESULT err=0 tag=101 nentries=24 wtime=0.000078414 optime=0.001614101 etime=0.001690742

Almost all records appear in pairs: a service request record, SRCH in the example, followed by a RESULT record. Connection, closed, and abandon records appear individually.

The access logs have several levels of logging that you can configure using the nsslapd-accesslog-level attribute.

11.1.1. Access logging levels

Different levels of access logging record different kinds of operations that Directory Server performs.

The access log has the following log levels:

  • No access logging (0).
  • Logging for internal access operations (4).
  • Logging for connections, operations, and results (256). The default level.
  • Logging for access to an entry and referrals (512).

Use the nsslapd-accesslog-level attribute to configure the access log level. The attribute values are additive: if you set a log level value of 260, it includes levels 256 and 4.

Additional resources

11.1.2. Default access log content

By default, Directory Server has the 256 logging level that records access to an entry and contains information presented further.

Connection number (conn)

Directory Server lists every external LDAP request with an incremental connection number, conn=13 in the example. Connection numbers start at conn=0 immediately after the server startup. 

[time_stamp] conn=13 fd=608 slot=608 connection from 172.17.0.2 to 172.17.0.2

Directory Server does not record internal LDAP requests by default. To enable logging of internal access operations, use the nsslapd-accesslog-level configuration attribute.

File descriptor (fd)

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. The fd=608 value indicates that an external LDAP client used the file descriptor number 608 out of the total pool of available file descriptors. 

[time_stamp] conn=11 fd=608 slot=608 connection from 172.17.0.2 to 172.17.0.2

Slot number (slot)

The slot number, slot=608 in the example, is a legacy part of the access log that has the same meaning as file descriptor. Ignore this part of the access log. 

[time_stamp] conn=11 fd=608 slot=608 connection from 172.17.0.2 to 172.17.0.2.

Operation number (opt)

To process an LDAP request, Directory Server performs a series of operations. For a connection, all operation request and operation result pairs have incremental operation numbers beginning with op=0 to identify different operations. 

[time_stamp] conn=14 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[time_stamp] conn=14 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680
[time_stamp] conn=14 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=bjensen)"
[time_stamp] conn=14 op=2 ABANDON targetop=2 msgid=3 nentries=0 etime=0.0000113702
[time_stamp] conn=14 op=3 UNBIND
[time_stamp] conn=14 op=3 fd=634 closed - U1

In the example:

  • op=0 for the bind operation request and the result
  • op=1 for the LDAP search request and the result
  • op=2 for the abandon operation
  • op=3 for the unbind operation the LDAP client sends and the result

Method type (method)

The method number, method=128 in the example, indicates which LDAPv3 bind method the client used. 

[time_stamp] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3

The method type can have one of the three possible values:

  • 0 for authentication
  • 128 for a simple bind with a user password
  • sasl for a SASL bind that uses an external authentication mechanism

Version number (version)

The version number indicates the LDAP version number that the LDAP client used to communicate with the LDAP server. The LDAP version number can be either LDAPv2 or LDAPv3. In the example, it uses version=3. 

[time_stamp] conn=11 op=0 BIND dn="cn=Directory Manager" method=128 version=3

Error number (err)

The error number provides the LDAP result code that returns performed LDAP operation. The LDAP error number 0 means that the operation was successful. The example has op=0. 

[time_stamp] conn=2 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680

Tag number (tag)

The tag number indicates the type of a returned result for an operation. Directory Server uses a BER tags from the LDAP protocol. The example has tag=97. 

[time_stamp] conn=11 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680

The following table provides commonly used tags:

TagDescription

tag=97

The result from a client bind operation.

tag=100

The actual entry that Directory Server searched for. It is not a result tag, and the access log does not contain such a tag.

tag=101

The result from a search operation.

tag=103

The result from a modify operation.

tag=105

The result from an add operation.

tag=107

The result from a delete operation.

tag=109

The result from a moddn (renaming) operation.

tag=111

The result from a compare operation.

tag=115

Search reference when the entry that the operation searches for holds a referral to the required entry. It is not a result tag, and the access log does not contain such a tag.

tag=120

The result from an extended operation.

tag=121

The result from an intermediate operation.

Number of entries (nentries)

The nentries record shows the number of entries that a search operation found matching the LDAP client request. 

[time_stamp] conn=11 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680

In the example, nentries=0, Directory Server did not find any matching entries.

Elapsed time (etime)

The etime record shows the elapsed time or the amount of time (in seconds) that Directory Server spent to perform the LDAP operation. 

[time_stamp] conn=11 op=1 RESULT err=0 tag=101 nentries=1 wtime=0.000076581 optime=0.000082736 etime=0.000158680 notes=U

In the example, Directory Server spent 0.000158680 seconds to perform the operation.

An etime value of 0 means that the operation actually took 0 nanoseconds to perform.

LDAP request type

The LDAP request type indicates what type of an LDAP request LDAP client issued. Possible values are:

  • SRCH for a search operation
  • MOD for a modify operation
  • DEL for a delete operation
  • ADD for an add operation
  • MODDN for a moddn (renaming) operation
  • EXT for an extended operation
  • ABANDON for an abandon operation
  • SORT serialno if the LDAP request results in sorting the entries 
[time_stamp] conn=114 op=68 SORT serialno (1)

In the example, the number enclosed in parentheses specifies that the LDAP request sorted one candidate entry.

LDAP response type

Directory Server can issue three LDAP response types:

  • RESULT means a result to the client LDAP request.
  • ENTRY means an entry Directory Server returns in response to a search operation.
  • REFERRAL means that the Directory Server sends the LDAP request to another server.

The RESULT message contains the following performance-related records:

wtime
The amount of time the operation was waiting in the work queue before a worker thread picked up the operation
optime
The amount of time it took for the actual operation to perform the task
etime
The time between when Directory Server receives the request and when the server sends the result back to the client.
Note

The wtime and optime values provide useful information about how the server handles the load and processes operations. Because Directory Server requires some time to gathers these statistics, the sum of the wtime and optime values are slightly greater than the etime value.

Search indicators (note)

Directory Server provides additional information on searches in the note message of log entries. For example: 

[time_stamp] conn=11 op=1 RESULT err=0 tag=101 nentries=1 wtime=0.000076581 optime=0.000082736 etime=0.000158680 notes=U

Directory Server supports the following search indicators:

Search indicatorDescription

notes=P

Paged search indicator. LDAP clients with limited resources can control the rate at which an LDAP server returns the results of a search operation. When the performed search used the LDAP control extension for simple paging of search results, Directory Server logs the notes=P paged search indicator. This indicator is informational and no further actions are required. For more details on paged search indicator, see RFC 2696 specification.

notes=A

Unindexed search indicator. Directory Server logs notes=A when all candidate attributes in the filter were unindexed and a full table scan was required. This can exceed the value set in the nsslapd-lookthroughlimit attribute.

notes=U

Unindexed search indicator. Directory Server logs notes=U in the following situations:

  • At least one of the search terms is unindexed.
  • A search operation exceeds the limit set in the nsslapd-idlistscanlimit attribute.

notes=F

Unknown attribute indicator. Directory Server logs notes=F when a search filter contains an unknown attribute.

notes=M

MFA plug-in binds indicator. Directory Server logs notes=M when you configured the two-factor authentication for user accounts by using a pre-bind authentication plug-in, such as the MFA plug-in.

The note records can have combinations of values: notes=P,A and notes=U,P.

When attributes are not indexed, Directory Server must search them directly in the database. This procedure is more resource-intensive than searching the index file.

Unindexed searches occur in the following scenarios:

  • The search operation exceeds the number of searched entries set in the nsslapd-idlistscanlimit attribute even when using the index file. For details about the nsslapd-idlistscanlimit attribute, see nsslapd-idlistscanlimit description
  • No index file exists.
  • The index file was not configured in the way required by the search.

To optimize future searches, add frequently searched unindexed attributes to the index.

Note

An unindexed search indicator is often accompanied by a large etime value, because unindexed searches are generally more time consuming.

MFA plug-in binds

When you configure the two-factor authentication for user accounts by using a pre-bind authentication plug-in, such as the MFA plug-in, the access log records the notes=M note message to the file: 

[time_stamp] conn=1 op=0 BIND dn=“uid=jdoe,ou=people,dc=example,dc=com” method=128 version=3
[time_stamp] conn=1 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000111632 optime=0.006612223 etime=0.006722325 notes=M details=“Multi-factor Authentication” dn=“uid=jdoe,ou=people,dc=example,dc=com”
Note

For the access log to record the notes=M note messages, the pre-bind authentication plug-in must set the flag by using the SLAPI API if a bind was part of this plug-in.

VLV-related entries (VLV)

When a search involves virtual list views (VLVs), Directory Server logs appropriate entries to the access log file. Similar to the other entries, VLV-specific records show the request and response information together: 

[time_stamp] conn=67 op=8530 VLV 0:5:0210 10:5397 (0)

In the example, the request information is 0:5:0210 and has the format beforeCount:afterCount:index:contentCount. The response information is 10:5397 (0) and has the format targetPosition:contentCount (resultCode).

If the client uses a position-by-value VLV request, the request information format is beforeCount: afterCount: value.

Search scope (scope)

The scope entry defines the scope for a performed search operation and can have one of the following values:

  • 0 for a base search
  • 1 for a one-level search
  • 2 for a subtree search

Extended operation OID (oid)

The oid record provides the object identifier (OID) of the performed extended operation. Below is an example of access log records with the extended operation OIDs: 

[time_stamp] conn=13 op=1 EXT oid="2.16.840.1.113730.3.5.3"
...
[time_stamp] conn=15 op=3 EXT oid="2.16.840.1.113730.3.5.5"

Directory Server supports the following list of LDAPv3 extended operations and their OIDs:

Extended operation nameDescriptionOID

Directory Server Start Replication Request

A replication initiator requests a replication session.

2.16.840.1.113730.3.5.3

Directory Server Replication Response

A replication responder answers in the 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

A replication initiator terminates the replication session.

2.16.840.1.113730.3.5.5

Directory Server Replication Entry Request

Carries an entry with the 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

A client requests a bulk import together with the imported suffix using the Bulk Import Start operation, and Directory Server indicates that the bulk import may begin.

2.16.840.1.113730.3.5.7

Directory Server Bulk Import Finished

A client ends a bulk import using the Bulk Import Finished operation, and Directory Server acknowledges the bulk import ending.

2.16.840.1.113730.3.5.8

Change sequence number (csn)

The csn message, such as csn=3b4c8cfb000000030000, indicates that Directory Server received an update identified by its 'csn' and processed it.

Abandon message (ABANDON)

The abandon message indicates that a client or Directory Server terminates an operation.

Below is an example of log records that contain an abandon message: 

[time_stamp] conn=12 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=bjensen)"
[time_stamp] conn=12 op=2 ABANDON targetop=2 msgid=3 nentries=0 etime=0.0000113980

The nentries=0 value indicates the number of entries Directory Server sent before the operation was terminated, etime=0.0000113980 value indicates how much time (in seconds) had elapsed, and targetop=2 corresponds to the operation number that Directory Server initiated earlier (opt=2).

If Directory Server does not find what operation to abandon, a log record contains a targetop=NOTFOUND message: 

[time_stamp] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2

The example message means that Directory Server has completed the operation earlier or it is an unknown operation.

Message ID (msgid)

An LDAP SDK client generates the message ID, such as msgid=2, which is also an LDAP operation identifier. The msgid value may differ from the opt value; however, it identifies the same operation. Directory Server records the msgid with an ABANDON operation and tells the user which client operation was abandoned: 

[time_stamp] conn=12 op=2 ABANDON targetop=NOTFOUND msgid=2
Note

The Directory Server operation number opt starts counting at 0 for a connection. In the majority of LDAP SDK/client implementations, the message ID number msgid starts counting at 1. This explains why the msgid is frequently equal to the Directory Server opt plus 1.

SASL multi-stage bind logging

Directory Server logs each stage of the bind process. The error codes for SASL connections are really return codes: 

[time_stamp] conn=16 op=0 BIND dn="" method=sasl version=3 mech=DIGEST-MD5
[time_stamp] conn=16 op=0 RESULT err=14 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680, SASL bind in progress

The example record indicates that the SASL bind is currently in progress (SASL bind in progress) and has the return code of err=14. This means that the connection is still open. Directory Server logs SASL bind information together with the LDAP version number (version=3) and used SASL mechanism (mech=DIGEST-MD5).

Note

Because SASL authentication requires multiple steps, Directory Server logs the authenticated DN (the DN used for access control decisions) in the bind RESULT line when Directory Server completes the binding process. This shows what entry was mapped to the SASL bind request: 

[time_stamp] conn=14 op=1 RESULT err=0 tag=97 nentries=0 wtime=0.000076581 optime=0.000082736 etime=0.000158680 dn="uid=jdoe,dc=example,dc=com"

11.1.3. Non-default access log content

When you set non-default log levels or apply specific log configurations, Directory Server starts to record additional information to the access log file.

Internal operation records

When you enable logging for internal operations (4), Directory Server starts to log internal operations initiated by Directory Server or a client.

Server-initiated internal operations

If a client deletes an entry, the server runs several internal operations, such as locating the entry and updating groups in which the user was a member.

The following example shows the server-initiated internal operation logs format: 

[time_stamp] conn=Internal(0) op=0(0)(0) MOD dn="cn=uniqueid generator,cn=config"
[time_stamp] conn=Internal(0) op=0(0)(0) RESULT err=0 tag=48 nentries=0 wtime=0.0003979676 optime=0.0003989250 etime=0.0007968796

The example record has conn=Internal that is followed by (0) and op=0(0)(nesting_level). Operation ID and internal operation ID are always 0. For the non-nested log records the nesting level is 0.

Client-initiated internal operation

Client-initiated internal operation logs have a search base, scope, filter, and requested search attributes in addition to the details of the performed search. The following example shows the format of the log records: 

[time_stamp] conn=5 (Internal) op=15(1)(0) SRCH base="cn=config,cn=userroot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL
[time_stamp] conn=5 (Internal) op=15(1)(0) RESULT err=0 tag=48 nentries=0 wtime=0.0000143989 optime=0.0000151450 etime=0.0000295419
[time_stamp] conn=5 (Internal) op=15(2)(0) SRCH base="cn=config,cn=example,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL
[time_stamp] conn=5 (Internal) op=15(2)(0) RESULT err=0

The example record has the conn record that is set to the client connection ID and followed by the string (Internal). The op record contains the operation ID, followed by (internal_operation_ID)(nesting_level). The internal operation ID can vary. For the non-nested log entries the nesting level is 0.

Internal operations with plug-in logging enabled

If the nsslapd-plugin-logging parameter is set to on and you enabled internal operations logging (4), Directory Server additionally logs internal operations of plug-ins.

For example, if you delete the uid=user,dc=example,dc=com entry, and the Referential Integrity plug-in automatically deletes this entry from the example group, the server logs the following: 

[time_stamp] conn=2 op=37 DEL dn="uid=user,dc=example,dc=com"
[time_stamp] conn=2 (Internal) op=37(1) SRCH base="uid=user,dc=example,dc=com" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL
[time_stamp] conn=2 (Internal) op=37(1) RESULT err=0 tag=48 nentries=1 wtime=0.0000062569 optime=0.0000067203 etime=0.0000129148
[time_stamp] conn=2 (Internal) op=37(2) SRCH base="dc=example,dc=com" scope=2 filter="(member=uid=user,dc=example,dc=com)" attrs="member"
[time_stamp] conn=2 (Internal) op=37(2) RESULT err=0 tag=48 nentries=0 wtime=0.0000058002 optime=0.0000065198 etime=0.0000123162
[time_stamp] conn=2 (Internal) op=37(3) SRCH base="dc=example,dc=com" scope=2 filter="(uniquemember=uid=user,dc=example,dc=com)" attrs="uniquemember"
[time_stamp] conn=2 (Internal) op=37(3) RESULT err=0 tag=48 nentries=1 wtime=0.0000062123 optime=0.0000066022 etime=0.0000128104
[time_stamp] conn=2 (Internal) op=37(4) MOD dn="cn=example,dc=example,dc=com"
[time_stamp] conn=2 (Internal) op=37(5) SRCH base="cn=example,dc=example,dc=com" scope=0 filter="(|(objectclass=\*)(objectclass=ldapsubentry))" attrs=ALL
[time_stamp] conn=2 (Internal) op=37(5) RESULT err=0 tag=48 nentries=1 wtime=0.0000061994 optime=0.0000068742 etime=0.0000130685
[time_stamp] conn=2 (Internal) op=37(4) RESULT err=0 tag=48 nentries=0 wtime=0.0002600573 optime=0.0002617786 etime=0.0005217545
[time_stamp] conn=2 (Internal) op=37(6) SRCH base="dc=example,dc=com" scope=2 filter="(owner=uid=user,dc=example,dc=com)" attrs="owner"
[time_stamp] conn=2 (Internal) op=37(6) RESULT err=0 tag=48 nentries=0 wtime=0.000061678 optime=0.000076107 etime=0.0000137656
[time_stamp] conn=2 (Internal) op=37(7) SRCH base="dc=example,dc=com" scope=2 filter="(seeAlso=uid=user,dc=example,dc=com)" attrs="seeAlso"
[time_stamp] conn=2 (Internal) op=37(7) RESULT err=0 tag=48 nentries=0 wtime=0.0000031789 optime=0.0000035354 etime=0.0000066978
[time_stamp] conn=2 (Internal) op=37(8) SRCH base="o=example" scope=2 filter="(member=uid=user,dc=example,dc=com)" attrs="member"
[time_stamp] conn=2 (Internal) op=37(8) RESULT err=0 tag=48 nentries=0 wtime=0.0000030987 optime=0.0000032456 etime=0.0000063316
[time_stamp] conn=2 (Internal) op=37(9) SRCH base="o=example" scope=2 filter="(uniquemember=uid=user,dc=example,dc=com)" attrs="uniquemember"
[time_stamp] conn=2 (Internal) op=37(9) RESULT err=0 tag=48 nentries=0 wtime=0.0000021958 optime=0.0000026676 etime=0.0000048634
[time_stamp] conn=2 (Internal) op=37(10) SRCH base="o=example" scope=2 filter="(owner=uid=user,dc=example,dc=com)" attrs="owner"
[time_stamp] conn=2 (Internal) op=37(10) RESULT err=0 tag=48 nentries=0 wtime=0.0000022109 optime=0.00000268003 etime=00000048854
[time_stamp] conn=2 (Internal) op=37(11) SRCH base="o=example" scope=2 filter="(seeAlso=uid=user,dc=example,dc=com)" attrs="seeAlso"
[time_stamp] conn=2 (Internal) op=37(11) RESULT err=0 tag=48 nentries=0 wtime=0.0000021786 optime=0.0000024867 etime=0.0000046522
[time_stamp] conn=2 op=37 RESULT err=0 tag=107 nentries=0 wtime=0.005147365 optime=0.005150798 etime=0.0010297858

Access to an entry and referrals

When you enable logging for the access to an entry and referrals (512), Directory Server has the following records in the access log file: 

[time_stamp] conn=306 fd=60 slot=60 connection from 127.0.0.1 to 127.0.0.1
[time_stamp] conn=306 op=0 SRCH base="dc=example,dc=com" scope=2 filter="(description=*)" attrs=ALL
[time_stamp] conn=306 op=0 ENTRY dn="ou=Special
[time_stamp] conn=306 op=0 ENTRY dn="cn=Accounting Managers,ou=groups,dc=example,dc=com"
[time_stamp] conn=306 op=0 ENTRY dn="cn=HR Managers,ou=groups,dc=example,dc=com"
[time_stamp] conn=306 op=0 ENTRY dn="cn=QA Managers,ou=groups,dc=example,dc=com"
[time_stamp] conn=306 op=0 ENTRY dn="cn=PD Managers,ou=groups,dc=example,dc=com"
[time_stamp] conn=306 op=0 ENTRY dn="ou=Red Hat Servers,dc=example,dc=com"
[time_stamp0] conn=306 op=0 REFERRAL

The example has the logging level 768 (512 + 256) and shows six entries and one referral that a search request returns in response.

Options description

The options=persistent message indicates that Directory Server performs a persistent search. You can use persistent searches for monitoring purposes and configure returning changes to given configurations when changes occur.

The following example shows the 512 and 4 log levels that contain options description. 

[time_stamps] conn=1 (Internal) op=2(1)(0) SRCH base="cn=\22dc=example,dc=com\22,cn=mapping tree,cn=config"scope=0 filter="objectclass=nsMappingTree"attrs="nsslapd-referral" options=persistent

Statistics per a search operation

When you set the nsslapd-statlog-level attribute to 1, the access log starts to collect metrics, such as number of index lookups and overall duration of an index lookup, for each search operation. 

[time_stamps] conn=1 op=73 SRCH base="dc=example,dc=com" scope=2 filter="(cn=user_*)" attrs=ALL
[time_stamps] conn=1 op=73 STAT read index: attribute=objectclass key(eq)=referral --> count 0
[time_stamps] conn=1 op=73 STAT read index: attribute=cn key(sub)=er_ --> count 24
[time_stamps] conn=1 op=73 STAT read index: attribute=cn key(sub)=ser --> count 25
[time_stamps] conn=1 op=73 STAT read index: attribute=cn key(sub)=use --> count 25
[time_stamps] conn=1 op=73 STAT read index: attribute=cn key(sub)=^us --> count 24
[time_stamps] conn=1 op=73 STAT read index: duration 0.000010276
[time_stamps] conn=1 op=73 RESULT err=0 tag=101 nentries=24 wtime=0.00007841

The example of the log records shows that during the search with filter (cn=user_*), Directory Server performed the following number of database lookups:

  • 0 for referrals
  • 24 for er_ key
  • 25 for the ser key
  • 25 for the use key
  • 24 for the ^us key

11.1.4. Common connection codes

Directory Server adds a connection code to the closed log message with additional information related to the connection closure.

Connection CodeDescription

A1

The client aborts the connection.

B1

A corrupt BER tag is encountered. Directory Server logs B1 connection code to the access log when it receives corrupted BER tags that were sent over the wire. A BER tags can be corrupted due to physical layer network problems or bad LDAP client operations, such as an LDAP client cancels the operation before receives all request results.

B2

The BER tag is longer than the nsslapd-maxbersize attribute value.

B3

A corrupt BER tag is encountered.

B4

The server failed to send response back to the client.

P2

A closed or corrupt connection is detected.

T1

The client does not receive a result after the idle period that you can set in the nsslapd-idletimeout attribute.

T2

The server closed connection to a stalled LDAP client after a period of time you set in the nsslapd-ioblocktimeout.

U1

The server closes the connection after the client sends an unbind request. The server always closes a connection when it receives an unbind request.

Additional resources

11.2. Error log reference

The Directory Server error log records messages of Directory Server transactions and operations. The error log contains not only error messages for failed operations, but also general information about the Directory Server processes and LDAP tasks, such as server startup messages, logins and searches of the directory, and connection information.

11.2.1. Error logging levels

The error log can record different details of the Directory Server operations, including different types of information depending on the enabled logging level.

You can set the logging level by using the nsslapd-errorlog-level configuration attribute of the cn=config entry.

The default logging level is 16384. This level includes critical error messages and standard logged messages, such as LDAP results codes and startup messages. Error logging levels are additive. To enable both replication logging (8192) and plug-in logging (65536), set the nsslapd-errorlog-level attribute to 73728 (8192 + 65536).

Note

Enabling high levels of debug logging can significantly decrease the server performance. Therefore, enable high debug logging levels, such as replication (8192), only for troubleshooting.

Table 11.1. Error log levels

SettingConsole nameDescription

1

Trace function calls

Logs a message when the server enters and exits a function.

2

Packeting handlings

Logs debug information for packets the server processes.

4

Heavy trace output

Logs when the server enters and exits a function, with additional debugging messages.

8

Connection management

Logs the current connection status, including the connection methods used for a SASL bind.

16

Packets sent and received

Prints the numbers of packets the server sends and receives.

32

Search filter processing

Logs all functions a search operation calls.

64

Config file processing

Prints every .conf configuration files the server used, line by line, when the server starts. By default, Directory Server processes only the slapd-collations.conf file.

128

Access control list processing

Provides detailed access control list processing information.

2048

Log entry parsing

Logs schema parsing debugging information.

4096

Housekeeping

Logs debug information for housekeeping threads.

8192

Replication

Logs detailed information about every replication-related operation, including updates and errors, which is important for debugging replication problems.

16384

Default

Logs critical errors and other messages that Directory Server always writes to the error log, such as server startup messages. The error log contains these messages regardless of the log level setting.

32768

Entry cache

Logs debug information for the database entry cache.

65536

Plug-in

Writes an entry to the log file when a server plug-in calls the slapi-log-error() function. You can use the plug-in logging level for server plug-in debugging.

262144

Access control summary

Summarizes information about access to the server, contains less details than the 128 level. Use the 262144 value when you need a summary of access control processing. Use the 128 value for very detailed processing messages.

524288

Backend database

Logs debug information for handling databases associated with suffixes.

1048576

Password policy

Logs debug information about password policy decisions.

Additional resources

11.2.2. Default error log content

Either a server or a plug-in can write entries to the error log:

  • When a server writes logs, it uses the following format: 

    [time_stamp] - <severity_level> - <function_name> - <message>

    An example of the error log a server generates: 

    [time_stamp] - NOTICE - bdb_start_autotune - found 7110616k physical memory

  • When a plug-in writes logs, it uses the following format: 

    [time_stamp] - <severity_level> - <plug-in_name> - <function_name> - <message>

    An example of the error log a plug-in generates: 

    [time_stamp] - ERR - NSMMReplicationPlugin - multimaster_extop_StartNSDS50ReplicationRequest - conn=19 op=3 repl="o=example.com": Excessive clock skew from supplier RUV

Error log entries contain the following information:

Log messageDescription

Time stamp

The time stamp format can differ depending on your local settings. By default, the high-resolution time stamps are enabled and measured in nanoseconds.

Severity level

The severity level can have the following values:

  • EMERG when the server fails to start.
  • ALERT when the server is in a critical state, and you must take possible actions.
  • CRIT when a severe error appears.
  • ERR when a general error appears.
  • WARNING for a warning message that is not necessarily an error.
  • NOTICE when a normal but significant condition occurs. For example, Directory Server logs a notice message for the expected behavior.
  • INFO for informational messages, such as startup, shutdown, import, export, backup, and restore.
  • DEBUG for debug-level messages. Verbose logging levels, such as Trace function calls (1), Access control list processing (128), and Replication (8192) use DEBUG messages by default.

Plug-in name

The plug-in name appears only if a plug-in writes the message to the error log.

Function name

Functions that the operation or the plug-in call.

Message

The output that the operation or plug-in returns. The message contains additional information, such as LDAP error codes and connection information.

You can use the severity levels to filter your log entries. For example, to display only log entries with the ERR severity, run: 

# grep ERR /var/log/dirsrv/slapd-instance_name/errors
[time_stamp] - ERR - no_diskspace - No enough space left on device (/var/lib/dirsrv/slapd-instance_name/db) (40009728 bytes); at least 145819238 bytes space is needed for db region files
[time_stamp] - ERR - ldbm_back_start - Failed to init database, err=28 No space left on device
[time_stamp] - ERR - plugin_dependency_startall - Failed to start database plugin ldbm database
...

Additional resources

11.2.3. Non-default error log content

Different logging levels return different details, including types of server operations. The following are the most frequently used error logging levels that are not enabled by default. Remember that you can combine logging levels.

Replication (8192)

The replication logging is one of the most important diagnostic levels to implement. The replication (8192) level records all operations related to replication and Windows synchronization, including processing modifications on a supplier and writing them to the changelog, sending updates, and changing replication agreements.

When Directory Server prepares or sends a replication update, the error log identifies if it is a replication or synchronization agreement. The log also identifies the consumer host and port and the current replication task.

The replication level log has the following format: 

[time_stamp] NSMMReplicationPlugin - agmt="name" (consumer_host:consumer_port): current_task

The following is the example of the replication (8192) level log, where {replicageneration} means that Directory Server sends the new information and 4949df6e000000010000 is the change sequence number (CSN) of the replicated entry: 

[time_stamp] NSMMReplicationPlugin - agmt="cn=example2_agreement" (alt:13864): {replicageneration} 4949df6e000000010000

The following is the example of the complete process of sending a single entry to a consumer, from adding the entry to the changelog to releasing the consumer after replication is complete. 

[time_stamp] - DEBUG - _csngen_adjust_local_time - gen state before 592c103d0000:1496059964:0:1
[time_stamp] - DEBUG - _csngen_adjust_local_time - gen state after 592c10e20000:1496060129:0:1
[time_stamp] - DEBUG - NSMMReplicationPlugin - ruv_add_csn_inprogress - Successfully inserted csn 592c10e2000000020000 into pending list
[time_stamp] - DEBUG - NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName - found DB object 0x558ddfe1f720 for database /var/lib/dirsrv/slapd-supplier_2/changelogdb/d3de3e8d-446611e7-a89886da-6a37442d_592c0e0b000000010000.db
[time_stamp] - DEBUG - NSMMReplicationPlugin - changelog program - cl5WriteOperationTxn - Successfully written entry with csn (592c10e2000000020000)
[time_stamp] - DEBUG - NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName - found DB object 0x558ddfe1f720 for database /var/lib/dirsrv/slapd-supplier_2/changelogdb/d3de3e8d-446611e7-a89886da-6a37442d_592c0e0b000000010000.db
[time_stamp] - DEBUG - NSMMReplicationPlugin - csnplCommitALL: committing all csns for csn 592c10e2000000020000
[time_stamp] - DEBUG - NSMMReplicationPlugin - csnplCommitALL: processing data csn 592c10e2000000020000
[time_stamp] - DEBUG - NSMMReplicationPlugin - ruv_update_ruv - Successfully committed csn 592c10e2000000020000
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTo_localhost:39001" (localhost:39001): State: wait_for_changes -> wait_for_changes
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTo_localhost:39001" (localhost:39001): State: wait_for_changes -> ready_to_acquire_replica
[time_stamp] - DEBUG - NSMMReplicationPlugin - conn_connect - agmt="cn=meTo_localhost:39001" (localhost:39001) - Trying non-secure slapi_ldap_init_ext
[time_stamp] - DEBUG - NSMMReplicationPlugin - conn_connect - agmt="cn=meTo_localhost:39001" (localhost:39001) - binddn = cn=replrepl,cn=config,  passwd = {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVGRERBNEJDUmlZVFUzTnpRMk55MDBaR1ZtTXpobQ0KTWkxaE9XTTRPREpoTlMwME1EaGpabVUxWmdBQ0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCRGhwMnNLcEZ2ZWE2RzEwWG10OU41Tg==}+36owaI7oTmvWhxRzUqX5w==
[time_stamp] - DEBUG - NSMMReplicationPlugin - conn_cancel_linger - agmt="cn=meTo_localhost:39001" (localhost:39001) - No linger to cancel on the connection
[time_stamp] - DEBUG - _csngen_adjust_local_time - gen state before 592c10e20001:1496060129:0:1
[time_stamp] - DEBUG - _csngen_adjust_local_time - gen state after 592c10e30000:1496060130:0:1
[time_stamp] - DEBUG - NSMMReplicationPlugin - acquire_replica - agmt="cn=meTo_localhost:39001" (localhost:39001): Replica was successfully acquired.
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTo_localhost:39001" (localhost:39001): State: ready_to_acquire_replica -> sending_updates
[time_stamp] - DEBUG - csngen_adjust_time - gen state before 592c10e30001:1496060130:0:1
[time_stamp] - DEBUG - NSMMReplicationPlugin - changelog program - _cl5GetDBFile - found DB object 0x558ddfe1f720 for database /var/lib/dirsrv/slapd-supplier_2/changelogdb/d3de3e8d-446611e7-a89886da-6a37442d_592c0e0b000000010000.db
[time_stamp] - DEBUG - NSMMReplicationPlugin - changelog program - _cl5PositionCursorForReplay - (agmt="cn=meTo_localhost:39001" (localhost:39001)): Consumer RUV:
[time_stamp] - DEBUG - NSMMReplicationPlugin - agmt="cn=meTo_localhost:39001" (localhost:39001): {replicageneration} 592c0e0b000000010000
[time_stamp] - DEBUG - NSMMReplicationPlugin - agmt="cn=meTo_localhost:39001" (localhost:39001): {replica 1 ldap://localhost:39001} 592c0e17000000010000 592c0e1a000100010000 00000000
[time_stamp] - DEBUG - NSMMReplicationPlugin - agmt="cn=meTo_localhost:39001" (localhost:39001): {replica 2 ldap://localhost:39002} 592c103c000000020000 592c103c000000020000 00000000
[time_stamp] - DEBUG - NSMMReplicationPlugin - changelog program - _cl5PositionCursorForReplay - (agmt="cn=meTo_localhost:39001" (localhost:39001)): Supplier RUV:
[time_stamp] - DEBUG - NSMMReplicationPlugin - agmt="cn=meTo_localhost:39001" (localhost:39001): {replicageneration} 592c0e0b000000010000
[time_stamp] - DEBUG - NSMMReplicationPlugin - agmt="cn=meTo_localhost:39001" (localhost:39001): {replica 2 ldap://localhost:39002} 592c103c000000020000 592c10e2000000020000 592c10e1
[time_stamp] - DEBUG - NSMMReplicationPlugin - agmt="cn=meTo_localhost:39001" (localhost:39001): {replica 1 ldap://localhost:39001} 592c0e1a000100010000 592c0e1a000100010000 00000000
[time_stamp] - DEBUG - agmt="cn=meTo_localhost:39001" (localhost:39001) - clcache_get_buffer - found thread private buffer cache 0x558ddf870f00
[time_stamp] - DEBUG - agmt="cn=meTo_localhost:39001" (localhost:39001) - clcache_get_buffer - _pool is 0x558ddfe294d0 _pool->pl_busy_lists is 0x558ddfab84c0 _pool->pl_busy_lists->bl_buffers is 0x558ddf870f00
[time_stamp] - DEBUG - agmt="cn=meTo_localhost:39001" (localhost:39001) - clcache_initial_anchorcsn - agmt="cn=meTo_localhost:39001" (localhost:39001) - (cscb 0 - state 0) - csnPrevMax () csnMax (592c10e2000000020000) csnBuf (592c103c000000020000) csnConsumerMax (592c103c000000020000)
[time_stamp] - DEBUG - clcache_initial_anchorcsn - anchor is now: 592c103c000000020000
[time_stamp] - DEBUG - NSMMReplicationPlugin - changelog program - agmt="cn=meTo_localhost:39001" (localhost:39001): CSN 592c103c000000020000 found, position set for replay
[time_stamp] - DEBUG - agmt="cn=meTo_localhost:39001" (localhost:39001) - clcache_get_next_change - load=1 rec=1 csn=592c10e2000000020000
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain - Starting
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain - Read result for message_id 0
[time_stamp] - DEBUG - NSMMReplicationPlugin - replay_update - agmt="cn=meTo_localhost:39001" (localhost:39001): Sending add operation (dn="cn=user,ou=People,dc=example,dc=com" csn=592c10e2000000020000)
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain - Read result for message_id 0
[time_stamp] - DEBUG - NSMMReplicationPlugin - replay_update - agmt="cn=meTo_localhost:39001" (localhost:39001): Consumer successfully sent operation with csn 592c10e2000000020000
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain - Read result for message_id 0
[time_stamp] - DEBUG - agmt="cn=meTo_localhost:39001" (localhost:39001) - clcache_adjust_anchorcsn - agmt="cn=meTo_localhost:39001" (localhost:39001) - (cscb 0 - state 1) - csnPrevMax (592c10e2000000020000) csnMax (592c10e2000000020000) csnBuf (592c10e2000000020000) csnConsumerMax (592c10e2000000020000)
[time_stamp] - DEBUG - agmt="cn=meTo_localhost:39001" (localhost:39001) - clcache_load_buffer - rc=-30988
[time_stamp] - DEBUG - NSMMReplicationPlugin - send_updates - agmt="cn=meTo_localhost:39001" (localhost:39001): No more updates to send (cl5GetNextOperationToReplay)
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_waitfor_async_results - 0 5
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain - Read result for message_id 0
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain - Read result for message_id 0
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain - Read result for message_id 5
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain - Result 1, 0, 0, 5, (null)
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain - Read result for message_id 5
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_waitfor_async_results - 5 5
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_result_threadmain exiting
[time_stamp] - DEBUG - agmt="cn=meTo_localhost:39001" (localhost:39001) - clcache_return_buffer - session end: state=5 load=1 sent=1 skipped=0 skipped_new_rid=0 skipped_csn_gt_cons_maxcsn=0 skipped_up_to_date=0 skipped_csn_gt_ruv=0 skipped_csn_covered=0
[time_stamp] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_acquire_exclusive_access - conn=4 op=3 Acquired consumer connection extension
[time_stamp] - DEBUG - NSMMReplicationPlugin - multimaster_extop_StartNSDS50ReplicationRequest - conn=4 op=3 repl="dc=example,dc=com": Begin incremental protocol
[time_stamp] - DEBUG - csngen_adjust_time - gen state before 592c10e30001:1496060130:0:1
[time_stamp] - DEBUG - csngen_adjust_time - gen state after 592c10e40001:1496060130:1:1
[time_stamp] - DEBUG - NSMMReplicationPlugin - replica_get_exclusive_access - conn=4 op=3 repl="dc=example,dc=com": Acquired replica
[time_stamp] - DEBUG - NSMMReplicationPlugin - release_replica - agmt="cn=meTo_localhost:39001" (localhost:39001): Successfully released consumer
[time_stamp] - DEBUG - NSMMReplicationPlugin - conn_start_linger -agmt="cn=meTo_localhost:39001" (localhost:39001) - Beginning linger on the connection
[time_stamp] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTo_localhost:39001" (localhost:39001): State: sending_updates -> wait_for_changes
[time_stamp] - DEBUG - NSMMReplicationPlugin - multimaster_extop_StartNSDS50ReplicationRequest - conn=4 op=3 repl="dc=example,dc=com": StartNSDS90ReplicationRequest: response=0 rc=0
[time_stamp] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_relinquish_exclusive_access - conn=4 op=3 Relinquishing consumer connection extension
[time_stamp] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_acquire_exclusive_access - conn=4 op=4 Acquired consumer connection extension
[time_stamp] - DEBUG - NSMMReplicationPlugin - replica_relinquish_exclusive_access - conn=4 op=4 repl="dc=example,dc=com": Released replica held by locking_purl=conn=4 id=3
[time_stamp] - DEBUG - NSMMReplicationPlugin - consumer_connection_extension_relinquish_exclusive_access - conn=4 op=4 Relinquishing consumer connection extension

Plug-in (65536)

The plug-in (65536) level records the name of a plug-in and all functions the plug-in calls.

The plug-in level log has the following format: 

[time_stamp] plug-in_name - message
[time_stamp] - function - message

The returned information can contain hundreds of lines because Directory Server processes every step. The precise recorded information depends on the plug-in itself. In the following example, the ACL Plug-in includes a connection and operation number: 

[time_stamp] - DEBUG - NSACLPlugin - acl_access_allowed - conn=15 op=1 (main): Allow search on entry(cn=replication,cn=config): root user

Config file processing (64)

The configuration file processing log level goes through each .conf file the server uses and prints every line when the server starts up. You can use the 64 log level to debug any problems with files outside of the server normal configuration. By default, only the slapd-collations.conf file, which contains configurations for international language sets, is available.

Example of the config file processing (64) level: 

[time_stamp] - DEBUG - collation_read_config - Reading config file /etc/dirsrv/slapd-supplier_1/slapd-collations.conf
[time_stamp] - DEBUG - collation-plugin - collation_read_config - line 16: collation "" "" "" 1 3	2.16.840.1.113730.3.3.2.0.1	default
[time_stamp] - DEBUG - collation-plugin - collation_read_config - line 17: collation ar "" "" 1 3	2.16.840.1.113730.3.3.2.1.1	ar
[time_stamp] - DEBUG - collation-plugin - collation_read_config - line 18: collation be "" "" 1 3	2.16.840.1.113730.3.3.2.2.1	be	be-BY
...

Access control list processing (128) and Access control summary (262144)

Both of the ACI logging levels record information that other log levels do not include and contain a connection number (conn) and an operation number (op). The access control list processing (128) shows the series of functions called in the course of the bind and any other operations. The access control summary (262144) records the name of the plug-in, the bind DN of the user, the performed or attempted operation, and the applied ACI.

Example of the access control summary (262144) level: 

[time_stamp] - DEBUG - NSACLPlugin - acllist_init_scan - Failed to find root for base: cn=features,cn=config
[time_stamp] - DEBUG - NSACLPlugin - acllist_init_scan - Failed to find root for base: cn=config
[time_stamp] - DEBUG - NSACLPlugin - acl_access_allowed - ## conn=6 op=1 binddn="cn=user,ou=people,dc=example,dc=com"
[time_stamp] - DEBUG - NSACLPlugin -                  RESOURCE INFO STARTS
[time_stamp] - DEBUG - NSACLPlugin -     Client DN: cn=user,ou=people,dc=example,dc=com
[time_stamp] - DEBUG - NSACLPlugin -     resource type:256(search target_DN )
[time_stamp] - DEBUG - NSACLPlugin -     Slapi_Entry DN: cn=features,cn=config
[time_stamp] - DEBUG - NSACLPlugin -     ATTR: objectClass
[time_stamp] - DEBUG - NSACLPlugin -     rights:search
[time_stamp] - DEBUG - NSACLPlugin -                  RESOURCE INFO ENDS
[time_stamp] - DEBUG - NSACLPlugin - acl__scan_for_acis - Num of ALLOW Handles:0, DENY handles:0
[time_stamp] - DEBUG - NSACLPlugin - print_access_control_summary - conn=6 op=1 (main): Deny search on entry(cn=features,cn=config).attr(objectClass) to cn=user,ou=people,dc=example,dc=com: no aci matched the resource

Other logging levels

Many other logging levels have the output format that is similar to the plug-in logging level. The only difference is in recorded internal operations.

Logging levels, such as Heavy trace output (4), access control list processing (128), schema parsing (2048), and housekeeping (4096) levels, record the called functions when Directory Server performs different operations. In addition, the error log writes why Directory Server calls these functions for specified operations.

11.3. Audit log reference

The audit log records changes made to each database and to the server configuration. This log type is not enabled by default. If you enable audit logging, Directory Server records only successful operations to the audit log file. However, you can record failing operations to a separate file if you enable audit fail logging.

Unlike the error and access log, the audit log does not record access to the server instance, so searches against the database are not logged.

The format of the the audit log differs from the access and error logs format. Directory Server records operations in the audit log in the LDIF statements: 

timestamp: date
dn: modified_entry
changetype: action
action:attribute
attribute:new_value
-
replace: modifiersname
modifiersname: dn
-
replace: modifytimestamp
modifytimestamp: date
-

For more details about the LDIF files and formats see LDAP Data Interchange Format

The audit log example: 

... modifying an entry ...
time: 20200108181429
dn: uid=scarter,ou=people,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: {SSHA}8EcJhJoIgBgY/E5j8JiVoj6W3BLyj9Za/rCPOw==
-
replace: modifiersname
modifiersname: cn=Directory Manager
-
replace: modifytimestamp
modifytimestamp: 20200108231429Z
-

... sending a replication update ...
time: 20200109131811
dn: cn=example2,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: modify
replace: nsds5BeginReplicaRefresh
nsds5BeginReplicaRefresh: start
-
replace: modifiersname
modifiersname: cn=Directory Manager
-
replace: modifytimestamp
modifytimestamp: 20200109181810Z
-

Additional resources

11.4. Audit fail log reference

If you enable fail audit logging, Directory Server starts to record only failing changes made to the server instance to the audit fail log file.

The audit fail log has the same format as the audit log and looks like LDIF statements and is not enabled by default.

Additional resources

11.5. Security log reference

The security log records a variety of security events, including the following:

  • Authentication events
  • Authorization issues
  • DoS and TCP attacks

Directory Server stores the security log in the /var/log/dirsrv/slapd-instance_name/ directory along with other log files. The security log does not rotate quickly and consumes less disk resources in comparison to the access log that has all the information, but requires expensive parsing to get the security data.

The security log is in JSON format and enables other tooling to do the complex parsing of the log. You cannot change the log format or set a log level for the security log.

The security log example: 

{ “date”: “[time_stamp] “, “utc_time”: “1684155510.154562500", “event”: “BIND_SUCCESS”, “dn”: “cn=directory manager”, “bind_method”: “LDAPI”, “root_dn”: true, “client_ip”: “local”, “server_ip”: “\/run\/slapd-instance_name.socket”, “ldap_version”: 3, “conn_id”: 1, “op_id”: 0, “msg”: “” }
{ “date”: “[time_stamp] “, “utc_time”: “1684155510.163790695", “event”: “BIND_SUCCESS”, “dn”: “cn=directory manager”, “bind_method”: “LDAPI”, “root_dn”: true, “client_ip”: “local”, “server_ip”: “\/run\/slapd-instance_name.socket”, “ldap_version”: 3, “conn_id”: 2, “op_id”: 0, “msg”: “” }
{'date': '[time_stamp]', 'utc_time': '168485945', 'event': 'BIND_FAILED', 'dn': 'uid=mark,ou=people,dc=example,dc=com', 'bind_method': 'SIMPLE', 'root_dn': 'false', 'client_ip': '127.0.0.1', 'server_ip': '127.0.0.1', 'conn_id': '2', 'op_id': '1', 'msg': 'INVALID_PASSWORD'}
{'date': '[time_stamp]', 'utc_time': '168499999', 'event': 'BIND_FAILED', 'dn': 'uid=mike,ou=people,dc=example,dc=com', 'bind_method': 'SIMPLE', 'root_dn': 'false', 'client_ip': '127.0.0.1', 'server_ip': '127.0.0.1', 'conn_id': '7', 'op_id': '1', 'msg': 'NO_SUCH_ENTRY'}
{"date": "[time_stamp]", "utc_time": 1657907429, "event": "TCP_ERROR", "client_ip": "::1", "server_ip": "::1", "ldap_version": 3, "conn_id": 1, "msg": "Bad Ber Tag or uncleanly closed connection - B1"}

The log example shows that two binds to the server were successful, two binds failed, and one event is a TCP error.

In addition, when you configure the two-factor authentication for user accounts by using a pre-bind authentication plug-in, the security log records the bind method, for example: 

{ "date": "[time_stamp] ", "utc_time": "1709327649.232748932", "event": "BIND_SUCCESS", "dn": "uid=djoe,ou=people,dc=example,dc=com", "bind_method": "SIMPLE\/MFA", "root_dn": false, "client_ip": "::1", "server_ip": "::1", "ldap_version": 3, "conn_id": 1, "op_id": 0, "msg": "" }

Note that for the secutiry log to record such messages, the pre-bind authentication plug-in must set the flag if a bind was part of this plug-in by using the SLAPI API.

Additional resources

11.6. LDAP result codes

Directory Server uses the following LDAP result codes the log files:

Decimal valuesHex valuesConstants

0

0x00

LDAP_SUCCESS

1

0x01

LDAP_OPERATIONS_ERROR

2

0x02

LDAP_PROTOCOL_ERROR

3

0x03

LDAP_TIMELIMIT_EXCEEDED

4

0x04

LDAP_SIZELIMIT_EXCEEDED

5

0x05

LDAP_COMPARE_FALSE

6

0x06

LDAP_COMPARE_TRUE

7

0x07

LDAP_AUTH_METHOD_NOT_SUPPORTED LDAP_STRONG_AUTH_NOT_SUPPORTED

8

0x08

LDAP_STRONGER_AUTH_REQUIRED LDAP_STRONG_AUTH_REQUIRED

9

0x09

LDAP_PARTIAL_RESULTS

10

0x0a

LDAP_REFERRAL (LDAPv3)

11

0x0b

LDAP_ADMINLIMIT_EXCEEDED

12

0x0c

LDAP_UNAVAILABLE_CRITICAL_EXTENSION

13

0x0d

LDAP_CONFIDENTIALITY_REQUIRED

14

0x0e

LDAP_SASL_BIND_IN_PROGRESS

16

0x10

LDAP_NO_SUCH_ATTRIBUTE

17

0x11

LDAP_UNDEFINED_TYPE

18

0x12

LDAP_INAPPROPRIATE_MATCHING

19

0x13

LDAP_CONSTRAINT_VIOLATION

20

0x14

LDAP_TYPE_OR_VALUE_EXISTS

21

0x15

LDAP_INVALID_SYNTAX

32

0x20

LDAP_NO_SUCH_OBJECT

33

0x21

LDAP_ALIAS_PROBLEM

34

0x22

LDAP_INVALID_DN_SYNTAX

35

0x23

LDAP_IS_LEAF (not used in LDAPv3)

36

0x24

LDAP_ALIAS_DEREF_PROBLEM

48

0x30

LDAP_INAPPROPRIATE_AUTH

49

0x31

LDAP_INVALID_CREDENTIALS

50

0x32

LDAP_INSUFFICIENT_ACCESS

51

0x33

LDAP_BUSY

52

0x34

LDAP_UNAVAILABLE

53

0x35

LDAP_UNWILLING_TO_PERFORM

54

0x36

LDAP_LOOP_DETECT

60

0x3c

LDAP_SORT_CONTROL_MISSING

61

0x3d

LDAP_INDEX_RANGE_ERROR

64

0x40

LDAP_NAMING_VIOLATION

65

0x41

LDAP_OBJECT_CLASS_VIOLATION

66

0x42

LDAP_NOT_ALLOWED_ON_NONLEAF

67

0x43

LDAP_NOT_ALLOWED_ON_RDN

68

0x44

LDAP_ALREADY_EXISTS

69

0x45

LDAP_NO_OBJECT_CLASS_MODS

70

0x46

LDAP_RESULTS_TOO_LARGE (reserved for CLDAP)

71

0x47

LDAP_AFFECTS_MULTIPLE_DSAS

76

0x4C

LDAP_VIRTUAL_LIST_VIEW_ERROR

80

0x50

LDAP_OTHER

81

0x51

LDAP_SERVER_DOWN

82

0x52

LDAP_LOCAL_ERROR

83

0x53

LDAP_ENCODING_ERROR

84

0x54

LDAP_DECODING_ERROR

85

0x55

LDAP_TIMEOUT

86

0x56

LDAP_AUTH_UNKNOWN

87

0x57

LDAP_FILTER_ERROR

88

0x58

LDAP_USER_CANCELLED

89

0x59

LDAP_PARAM_ERROR

90

0x5A

LDAP_NO_MEMORY

91

0x5B

LDAP_CONNECT_ERROR

92

0x5C

LDAP_NOT_SUPPORTED

93

0x5D

LDAP_CONTROL_NOT_FOUND

94

0x5E

LDAP_MORE_RESULTS_TO_RETURN

95

0x5F

LDAP_MORE_RESULTS_TO_RETURN

96

0x60

LDAP_CLIENT_LOOP

97

0x61

LDAP_REFERRAL_LIMIT_EXCEEDED

118

0x76

LDAP_CANCELLED