Ce contenu n'est pas disponible dans la langue sélectionnée.

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
Copier lien

The Red Hat 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
Copier lien

Different levels of access logging record different kinds of operations that Red Hat 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.

11.1.2. Default access log content
Copier lien

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

Connection number (conn)

RHDS 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

RHDS 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 RHDS 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 (op)

To process an LDAP request, RHDS 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. RHDS 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:

Expand

Tag	Description
tag=97	The result from a client bind operation.
tag=100	The actual entry that RHDS 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, RHDS did not find any matching entries.

Elapsed time (etime)

The etime record shows the elapsed time or the amount of time (in seconds) that RHDS 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, RHDS 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

RHDS can issue three LDAP response types:

RESULT means a result to the client LDAP request. 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 RHDS 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 RHDS requires some time to gathers these statistics, the sum of the wtime and optime values are slightly greater than the etime value.
ENTRY means an entry RHDS returns in response to a search operation.
REFERRAL means that the RHDS sends the LDAP request to another server.

Search indicators (note)

RHDS 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

RHDS supports the following search indicators:

Expand

Search indicator	Description
`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, RHDS 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. RHDS 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. RHDS 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. RHDS logs `notes=F` when a search filter contains an unknown attribute.
`notes=M`	MFA plug-in binds indicator. RHDS 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.
`notes=N`	The operation is not synchronous. RHDS logs `notes=N` when applications send asynchronous requests. In this case, you might need to increase the `nsslapd-maxthreadsperconn` attribute value, because asynchronous operations can consume multiple workers.
`notes=B`	The operation blocks other new incoming operations: pending operations, not the read operations, are delayed. Possible workarounds: If you do not expect delays in the operation processing, but the delays happen, you can analyze why the threads are slow by looking at the access logs, enabling some debug error logs, and using the `pstacks` utility. If delayed processing of operations creates issues for your application or the delays do not happen often, you can increase 'nsslapd-maxthreadperconn' and, possibly, 'nsslapd-threadnumber'.

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

When attributes are not indexed, RHDS 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 attribute, see nsslapd-idlistscanlimit.
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), RHDS 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"

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

Expand

Extended operation name	Description	OID
RHDS Start Replication Request	A replication initiator requests a replication session.	2.16.840.1.113730.3.5.3
RHDS 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
RHDS End Replication Request	A replication initiator terminates the replication session.	2.16.840.1.113730.3.5.5
RHDS 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
RHDS Bulk Import Start	A client requests a bulk import together with the imported suffix using the Bulk Import Start operation, and RHDS indicates that the bulk import may begin.	2.16.840.1.113730.3.5.7
RHDS Bulk Import Finished	A client ends a bulk import using the Bulk Import Finished operation, and RHDS 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 RHDS received an update identified by its 'csn' and processed it.

Abandon message (ABANDON)

The abandon message indicates that a client or RHDS 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 RHDS 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 RHDS initiated earlier (op=2).

If RHDS 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 RHDS 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 op value; however, it identifies the same operation. RHDS 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 RHDS operation number op 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 RHDS op plus 1.

SASL multi-stage bind logging

RHDS 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. RHDS 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, RHDS logs the authenticated DN (the DN used for access control decisions) in the bind RESULT line when RHDS 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"

Session tracking identifier (sid)

In a replication topology, the RHDS consumer server records a session tracking identifier (sid) to the access log to identify which supplier server made changes to a database.

[03/Nov/2025:04:35:47.979787866 -0500] conn=1 op=3 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multisupplier-extop"
[03/Nov/2025:04:35:48.036592751 -0500] conn=1 op=3 RESULT err=0 tag=120 nentries=0 wtime=0.000135269 optime=0.056815411 etime=0.056949037 sid="u5aM64k2pxZ 3"

[03/Nov/2025:04:35:48.308889287 -0500] conn=1 op=5 MOD dn="uid=demo_user,ou=people,dc=example,dc=com"
[03/Nov/2025:04:35:48.350994382 -0500] conn=1 op=5 RESULT err=0 tag=103 nentries=0 wtime=0.000157697 optime=0.042113370 etime=0.042269379 csn=69087772000000010000 sid="u5aM64k2pxZ 3"
[03/Nov/2025:04:35:48.603323146 -0500] conn=1 op=6 EXT oid="2.16.840.1.113730.3.5.5" name="replication-multisupplier-extop"
[03/Nov/2025:04:35:48.634094566 -0500] conn=1 op=6 RESULT err=0 tag=120 nentries=0 wtime=0.000089355 optime=0.030776954 etime=0.030864266 sid="u5aM64k2pxZ 3"

11.1.3. Non-default access log content
Copier lien

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
Copier lien

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

Expand

Connection Code	Description
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`.
T3	The server closed the connection because the specified time limit for a paged result search has been exceeded.
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.

11.2. Error log reference
Copier lien

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

11.2.1. Error logging levels
Copier lien

The error log can record different details of the Red Hat 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.

Expand

Table 11.1. Error log levels
Setting	Console name	Description
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.

11.2.2. Default error log content
Copier lien

The default error log content contains basic information about an error event: time stamp, severity level, and a message.

Either a server or a plugin 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 plugin 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:

Expand

Log message	Description
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.
Plugin 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
...

11.2.3. Non-default error log content
Copier lien

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

On a supplier server, a replication agreement generates a session tracking identifier (sid), which is then recorded in the error log to specify which supplier sends requests to a consumer. The replication agreement adds sid to each request it sends. The following is an example of log messages with sid.

[03/Nov/2025:04:35:48.045087151 -0500] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - sid="u5aM64k2pxZ 3" - agmt="cn=002" (prereserve-1mt-rhel-10:39002): State: backoff -> sending_updates
[03/Nov/2025:04:35:48.094419605 -0500] - DEBUG - NSMMReplicationPlugin - replay_update - sid="u5aM64k2pxZ 3" - agmt="cn=002" (prereserve-1mt-rhel-10:39002): Sending modify operation (dn="uid=demo_user,ou=people,dc=example,dc=com" csn=69087772000000010000)
[03/Nov/2025:04:35:48.097990796 -0500] - DEBUG - NSMMReplicationPlugin - replay_update - sid="u5aM64k2pxZ 3" - agmt="cn=002" (prereserve-1mt-rhel-10:39002): Receiver successfully sent operation with csn 69087772000000010000
[03/Nov/2025:04:35:48.112957117 -0500] - DEBUG - NSMMReplicationPlugin - send_updates - sid="u5aM64k2pxZ 3" - agmt="cn=002" (prereserve-1mt-rhel-10:39002): No more updates to send (cl5GetNextOperationToReplay)

[03/Nov/2025:04:35:48.440553764 -0500] - DEBUG - NSMMReplicationPlugin - repl5_inc_waitfor_async_results - sid="u5aM64k2pxZ 3" - 6 6
[03/Nov/2025:04:35:48.721498133 -0500] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - sid="u5aM64k2pxZ 3" - agmt="cn=002" (prereserve-1mt-rhel-10:39002): State: sending_updates -> wait_for_changes

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
Copier lien

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, Red Hat Directory Server (RHDS) 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 audit log differs from the access and error logs format. RHDS 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

Configuring log files

11.4. Audit fail log reference
Copier lien

The audit fail log records only failing changes made to the server instance.

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

Configuring log files

11.5. Security log reference
Copier lien

The security log records a variety of security events, including authentication events, authorization issues, DoS and TCP attacks.

Red Hat 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

Configuring log files

11.6. LDAP result codes
Copier lien

LDAP result codes indicate the outcome of operations recorded in Red Hat Directory Server log files.

Expand

Decimal values	Hex values	Constants
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

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 11. Log files reference

11.1. Access log reference
Copier lien

11.1.1. Access logging levels
Copier lien

11.1.2. Default access log content
Copier lien

11.1.3. Non-default access log content
Copier lien

11.1.4. Common connection codes
Copier lien

11.2. Error log reference
Copier lien

11.2.1. Error logging levels
Copier lien

11.2.2. Default error log content
Copier lien

11.2.3. Non-default error log content
Copier lien

11.3. Audit log reference
Copier lien

11.4. Audit fail log reference
Copier lien

11.5. Security log reference
Copier lien

11.6. LDAP result codes
Copier lien

Apprendre

Essayez, achetez et vendez

Communautés

À propos de Red Hat

Rendre l’open source plus inclusif

À propos de la documentation Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 11. Log files reference

11.1. Access log referenceCopier lienLien copié sur presse-papiers!

11.1.1. Access logging levelsCopier lienLien copié sur presse-papiers!

11.1.2. Default access log contentCopier lienLien copié sur presse-papiers!

11.1.3. Non-default access log contentCopier lienLien copié sur presse-papiers!

11.1.4. Common connection codesCopier lienLien copié sur presse-papiers!

11.2. Error log referenceCopier lienLien copié sur presse-papiers!

11.2.1. Error logging levelsCopier lienLien copié sur presse-papiers!

11.2.2. Default error log contentCopier lienLien copié sur presse-papiers!

11.2.3. Non-default error log contentCopier lienLien copié sur presse-papiers!

11.3. Audit log referenceCopier lienLien copié sur presse-papiers!

11.4. Audit fail log referenceCopier lienLien copié sur presse-papiers!

11.5. Security log referenceCopier lienLien copié sur presse-papiers!

11.6. LDAP result codesCopier lienLien copié sur presse-papiers!

Apprendre

Essayez, achetez et vendez

Communautés

À propos de Red Hat

Rendre l’open source plus inclusif

À propos de la documentation Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

11.1. Access log reference
Copier lien

11.1.1. Access logging levels
Copier lien

11.1.2. Default access log content
Copier lien

11.1.3. Non-default access log content
Copier lien

11.1.4. Common connection codes
Copier lien

11.2. Error log reference
Copier lien

11.2.1. Error logging levels
Copier lien

11.2.2. Default error log content
Copier lien

11.2.3. Non-default error log content
Copier lien

11.3. Audit log reference
Copier lien

11.4. Audit fail log reference
Copier lien

11.5. Security log reference
Copier lien

11.6. LDAP result codes
Copier lien