OpenLDAP Software is a free

Free software

Free software, software libre or libre software is software that can be used, studied, and modified without restriction, and which can be copied and redistributed in modified or unmodified form either without restriction, or with restrictions that only ensure that further recipients can also do...

, open source

Open source

The term open source describes practices in production and development that promote access to the end product's source materials. Some consider open source a philosophy, others consider it a pragmatic methodology...

 implementation of the Lightweight Directory Access Protocol

Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol network...

 (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

Linux

Linux is a Unix-like computer operating system assembled under the model of free and open source software development and distribution. The defining component of any Linux system is the Linux kernel, an operating system kernel first released October 5, 1991 by Linus Torvalds...

 distributions include OpenLDAP Software for LDAP support. The software also runs on BSD-variants, as well as AIX

AIX operating system

AIX AIX AIX (Advanced Interactive eXecutive, pronounced "a i ex" is a series of proprietary Unix operating systems developed and sold by IBM for several of its computer platforms...

, Android, HP-UX

HP-UX

HP-UX is Hewlett-Packard's proprietary implementation of the Unix operating system, based on UNIX System V and first released in 1984...

, Mac OS X

Mac OS X

Mac OS X is a series of Unix-based operating systems and graphical user interfaces developed, marketed, and sold by Apple Inc. Since 2002, has been included with all new Macintosh computer systems...

, Solaris, Microsoft Windows

Microsoft Windows

Microsoft Windows is a series of operating systems produced by Microsoft.Microsoft introduced an operating environment named Windows on November 20, 1985 as an add-on to MS-DOS in response to the growing interest in graphical user interfaces . Microsoft Windows came to dominate the world's personal...

 (NT and derivatives, e.g. 2000, XP, Vista, Windows 7, etc.), and z/OS

Z/OS

z/OS is a 64-bit operating system for mainframe computers, produced by IBM. It derives from and is the successor to OS/390, which in turn followed a string of MVS versions.Starting with earliest:*OS/VS2 Release 2 through Release 3.8...

.

Project history and core team

The OpenLDAP Project was started in 1998 by Kurt Zeilenga. The project started by cloning the LDAP reference source from the University Of Michigan

University of Michigan

The University of Michigan is a public research university located in Ann Arbor, Michigan in the United States. It is the state's oldest university and the flagship campus of the University of Michigan...

 where a long-running project had supported development and evolution of the LDAP protocol.

As of April, 2006, the OpenLDAP Project has three Core Team members: Howard Chu (Chief Architect), Pierangelo Masarati, and Kurt Zeilenga. There are numerous other important and active contributors including Luke Howard, Hallvard Furuseth, Quanah Gibson-Mount, and Gavin Henry.

Components of OpenLDAP Software

OpenLDAP Software has three main components:

• slapd
  SLAPD
  The SLAPD and SLURPD originally evolved within the long-running project that developed the LDAP protocol....
  
   - stand-alone LDAP daemon
  Daemon (computer software)
  In Unix and other multitasking computer operating systems, a daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user...
  
   and associated modules and tools,
• libraries implementing the LDAP protocol and ASN.1 Basic Encoding Rules (BER), and
• clients 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++
  C++
  C++ is a statically typed, free-form, multi-paradigm, compiled, general-purpose programming language. It is regarded as an intermediate-level language, as it comprises a combination of both high-level and low-level language features. It was developed by Bjarne Stroustrup starting in 1979 at Bell...
  
  

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. The architecture is modular and many
different backends are 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 16 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 BerkeleyDB
  • back-hdb: a variant of back-bdb that is fully hierarchical and supports subtree renames
  • back-ldif: built on plain text LDIF files
  • 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.

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.

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.

• 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)

Other Modules

Backends and overlays are the two most commonly used types of modules. Backends were typically built in to 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 SHA2.
• 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
  IPv6
  Internet Protocol version 6 is a version of the Internet Protocol . It is designed to succeed the Internet Protocol version 4...
  
  ) support, and numerous other enhancements.
• OpenLDAP Version 2.1, released in June, 2002, included the transactional database backend (based on Berkeley Database
  Berkeley DB
  Berkeley DB is a computer software library that provides a high-performance embedded database for key/value data. Berkeley DB is a programmatic software library written in C with API bindings for C++, PHP, Java, Perl, Python, Ruby, Tcl, Smalltalk, and most other programming languages...
  
   or BDB), Simple Authentication and Security Layer
  Simple Authentication and Security Layer
  Simple Authentication and Security Layer is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses...
  
  (SASL) support, and Meta, Monitor, and Virtual experimental backends.
• OpenLDAP Version 2.2, released in December, 2003, included the LDAP "sync" Engine with replication support (syncrepl), the overlay interface, and numerous database and RFC-related functional enhancements.
• OpenLDAP Version 2.3, released in June, 2005, included the Configuration Backend (dynamic configuration), additional overlays including RFC-compliant Password Policy software, and numerous additional enhancements.
• OpenLDAP Version 2.4, released in October, 2007, introduced N-way MultiMaster replication, Stand-by master, and the ability to delete and modify Schema elements on the fly, plus many more.

Replication

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 (CSN) 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 (consumer) sends a "content synchronizing search" to a replication server (provider). The consumer can provide a cookie in this search (especially when it has been in sync with the provider previously). In the OpenLDAP implementation of the RFC 4533, this cookie includes the latest CSN that has been received from the provider (called the contextCSN).

The provider then returns as search results (or, see optimization below, sync info replies) the present (unchanged entry only used in the present phase of the refresh stage) (no attributes), added, modified (represented in the refresh phase as an add with all current attributes), or deleted (no attributes) 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 (including those that represent the current result of modifies) and deletes that have occurred since the time the consumer last synchronized with the provider. However, due to limited session log state (also non persistent) kept in the provider, a present phase may be required, particularly including the presentation of all unchanged entries as a means (inefficient) 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 (including adds that represent all current attributes of modified 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 (no present unchanged entry indications) 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 (whichever phase was currently active).

delta-syncrepl

This protocol keeps a persistent database of write accesses (changes) and can represent each modify precisely (meaning only the attributes that have changed). 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.

External links

• The OpenLDAP website
• The OpenLDAP Project
• The OpenLDAP Foundation
• OpenLDAP Software
• OpenLDAP Public License
• Using libldap, A tutorial on the OpenLDAP client API
• An OpenLDAP Update article by Marty Heyman 13 September 2007