OpenLDAP – Wikipedia

OpenLDAP ist eine kostenlose Open-Source-Implementierung des vom OpenLDAP-Projekt entwickelten Lightweight Directory Access Protocol (LDAP). Es wird unter seiner eigenen BSD-Lizenz namens OpenLDAP Public License veröffentlicht.^[4]

LDAP ist ein plattformunabhängiges Protokoll. Einige gängige Linux-Distributionen enthalten OpenLDAP-Software für die LDAP-Unterstützung. Die Software läuft auch auf BSD-Varianten sowie auf AIX, Android, HP-UX, MacOS, Solaris, Microsoft Windows (NT und Derivate, z. B. 2000, XP, Vista, Windows 7 usw.) und z / OS.

Geschichte[edit]

Das OpenLDAP-Projekt^[5] wurde 1998 von Kurt Zeilenga gestartet.^[6] Das Projekt begann mit dem Klonen der LDAP-Referenzquelle von der University of Michigan, wo ein langjähriges Projekt die Entwicklung und Weiterentwicklung des LDAP-Protokolls bis zur endgültigen Veröffentlichung dieses Projekts im Jahr 1996 unterstützt hatte.

Stand Mai 2015^[update]Das OpenLDAP-Projekt hat vier Mitglieder des Kernteams: Howard Chu (Chefarchitekt),^[7] Quanah Gibson-Mount, Hallvard Furuseth und Kurt Zeilenga. Es gibt zahlreiche andere wichtige und aktive Mitwirkende, darunter Luke Howard, Ryan Tandy und Gavin Henry. Zu den früheren Mitgliedern des Kernteams gehört Pierangelo Masarati.^[8]

Komponenten[edit]

OpenLDAP besteht aus drei Hauptkomponenten:

• slapd – eigenständiger LDAP-Daemon und zugehörige Module und Tools
• Bibliotheken, die das LDAP-Protokoll und ASN.1 Basic Encoding Rules (BER) implementieren
• Client-Software: ldapsearch, ldapadd, ldapdelete und andere

Darüber hinaus enthält das OpenLDAP-Projekt eine Reihe von Teilprojekten:

• JLDAP – LDAP-Klassenbibliotheken für Java
• JDBC-LDAP – Java JDBC – LDAP Bridge-Treiber
• ldapc ++ – LDAP-Klassenbibliotheken für C ++
• Fortress – Rollenbasiertes Java SDK zur Verwaltung des Identitätszugriffs
• LMDB – speicherabgebildete Datenbankbibliothek

Backends[edit]

Gesamtkonzept[edit]

In der Vergangenheit war die OpenLDAP-Serverarchitektur (slapd, Standalone LDAP Daemon) zwischen einem Frontend für den Netzwerkzugriff und die Protokollverarbeitung und einem Backend für die Datenspeicherung aufgeteilt. Dieses geteilte Design war ein Merkmal des ursprünglichen Codes der Universität von Michigan, der 1996 geschrieben wurde^[9] und in allen nachfolgenden OpenLDAP-Releases fortgesetzt. Der ursprüngliche Code enthielt ein Hauptdatenbank-Backend und zwei Experimental- / Demo-Backends. Die Architektur ist modular aufgebaut und es stehen jetzt viele verschiedene Backends für die Anbindung an andere Technologien zur Verfügung, nicht nur an herkömmliche Datenbanken.

Hinweis: In älteren (1.x) Versionen wurden die Begriffe “Backend” und “Datenbank” häufig synonym verwendet. Um genau zu sein, ist ein “Backend” eine Klasse von Speicherschnittstellen, und eine “Datenbank” ist eine Instanz eines Backends. Der slapd-Server kann beliebig viele Backends gleichzeitig verwenden und beliebig viele Instanzen jedes Backends (dh beliebig viele Datenbanken) gleichzeitig aktiv haben.

Verfügbare Backends[edit]

Derzeit werden in der OpenLDAP-Distribution 17 verschiedene Backends bereitgestellt, und es ist bekannt, dass verschiedene Dritte andere Backends unabhängig voneinander verwalten. Die Standard-Backends sind lose in drei verschiedene Kategorien unterteilt:

• Datenspeicher-Backends – diese speichern tatsächlich Daten
  • back-bdb: Das erste Transaktions-Backend für OpenLDAP, das auf Berkeley DB basiert
  • back-hdb: Eine Variante von back-bdb, die vollständig hierarchisch ist und das Umbenennen von Teilbäumen unterstützt
  • back-ldif: basiert auf LDIF-Dateien im Klartext
  • back-mdb: Ein Transaktions-Backend, das auf der Lightning Memory-Mapped Database (LMDB) von OpenLDAP basiert.
  • back-ndb: Ein Transaktions-Backend, das auf der NDB-Cluster-Engine von MySQL basiert
• Proxy-Backends – Diese fungieren als Gateways zu anderen Datenspeichersystemen
  • back-ldap: einfacher Proxy zu anderen LDAP-Servern
  • Back-Meta: Proxy mit Meta-Verzeichnis-Funktionen
  • back-passwd: Verwendet die passwd- und Gruppendaten eines Unix-Systems
  • Back-Relay: Leitet intern zu anderen Slapd-Backends um
  • back-sql: spricht mit beliebigen SQL-Datenbanken
• Dynamische Backends – diese generieren Daten im laufenden Betrieb
  • back-config: slapd-Konfiguration über LDAP
  • back-dnssrv: Findet LDAP-Server über DNS
  • Back-Monitor: Slapd-Statistiken über LDAP
  • back-null: ein sink / no-op-Backend, analog zu Unix / dev / null
  • Back-Perl: Ruft beliebige Perl-Module als Antwort auf LDAP-Anforderungen auf
  • Back-Shell: Ruft Shell-Skripte für LDAP-Anforderungen auf
  • Back-Sock: Leitet LDAP-Anforderungen über IPC an beliebige Daemons weiter

Einige Backends, die in älteren OpenLDAP-Versionen verfügbar sind, wurden nicht mehr verwendet, insbesondere back-ldbm, das vom ursprünglichen UMich-Code geerbt wurde, und back-tcl, das Back-Perl und Back-Shell ähnelte.

Die Unterstützung für andere Backends wird ebenfalls bald eingestellt. back-ndb ist jetzt veraltet, da die Partnerschaft mit MySQL, die zu seiner Entwicklung führte, von Oracle beendet wurde, nachdem Oracle MySQL übernommen hatte. back-bdb und back-hdb werden bald zugunsten von back-mdb verworfen, da back-mdb in allen Aspekten der Leistung, Zuverlässigkeit und Verwaltbarkeit überlegen ist.

In der Praxis ermöglichen Backends wie -perl, -shell und -sock die Anbindung an eine beliebige Programmiersprache und bieten somit unbegrenzte Möglichkeiten zur Anpassung und Erweiterung. Tatsächlich wird der slapd-Server zu einer RPC-Engine mit einer kompakten, genau definierten und allgegenwärtigen API.

Überlagerungen[edit]

Gesamtkonzept[edit]

Normalerweise wird eine LDAP-Anforderung vom Frontend empfangen, dekodiert und dann zur Verarbeitung an ein Backend übergeben. Wenn das Backend eine Anforderung abschließt, gibt es ein Ergebnis an das Frontend zurück, das das Ergebnis dann an den LDAP-Client sendet. Ein Overlay ist ein Code, der zwischen Frontend und Backend eingefügt werden kann. Es ist somit in der Lage, Anforderungen abzufangen und andere Aktionen auf sie auszulösen, bevor das Backend sie empfängt, und es kann ebenfalls auf die Ergebnisse des Backends einwirken, bevor sie das Frontend erreichen. Overlays haben vollständigen Zugriff auf die internen slapd-APIs und können so alles aufrufen, was das Frontend oder andere Backends leisten könnten. Es können mehrere Overlays gleichzeitig verwendet werden, die einen Stapel von Modulen zwischen dem Frontend und dem Backend bilden.

Overlays bieten eine einfache Möglichkeit, die Funktionalität einer Datenbank zu erweitern, ohne dass ein völlig neues Backend geschrieben werden muss, und ermöglichen das Hinzufügen neuer Funktionen in kompakten, leicht zu debuggenden und wartbaren Modulen. Seit der Einführung der Overlay-Funktion in OpenLDAP 2.2 wurden viele neue Overlays von der OpenLDAP-Community bereitgestellt.

Verfügbare Überlagerungen[edit]

Derzeit gibt es 21 Overlays in der OpenLDAP-Kerndistribution, weitere 15 Overlays im vom Benutzer bereitgestellten Codeabschnitt und weitere warten auf die Genehmigung zur Aufnahme.

Andere Module[edit]

Backends und Overlays sind die beiden am häufigsten verwendeten Modultypen. Backends wurden normalerweise in die slapd-Binärdatei integriert, sie können jedoch auch als dynamisch geladene Module erstellt werden, und Overlays werden normalerweise als dynamische Module erstellt. Darüber hinaus unterstützt slapd dynamische Module zum Implementieren neuer LDAP-Syntaxen, Abgleichsregeln, Steuerelemente und erweiterter Vorgänge sowie zum Implementieren benutzerdefinierter Zugriffssteuerungsmechanismen und Kennwort-Hashing-Mechanismen.

OpenLDAP unterstützt auch SLAPI, die Plugin-Architektur von Sun und Netscape / Fedora / Red Hat. In aktuellen Versionen ist das SLAPI-Framework in einem Slapd-Overlay implementiert. Während viele für Sun / Netscape / Fedora / Red Hat geschriebene Plugins mit OpenLDAP kompatibel sind, verwenden nur sehr wenige Mitglieder der OpenLDAP-Community SLAPI.

Verfügbare Module[edit]

• Native Slapd-Module
  • acl / posixgroup – unterstützt die posixGroup-Mitgliedschaft in Zugriffskontrollen
  • comp_match – unterstützt komponentenbasiertes Matching
  • kinit – Verwalten / Aktualisieren eines Kerberos TGT für slapd
  • passwd / – zusätzliche Passwort-Hashing-Mechanismen. Enthält derzeit Kerberos, Netscape, RADIUS und SHA-2.
• SLAPI-Plugins
  • addrdnvalue – Fügt einem Eintrag einen RDN-Wert hinzu, wenn dieser in einer Add-Anforderung weggelassen wurde

Release-Zusammenfassung[edit]

Die wichtigsten (funktionalen) Versionen der OpenLDAP-Software umfassen:

• OpenLDAP Version 1 war eine allgemeine Bereinigung der letzten Version des University of Michigan-Projekts (Version 3.3) und die Konsolidierung zusätzlicher Änderungen.
• OpenLDAP Version 2.0, das im August 2000 veröffentlicht wurde, enthielt wichtige Verbesserungen, einschließlich LDAPv3-Unterstützung (LDAP Version 3), IPv6-Unterstützung (Internet Protocol Version 6) und zahlreiche andere Verbesserungen.
• OpenLDAP Version 2.1, die im Juni 2002 veröffentlicht wurde, umfasste das Transaktionsdatenbank-Backend (basierend auf Berkeley Database oder BDB), die Unterstützung für einfache Authentifizierung und Sicherheitsschicht (SASL) sowie experimentelle Meta-, Monitor- und virtuelle Backends.
• OpenLDAP Version 2.2, veröffentlicht im Dezember 2003, enthielt die LDAP “Sync” Engine mit Replikationsunterstützung (Syncrepl), die Overlay-Schnittstelle sowie zahlreiche Datenbank- und RFC-bezogene Funktionserweiterungen.
• OpenLDAP Version 2.3, veröffentlicht im Juni 2005, enthielt das Konfigurations-Backend (dynamische Konfiguration), zusätzliche Overlays, einschließlich RFC-kompatibler Passwortrichtlinien-Software, und zahlreiche zusätzliche Verbesserungen.
• OpenLDAP Version 2.4, veröffentlicht im Oktober 2007, führte die N-Wege-MultiMaster-Replikation, den Standby-Master und die Möglichkeit ein, Schema-Elemente im laufenden Betrieb zu löschen und zu ändern, sowie viele weitere.^[10]

Reproduzieren[edit]

OpenLDAP unterstützt die Replikation mithilfe der Inhaltssynchronisierung wie in angegeben RFC 4533. Diese Spezifikation wird im Folgenden als “Syncrepl” bezeichnet. Zusätzlich zur Basisspezifikation wird auch eine als Delta-Syncrepl bekannte Verbesserung unterstützt. Zusätzliche Verbesserungen wurden implementiert, um die Multi-Master-Replikation zu unterstützen.

syncrepl[edit]

Die grundlegende Synchronisationsoperation ist in beschrieben RFC 4533. Das Protokoll ist so definiert, dass keine dauerhafte Datenbank mit Änderungen erforderlich ist. Vielmehr wird der Satz von Änderungen über CSN-Informationen (Change Sequence Number) impliziert, die in jedem Eintrag gespeichert und über ein optionales Sitzungsprotokoll optimiert sind, das besonders nützlich ist, um die letzten Löschvorgänge zu verfolgen. Das Betriebsmodell besteht darin, dass ein Replikationsclient (Verbraucher) eine “Suche nach Inhaltssynchronisierung” an einen Replikationsserver (Anbieter) sendet. Der Verbraucher kann bei dieser Suche ein Cookie bereitstellen (insbesondere, wenn es zuvor mit dem Anbieter synchronisiert wurde). In der OpenLDAP-Implementierung des RFC 4533Dieses Cookie enthält den neuesten CSN, der vom Anbieter empfangen wurde (als Kontext-CSN bezeichnet).

Der Anbieter gibt dann als Suchergebnisse (oder, siehe Optimierung unten, Antworten auf Synchronisierungsinformationen) den vorhandenen (unveränderten Eintrag, der nur in der aktuellen Phase der Aktualisierungsphase verwendet wird) (keine Attribute) zurück, hinzugefügt, geändert (in der Aktualisierungsphase als dargestellt) Hinzufügen mit allen aktuellen Attributen) oder gelöschten Einträgen (keine Attribute), um den Verbraucher in einen synchronisierten Zustand zu versetzen, der auf dem basiert, was über sein Cookie bekannt ist. Wenn das Cookie fehlt oder anzeigt, dass der Verbraucher nicht mehr synchron ist, sendet der Anbieter in der Aktualisierungsphase für jeden Eintrag ein Add. Im Idealfall enthält die Aktualisierungsphase der Antwort nur eine Löschphase mit nur einem kleinen Satz von Adds (einschließlich derjenigen, die das aktuelle Ergebnis von Änderungen darstellen) und Löschvorgängen, die seit der letzten Synchronisierung des Verbrauchers mit dem Anbieter aufgetreten sind. Aufgrund des begrenzten Sitzungsprotokollstatus (auch nicht persistent), der im Anbieter gespeichert ist, kann jedoch eine aktuelle Phase erforderlich sein, insbesondere die Darstellung aller unveränderten Einträge als Mittel (ineffizient), um zu implizieren, was seitdem im Anbieter gelöscht wurde der Verbraucher zuletzt synchronisiert.

Die Suche kann entweder im Aktualisierungs- oder im AktualisierungsAndPersist-Modus durchgeführt werden, was impliziert, welche Phasen auftreten. Die Aktualisierungsphase erfolgt immer zuerst. Während der Aktualisierungsphase können zwei Phasen auftreten: vorhanden und löschen, wobei vorhanden immer vor dem Löschen auftritt. Die Phasen werden über eine Synchronisierungsinfo-Antwort abgegrenzt, die angibt, welche Phase abgeschlossen ist. Die Aktualisierungs- und Persistenzstufen werden auch über eine solche Antwort auf Synchronisierungsinformationen begrenzt. Eine optionale Optimierung zur kompakteren Darstellung einer Gruppe von Einträgen, die präsentiert oder gelöscht werden sollen, besteht darin, eine Antwort auf Synchronisierungsinformationen zu verwenden, die ein syncIdSet enthält, das die Liste der entryUUID-Werte dieser Einträge identifiziert.

Die vorliegende Phase unterscheidet sich wie folgt von der Löschphase. Einträge, die unveränderte Einträge enthalten, können nur in der aktuellen Phase zurückgegeben werden. Einträge, die Einträge löschen, dürfen nur in der Löschphase bereitgestellt werden. In beiden Phasen können Add-Einträge (einschließlich Adds, die alle aktuellen Attribute geänderter Einträge darstellen) zurückgegeben werden. Am Ende einer gegenwärtigen Phase befindet sich jeder Eintrag des Verbrauchers, der in der aktuellen Phase nicht in einem Eintrag oder einer aktuellen Antwort identifiziert wurde, implizit nicht mehr im Anbieter und muss daher beim Verbraucher gelöscht werden, um den Verbraucher zu synchronisieren mit dem Anbieter.

Sobald die Persist-Phase beginnt, sendet der Anbieter Suchergebnisse, die nur das Hinzufügen, Ändern und Löschen von Einträgen (keine vorhandenen unveränderten Eintragsangaben) für die Einträge anzeigen, die seit Abschluss der Aktualisierungsphase geändert wurden. Die Persistenzphase wird auf unbestimmte Zeit fortgesetzt, was bedeutet, dass die Suche keine endgültige “erledigt” Antwort hat. Im Auffrischungsmodus tritt dagegen nur eine Auffrischungsstufe auf, und diese Stufe wird mit einer Antwort abgeschlossen, die auch die aktuelle oder Löschphase beendet (je nachdem, welche Phase gerade aktiv war).

Delta-Syncrepl[edit]

Dieses Protokoll führt eine persistente Datenbank mit Schreibzugriffen (Änderungen) und kann jede Änderung genau darstellen (dh nur die Attribute, die sich geändert haben). Es basiert weiterhin auf der Standard-Syncrepl-Spezifikation, die Änderungen immer als vollständige Einträge sendet. Bei Delta-Syncrepl werden die übertragenen Einträge jedoch tatsächlich aus einer Protokolldatenbank gesendet, wobei jede Änderung in der Hauptdatenbank als Protokolleintrag aufgezeichnet wird. Die Protokolleinträge werden mithilfe des LDAP-Protokollschemas aufgezeichnet.^[11]

Siehe auch[edit]

Verweise[edit]

Externe Links[edit]