Learn LDAP - Audit Logging & Monitoring

#Introduction

In episode 17 you built SASL authentication all the way to the system level. Now the operation needs to see what the server is doing. Episode 18 covers audit logging and monitoring: how slapd writes logs, the overlays that record access and change history, the cn=Monitor statistics, and how all of it connects to tools like SNMP and Prometheus.

#Why Log and Monitor

A directory without logging is a black box. Proper logging and monitoring give you:

• Security auditing — who accessed what, from where, and when; bind failures are the first sign of a password attack.
• Troubleshooting — when something breaks, the log is the starting point to find out what happened.
• Performance analysis — search, bind, and operation counts reveal load patterns and bottlenecks.
• Compliance — many regulations (see episode 29) demand an access record that's complete and retained.

Without logs, a compromise is discovered too late and cannot be reconstructed.

#Slapd Log Levels

slapd produces logs in its stats level set. Log levels are selected with olcLogLevel in cn=config:

For production, a good balance is stats (and sync on replication servers). Start from there; enable more only while troubleshooting.

Setting the log level

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats

#Logging Configuration

Where the logs go depends on the system service manager. Under systemd, slapd logs to the journal (journalctl -u slapd). To separate logs, configure rsyslog to route slapd output to its own file and rotate it with logrotate:

local4.*    /var/log/slapd/slapd.log

/var/log/slapd/slapd.log {
    weekly
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 0640 syslog adm
}

Proper rotation prevents the disk from filling up and preserves history for audit.

#The auditlog Overlay

The auditlog overlay writes every write operation (add, modify, delete) as an LDIF entry to a text file — a real audit trail of who changed what:

Enabling the auditlog overlay

dn: cn=module{0},cn=config
objectClass: olcModuleList
olcModulePath: /usr/lib/ldap
olcModuleLoad: auditlog.la
 
dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
olcAuditlogFile: /var/log/slapd/auditlog.log

Each change is appended to olcAuditlogFile with the timestamp, the operator DN, and the full LDIF of the operation. This is the primary data source for compliance and internal audits.

#The accesslog Overlay

accesslog (already mentioned in episode 13 for delta-syncrepl) records every access to every entry in a special database, cn=accesslog. Unlike auditlog, which writes to a file, accesslog is a directory database that can be queried and indexed:

Enabling the accesslog overlay

dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
olcDatabase: mdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcDbIndex: reqStart eq
olcDbIndex: entryCSN eq
olcDbIndex: objectClass eq
 
dn: olcOverlay=accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogSuccess: TRUE

Searching it:

ldapsearch -x -D cn=admin,dc=example,dc=com -W \
  -b cn=accesslog "(reqDN=uid=budi,ou=people,dc=example,dc=com)" \
  reqStart reqDN reqMod

The difference from auditlog: accesslog keeps historical state of attributes (useful for forensics and replication) while auditlog is a simpler, human-readable file for auditing.

#cn=Monitor

cn=Monitor is the built-in monitoring database. It doesn't store user data — it publishes live statistics about the server. With the database enabled:

Enabling the monitor database

dn: olcDatabase=monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: monitor
olcMonitorConfig: FALSE

Reading statistics:

ldapsearch -x -D cn=admin,dc=example,dc=com -W \
  -b cn=Connections,cn=Monitor \
  monitorConnectionCurrent monitorConnectionTotal
ldapsearch -x -D cn=admin,dc=example,dc=com -W \
  -b cn=Statistics,cn=Monitor \
  monitorOpInitiated monitorOpCompleted

monitorConnectionTotal shows how many connections ever opened; monitorOpInitiated and monitorOpCompleted show operation activity. These numbers are the basis for dashboards and capacity planning.

#SNMP and Prometheus

To reach the operations team's monitoring tools:

• SNMP — slapd can export monitoring data via an agent (snmpd with slapd MIB). Query it with snmpget/snmpwalk, then collect with Zabbix, Nagios, etc.
• Prometheus — a Prometheus exporter for OpenLDAP reads cn=Monitor and exposes metrics like openldap_connections_total and openldap_operations_total, which Grafana then visualizes.

Monitoring suggestions:

curl -s http://localhost:9330/metrics | grep openldap

#Closing

In this episode 18 you understood OpenLDAP logging and monitoring: olcLogLevel levels from stats to trace; log placement and rotation; the auditlog overlay writing every write operation to a file; the accesslog overlay recording access to a queryable database; the cn=Monitor statistics; and integration with SNMP and Prometheus.

Key takeaways:

• Logs first, questions later — stats is the production baseline, sync for replication servers.
• auditlog for audit, accesslog for forensics — each answers a different question.
• cn=Monitor is a live source of truth — connect it to your monitoring stack.
• Rotate or fill the disk — unbounded logs are a ticking bomb.

In the next episode, episode 19, we turn from observing to consuming: Linux system authentication — how NSS, PAM, and SSSD make LDAP users log into Linux systems, with configuration, testing, and troubleshooting.