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)

Related

Prometheus Pushgateway

Prometheus Pushgateway

The Prometheus Pushgateway exists to allow ephemeral and… 

  • 8.7K
  • 0

Stellar Core

Stellar is an open-source and distributed payments… 

  • 5K
  • 0

Datadog

Datadog is a hosted infrastructure monitoring platform.… 

  • 4.5K
  • 0

Tell us about a new Kubernetes application

Newsletter

Never miss a thing! Sign up for our newsletter to stay updated.

About

Discover and learn about everything Kubernetes

Navigation
Follow

Submit