Browse learn

What Is slapd?

Learn what the OpenLDAP slapd daemon does, how it processes LDAP operations, loads configuration and schemas, secures access, and uses backends.

Type
Concept
Level
Intermediate
Technologies
OpenLDAP, LDAP
On this page

What is slapd? The Core LDAP Daemon Explained

slapd—the Stand-Alone LDAP Daemon—is the core server process of OpenLDAP, responsible for providing all directory services in an OpenLDAP deployment. It is the executable (slapd) that listens on LDAP ports (typically 389 for LDAP and 636 for LDAPS), accepts client connections, interprets LDAP protocol operations, and manages access to directory data. slapd services all reads, writes, authentication attempts, and search queries performed using the LDAP protocol.

Within the OpenLDAP suite, slapd is the directory server daemon. OpenLDAP proper is a broader, multi-component suite that includes libraries, utilities, client tools, and administrative programs; slapd is its main server engine. Thus, while casual conversation often conflates slapd with OpenLDAP, slapd is one component—the critical one that delivers LDAP directory services.

As a standalone daemon, slapd is not a generic term for all directory servers. It refers specifically to the OpenLDAP project's directory server executable. Other directory products (such as 389 Directory Server, ApacheDS, and Active Directory) have their own server processes.

The Architecture of slapd: Components and Workflow

At its core, slapd handles directory requests from clients and routes them through a modular flow:

  • Network Front-End: slapd accepts LDAP client connections over TCP (plain or TLS-secured) and decodes protocol requests such as search, bind (authentication), add, modify, or delete.

  • Access Control Enforcement: Before touching data or returning responses, slapd evaluates access control lists (ACLs) to check client permissions at the entry and attribute level.

  • Schema Validation: All data is checked against LDAP schema rules, which define the allowed structure of entries, attributes, and object classes.

  • Backend Dispatch: Each request is routed to a backend, the engine responsible for actually reading, writing, or manipulating stored data. Backends may represent persistent databases (such as MDB), proxies to other directories, or virtual data views.

  • Overlays: Optionally, additional modules (overlays) can intercept and augment operations for features like replication, access logging, or attribute transformation.

At all times, slapd manages the Directory Information Tree (DIT)—the hierarchical structure anchoring all directory data. Each branch of the DIT corresponds to an LDAP database configured in slapd, and each entry in the tree must comply with registered schema definitions.

Configuring slapd: slapd.conf vs. cn=config (slapd.d)

slapd configuration has evolved significantly. Two primary paradigms exist:

  • slapd.conf (Legacy): Historically, slapd read startup configuration from a single text file (slapd.conf). This file defines global options, schemas, backends, databases, and access controls using a directive-based syntax. This static approach is considered deprecated.

  • cn=config (slapd.d) (Modern): Contemporary OpenLDAP releases (2.3 and later) use an on-disk configuration directory, often called slapd.d, which exposes configuration as an LDAP directory tree rooted at cn=config. This backend represents configuration as LDIF files and supports dynamic, live modification via LDAP operations—without server restarts. All major configuration objects (schemas, backends, ACLs, overlays, logging, and server options) appear as entries in this tree and can be queried, added, or modified using standard LDAP tools.

Best Practice: Use cn=config/slapd.d for all new OpenLDAP installations. While slapd.conf is supported for backward compatibility, it is deprecated and will be removed in future releases.

Important: Never edit the slapd.d/cn=config LDIF files directly. All changes must be made through LDAP operations to avoid corruption or undefined behavior.

Access Control in slapd

Access control in slapd is managed through detailed access control lists (ACLs). These ACLs specify who can access which data, at what privilege level, and for what operations (read, write, search, compare, etc.). ACLs can be set at granular levels—per database, per entry, per attribute, or subtrees within the DIT.

In legacy slapd.conf, ACLs are defined using access directives in the configuration file. In cn=config/slapd.d, ACLs are set as entries in the LDAP configuration tree and modified via LDAP operations.

ACL evaluation is hierarchical and stops at the first matching rule. Options exist to differentiate anonymous users, authenticated users, specific bind DNs, and groups.

A misconception is that ACLs need to grant explicit access to the rootdn (directory manager). In fact, rootdn always bypasses access controls by design. Explicitly granting rootdn access in ACLs is unnecessary and can even degrade performance.

Backends, Overlays, and Directory Storage

slapd's modularity is rooted in its pluggable backends and overlays:

  • Backends: The choice of backend determines where and how data is stored. Common backends include mdb (modern on-disk database), bdb/hdb (older Berkeley DB-based), and various backend types for special use (such as proxy for forwarding, or memory for ephemeral storage). Each database section in the configuration specifies its backend explicitly. Different databases can use different backends simultaneously.

  • Overlays: Overlays are optional modules layered on databases to provide additional functionality. Typical overlays add features like attribute value uniqueness, audit logging, or—critically—replication support (such as the syncprov overlay used with syncrepl). Overlays can be stacked and are applied in order.

The backend and overlays chosen affect storage style, extensibility, and features available to directory clients.

Replication and Scalability: slapd’s Approach

slapd enables multi-server and scalable deployments through its replication subsystem. The primary mechanism is syncrepl, a synchronization replication engine introduced in later OpenLDAP releases.

  • Syncrepl: syncrepl allows a database (or databases) on one slapd instance (the provider) to be kept synchronized with one or more consumers. This can be configured for one-way or multi-way (more complex) replication, enabling high availability and load distribution. syncrepl supports both “refreshOnly” (periodic polling) and “refreshAndPersist” (event-driven push) modes.

Older replication was handled by slurpd, a separate process; this is now obsolete—syncrepl is robust and highly configurable.

Replication is configured per-database and can scale from simple master-slave to complex, multi-master topologies.

Comparing slapd to Other LDAP Servers

slapd is the OpenLDAP server daemon, not a generic LDAP server. While people may refer to any LDAP server daemon loosely as "slapd", technically it is unique to the OpenLDAP project.

Major alternative directory servers include:

  • 389 Directory Server: Uses its own configuration mechanisms; differs in access control and plugin architecture.
  • ApacheDS: A Java-based server with schema and configuration managed differently.
  • Active Directory: Integrated into Microsoft Windows, offers LDAP-like protocol access but with AD-specific schemas, semantics, and management.

slapd's configuration (especially cn=config), backend modularity, and access control language are distinct from those in alternative servers. Plugins and extensibility also differ across products.

Practical Considerations: Logging, Troubleshooting, and Best Practices

slapd includes flexible logging and runtime monitoring. Logging output can be directed to system logs and is configured through the same cn=config or slapd.conf options. Logs cover operational events, access details, and errors. Consult the official OpenLDAP Administrator’s Guide for specifics on adjusting log levels for troubleshooting.

Troubleshooting slapd is best performed using:

  • Log analysis
  • Diagnostics via LDAP tools querying cn=config
  • Reference to authoritative OpenLDAP documentation

Key warnings:

  • Do not edit LDIF files inside slapd.d/cn=config by hand.
  • Favor the cn=config approach and migrate off slapd.conf where practical.
  • Understand backends and overlays before deploying or extending a slapd instance.

Common Misconceptions About slapd

  • Misconception: “slapd and OpenLDAP are the same.”
    Correction: slapd is just the directory server daemon; OpenLDAP is the entire suite including libraries and tools.

  • Misconception: “slapd.conf is the preferred or only way to configure slapd.”
    Correction: slaps.conf is deprecated—use cn=config (slapd.d) for current and future compatibility.

  • Misconception: “All slapd installations use the same backend/database setup.”
    Correction: Backend choice is flexible and should be explicitly configured per-database.

  • Misconception: “It’s safe to hand-edit slapd.d/cn=config LDIF files.”
    Correction: Always modify slapd.d/cn=config through LDAP operations, not direct file editing.

References and Further Reading

For comprehensive and authoritative details on slapd, configuration, access controls, replication, and best practices, consult the following official OpenLDAP documentation:

  • OpenLDAP Software 2.4 Administrator's Guide
  • Configuring slapd (cn=config and slapd.conf)
  • Access Control in slapd
  • LDAP Sync Replication (syncrepl)
  • Introduction to OpenLDAP Directory Services
  • The slapd Configuration File

These resources provide up-to-date, practical, and technically exhaustive coverage for both new deployments and ongoing operations.

Sources

Related resources