OpenLDAP


OpenLDAP is a free, open-source implementation of the Lightweight Directory Access Protocol 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, 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, Quanah Gibson-Mount, Hallvard Furuseth, and Kurt Zeilenga. There are numerous other important and active contributors including Luke Howard, Ryan Tandy, and Gavin Henry. Past core team members include Pierangelo Masarati.

Components

OpenLDAP has three main components:
Additionally, the OpenLDAP Project is home to a number of subprojects:

Overall concept

Historically the OpenLDAP server 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 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 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 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:
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 from 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.
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

The major releases of OpenLDAP Software include:
OpenLDAP supports replication using Content Synchronization as specified in RFC 4533. This spec is hereafter referred to as "syncrepl". In addition to the base specification, an enhancement known as delta-syncrepl is also supported. Additional enhancements have been implemented to support multi-master replication.

syncrepl

The basic synchronization operation is described in RFC 4533. The protocol is defined such that a persistent database of changes is not required. Rather the set of changes is implied via change sequence number information stored in each entry and optimized via an optional session log which is particularly useful to track recent deletes. The model of operation is that a replication client sends a "content synchronizing search" to a replication server. The consumer can provide a cookie in this search. In the OpenLDAP implementation of the RFC 4533, this cookie includes the latest CSN that has been received from the provider.
The provider then returns as search results the present , added, modified, or deleted entries to put the consumer into a synchronized state based on what is known via their cookie. If the cookie is absent or indicates that the consumer is totally out of sync, then the provider will, in the refresh stage, send an add for each entry it has. In the ideal case, the refresh stage of the response contains only a delete phase with just a small set of adds and deletes that have occurred since the time the consumer last synchronized with the provider. However, due to limited session log state kept in the provider, a present phase may be required, particularly including the presentation of all unchanged entries as a means of implying what has been deleted in the provider since the consumer last synchronized.
The search can be done in either refresh or refreshAndPersist mode, which implies what stages occur. The refresh stage always occurs first. During the refresh stage, two phases may occur: present and delete, where present always occurs before delete. The phases are delimited via a sync info response that specifies which phase is completed. The refresh and persist stages are also delimited via such sync info response. An optional optimization to more compactly represent a group of entries that are to be presented or deleted is to use a sync info response containing a syncIdSet that identifies the list of entryUUID values of those entries.
The present phase is differentiated from the delete phase as follows. Entries that present unchanged entries may only be returned in the present phase. Entries that delete entries may only be provided in the delete phase. In either phase, add entries can be returned. At the end of a present phase, each entry that the consumer has that was not identified in an add entry or present response during the present phase is implicitly no longer in the provider and thus must be deleted at the consumer so as to synchronize the consumer with the provider.
Once the persist stage begins, the provider sends search results that indicate only the add, modify and delete of entries for those entries changed since the refresh stage completed. The persist stage continues indefinitely, meaning that search has no final "done" response. By contrast, in the refresh mode only a refresh stage occurs and such stage completes with a done response that also ends the present or delete phase.

delta-syncrepl

This protocol keeps a persistent database of write accesses and can represent each modify precisely. It is still built on the standard syncrepl specification, which always sends changes as complete entries. But in delta-syncrepl, the transmitted entries are actually sent from a log database, where each change in the main database is recorded as a log entry. The log entries are recorded using the LDAP Log Schema.