Das Leichtgewichtsverzeichniszugriffsprotokoll (LDAP) ist ein Anwendungsprotokoll, um auf verteilte Verzeichnisinformationsdienstleistungen über ein Netz von Internet Protocol (IP) zuzugreifen und sie aufrechtzuerhalten. LDAP wird in Bezug auf ASN.1 definiert und hat das Verwenden BER übersandt.

Verzeichnisdienstleistungen können jeden organisierten Satz von Aufzeichnungen häufig mit einer hierarchischen Struktur wie ein korporatives elektronisches Postverzeichnis zur Verfügung stellen. Ähnlich ist ein Telefonbuch eine Liste von Unterzeichneten mit einer Adresse und einer Telefonnummer.

LDAP wird in einer Reihe von Standardspur-Bitten von Internet Engineering Task Force (IETF) um Anmerkungen (RFCs) angegeben. Die letzte Version ist Version 3, veröffentlicht als RFC 4510.

Ursprung und Einflüsse

Das Fernmeldefirmenverstehen von Verzeichnisvoraussetzungen wurde nach ungefähr 70 Jahren des Produzierens und der Betriebstelefonbücher gut entwickelt. Diese Gesellschaften haben das Konzept von Verzeichnisdienstleistungen zur Informationstechnologie und dem Computernetzwerkanschluss, ihr Eingang eingeführt, der in der umfassenden X.500 Spezifizierung, einem Gefolge von Protokollen kulminiert, die von International Telecommunication Union (ITU) in den 1980er Jahren erzeugt sind.

Auf X.500 Verzeichnisdienstleistungen wurde über X.500 Directory Access Protocol (DAP) traditionell zugegriffen, das den Protokoll-Stapel von Open Systems Interconnection (OSI) verlangt hat. LDAP war ursprünglich beabsichtigt, um ein alternatives Leichtgewichtsprotokoll zu sein, um auf X.500 Verzeichnisdienstleistungen durch das einfachere (und jetzt weit verbreitet) TCP/IP Protokoll-Stapel zuzugreifen. Dieses Modell des Verzeichniszugangs wurde vom KOCHGESCHIRR und den Telefonauskunft-Dienstprotokollen geliehen.

Eigenständige LDAP Verzeichnisserver sind bald gefolgt, wie Verzeichnisserver getan hat, die sowohl DAP als auch LDAP unterstützen. Der Letztere ist populär in Unternehmen geworden, weil LDAP jedes Bedürfnis entfernt hat, ein OSI Netz einzusetzen. Heute können X.500 Verzeichnisprotokolle einschließlich DAP auch direkt über TCP/IP verwendet werden.

Das Protokoll wurde von Tim Howes von der Universität Michigans, Steve Kille von Isode Limited und Wengyik Yeong von Performance Systems International um 1993 ursprünglich geschaffen. Mark Wahl von Critical Angle Inc., Tim Howes und Steve Kille haben Arbeit 1996 an einer neuen Version von LDAP, LDAPv3 unter der Ägide Internet Engineering Task Force (IETF) angefangen. LDAPv3, zuerst veröffentlicht 1997, ersetzter LDAPv2 und hinzugefügte Unterstützung für die Dehnbarkeit, hat die Einfache Beglaubigung und Sicherheit Schicht integriert, und hat besser das Protokoll zur 1993-Ausgabe von X.500 ausgerichtet. Die weitere Entwicklung der LDAPv3 Spezifizierungen selbst und zahlreicher Erweiterungen, die Eigenschaften zu LDAPv3 hinzufügen, ist durch den IETF durchgekommen.

In den frühen Technikstufen von LDAP war es als Leichtgewichtsverzeichnisbrowsing-Protokoll oder LDBP bekannt. Es wurde mit der Vergrößerung des Spielraums des Protokolls außer dem Verzeichnisdurchsuchen und der Suche umbenannt, um Verzeichnisaktualisierungsfunktionen einzuschließen. Ihm wurde sein Leichtgewichtsname gegeben, weil es nicht als Netz intensiv als sein DAP Vorgänger war und leichter so über das Internet wegen seines relativ bescheidenen Bandbreite-Gebrauchs durchgeführt wurde.

LDAP hat nachfolgende Internetprotokolle, einschließlich späterer Versionen von X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML) und Service Location Protocol (SLP) beeinflusst.

Protokoll-Übersicht

Ein Kunde fängt eine LDAP Sitzung an, indem er zu einem LDAP Server, genannt Directory System Agent (DSA), standardmäßig auf dem TCP Hafen 389 in Verbindung steht. Der Kunde sendet dann eine Operationsbitte an den Server, und der Server sendet Antworten dafür. Mit einigen Ausnahmen braucht der Kunde nicht auf eine Antwort vor dem Senden der folgenden Bitte zu warten, und der Server kann die Antworten in jeder Ordnung senden.

Der Kunde kann um die folgenden Operationen bitten:

• StartTLS — verwenden die LDAPv3 Erweiterung von Transport Layer Security (TLS) für eine sichere Verbindung
• Binden Sie — beglaubigen und geben LDAP Protokoll-Version an
• Suchen Sie — suchen und/oder bekommen Verzeichniseinträge wieder
• Vergleichen Sie sich — Test, wenn ein genannter Zugang einen gegebenen Attribut-Wert enthält
• Fügen Sie einen neuen Zugang hinzu
• Löschen Sie einen Zugang
• Modifizieren Sie einen Zugang
• Modifizieren Sie Distinguished Name (DN) — bewegen oder benennen einen Zugang um
• Hemmungslosigkeit — bricht eine vorherige Bitte ab
• Verlängerte Operation — allgemeine Operation hat gepflegt, andere Operationen zu definieren
• Binden Sie los — schließen die Verbindung (nicht das Gegenteil dessen Bindet)

Außerdem kann der Server "Freiwillige Ankündigungen" senden, die nicht Antworten auf jede Bitte, z.B davor Zeiten eine Verbindung sind.

Eine allgemeine alternative Methode, LDAP Kommunikation zu sichern, verwendet einen SSL Tunnel. Das wird in LDAP URL-ADRESSEN durch das Verwenden des URL-ADRESSE-Schemas "ldaps" angezeigt. Der Verzug-Hafen für LDAP über SSL ist 636. Der Gebrauch von LDAP über SSL war in der LDAP Version 2 (LDAPv2) üblich, aber es wurde in jeder formellen Spezifizierung nie standardisiert. Dieser Gebrauch ist zusammen mit LDAPv2 missbilligt worden, der 2003 offiziell pensioniert war.

Verzeichnisstruktur

Die LDAP Protokoll-Zugriffsverzeichnisse, die der 1993-Ausgabe des X.500 Modells folgen:

• Ein Zugang besteht aus einer Reihe von Attributen.
• Ein Attribut hat einen Namen (ein Attribut-Typ oder Attribut-Beschreibung) und ein oder mehr Werte. Die Attribute werden in einem Diagramm (sieh unten) definiert.
• Jeder Zugang hat einen einzigartigen Bezeichner: sein Distinguished Name (DN). Das besteht aus seinem Relative Distinguished Name (RDN), der von etwas Attribut (En) im Zugang gebaut ist, der vom DN des Elternteilzugangs gefolgt ist. Denken Sie an den DN als der volle Dateipfad und der RDN als sein Verhältnisdateiname in seiner Elternteilmappe (z.B, wenn /foo/bar/myfile.txt der DN wären, dann myfile.txt würde der RDN sein).

Seien Sie

bewusst, dass ein DN die Lebenszeit des Zugangs zum Beispiel umstellen kann, wenn Einträge bewegt werden

innerhalb eines Baums. Zu zuverlässig und identifizieren eindeutig Einträge, ein UUID könnte im Satz der betrieblichen Attribute des Zugangs zur Verfügung gestellt werden.

Ein Zugang kann wie das, wenn vertreten, in LDAP Data Interchange Format (LDIF) aussehen (LDAP selbst ist ein binäres Protokoll):

dn: cn=John Doe, dc=example, dc=com

cn: Unbekannter

givenName: John

sn: Hirschkuh

telephoneNumber: +1 888 555 6789

telephoneNumber: +1 888 555 1232

Post: john@example.com

Betriebsleiter: cn=Barbara Doe, dc=example, dc=com

objectClass: inetOrgPerson

objectClass: organizationalPerson

objectClass: Person

objectClass: Spitze

"dn" ist der ausgezeichnete Name des Zugangs; es ist weder ein Attribut noch ein Teil des Zugangs. "cn=John Doe" ist der RDN des Zugangs (Ausgezeichneter Verhältnisname), und "dc=example, dc=com", ist der DN des Elternteilzugangs, wo "dc" 'Bereichsbestandteil' anzeigt. Die anderen Linien zeigen die Attribute im Zugang. Attribut-Namen sind normalerweise mnemonische Schnuren, wie "cn" für die gemeinsame Bezeichnung, "dc" für den Bereichsbestandteil, "die Post" für die E-Mail-Adresse und "sn" für den Nachnamen.

Ein Server hält einen Subbaum, der von einem spezifischen Zugang, z.B "dc=example, dc=com" und seine Kinder anfängt. Server können auch Verweisungen auf andere Server halten, so konnte ein Versuch, "ou=department, dc=example, dc=com" zuzugreifen, einen referral oder Verlängerungsverweisung auf einen Server zurückgeben, der dass ein Teil des Verzeichnisbaums meint. Der Kunde kann sich dann mit dem anderen Server in Verbindung setzen. Einige Server unterstützen auch das Anketten, was bedeutet, dass sich der Server mit dem anderen Server in Verbindung setzt und die Ergebnisse dem Kunden zurückgibt.

LDAP definiert selten jede Einrichtung: Der Server kann die Werte eines Attributes, der Attribute in einem Zugang und den Einträgen zurückgeben, die durch eine Suchaktion in jeder Ordnung gefunden sind. Das folgt aus den formellen Definitionen - ein Zugang wird als eine Reihe von Attributen definiert, und ein Attribut ist eine Reihe von Werten und geht unter braucht nicht bestellt zu werden.

Operationen

:Expand-Diskussion von referral Antworten auf verschiedene Operationen, modifizieren Sie besonders zum Beispiel, wo alles modifiziert, muss von Repliken bis ein Master-Verzeichnis geleitet werden.

Binden Sie (beglaubigen)

Die Binden Operation gründet den Beglaubigungsstaat für eine Verbindung. Einfach Binden kann den DN des Benutzers und Kennwort in plaintext senden, so sollte die Verbindung mit Transport Layer Security (TLS) geschützt werden. Der Server überprüft normalerweise das Kennwort gegen das UserPassword-Attribut im genannten Zugang. Anonym Binden (mit leerem DN, und Kennwort) fasst die Verbindung zum anonymen Staat neu. SASL (Einfache Beglaubigung und Sicherheit Schicht) Binden stellt Beglaubigungsdienstleistungen durch eine breite Reihe von Mechanismen z.B zur Verfügung. Kerberos oder das Kundenzertifikat mit TLS gesandt.

Binden Sie auch setzt die LDAP Protokoll-Version. Die Version ist eine ganze Zahl und muss zurzeit entweder 2 (zwei) oder 3 (drei) sein, obwohl der Standard ganze Zahlen zwischen 1 und 127 (einschließlich) im Protokoll unterstützt. Wenn der Kunde um eine Version bittet, die der Server nicht unterstützt, muss der Server den Ergebnis-Code in der binden Antwort auf den Code für einen Protokoll-Fehler setzen. Normalerweise sollten Kunden LDAPv3 verwenden, der der Verzug im Protokoll, aber nicht immer in LDAP Bibliotheken ist.

Binden Sie musste die erste Operation in einer Sitzung in LDAPv2 sein, aber ist in LDAPv3 (die LDAP aktuelle Version) nicht erforderlich.

Suchen Sie und vergleichen Sie sich

Die Suchaktion wird verwendet, um sowohl zu suchen als auch Einträge zu lesen. Seine Rahmen sind:

baseObject: Der Name des Grundgegenstand-Zugangs (oder vielleicht die Wurzel), hinsichtlich dessen die Suche durchgeführt werden soll.

Spielraum: Welche Elemente unter dem baseObject zu suchen. Das kann sein (suchen Sie gerade den genannten Zugang, normalerweise verwendet, um einen Zugang zu lesen), (Einträge sofort unter dem Grund-DN), oder (der komplette Subbaum, der am Grund-DN anfängt).

Filter: Kriterien, um im Auswählen von Elementen innerhalb des Spielraums zu verwenden. Zum Beispiel wird der Filter "Personen" auswählen (Elemente von objectClass), wo die zusammenpassenden Regeln dafür und bestimmen, ob die Werte für jene Attribute die Filterbehauptung vergleichen. Bemerken Sie, dass ein häufiger Irrtum ist, dass LDAP Daten gegen den Fall unempfindlich sind, wohingegen tatsächlich das Zusammenbringen von Regeln und die Einrichtung von Regeln das Zusammenbringen, die Vergleiche und die Verhältniswertbeziehungen bestimmen. Wenn die Beispiel-Filter erforderlich waren, den Fall des Attribut-Werts zu vergleichen, muss ein ausziehbarer Match-Filter, zum Beispiel, verwendet werden

derefAliases: Ob und wie man Deckname-Einträgen folgt (Einträge, die sich auf andere Einträge beziehen),

Attribute: Der der Rückkehr in Ergebnis-Einträgen zuschreibt.

sizeLimit, timeLimit: Maximale Zahl von Einträgen zur Rückkehr, und maximale Zeit, um Suche zu erlauben, zu laufen. Diese Werte können jedoch keine Beschränkungen die Server-Plätze auf der Größe-Grenze und Frist überreiten.

typesOnly: Geben Sie Attribut-Typen nur zurück, schreiben Sie Werte nicht zu.

Der Server gibt die zusammenpassenden Einträge und potenziell Verlängerungsverweisungen zurück. Diese können in jeder Ordnung zurückgegeben werden. Das Endresultat wird den Ergebnis-Code einschließen.

Die Vergleichen Operation nimmt einen DN, einen Attribut-Namen und einen Attribut-Wert und überprüft, ob der genannte Zugang dieses Attribut mit diesem Wert enthält.

Aktualisierungsdaten

Fügen Sie hinzu, Löschen Sie, und Modifizieren Sie DN - alle verlangen den DN des Zugangs, der geändert werden soll.

Modifizieren Sie nimmt eine Liste von Attributen, um zu modifizieren, und die Modifizierungen zu jedem: Löschen Sie das Attribut oder einige Werte, fügen Sie neue Werte hinzu, oder ersetzen Sie die aktuellen Werte durch die neuen.

Fügen Sie hinzu, dass Operationen auch zusätzliche Attribute und Werte für jene Attribute haben können.

Modifizieren Sie DN (bewegen Sie sich Zugang/umbenennen Sie) nimmt den neuen RDN (Ausgezeichneter Verhältnisname), fakultativ der DN des neuen Elternteils und eine Fahne, die sagt, ob man den Wert (E) im Zugang löscht, die den alten RDN vergleichen. Der Server kann Umbenennung von kompletten Verzeichnissubbäumen unterstützen.

Eine Aktualisierungsoperation ist atomar: Andere Operationen werden entweder den neuen Zugang oder den alten sehen. Andererseits definiert LDAP Transaktionen von vielfachen Operationen nicht: Wenn Sie einen Zugang lesen und ihn dann modifizieren, kann ein anderer Kunde den Zugang inzwischen aktualisiert haben. Server können Erweiterungen durchführen, die das unterstützen, dennoch.

Verlängerte Operationen

Die Verlängerte Operation ist eine allgemeine LDAP Operation, die neue Operationen definieren kann, die nicht ein Teil der ursprünglichen Protokoll-Spezifizierung waren. StartTLS ist eine der bedeutendsten Erweiterungen. Andere Beispiele schließen das Annullieren ein, und Kennwort Modifizieren.

StartTLS

Die Operation von StartTLS gründet Transportschicht-Sicherheit (der Nachkomme von SSL) auf der Verbindung. Es kann Datengeheimnis zur Verfügung stellen (um Daten davor zu schützen, durch Dritte beobachtet zu werden), und/oder Datenintegritätsschutz (der die Daten davor schützt herumzubasteln). Während der TLS Verhandlung sendet der Server sein X.509 Zertifikat, um seine Identität zu beweisen. Der Kunde kann auch ein Zertifikat senden, um seine Identität zu beweisen. Nach dem Tun so kann der Kunde dann SASL/EXTERNAL verwenden. Indem er den SASL/EXTERNAL verwendet, bittet der Kunde, dass der Server seine Identität vom Ausweis zur Verfügung gestellt auf niedrigerer Ebene (wie TLS) ableitet. Obwohl technisch der Server jede an jeder niedrigeren Ebene gegründete Identitätsinformation verwenden kann, normalerweise wird der Server die durch TLS gegründete Identitätsinformation verwenden.

Server unterstützen auch häufig den umgangssprachlichen "LDAPS" ("Sichern LDAP", allgemein bekannt als "LDAP über SSL") das Protokoll auf einem getrennten Hafen, standardmäßig 636. LDAPS unterscheidet sich von LDAP auf zwei Weisen:

1) darauf stehen in Verbindung, der Kunde und Server setzen TLS ein, bevor irgendwelche LDAP Nachrichten (ohne eine Operation von StartTLS) und übertragen werden

2) die LDAPS Verbindung muss nach dem TLS Verschluss geschlossen werden.

Es sollte bemerkt werden, dass einige "LDAPS" Kundenbibliotheken nur encrypt Kommunikation, sie den Hostnamen gegen den Namen im gelieferten Zertifikat nicht überprüfen

LDAPS wurde mit LDAPv2 verwendet, weil die Operation von StartTLS noch nicht definiert worden war. Der Gebrauch von LDAPS wird missbilligt, und moderne Software sollte nur StartTLS verwenden.

Hemmungslosigkeit

Die Hemmungslosigkeitsoperation bittet, dass der Server eine durch einen Nachrichtenpersonalausweis genannte Operation abbricht. Der Server braucht die Bitte nicht zu beachten. Leider senden weder Hemmungslosigkeit noch eine erfolgreich aufgegebene Operation eine Antwort. Ein ähnlicher Annulliert erweiterte Operation sendet Antworten, aber nicht alle Durchführungen unterstützen das.

Losbinden

Die Losbinden Operation gibt irgendwelche hervorragenden Operationen auf und schließt die Verbindung. Es hat keine Antwort. Der Name ist des historischen Ursprungs, und ist nicht das Gegenteil der Binden Operation.

Kunden können eine Sitzung abbrechen, indem sie einfach die Verbindung schließen, aber sie sollten verwenden binden Los. Binden Sie los erlaubt dem Server, die Verbindung und kostenlosen Quellen anmutig zu schließen, die es für einige Zeit bis zum Entdecken sonst behalten würde, dass der Kunde die Verbindung aufgegeben hatte. Es beauftragt auch den Server, Operationen zu annullieren, die annulliert werden können, und Antworten für Operationen nicht zu senden, die nicht annulliert werden können.

LDAP URL-ADRESSEN

Ein LDAP URL-ADRESSE-Format besteht, den Kunden in unterschiedlichen Graden und Server-Rückkehr in referrals und Verlängerungsverweisungen unterstützen (sieh RFC 4516):

ldap://host:port/DN?attributes?scope?filter?extensions

Die meisten Bestandteile, die unten beschrieben sind, sind fakultativ.

• Gastgeber ist der FQDN oder die IP Adresse des LDAP Servers, um zu suchen.
• Hafen ist der Netzhafen (Verzug-Hafen 389) vom LDAP Server.
• DN ist der ausgezeichnete Name, um als die Suchbasis zu verwenden.
• Attribute sind eine Komma-getrennte Liste von Attributen, um wiederzubekommen.
• Spielraum gibt das Suchspielraum an und kann "Basis" (der Verzug), "ein" oder "U-Boot" sein.
• Filter ist ein Suchfilter. Zum Beispiel wie definiert, in RFC 4515.
• Erweiterungen sind Erweiterungen auf das LDAP URL-ADRESSE-Format.

Zum Beispiel, "" bezieht sich auf alle Benutzerattribute im Zugang des Unbekannten darin, während "" nach dem Zugang im Verzug-Server sucht (bemerken Sie den dreifachen Hieb, den Gastgeber und das doppelte Fragezeichen weglassend, die Attribute weglassend). Als in anderen URL-ADRESSEN müssen spezielle Charaktere Prozent-verschlüsselt werden.

Es gibt ein ähnliches Sonder-URL-ADRESSE-Schema für LDAP über SSL. Das sollte mit LDAP mit TLS nicht verwirrt sein, der mit der Operation von StartTLS mit dem Standardschema erreicht wird.

Diagramm

Der Inhalt der Einträge in einem Subbaum wird durch ein als ein Verzeichnisinformationsbaum (DIT) bekanntes Diagramm geregelt.

Das Diagramm eines Verzeichnisservers definiert eine Reihe von Regeln, die die Arten der Information regeln, die der Server halten kann. Es hat mehrere Elemente, einschließlich:

• Attribut-Syntaxen — Geben Auskunft über die Art der Information, die in einem Attribut versorgt werden kann.
• Das Zusammenbringen von Regeln — Gibt Auskunft darüber, wie man Vergleiche gegen Attribut-Werte macht.
• Das Zusammenbringen des Regel-Gebrauches — zeigt An, welche Attribut-Typen in Verbindung mit einer besonderen zusammenpassenden Regel verwendet werden können.
• Attribut-Typen — Definieren einen Gegenstand-Bezeichner (OID) und eine Reihe von Namen, die verwendet werden können, um sich auf ein gegebenes Attribut und Partner zu beziehen, die mit einer Syntax und Satz zuschreiben, Regeln zu vergleichen.
• Gegenstand-Klassen — Definieren genannte Sammlungen von Attributen und teilen sie in Sätze von erforderlichen und fakultativen Attributen ein.
• Namenformen — Definieren Regeln für den Satz von Attributen, die in den RDN für einen Zugang eingeschlossen werden sollten.
• Zufriedene Regeln — Definieren zusätzliche Einschränkungen über die Gegenstand-Klassen und Attribute, die in Verbindung mit einem Zugang verwendet werden können.
• Struktur-Regel — Definiert Regeln, die die Arten von untergeordneten Einträgen regeln, die ein gegebener Zugang haben kann.

Attribute sind die Elemente, die dafür verantwortlich sind, Information in einem Verzeichnis zu versorgen, und das Diagramm definiert die Regeln, für die Attribute in einem Zugang, den Arten von Werten verwendet werden können, die jene Attribute haben können, und wie Kunden mit jenen Werten aufeinander wirken können.

Kunden können von den Diagramm-Elementen erfahren, dass der Server durch das Wiederbekommen eines passenden Subdiagramm-Subzugangs unterstützt.

Das Diagramm definiert Gegenstand-Klassen. Jeder Zugang muss ein ObjectClass-Attribut haben, genannt im Diagramm definierte Klassen enthaltend. Die Diagramm-Definition der Klassen eines Zugangs definiert, welchen Gegenstand der Zugang - z.B eine Person, Organisation oder Gebiet vertreten kann. Die Gegenstand-Klassendefinitionen definieren auch die Liste von Attributen, die Werte und die Liste von Attributen enthalten müssen, die Werte enthalten können.

Zum Beispiel könnte ein Zugang, der eine Person vertritt, den Klassen "Spitze" und "Person" gehören. Die Mitgliedschaft in der "Person"-Klasse würde verlangen, dass der Zugang die "sn-" und "Cn"-Attribute enthält, und dem Zugang auch erlaubt, "userPassword", "telephoneNumber", und andere Attribute zu enthalten. Da Einträge vielfache Werte von ObjectClasses haben können, hat jeder Zugang einen Komplex von fakultativen und obligatorischen Attribut-Sätzen, die von der Vereinigung der Gegenstand-Klassen gebildet sind, die es vertritt. ObjectClasses kann geerbt werden, und ein einzelner Zugang kann vielfache Werte von ObjectClasses haben, die die verfügbaren und erforderlichen Attribute des Zugangs selbst definieren. Eine Parallele zum Diagramm eines objectClass ist eine Klassendefinition und ein Beispiel in der Objektorientierten Programmierung, LDAP objectClass und dem LDAP Zugang beziehungsweise vertretend.

Verzeichnisserver können das Verzeichnisdiagramm veröffentlichen, einen Zugang an einem durch das subschemaSubentry betriebliche Attribut des Zugangs gegebenen Grund-DN kontrollierend. (Ein betriebliches Attribut beschreibt Operation des Verzeichnisses aber nicht der Benutzerinformation und wird nur von einer Suche zurückgegeben, wenn es ausführlich gebeten wird.)

Server-Verwalter können zusätzliche Diagramm-Einträge zusätzlich zu den zur Verfügung gestellten Diagramm-Elementen hinzufügen. Ein Diagramm, um individuelle Leute innerhalb von Organisationen zu vertreten, wird ein weißes Seitendiagramm genannt.

Schwankungen

Viel von der Server-Operation wird zum implementor oder Verwalter verlassen zu entscheiden. Entsprechend können Server aufgestellt werden, um ein großes Angebot an Drehbüchern zu unterstützen.

Zum Beispiel wird die Datenlagerung im Server nicht angegeben - der Server kann flache Dateien, Datenbanken verwenden, oder gerade ein Tor zu einem anderen Server sein. Zugriffskontrolle wird nicht standardisiert, obwohl es Arbeit daran gegeben hat und es allgemein verwendete Modelle gibt. Die Kennwörter von Benutzern können in ihren Einträgen oder anderswohin versorgt werden. Der Server kann sich weigern, Operationen durchzuführen, wenn er wünscht, und setzen Sie verschiedene Grenzen fest.

Die meisten Teile von LDAP sind ausziehbar. Beispiele: Man kann neue Operationen definieren. Steuerungen können Bitten und Antworten modifizieren, um z.B um sortierte Suchergebnisse zu bitten. Neue Suchspielraume und Binden Methoden können definiert werden. Attribute können Optionen haben, die ihre Semantik modifizieren können.

Andere Datenmodelle

Da LDAP Schwung gewonnen hat, haben Verkäufer es als ein Zugriffsprotokoll zu anderen Dienstleistungen zur Verfügung gestellt. Die Durchführung arbeitet dann die Daten um, um das LDAP/X.500 Modell nachzuahmen, aber wie nah diesem Modell gefolgt wird, ändert sich. Zum Beispiel gibt es Software zum Zugang SQL Datenbanken durch LDAP, wenn auch LDAP sich dazu nicht sogleich leiht. X.500 Server können LDAP ebenso unterstützen.

Ähnlich werden in anderen Typen von Datenläden vorher gehaltene Daten manchmal zu LDAP Verzeichnissen bewegt. Zum Beispiel können Benutzer von Unix und Gruppeninformation in LDAP versorgt und über PAM und NSS Module zugegriffen werden. LDAP wird häufig durch andere Dienstleistungen für die Beglaubigung verwendet.

Ein Beispiel solchen Datenmodells ist das LEIM-Diagramm, das in einem verteilten Informationssystem verwendet wird, das auf LDAP gestützt ist, die Benutzern, Anwendungen und Dienstleistungen ermöglichen zu entdecken, welche Dienstleistungen in einer Bratrost-Infrastruktur und weiterer Information über ihre Struktur und Staat bestehen.

Gebrauch

Ein LDAP Server kann referrals in andere Server für Bitten zurückgeben, dass es sich nicht erfüllen kann. Das verlangt eine Namengeben-Struktur für LDAP Einträge, so kann man einen Server finden, der einen gegebenen DN oder bemerkenswerten Namen, ein Konzept definiert im X.500 Verzeichnis und auch verwendet in LDAP hält. Eine andere Weise, LDAP Server für eine Organisation ausfindig zu machen, ist eine DNS Server-Quellenaufzeichnung (SRV).

Eine Organisation mit dem Gebiet kann example.org das Spitzenniveau LDAP DN verwenden (wo dc Bereichsbestandteil bedeutet). Wenn der LDAP Server auch ldap.example.org, das Spitzenniveau der Organisation genannt wird, wird LDAP URL-ADRESSE.

In erster Linie werden zwei allgemeine Stile des Namengebens sowohl in X.500 [2008] als auch in LDAPv3 verwendet. Diese werden in den ITU Spezifizierungen und IETF RFCs dokumentiert. Die ursprüngliche Form nimmt den Spitzenniveau-Gegenstand als der Landgegenstand, wie c=US, c=FR. Das Bereichsteilmodell verwendet das Modell, das oben beschrieben ist. Ein Beispiel des Landes das basierte Namengeben konnte c=FR, o=Some Organisation, ou=Some Organisatorische Einheit L=Locality, oder in den Vereinigten Staaten sein: c=US, st=CA, o=Some Organisation ou=Organizational Einheit, L=Locality und CN=Common-Name.

Siehe auch

• Bundesnamengeben-Dienst
• Globaler Verzeichnisserver
• Hesiod (nennen Dienst)
• Hierarchisches Datenbankmodell
• Schlüsselserver (kryptografischer)
• LDAP Anwendungsprogramm-Schnittstelle
• Liste der LDAP Software
• Einfache Beglaubigung und Sicherheitsschicht (SASL)
• ITU-T Rec. X.680, "Abstrakte Syntax-Notation Eine (ASN.1) - Spezifizierung der Grundlegenden Notation", 1994
• Grundlegende Verschlüsselungsregeln (BER) - ITU-T Rec. X.690, "Spezifizierung von ASN.1-Verschlüsselungsregeln: Grundlegende, Kanonische und Ausgezeichnete Verschlüsselungsregeln", 1994
• RFC 3641 - Generic String Encoding Rules (GSER) für ASN.1 Typen
• RFC 4346 - Die TLS Protokoll-Version 1.1
• RFC 4422 - Einfache Beglaubigung und Sicherheitsschicht (SASL)
• SASL Mechanismen haben sich bei IANA eingeschrieben

Weiterführende Literatur

Links

• Devshed.com, LDAP, Einen einfachen, leichten einleitenden Tutorenkurs für LDAP Verstehend.
• Skills-1st.co.uk, LDAP Diagramm-Design
• Capitalhead.com gibt Fehlerbeseitigung LDAP SSL Verbindung zwischen Microsoft ILM/MIIS & Novell eDirectory 8.7.3 aus
• Prasannatech.com, LDAP Diagramm-Design - Eine Fallstudie

RFCs

LDAP wird in einer Reihe der Bitte um Anmerkungsdokumente angegeben:

• RFC 4510 - LDAP: Technische Spezifizierungsautokarte (Obsoletes: RFC 2251, RFC 2252, RFC 2253, RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC 2830, RFC 3377, RFC 3771)
• RFC 4511 - LDAP: Das Protokoll (Obsoletes RFC 2251, RFC 2830 & RFC 3771)
• RFC 4512 - LDAP: Verzeichnisinformationsmodelle (Obsoletes RFC 2251, RFC 2252, RFC 2256 & RFC 3674)
• RFC 4513 - LDAP: Beglaubigungsmethoden und Sicherheit Mechanismen (Obsoletes RFC 2251, RFC 2829 & RFC 2830)
• RFC 4514 - LDAP: Schnur-Darstellung von Ausgezeichneten Namen (Obsoletes RFC 2253)
• RFC 4515 - LDAP: Schnur-Darstellung von Suchfiltern (Obsoletes RFC 2254)
• RFC 4516 - LDAP: Internetadresse (Obsoletes RFC 2255)
• RFC 4517 - LDAP: Syntaxen und das Zusammenbringen von Regeln (Obsoletes RFC 2252 & RFC 2256, Aktualisierungen RFC 3698)
• RFC 4518 - LDAP: Internationalisierte Schnur-Vorbereitung
• RFC 4519 - LDAP: Diagramm für Benutzeranwendungen (Obsoletes RFC 2256, Aktualisierungen RFC 2247, RFC 2798 & RFC 2377)

Das folgende RFCs Detail LDAP-spezifische Beste Aktuelle Methoden:

• RFC 4520 (auch BCP 64) - Rücksichten von Internet Assigned Numbers Authority (IANA) für Lightweight Directory Access Protocol (LDAP) (hat RFC 3383 ersetzt)
• RFC 4521 (auch BCP 118) - Rücksichten für Erweiterungen von Lightweight Directory Access Protocol (LDAP)

Der folgende ist eine teilweise Liste von RFCs das Spezifizieren von LDAPv3 Erweiterungen:

• RFC 2247 - Gebrauch von DNS Gebieten in ausgezeichneten Namen (Aktualisiert durch RFC 4519 & RFC 4524)
• RFC 2307 - LDAP als ein Netzinformationsdienst Verwendend
• RFC 2589 - LDAPv3: Erweiterungen von Dynamic Directory Services
• RFC 2649 - LDAPv3 Betriebliche Unterschriften
• RFC 2696 - LDAP Einfache Paginierte Ergebnis-Kontrolle
• RFC 2798 - inetOrgPerson LDAP Gegenstand-Klasse (Aktualisiert durch RFC 3698, RFC 4519 & RFC 4524)
• RFC 2830 - LDAPv3: Erweiterung für die Transportschicht-Sicherheit
• RFC 2849 - LDAP Data Interchange Format (LDIF)
• RFC 2891 - das Server-Seitensortieren von Suchergebnissen
• RFC 3045 - Speicherung der Verkäufer-Information im LDAP lassen DSE einwurzeln
• RFC 3062 - LDAP Kennwort Modifizieren Verlängerte Operation
• RFC 3296 - Genannt Untergeordnete Verweisungen in LDAP Verzeichnissen
• RFC 3671 - Gesammelte Attribute in LDAP
• RFC 3672 - Subeinträge in LDAP
• RFC 3673 - LDAPv3: Alle Betrieblichen Attribute
• RFC 3687 - LDAP Bestandteil das Zusammenbringen von Regeln
• RFC 3698 - LDAP: Das Zusätzliche Zusammenbringen von Regeln
• RFC 3829 - LDAP Genehmigungsidentitätssteuerungen
• RFC 3866 - Sprachanhängsel und Reihen in LDAP
• RFC 3909 - LDAP Annullieren Operation
• RFC 3928 - LDAP Kundenaktualisierungsprotokoll
• RFC 4370 - LDAP Proxied Genehmigungskontrolle
• RFC 4373 - LBURP
• RFC 4403 - LDAP Diagramm für UDDI
• RFC 4522 - LDAP: Binäre Verschlüsselungsauswahl
• RFC 4523 - LDAP: X.509 Zertifikat-Diagramm
• RFC 4524 - LDAP: KOSINUS-Diagramm (ersetzt RFC 1274)
• RFC 4525 - LDAP: Modifizieren-Zunahme-Erweiterung
• RFC 4526 - LDAP: Absolute Wahre und Falsche Filter
• RFC 4527 - LDAP: Lesen Sie Zugang-Steuerungen
• RFC 4528 - LDAP: Behauptungskontrolle
• RFC 4529 - LDAP: Anforderung von Attributen durch die Gegenstand-Klasse
• RFC 4530 - LDAP: entryUUID
• RFC 4531 - LDAP Umdrehungsoperation
• RFC 4532 - LDAP Wer bin ich? Operation
• RFC 4533 - LDAP Inhalt Synchronisierte Operation
• RFC 4876 - Konfigurationsprofil-Diagramm für LDAP-basierte Agenten
• RFC 5020 - LDAP entryDN Betriebliches Attribut

LDAPv2 wurde im folgenden RFCs angegeben:

• RFC 1777 - Leichtgewichtsverzeichniszugriffsprotokoll (hat RFC 1487 ersetzt)
• RFC 1778 - Die Schnur-Darstellung von Standardattribut-Syntaxen (hat RFC 1488 ersetzt)
• RFC 1779 - Eine Schnur-Darstellung von Ausgezeichneten Namen (hat RFC 1485 ersetzt)

LDAPv2 wurde zum historischen Status durch den folgenden RFC bewegt:

• RFC 3494 - Lightweight Directory Access Protocol version 2 (LDAPv2) zum Historischen Status