Software von OpenLDAP ist eine freie, offene Quelldurchführung von durch das Projekt von OpenLDAP entwickeltem Lightweight Directory Access Protocol (LDAP). Es wird laut seiner eigenen BSD-artigen Lizenz genannt die Publikum-Lizenz von OpenLDAP veröffentlicht. LDAP ist ein mit der Plattform unabhängiges Protokoll. Mehrerer allgemeiner Vertrieb von Linux schließt Software von OpenLDAP für die LDAP-Unterstützung ein. Die Software läuft auch auf BSD-Varianten, sowie AIX, Androiden, HP-UX, Mac OS X, Solaris, Windows von Microsoft (NT und Ableitungen, z.B 2000, XP, Aussicht, Windows 7, usw.), und z/OS.

Projektgeschichte und Kernmannschaft

Das Projekt von OpenLDAP wurde 1998 von Kurt Zeilenga angefangen. Das Projekt hat durch das Klonen der LDAP Bezugsquelle von der Universität Michigans angefangen, wo ein Langzeitprojekt Entwicklung und Evolution des LDAP Protokolls unterstützt hatte.

Bezüglich des Aprils 2006 hat das Projekt von OpenLDAP drei Kerngruppenmitglieder: Howard Chu (Hauptarchitekt), Pierangelo Masarati und Kurt Zeilenga. Es gibt viele andere wichtige und energische Mitwirkende einschließlich Luke Howards, Hallvard Furuseth, des Gibson-Bergs Quanah und Gavin Henrys.

Bestandteile der Software von OpenLDAP

Software von OpenLDAP hat drei Hauptbestandteile:

• slapd - eigenständiger LDAP Dämon und vereinigte Module und Werkzeuge,
• Bibliotheken, die das LDAP Protokoll und ASN.1 Basic Encoding Rules (BER) und den durchführen
• Kundensoftware: ldapsearch, ldapadd, ldapdelete, und andere

Zusätzlich beherbergt das Projekt von OpenLDAP mehrere Subprojekte:

• JLDAP - LDAP Klassenbibliotheken für Java
• JDBC-LDAP - Java JDBC - Fahrer der LDAP Bridge
• ldapc ++ - LDAP Klassenbibliotheken für C ++

Backends

Gesamtes Konzept

Historisch der Server von OpenLDAP (slapd, der Eigenständige LDAP Dämon) Architektur war

der Spalt zwischen einem frontend, der Netzzugang und Protokoll-Verarbeitung und einen behandelt

backend, der sich ausschließlich mit der Datenlagerung befasst. Die Architektur ist modular und viele

verschiedene backends sind verfügbar, um zu anderen Technologien, nicht nur zu verbinden

traditionelle Datenbanken.

Zeichen: Im Älteren (1.x) wurden Ausgaben, die Begriffe "backend" und "Datenbank" häufig austauschbar verwendet.

Um genau zu sein, ist ein "backend" eine Klasse der Lagerungsschnittstelle, und eine "Datenbank" ist ein Beispiel eines

backend. Der slapd Server kann willkürlich viele backends sofort verwenden, und kann willkürlich haben

viele Beispiele jedes backend (d. h., willkürlich viele Datenbanken) aktiv sofort.

Verfügbarer Backends

Zurzeit werden 16 verschiedene backends im Vertrieb von OpenLDAP und verschiedenen zur Verfügung gestellt

wie man

bekannt, erhalten Dritte anderen backends unabhängig aufrecht. Der Standard backends

werden in drei verschiedene Kategorien lose organisiert:

• Datenlagerung backends - diese versorgen wirklich Daten
• Zurück-Bdb: Der erste transactional backend für OpenLDAP, hat auf BerkeleyDB gebaut
• Zurück-Hdb: Eine Variante des Zurück-Bdb, das völlig hierarchisch ist und Subbaum unterstützt, benennt um
• Zurück-Ldif: gebaut auf Klartext LDIF Dateien
• Zurück-Mdb: Ein transactional backend hat auf den MDB von OpenLDAP mit dem Gedächtnis kartografisch dargestellte Datenbank gebaut
• Zurück-Ndb: Ein transactional backend hat auf den NDB Traube-Motor von MySQL gebaut
• Vertretung backends - diese handeln als Tore zu anderen Datenlagerungssystemen
• Zurück-Ldap: einfache Vertretung zu anderen LDAP Servern
• Zurück-Meta: Vertretung mit Meta-Verzeichniseigenschaften
• Zurück-Passwd: Verwendet einen Systempasswd von Unix und Gruppendaten
• Zurückrelais: Innerlich adressiert zu anderem slapd backends um
• Zurück-Sql: Gespräche zu willkürlichen SQL Datenbanken
• Dynamischer backends - diese erzeugen Daten im Fluge
• Zurück-Config: Slapd-Konfiguration über LDAP
• Zurück-Dnssrv: Macht LDAP Server über DNS ausfindig
• Zurückmonitor: Slapd-Statistik über LDAP
• zurückungültig: ein sink/no-op backend, analog Unix/dev/null
• Zurück-Perl: Ruft willkürliche perl Module als Antwort auf LDAP Bitten an
• Zurückschale: Ruft Schale-Schriften für LDAP Bitten an
• Zurücksocke: Vorwärts bittet LDAP über IPC willkürlichen Dämonen

Einige backends verfügbar in älteren Ausgaben von OpenLDAP sind vom Gebrauch, pensioniert gewesen

am meisten namentlich Zurück-Ldbm, das aus dem ursprünglichen UMich-Code und geerbt wurde

Zurück-Tcl, das dem Zurück-Perl und der Zurückschale ähnlich war.

In der Praxis, backends wie-perl, - Schale, und - Socke erlauben, in jede willkürliche Programmiersprache zu verbinden, so grenzenlose Fähigkeiten für die Anpassung und Vergrößerung zur Verfügung stellend. Tatsächlich wird der slapd Server ein RPC Motor mit einem kompakten,

bestimmte und allgegenwärtige API.

Bedeckungen

Gesamtes Konzept

Normalerweise wird eine LDAP-Bitte durch den frontend erhalten, hat decodiert, und ist dann zu einem backend für die Verarbeitung gegangen. Wenn der backend eine Bitte vollendet, gibt er ein Ergebnis in den frontend zurück, der dann das Ergebnis dem LDAP Kunden sendet. Eine Bedeckung ist ein Stück des Codes, der zwischen dem frontend und dem backend eingefügt werden kann. Es ist so im Stande, Bitten abzufangen und andere Handlungen auf ihnen auszulösen, bevor der backend sie erhält, und es auch den Ergebnissen des backend ebenfalls folgen kann, bevor sie den frontend erreichen. Bedeckungen haben ganzen Zugang zum slapd inneren APIs, und können so irgendetwas anrufen der frontend oder anderer backends konnten leisten. Vielfache Bedeckungen können sofort verwendet werden, einen Stapel von Modulen zwischen dem frontend und dem backend bildend.

Bedeckungen stellen ein einfaches Mittel zur Verfügung, die Funktionalität einer Datenbank zu vermehren, ohne zu verlangen, dass ein völlig neuer backend geschrieben werden, und neuen Funktionalitäten erlaubt, im kompakten, leicht debuggable und den haltbaren Modulen hinzugefügt zu werden. Seit der Einführung

der Bedeckungseigenschaft in OpenLDAP 2.2 sind viele neue Bedeckungen von der Gemeinschaft von OpenLDAP beigetragen worden.

Verfügbare Bedeckungen

Zurzeit gibt es 21 Bedeckungen im Kernvertrieb von OpenLDAP, mit weiteren 15 Bedeckungen in der benutzerbeigetragenen Codeabteilung und mehr Erwarten-Billigung für die Einschließung.

• Die Kernbedeckungen schließen ein:
• accesslog: Klotz-Server-Tätigkeit in einer anderen LDAP Datenbank, für die LDAP-zugängliche Protokollierung
• auditlog: Klotz-Server-Tätigkeit in einer flachen Textdatei
• Kette: Fangen Sie referrals ab und ketten Sie sie stattdessen; Code ist ein Teil des Zurück-Ldap
• versammeln Sie sich: Führen Sie X.500-artige gesammelte Attribute (auch bekannt als Netscape Klasse des Dienstes) durch
• Einschränkung: Schränken Sie die annehmbaren Werte für besondere Attribute ein
• dds: dynamischer Datendienst - kurzlebige, selbstablaufende Einträge
• deref: Geben Sie Information über Einträge zurück, die in einem gegebenen Suchergebnis Verweise angebracht sind
• dyngroup: Einfache dynamische Gruppe unterstützt
• dynlist: Hoch entwickeltere dynamische Gruppe unterstützt plus mehr
• memberof: Die Unterstützung für memberOf und ähnlichen backlink schreibt zu
• pcache: Suchergebnisse des geheimen Lagers, um hauptsächlich Leistung für proxied Server zu verbessern
• ppolicy: LDAP Kennwort-Politik - Kennwort-Qualität, Ablauf, usw.
• refint: Verweisungsintegrität
• retcode: Setzen Sie vorher bestimmte Rückcodes für verschiedene Operationen; verwendet für den Kunden, der die Fehler beseitigt
• rwm: Schreiben Sie Modul, für verschiedene Modifizierungen von LDAP Daten um
• seqmod: Veröffentlichen Sie in Fortsetzungen schreibt individuellen Einträgen
• sssvlv: Das Server-Seitensortieren und die Virtuellen Listenansichten
• syncprov: Syncrepl Versorger, führt die Master-Seite einer Erwiderungsabmachung durch
• lichtdurchlässig: Halbdurchsichtiger Durchgang, um Daten auf einem proxied Server lokal zu vermehren
• einzigartig: Um Einzigartigkeit des Attributes geltend zu machen, schätzt innerhalb eines Baums
• valsort: Erhalten Sie verschiedene Sorte-Ordnungen für Werte eines Attributes aufrecht
• Die Contrib-Bedeckungen schließen ein:
• addpartial: Erhalten Sie Fügen Bitten Hinzu und drehen sie darin Modifiziert, wenn der Zielzugang bereits besteht
• allop: Zurückgeben für Kunden alle betrieblichen Attribute, die nicht wissen, wie man um sie bittet
• Autogruppe: dynamisch geführte statische Gruppen
• Umhang: Verbergen Sie Attribute, wenn ausführlich nicht gebeten, in einer Suche
• denyop: Weisen Sie willkürlich konfigurierte Bitten zurück
• dupent: Geben Sie mehrgeschätzte Ergebnisse als getrennte Einträge zurück
• lastbind: Registrieren Sie den Zeitstempel einer letzten erfolgreichen Beglaubigung eines Benutzers
• lastmod: Erhalten Sie den Zeitstempel der letzten Änderung innerhalb eines Baums aufrecht
• nops: Sickern Sie überflüssig durch modifiziert
• noopsrch: Einträge der Zählung, die durch eine Suche zurückgegeben würden
• nssov: Antworten Sie auf NSS und PAM-Bitten direkt in slapd, ersetzt nss-ldap und pam-ldap.
• proxyOld: Unterstützen Sie eine veraltete Verschlüsselung von ProxyAuthz, der durch die Sonne und al verwendet ist.
• smbk5pwd: Erhalten Sie Kennwörter von Samba und Kerberos aufrecht
• Spur: Loggen Sie jede LDAP-Bitte und Antwort
• usn: Aktualisierungsfolge-Zahlen (als in Microsoft AD, noch nicht befreit)

Andere Module

Backends und Bedeckungen sind die zwei meistens verwendeten Typen von Modulen. Backends wurden normalerweise in zur slapd Dualzahl, gebaut

aber sie können auch so dynamisch geladene Module gebaut werden, und Bedeckungen werden gewöhnlich gebaut wie dynamische Module. Außerdem,

slapd unterstützt dynamische Module, um neue LDAP Syntaxen durchzuführen, Regeln, Steuerungen und erweiterte Operationen, als vergleichend

gut bezüglich des Einführens kundenspezifischen Zugangs kontrollieren Mechanismen und Kennwort hashing Mechanismen.

OpenLDAP unterstützt auch SLAPI, die Steckarchitektur, die durch die Sonne und den Netscape/Fedora/Red Hut verwendet ist. In aktuellen Ausgaben,

das SLAPI Fachwerk wird innerhalb einer Slapd-Bedeckung durchgeführt. Während viele plugins, die für den Sun/Netscape/Fedora/Red Hut geschrieben sind

sind

mit OpenLDAP vereinbar, sehr wenige Mitglieder der Gemeinschaft von OpenLDAP verwenden SLAPI.

Verfügbare Module

• Heimische slapd Module
• acl/posixgroup - unterstützen posixGroup Mitgliedschaft in Zugang Steuerungen
• comp_match - unterstützen das teilbasierte Zusammenbringen
• kinit - erhalten einen Kerberos TGT für slapd aufrecht/erfrischen
• passwd/-zusätzliches Kennwort hashing Mechanismen. Zurzeit schließt Kerberos, Netscape, RADIUS und SHA2 ein.
• SLAPI plugins
• addrdnvalue - fügen hinzu, dass RDN zu einem Zugang schätzen, wenn er in einer Hinzufügen Bitte weggelassen wurde

Ausgabe-Zusammenfassung

Die größeren (funktionellen) Ausgaben der Software von OpenLDAP schließen ein:

• Version 1 von OpenLDAP war eine allgemeine Reinigung der letzten Ausgabe von der Universität des Michiganer Projektes (Ausgabe 3.3) und Verdichtung von zusätzlichen Änderungen.
• Version 2.0 von OpenLDAP, veröffentlicht im August 2000, hat Haupterhöhungen einschließlich der LDAP Unterstützung der Version 3 (LDAPv3), Internetprotokoll-Unterstützung der Version 6 (IPv6) und vielen anderen Erhöhungen eingeschlossen.
• Version 2.1 von OpenLDAP, veröffentlicht im Juni 2002, hat die transactional Datenbank backend (gestützt auf der Datenbank von Berkeley oder BDB), Einfache Beglaubigung und Sicherheitsschicht (SASL) Unterstützung, und Meta, Monitor und Virtueller experimenteller backends eingeschlossen.
• Version 2.2 von OpenLDAP, veröffentlicht im Dezember 2003, hat den LDAP-"Gleichzeitigkeits"-Motor mit der Erwiderungsunterstützung (syncrepl), die Bedeckungsschnittstelle, und zahlreiche Datenbank und RFC-zusammenhängenden funktionellen Erhöhungen eingeschlossen.
• Version 2.3 von OpenLDAP, veröffentlicht im Juni 2005, hat die Konfiguration Backend (dynamische Konfiguration), zusätzliche Bedeckungen einschließlich der RFC-entgegenkommenden Kennwort-Politiksoftware und zahlreiche zusätzliche Erhöhungen eingeschlossen.
• Version 2.4 von OpenLDAP, veröffentlicht im Oktober 2007, eingeführte N-way Erwiderung von MultiMaster, Hilfsmaster und die Fähigkeit, Diagramm-Elemente im Fluge, plus noch viele zu löschen und zu modifizieren.

Erwiderung

OpenLDAP unterstützt Erwiderung mit der Zufriedenen Synchronisation, wie angegeben, in RFC 4533. Diese Spekulation wird nachher "syncrepl" genannt. Zusätzlich zur Grundspezifizierung eine bekannte Erhöhung weil wird Delta-syncrepl auch unterstützt. Zusätzliche Erhöhungen sind durchgeführt worden, um Mehrmaster-Erwiderung zu unterstützen.

syncrepl

Die grundlegende Synchronisationsoperation wird in RFC 4533 beschrieben. Das Protokoll wird solch definiert, dass eine beharrliche Datenbank von Änderungen nicht erforderlich ist. Eher wird der Satz von Änderungen über die Information der Änderungsfolge-Zahl (CSN) einbezogen, die in jedem Zugang versorgt ist, und hat über einen fakultativen Sitzungsklotz optimiert, der für die neue Spur besonders nützlich ist, löscht. Das Modell der Operation ist, dass ein Erwiderungskunde (Verbraucher) eine "zufriedene gleichzeitig seiende Suche" an einen Erwiderungsserver (Versorger) sendet. Der Verbraucher kann ein Plätzchen in dieser Suche zur Verfügung stellen (besonders, als es synchron mit dem Versorger vorher gewesen ist). In der Durchführung von OpenLDAP des RFC 4533 schließt dieses Plätzchen den letzten CSN ein, der vom Versorger erhalten worden ist (hat den contextCSN genannt).

Der Versorger kehrt dann zurück, weil Suche resultiert (oder, sieh Optimierung unten, synchronisieren Sie Info-Antworten) die Gegenwart (unveränderter Zugang, der nur in der gegenwärtigen Phase der erfrischen Bühne verwendet ist) (keine Attribute), hinzugefügt, modifiziert (vertreten in der erfrischen Phase als ein Hinzufügen mit allen aktuellen Attributen), oder gelöscht (keine Attribute) Einträge, um den Verbraucher in einen synchronisierten Staat zu bringen, der darauf gestützt ist, was über ihr Plätzchen bekannt ist. Wenn das Plätzchen fehlt oder anzeigt, dass der Verbraucher völlig asynchron ist, dann wird der Versorger, in der erfrischen Bühne, ein Hinzufügen für jeden Zugang senden, den es hat. Im idealen Fall enthält die erfrischen Bühne der Antwort nur eine löschen Phase mit gerade einem kleinen Satz dessen trägt bei (einschließlich derjenigen, die das aktuelle Ergebnis dessen vertreten, modifiziert), und löscht, die seit der Zeit der Verbraucher letzt synchronisiert mit dem Versorger vorgekommen sind. Jedoch, wegen des beschränkten Sitzungsklotz-Staates (auch nicht beharrlich) behalten im Versorger, kann eine gegenwärtige Phase besonders einschließlich der Präsentation aller unveränderten Einträge als ein der Andeutung (ineffizientes) Mittel erforderlich sein, was im Versorger seit dem Verbraucher letzt synchronisiert gelöscht worden ist.

Die Suche kann getan werden entweder in erfrischen oder in refreshAndPersist Weise, die das einbezieht, welche Stufen vorkommen. Die erfrischen Bühne kommt immer zuerst vor. Während der erfrischen Bühne können zwei Phasen vorkommen: Präsentieren Sie und löschen Sie, wo Gegenwart immer vorkommt, vorher löschen. Die Phasen werden über eine synchronisierte Info-Antwort abgegrenzt, die angibt, welche Phase vollendet wird. Das Erfrischen und dauert an Stufen werden auch über solche synchronisierte Info-Antwort abgegrenzt. Eine fakultative Optimierung, um eine Gruppe von Einträgen kompakter zu vertreten, die präsentiert oder gelöscht werden sollen, soll eine synchronisierte Info-Antwort verwenden, die einen syncIdSet enthält, der die Liste von entryUUID Werten jener Einträge identifiziert.

Die gegenwärtige Phase wird von der löschen Phase wie folgt unterschieden. Einträge, die unveränderte Einträge präsentieren, können nur in der gegenwärtigen Phase zurückgegeben werden. Einträge, die Einträge löschen, können nur in der löschen Phase zur Verfügung gestellt werden. In jeder Phase, tragen Sie bei Einträge (einschließlich fügt hinzu, dass alle aktuellen Attribute von modifizierten Einträgen vertreten), kann zurückgegeben werden. Am Ende einer gegenwärtigen Phase ist jeder Zugang, den der Verbraucher hat, der in einem hinzufügen Zugang oder gegenwärtiger Antwort während der gegenwärtigen Phase nicht identifiziert wurde, implizit nicht mehr im Versorger und muss so am Verbraucher gelöscht werden, um den Verbraucher mit dem Versorger zu synchronisieren.

Sobald die andauern Bühne beginnt, sendet der Versorger Suchergebnisse, die nur das Hinzufügen anzeigen, modifizieren und von Einträgen (keine gegenwärtigen unveränderten Zugang-Anzeigen) für jene geänderten Einträge löschen, seitdem die erfrischen Bühne vollendet hat. Die andauern Bühne geht unbestimmt weiter, bedeutend, dass Suche keine "getane" Endantwort hat. Im Vergleich in der erfrischen Weise kommt nur eine erfrischen Bühne vor, und solche Bühne vollendet mit einer getanen Antwort, die auch die Gegenwart beendet oder löschen Sie Phase (welch auch immer Phase zurzeit aktiv war).

Delta-syncrepl

Dieses Protokoll behält eine beharrliche Datenbank dessen schreiben Zugänge (Änderungen) und kann vertreten jeder modifiziert genau (Bedeutung nur der Attribute, die sich geändert haben). Darauf wird noch auf dem Standard syncrepl auf Spezifizierung gebaut, die immer Änderungen als ganze Einträge sendet. Aber im Delta-syncrepl werden die übersandten Einträge wirklich von einer Klotz-Datenbank gesandt, wo jede Änderung in der Hauptdatenbank als ein Klotz-Zugang registriert wird. Die Klotz-Einträge werden mit dem LDAP-Klotz-Diagramm registriert.

Siehe auch

• Liste der LDAP Software

Links

• Die Website von OpenLDAP
• Das Projekt von OpenLDAP
• Das Fundament von OpenLDAP
• Software von OpenLDAP
• Publikum von OpenLDAP lizenziert
• Mit libldap, Ein Tutorenkurs auf der Kunden-API von OpenLDAP
• Ein Artikel OpenLDAP Update von Marty Heyman am 13. September 2007