S 4.407 Logging when using OpenLDAP

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

Since OpenLDAP is normally an integral component of a network, activities in OpenLDAP require logging and monitoring in order to detect technical issues or attempted attacks prematurely, for example. For OpenLDAP there are several options for creating event logs and monitoring the current system status.

The log files must be analysed regularly taking into consideration organisational specifications in order to detect misuse and system errors. When logging and monitoring a directory service used for user administration, personal data suitable for performance or behaviour control is collected as a matter of necessity. If logging and monitoring are configured, the Data Protection Officer (see also S 2.110 Data protection guidelines for logging procedures) and the competent workers' council should therefore be involved. Analysis may be manual or with the help of a tool. Critical events should be defined in advance as such events the occurrence of which requires a notification of an administrator.

Debug and Syslog

The slapd server has a Debug feature for identifying technical errors in particular. This function is used when the slapd server is started with the parameter "-d":

slapd -d [Loglevel] -d [Loglevel] ....

When starting the slapd server with the parameter "-d", the slapd server, contrary to a query being placed without Debug feature, is not disconnected from the terminal placing the query and executed continuously in the foreground. The Debug messages are displayed using the default output, normally this is the terminal placing the query.

The slapd server is also able to direct the Debug outputs to the Syslog system service also serving as a basis for other central monitoring tools. Instead of parameter "-d", parameter "-s" must be used during the query; the figures and aliases of the Loglevel remain the same. The same result is achieved by specifying the Loglevel in the global directive "logLevel" (slapd.conf) and/or "olcLogLevel" (slapd-config). Syslog or other central tools are particularly recommended for large structures, because events can hardly be controlled manually there. However, in the event of acute technical issues, the Debug feature in the console is more helpful, because Syslog often provides current events in a delayed manner at increasing load or does not process some messages if the number of messages is too high.

Along with the search for an acute technical error, the technical logs are suitable for identifying configuration inadequacies that have not been discovered so far. For example, if the logs indicate that a certain attribute without an index (index_param failed) is searched for frequently, a corresponding index should be created in order to avoid complex search processes.

The Debug feature is not suitable for logging the technical utilisation of the directory service. Therefore, the outputs should be deleted regularly after having been analysed.

Logging using auditlog

The "auditlog" (Audit Logging) overlay can be used in order to write all changes to a database to a file in the LDIF format. The overlay is only able to log changes and adaptation is difficult. The range of functions is significantly smaller than the one of the newer "accesslog" overlay. The "auditlog" overlay is occasionally used if capturing successful accesses is not necessary and if this is definitely to be avoided due to data protection reasons, for example.

Logging using accesslog

The "accesslog" (Access Logging) overlay can be used to capture all accesses to a database. The overlay is also used within the framework of delta replication. It is necessary to log the changed attributes so that only these must be transmitted to the consumer within the framework of the replication (see S 4.389 Partitioning and replication in OpenLDAP).

The overlay is characterised by the following properties:

The "accesslog" overlay is the best option for creating logs of the technical utilisation of the directive service. This makes particular sense in order to meet regulatory requirements such as the input control of the Federal Data Protection Act (BDSG), for example.

Monitoring via back-monitor

Relevant events such as security incidents are only considered in retrospect in any case when analysing the logs. For a central software such as the directory service, the ongoing operation requires monitoring. For this, OpenLDAP provides the required functions by means of the "back-monitor" backend. Due to the monitoring data requiring protection, a restrictive proprietary ACL should be taken into consideration for the backend (see S 4.387 Secure assignment of access rights to OpenLDAP).

In contrary to most of the other databases, the suffix is fixedly assigned in OpenLDAP. It always is "CN=monitor". "back-monitor" belongs to the class of dynamic backends, meaning that a search with the help of ldapsearch or similar tools does not access a written database, but generates data during the query. However, for the user this is transparent so that the "back-monitor" backend can be queried using the ldapsearch tool of OpenLDAP or graphical interfaces or specific applications for monitoring purposes.

The information made available by the "back-monitor" backend is very comprehensive and grows proportionally with the configured range of functions of OpenLDAP. Therefore, it is recommendable to create a documentation of which values must be considered. For example, reasonable objects for monitoring include:

CN=Backends, CN=Monitor

This suffix provides information about existing backends. The subelements contain information about the respective backend, its status, and the supported features.

CN=Databases, CN=Monitor

"Databases" provides information about configured databases. The subelements contain information about the respective database.

CN=Overlays, CN=Monitor

This subtree provides information about used overlays. The subelements contain information about the respective database.

CN=Connections, CN=Monitor

"Connections" contains information about current connections. The subelements contain the details about a connection in each case. Additionally, there are two special subelements providing information about the number of all (CN=Total, CN=Connections, CN=Monitor) as well as the current connections (CN=Current, CN=Connections, CN=Monitor). The current connections should be checked before stopping the directory service, amongst other things.

CN=Listener, CN=Monitor

This suffix contains information about IP addresses and ports where the slapd server waits for connections. It should be checked regularly that only deliberately configured connection options are active.

CN=Operations, CN=Monitor

"Operations" provides information about initiated and finished operations. The possible output is very comprehensive. Output should be event-related and then filtered according to the corresponding operations such as "bind", "add", "delete". The currently performed operations should be checked before stopping the directory service, amongst other things.

CN=Statistics, CN=Monitor

The subtree provides statistical information about the data transmitted by the server. A history of empirical values should be maintained for the output in order to be able to regularly check for abnormalities.

OpenLDAP monitoring should be associated with monitoring the IT system running OpenLDAP. The functionality of OpenLDAP also mainly depends on the available processor performance and the memory space for the database. These variables are not covered by the monitoring functions of OpenLDAP, however.

Review questions:

© Federal Office for Information Security. All rights reserved.