Developer(s) | The OpenLDAP project |
---|---|
Initial release | August 26, 1998 [1] |
Stable release | 2.6.7 [2] / 29 January 2024 |
Repository | |
Written in | C |
Operating system | Any |
Platform | Cross-platform |
Type | LDAP directory service |
License | OpenLDAP Public License [3] |
Website | www |
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. [4]
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.
The OpenLDAP project [5] was started in 1998 by Kurt Zeilenga. [6] 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.
As of May 2015 [update] , the OpenLDAP project has four core team members: Howard Chu (chief architect), [7] 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. [8]
OpenLDAP has four main components:
Additionally, the OpenLDAP Project is home to a number of subprojects:
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 [10] 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. [11]
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. [16]
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.
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.
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. [17]
|
|
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. [19]
The major (functional) releases of OpenLDAP Software include:
OpenLDAP supports replication using Content Synchronization as specified in RFC 4533. [24] 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. [25]
The basic synchronization operation is described in RFC 4533. [24] 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).
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. [26]
The Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.
rsync is a utility for transferring and synchronizing files between a computer and a storage drive and across networked computers by comparing the modification times and sizes of files. It is commonly found on Unix-like operating systems and is under the GPL-3.0-or-later license.
In computer science, a lock or mutex is a synchronization primitive that prevents state from being modified or accessed by multiple threads of execution at once. Locks enforce mutual exclusion concurrency control policies, and with a variety of possible methods there exists multiple unique implementations for different applications.
In computing, a directory service or name service maps the names of network resources to their respective network addresses. It is a shared information infrastructure for locating, managing, administering and organizing everyday items and network resources, which can include volumes, folders, files, printers, users, groups, devices, telephone numbers and other objects. A directory service is a critical component of a network operating system. A directory server or name server is a server which provides such a service. Each resource on the network is considered an object by the directory server. Information about a particular resource is stored as a collection of attributes associated with that resource or object.
Microsoft Exchange Server is a mail server and calendaring server developed by Microsoft. It runs exclusively on Windows Server operating systems.
Kolab is a free and open source groupware suite. It consists of the Kolab server and a wide variety of Kolab clients, including KDE PIM-Suite Kontact, Roundcube web frontend, Mozilla Thunderbird and Mozilla Lightning with SyncKolab extension and Microsoft Outlook with proprietary Kolab-Connector PlugIns.
Multi-master replication is a method of database replication which allows data to be stored by a group of computers, and updated by any member of the group. All members are responsive to client data queries. The multi-master replication system is responsible for propagating the data modifications made by each member to the rest of the group and resolving any conflicts that might arise between concurrent changes made by different members.
FreeRADIUS is a modular, high performance free RADIUS suite developed and distributed under the GNU General Public License, version 2, and is free for download and use. The FreeRADIUS Suite includes a RADIUS server, a BSD-licensed RADIUS client library, a PAM library, an Apache module, and numerous additional RADIUS related utilities and development libraries.
Intellisync Corporation was a provider of data synchronization software for mobile devices, such as mobile phones and personal digital assistants (PDAs). The company was acquired in 2006 by Nokia.
Zimbra Collaboration, formerly known as the Zimbra Collaboration Suite (ZCS) before 2019, is a collaborative software suite that includes an email server and a web client.
Microsoft Sync Framework is a data synchronization platform from Microsoft that can be used to synchronize data across multiple data stores. Sync Framework includes a transport-agnostic architecture, into which data store-specific synchronization providers, modelled on the ADO.NET data provider API, can be plugged in. Sync Framework can be used for offline access to data, by working against a cached set of data and submitting the changes to a master database in a batch, as well as to synchronize changes to a data source across all consumers and peer-to-peer synchronization of multiple data sources. Sync Framework features built-in capabilities for conflict detection – whether data to be changed has already been updated – and can flag them for manual inspection or use defined policies to try to resolve the conflict. Sync Services includes an embedded SQL Server Compact database to store metadata about the synchronization relationships as well as about each sync attempt. The Sync Framework API is surfaced both in managed code, for use with .NET Framework applications, as well as unmanaged code, for use with COM applications. It was scheduled to ship with Visual Studio 2008 in late November 2007.
CrushFTP is a proprietary multi-protocol, multi-platform file transfer server originally developed in 1999. CrushFTP is shareware with a tiered pricing model. It is targeted at home users on up to enterprise users.
Z-Push is a FOSS implementation of the Microsoft Exchange ActiveSync protocol which is used to synchronize email, personal contacts and other items between a central server and a mobile device.
oVirt is a free, open-source virtualization management platform. It was founded by Red Hat as a community project on which Red Hat Virtualization is based. It allows centralized management of virtual machines, compute, storage and networking resources, from an easy-to-use web-based front-end with platform independent access. KVM on x86-64, PowerPC64 and s390x architecture are the only hypervisors supported, but there is an ongoing effort to support ARM architecture in a future releases.
Kajona is a PHP based content management framework, released and developed as an open source project using the GNU Lesser General Public License. The system requires a relational database system such as MySQL, PostgreSQL or SQLite. Due to the abstraction of the database provided by Kajona's database-layer, nearly all relational database systems can be connected. Kajona uses UTF-8 to store its content, resulting in a system suitable for international websites. Since the system is written as a framework, external developers are able to enrich the system with new functionalities using one of the many hooks / plugin concepts Kajona provides. There are HotSpots for nearly every aspect such as for widgets, search plugins, elements or modules.
Canigó is the name chosen for the Java EE framework of the Generalitat de Catalunya.
GroupWise is a messaging and collaboration platform from OpenText that supports email, calendaring, personal information management, instant messaging, and document management. The GroupWise platform consists of desktop client software, which is available for Windows,, and the server software, which is supported on Windows Server and Linux.
multiOTP is an open source PHP class, a command line tool, and a web interface that can be used to provide an operating-system-independent, strong authentication system. multiOTP is OATH-certified since version 4.1.0 and is developed under the LGPL license. Starting with version 4.3.2.5, multiOTP open source is also available as a virtual appliance—as a standard OVA file, a customized OVA file with open-vm-tools, and also as a virtual machine downloadable file that can run on Microsoft's Hyper-V, a common native hypervisor in Windows computers.
Elliptics is a distributed key–value data storage with open source code. By default it is a classic distributed hash table (DHT) with multiple replicas put in different groups. Elliptics was created to meet requirements of multi-datacenter and physically distributed storage locations when storing huge amount of medium and large files.
Kopano is an open-source groupware application suite originally based on Zarafa. The initial version of Kopano Core (KC) was forked from the then-current release of Zarafa Collaboration Platform, and superseded ZCP in terms of lineage as ZCP switched to maintenance mode with patches flowing from KC. Kopano WebApp similarly descended from Zarafa WebApp. Since October 2017, Kopano Core is also known more specifically as Kopano Groupware Core, since Kopano B.V. developed more products that were not directly requiring groupware components.
{{cite web}}
: CS1 maint: archived copy as title (link)