Organizations often need several applications to look up the same users, groups and directory records. OpenLDAP provides a directory server that stores those records and answers requests using LDAP, a standard protocol for directory access. Applications can use it to check credentials or retrieve account and group information instead of maintaining every record independently. Running the service means managing its schemas, permissions and replication as well as the entries themselves; recovering the data without its configuration may leave applications unable to use it.
Current guidance
OpenLDAP provides the slapd directory server and associated tools; a container image and Helm chart are separate packaging choices. The current administrator guide documents backups using LMDB-aware copying or LDIF exports with slapcat. It specifically warns that a live export can be inconsistent from an application’s perspective when a workflow spans several LDAP operations.
Inventory directory suffixes, schemas, access-control rules, TLS material and replication configuration alongside entries. Preserve configuration as well as user data, and verify that the target server supports the required modules and schema definitions. Do not copy an old database directory into an arbitrary newer image and assume compatibility.
Rehearse the documented export/import or upgrade path in isolation, then test binds, searches, group membership and authorization with ordinary application accounts. Protect backups because directory entries can include credential material and sensitive organizational information. Coordinate writes if the application needs a consistent snapshot, and plan multi-provider deployments separately from a single-server example. This review identifies recovery constraints without certifying an image, chart or replicated directory migration.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
OpenLDAP is a free, open source implementation of the Lightweight Directory Access Protocol (LDAP) developed by the OpenLDAP Project. It is released under its own BSD-style license called the OpenLDAP Public License.
LDAP is a platform-independent protocol. Several common Linux distributions include OpenLDAP Software for LDAP support. The software also runs on BSD-variants, as well as AIX, Android, HP-UX, macOS, Solaris, Microsoft Windows (NT and derivatives, e.g. 2000, XP, Vista, Windows 7, etc.), and z/OS.
Prerequisites Details
- Kubernetes 1.8+
- PV support on the underlying infrastructure
Components
OpenLDAP has three main components:
- slapd – stand-alone LDAP daemon and associated modules and tools
- libraries implementing the LDAP protocol and ASN.1 Basic Encoding Rules (BER)
- client software: ldapsearch, ldapadd, ldapdelete, and others
- Additionally, the OpenLDAP Project is home to a number of subprojects:
- JLDAP – LDAP class libraries for Java
- JDBC-LDAP – Java JDBC – LDAP Bridge driver
- ldapc++ – LDAP class libraries for C++
- Fortress – Role-based identity access management Java SDK
- LMDB – Memory-mapped database library
Backends
Overall concept
Historically the OpenLDAP server (slapd, the Standalone LDAP Daemon) architecture was split between a frontend which handles network access and protocol processing, and a backend which deals strictly with data storage. This split design was a feature of the original University of Michigan code written in 1996[9] and carried on in all subsequent OpenLDAP releases. The original code included one main database backend and two experimental/demo backends. The architecture is modular and many different backends are now available for interfacing to other technologies, not just traditional databases.
Note: In older (1.x) releases, the terms “backend” and “database” were often used interchangeably. To be precise, a “backend” is a class of storage interface, and a “database” is an instance of a backend. The slapd server can use arbitrarily many backends at once and can have arbitrarily many instances of each backend (i.e., arbitrarily many databases) active at once.
Available backends
Currently, 17 different backends are provided in the OpenLDAP distribution, and various third parties are known to maintain other backends independently. The standard backends are loosely organized into three different categories:
- Data storage backends – these actually store data
- back-bdb: the first transactional backend for OpenLDAP, built on Berkeley DB
- back-hdb: a variant of back-bdb that is fully hierarchical and supports subtree renames
- back-ldif: built on plain text LDIF files
- back-mdb: a transactional backend built on OpenLDAP’s Lightning Memory-Mapped Database (LMDB)
- back-ndb: a transactional backend built on MySQL’s NDB cluster engine
- Proxy backends – these act as gateways to other data storage systems
- back-ldap: simple proxy to other LDAP servers
- back-meta: proxy with meta-directory features
- back-passwd: uses a Unix system’s passwd and group data
- back-relay: internally redirects to other slapd backends
- back-sql: talks to arbitrary SQL databases
- Dynamic backends – these generate data on the fly
- back-config: slapd configuration via LDAP
- back-dnssrv: Locates LDAP servers via DNS
- back-monitor: slapd statistics via LDAP
- back-null: a sink/no-op backend, analogous to Unix /dev/null
- back-perl: invokes arbitrary perl modules in response to LDAP requests
- back-shell: invokes shell scripts for LDAP requests
- back-sock: forwards LDAP requests over IPC to arbitrary daemons
Some backends available in older OpenLDAP releases have been retired from use, most notably back-ldbm which was inherited from the original UMich code, and back-tcl which was similar to back-perl and back-shell.
Support for other backends will soon be withdrawn as well. back-ndb is deprecated now since the partnership with MySQL that led to its development was terminated by Oracle after Oracle acquired MySQL. back-bdb and back-hdb will be deprecated in favor of back-mdb soon since back-mdb is superior in all aspects of performance, reliability, and manageability.
In practice, backends like -perl, -shell, and -sock allow interfacing to any arbitrary programming language, thus providing limitless capabilities for customization and expansion. In effect the slapd server becomes an RPC engine with a compact, well-defined and ubiquitous API.
Overlays
Overall concept
Ordinarily an LDAP request is received by the frontend, decoded, and then passed to a backend for processing. When the backend completes a request, it returns a result to the frontend, which then sends the result to the LDAP client. An overlay is a piece of code that can be inserted between the frontend and the backend. It is thus able to intercept requests and trigger other actions on them before the backend receives them, and it can also likewise act on the backend’s results before they reach the frontend. Overlays have complete access to the slapd internal APIs, and so can invoke anything the frontend or other backends could perform. Multiple overlays can be used at once, forming a stack of modules between the frontend and the backend.
Overlays provide a simple means to augment the functionality of a database without requiring that an entirely new backend be written, and allow new functionalities to be added in compact, easily debuggable and maintainable modules. Since the introduction of the overlay feature in OpenLDAP 2.2 many new overlays have been contributed by the OpenLDAP community.
Available overlays
Currently, there are 21 overlays in the core OpenLDAP distribution, with another 15 overlays in the user-contributed code section, and more awaiting approval for inclusion.
The core overlays include:
- accesslog: log server activity in another LDAP database, for LDAP-accessible logging
- auditlog: log server activity in a flat text file
- chain: intercept referrals and chain them instead; code is part of back-ldap
- collect: implement X.500-style collective attributes (aka Netscape Class Of Service)
- constraint: restrict the acceptable values for particular attributes
- dds: dynamic data service – short-lived, self-expiring entries
- deref: return information about entries referenced in a given search result
- dyngroup: simple dynamic group support
- dynlist: more sophisticated dynamic group support plus more
- memberof: support for memberOf and similar backlink attributes
- pcache: cache search results, mainly to improve performance for proxied servers
- ppolicy: LDAP Password Policy – password quality, expiration, etc.
- refint: referential integrity
- retcode: set predetermined return codes for various operations; used for client debugging
- rwm: rewrite module, for various alterations of LDAP data
- seqmod: serialize writes to individual entries
- sssvlv: Server Side Sorting and Virtual List Views
- syncprov: Syncrepl Provider, implements the master side of a replication agreement
- translucent: Semi-transparent pass-through, for locally augmenting data on a proxied server
- unique: for enforcing uniqueness of attribute values within a tree
- valsort: maintain various sort orders for values of an attribute
The contrib overlays include:
- addpartial: receive Add requests and turn them into Modifies if the target entry already exists
- allop: returns all operational attributes, for clients that don’t know how to request them
- autogroup: dynamically managed static groups
- cloak: hide attributes unless explicitly requested in a search
- denyop: reject arbitrarily configured requests
- dupent: return multivalued results as separate entries
- lastbind: record the timestamp of a user’s last successful authentication
- lastmod: maintain the timestamp of the last change within a tree
- nops: filter out redundant modifies
- noopsrch: count entries that would be returned by a search
- nssov: Answer NSS and PAM requests directly in slapd, replaces nss-ldap and pam-ldap.
- proxyOld: support an obsolete encoding of ProxyAuthz used by Sun et al.
- smbk5pwd: Maintain Samba and Kerberos passwords
- trace: Log every LDAP request and response
- usn: Update Sequence Numbers (as in Microsoft AD, not yet released)
Sources & further reading
Spotted something that needs another look?
Help improve this page →