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, OpenVMS, Solaris, Microsoft Windows (NT and derivatives, e.g. 2000, XP, Vista, Windows 7, etc.), and z/OS.
History The OpenLDAP project was started in 1998 by Kurt Zeilenga. The project started by cloning the LDAP reference source from the University of Michigan where a long-running project had supported development and evolution of the LDAP protocol until that project's final release in 1996.
, the OpenLDAP project has four core team members: Howard Chu (chief architect), Quanah Gibson-Mount, Hallvard Furuseth, and Kurt Zeilenga. There are numerous other important and active contributors including Ondrej Kuznik, Luke Howard, Ryan Tandy, and Gavin Henry. Past core team members include Pierangelo Masarati.
Components OpenLDAP has four main components: slapd – stand-alone LDAP daemon and associated modules and tools. lloadd - stand-alone LDAP load balancing proxy server 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++ LMDB – memory-mapped database library
Backends Overall concept Historically the OpenLDAP server (slapd, the Standalone LDAP Daemon) architecture was split between a frontend that handles network access and protocol processing, and a backend that deals strictly with data storage. This split design was a feature of the original University of Michigan code written in 1996 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, removed with OpenLDAP 2.5. back-hdb: a variant of back-bdb that is fully hierarchical and supports subtree renames, removed with OpenLDAP 2.5. 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, removed with OpenLDAP 2.6. back-wiredtiger: an experimental transactional backend built on WiredTiger, introduced with OpenLDAP 2.5. Proxy backends – these act as gateways to other data storage systems back-asyncmeta: an asynchronous proxy with meta-directory features, introduced with OpenLDAP 2.5. 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, deprecated with OpenLDAP 2.5. 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, deprecated with OpenLDAP 2.5. back-shell: invokes shell scripts for LDAP requests, removed with OpenLDAP 2.5. 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 removed now since the partnership with MySQL that led to its development was terminated by Oracle after Oracle acquired MySQL. back-bdb and back-hdb have been removed in favor of back-mdb since back-mdb is superior in all aspects of performance, reliability, and manageability.
In practice, backends like -perl 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 from the OpenLDAP community.
Available overlays Currently there are 25 overlays in the core OpenLDAP distribution, with another 24 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 autoca: Automatic Certificate Authority (OpenLDAP 2.5) 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 homedir: Remote home directory provisioning (OpenLDAP 2.5) memberof: support for memberOf and similar backlink attributes otp: allows OATH One-Time Passwords to be used in conjunction with the LDAP user password (OpenLDAP 2.5) pcache: cache search results, mainly to improve performance for proxied servers ppolicy: LDAP Password Policy – password quality, expiration, etc. refint: referential integrity remoteauth: Allows delegation of authentication requests to remote directories. Works with Active Directory. (OpenLDAP 2.5) 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 adremap: remaps attributes for PAM/NSS MS AD support (OpenLDAP 2.5) allop: returns all operational attributes, for clients that don't know how to request them authzid: implements RFC 3829 support (OpenLDAP 2.5) autogroup: dynamically managed static groups cloak: hide attributes unless explicitly requested in a search datamorph: stores enumerated values and fixed size integers (OpenLDAP 2.5) 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. ppm: adds additional password checking criteria to the slapo-ppolicy overlay (OpenLDAP 2.5) proxyOld: support an obsolete encoding of ProxyAuthz used by Sun et al. pw-radius: allows bind operations to be passed to the specified radius server(s) (OpenLDAP 2.5) rbac: intercepts, decodes and enforces specific RBAC policies per the Apache Fortress RBAC data formats (OpenLDAP 2.5) smbk5pwd: Maintain Samba and Kerberos passwords trace: Log every LDAP request and response totp: provides one time password support (OpenLDAP 2.5) usn: Update Sequence Numbers (OpenLDAP 2.5) variant: allows attributes/values to be shared between several entries (OpenLDAP 2.5) vc: provides the verify credentials extended operation (OpenLDAP 2.5)
Other modules Backends and overlays are the two most commonly used types of modules. Backends were typically built into the slapd binary, but they may also be built as dynamically loaded modules, and overlays are usually built as dynamic modules. In addition, slapd supports dynamic modules for implementing new LDAP syntaxes, matching rules, controls, and extended operations, as well as for implementing custom access control mechanisms and password hashing mechanisms.
OpenLDAP also supports SLAPI, the plugin architecture used by Sun and Netscape/Fedora/Red Hat. In current releases, the SLAPI framework is implemented inside a slapd overlay. While many plugins written for Sun/Netscape/Fedora/Red Hat are compatible with OpenLDAP, very few members of the OpenLDAP community use SLAPI.
Available modules Native slapd modules acl/posixgroup – support posixGroup membership in access controls comp_match – support component-based matching kinit – maintain/refresh a Kerberos TGT for slapd passwd/ – additional password hashing mechanisms. Currently includes Kerberos, Netscape, RADIUS, and SHA-2. SLAPI plugins addrdnvalue – add RDN value to an entry if it was omitted in an Add request
Release summary The major (functional) releases of OpenLDAP Software include: OpenLDAP Version 1 was a general clean-up of the last release from the University of Michigan project (release 3.3), and consolidation of additional changes. OpenLDAP Version 2.0, released in August 2000, included major enhancements including LDAP version 3 (LDAPv3) support, Internet Protocol version 6 (IPv6) support, and numerous other enhancements.