Chapter 5. Monitoring the LDAP server

Table of Contents

Log files
iPlanet/SunONE
OpenLDAP
Monitoring server performance
iPlanet/SunONE
OpenLDAP monitoring
Monitoring with SNMP
Summary
Exercises

Abstract

This chapter describes the monitoring of server activity. We will discuss the following topics:

  • Different types of log files.

  • Configuring log files.

  • Monitoring the server.

Log files

iPlanet/SunONE

General

The directory server comes with three types of log files:

  • Access logs

  • Error logs

  • Audit logs

In order for your logs not to fill all the available disk space, there are two main configuration tasks to be done: defining when log files will be created, and when they will be deleted. These rules are set in the log file rotation policy, which settles three issues:

  • Total number of log files that is to be kept for a given type. When this number is reached, the oldest log file is deleted and a new log file created.

    This number is by default set to 10. Do not set this value to 1 or your log file will grow as large as the file system on which it is residing.

  • The maximum size for each log file: if logs are not rotated before this amount of MB is reached, they will be rotated anyway. If no maximum size is required, set this value to -1

  • The rotation frequency: by default, logs are rotated every day. The attribute is ignored when set to 1.

In addition, the maximum size of the combined logs (default 500 MB), a minimal amount of disk space to leave free (default 5 MB) and a maximum age of log files (default 1 month) can be configured for all log files of the same type. This is called the log file deletion policy.

The access log

It is advised to have access logging always enabled, since it provides valuable debugging and troubleshooting information. For your convenience, the log level is by default rather high.

The access log can be customized in several ways:

  • Location of the log files. The default is /var/ds5/slapd-your_server/logs/access.

  • The maximum numbers of logs, the log size and the rotation frequency.

  • The maximum size of the combined archived logs, the minimum amount of free disk space and the maximum age.

The error log

The error log contains detailed messages about events that caused errors to happen during normal operation.

You should analyze this file regularly to check that all is well with your server. It gives information about failed requests, which might or might not be caused by potential hackers.

A typical log entry looks like this:

Feb 24 16:15:29 server1 login[1597]: pam_ldap: error trying to bind 
as user "uid=root,ou=People,dc=example,dc=com" (Invalid credentials)

The log entry starts with time and day of the offending event, the name of the server on which it occurred, the name of the program that generated the error and a clear description as to what went wrong.

The error log set can be configured similarly to the access log.

The audit log

The audit log holds detailed information about changes made to each database and to the server configuration. It is not enabled by default.

The audit log takes the same configuration attributes as the access log.

OpenLDAP

The best way here is to grep on the /var/log/slapd-log file. It logs all information the LDAP service has to log. The level of logging is defined in the slapd.conf file or at server startup on the command-line.

[Note] No rotation is enabled by default!

To enable log rotation for LDAP service log files, consult the documentation that comes with the “logrotate” package, it should be fairly easy adding an entry in the /etc/logrotate.d directory.

Analysing the log file can give you a good idea of the filters being applied. As an example, this is generated upon entering the command:

ldapsearch -b "ou=people,dc=example,dc=com" -x "objectclass=*" cn uid

Jul 17 16:53:53 server1 slapd[1010]: daemon: conn=7448 fd=43 connection from IP=127.0.0.1:40629 (IP=:: 389) accepted.
Jul 17 16:53:53 server1 slapd[1010]: conn=7448 op=0 BIND dn="" method=128
Jul 17 16:53:53 server1 slapd[1010]: conn=7448 op=0 RESULT tag=97 err=0 text=
Jul 17 16:53:53 server1 slapd[1010]: conn=7448 op=1 SRCH base="ou=people,dc=example,dc=com" scope=2 filter="(objectClass=*)"
Jul 17 16:53:53 server1 slapd[1010]: conn=7448 op=1 SEARCH RESULT tag=101 err=0 text=
Jul 17 16:53:54 server1 slapd[1010]: conn=7448 op=2 UNBIND
Jul 17 16:53:54 server1 slapd[1010]: conn=-1 fd=43 closed

Logging in to this system, which uses LDAP for authenticating its users, generates even more log information:

 
Jul 17 17:00:14 server1 slapd[1010]: daemon: conn=7453 fd=43 connection from IP=127.0.0.1:40648 (IP=:: 389) accepted.
Jul 17 17:00:14 server1 slapd[1010]: conn=7453 op=0 BIND dn="CN=MANAGER,DC=EXAMPLE,DC=COM" method=128
Jul 17 17:00:14 server1 slapd[1010]: conn=7453 op=0 RESULT tag=97 err=0 text=
Jul 17 17:00:14 server1 slapd[1010]: conn=7453 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=mmichiel)"
Jul 17 17:00:14 server1 slapd[1010]: conn=7453 op=1 SEARCH RESULT tag=101 err=0 text=
Jul 17 17:00:14 server1 slapd[1010]: conn=7453 op=2 SRCH base="ou=Group,dc=example,dc=com" scope=1 filter="(&(objectClass=posixGroup)(|(memberUid=mmichiel)(uniqueMember=uid=mmichiel,ou=People,dc=example,dc=com)))"
Jul 17 17:00:14 server1 slapd[1010]: conn=7453 op=2 SEARCH RESULT tag=101 err=0 text=
Jul 17 17:00:14 server1 slapd[1010]: conn=7453 op=3 SRCH base="ou=People,dc=example,dc=com" scope=1 filter="(&(objectClass=shadowAccount)(uid=mmichiel))"
Jul 17 17:00:14 server1 slapd[1010]: conn=7453 op=3 SEARCH RESULT tag=101 err=0 text=

Each connection to the server is assigned a number, so that multiple entries belonging to the same action can be traced.

The log file(s) also give(s) information about when the server has stopped and started. The amount of information logged is rather high by default, enabling easy debugging of possibly LDAP-related problems.