Das Lightweight Directory Access Protocol (LDAP) ist ursprünglich einProtokollzum Abfragen und Ändern vonVerzeichnisdiensten(eine Weiterentwicklung des DAP-Protokolls). Dieses Protokoll basiert aufTCP / IP. Es wurde jedoch weiterentwickelt, um einenStandardfür Verzeichnissystemedarzustellen, einschließlich einesDatenmodells, eines Namensmodells, eines LDAP-basierten Funktionsmodells, eines Sicherheitsmodells und eines Replikationsmodells. Es ist eine Baumstruktur, in der jeder der Knoten aus Attributen besteht, die ihren Werten zugeordnet sind. LDAP ist weniger komplex als dasvon derITU-T festgelegte X.500- Modell.
Die Benennung der Elemente, aus denen der Baum besteht (Wurzel, Zweige, Blätter), spiegelt häufig das politische, geografische oder organisatorische Modell der dargestellten Struktur wider. Der aktuelle Trend besteht darin, DNS- Namen für die Grundelemente des Verzeichnisses zu verwenden (Stamm- und erste Zweige, Domänenkomponenten oder dc =… ). Die tieferen Zweige des Verzeichnisses können Organisationseinheiten oder -gruppen ( Organisationseinheiten oder ou =… ), Personen ( gebräuchlicher Name oder cn =… oder sogar Benutzer- ID uid =… ) darstellen. Die Zusammenstellung aller Komponenten (von der genauesten bis zur allgemeinsten) eines Namens bildet seinen definierten Namen . Das folgende Beispiel zeigt zwei:
Die neueste Version des Protokolls ist LDAPv3. Diese Version wird von der IETF in mehreren RFCs definiert, beginnend mit RFC 4510.
LDAP wurde ursprünglich für den einfachen Zugriff auf X.500-Verzeichnisse entwickelt. Diese Verzeichnisse wurden traditionell mit dem X.500 Directory Access Protocol (DAP) abgefragt, für das der OSI-Modellprotokollstapel erforderlich war . Die Verwendung eines LDAP / DAP-Gateways ermöglichte den Zugriff auf einen DAP-Server in einem TCP / IP-Netzwerk. Dieses Verzeichnismodell wurde von DIXIE und Directory Assistance Service abgeleitet .
Das Aufkommen nativer LDAP-Verzeichnisse folgte schnell, ebenso wie das Aufkommen von Servern, die sowohl DAP als auch LDAP unterstützen. Verzeichnisse wurden in Unternehmen populär, da kein OSI-Netzwerk mehr bereitgestellt werden musste. Heutzutage können X.500- Verzeichniszugriffsprotokolle (einschließlich DAP) direkt über TCP / IP verwendet werden.
Das Protokoll wurde von Tim Howes der geschaffenen University of Michigan , Steve Kille von ISODE und Wengyik Yeong von Performance - Systems International in 1993 . Die folgenden Entwicklungen wurden von der Internet Engineering Task Force (IETF) geleitet.
Ursprünglich hieß das Protokoll LDBP ( Lightweight Directory Browsing Protocol ), da nur Daten gesucht werden konnten. Es wurde beim Hinzufügen neuer Möglichkeiten (Hinzufügen, Ändern) umbenannt.
LDAP hat eine Reihe von Internetprotokollen beeinflusst, darunter die neuesten Versionen von X.500 : XML Enabled Directory (XED), DSML ( Directory Services Markup Language ), SPML ( Service Provisioning Markup Language ) und SLP ( Service Location Protocol ).
Ein Client beginnt eine LDAP-Sitzung, indem er eine Verbindung zum TCP-Port 389 des Servers herstellt. Der Client sendet dann Betriebsanforderungen an den Server. Der Server sendet Antworten zurück. Mit wenigen Ausnahmen muss der Client nicht auf eine Antwort vom Server warten, um neue Anforderungen zu senden, und der Server kann seine Antworten in beliebiger Reihenfolge senden.
Sobald die Verbindung zum Server hergestellt ist, sind die typischen Vorgänge:
Darüber hinaus kann der Server unerwünschte Benachrichtigungen senden , die keine Antworten auf Anforderungen sind, z. B. bevor eine inaktive Verbindung geschlossen wird.
Eine Methode zum Sichern der LDAP-Kommunikation besteht in der Verwendung eines TLS / SSL- Tunnels . Bei Verwendung von URLs wird diese Verwendung durch den Namen des ldaps- Protokolls übersetzt , um ldap zu ersetzen . Der Standard-TCP-Port für ldaps ist 636.
Das LDAP-Protokoll verwendet die ASN.1- Notation und die Nachrichten werden mit dem BER- Binärformat codiert . Es wird jedoch eine Textdarstellung für eine Reihe von Attributen und Typen von ASN.1 verwendet.
LDAP-Verzeichnisse folgen dem X.500-Modell und seiner nativen mandantenfähigen Architektur :
Die Tatsache, dass Attribute mehrwertig sein können, ist ein wesentlicher Unterschied zwischen LDAP-Verzeichnissen und RDBMS . Wenn ein Attribut keinen Wert hat, fehlt es einfach im Eintrag.
Jeder Eintrag hat eine eindeutige Kennung, den Distinguished Name (DN). Es besteht aus dem Relative Distinguished Name (RDN), gefolgt vom DN des übergeordneten Namens . Es ist eine rekursive Definition. Wir können die Analogie mit einer anderen Baumstruktur machen, Dateisystemen; Der DN ist der absolute Pfad und der RDN der Pfad relativ zu einem Verzeichnis. Normalerweise ist die RDN eines Eintrags, der eine Person darstellt, das UID- Attribut :
dc=org | dc=example / \ ou=people ou=groups | uid=totoDie RDN von foo ist rdn: uid = foo , seine DN ist dn: uid = foo, ou = people, dc = example, dc = org .
Ein Eintrag kann wie folgt aussehen, wenn er als LDIF formatiert ist :
dn: cn=John Doe, dc=example, dc=org cn: John Doe givenName: John sn: Doe telephoneNumber: +1 555 6789 telephoneNumber: +1 555 1234 mail: [email protected] manager: cn=Barbara Doe, dc=exemple, dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: topdn ist der Name des Eintrags, es ist kein Attribut des Eintrags. "cn = John Doe" ist die RDN des Eintrags und "dc = Beispiel, dc = org" ist der DN seines übergeordneten Eintrags. Die anderen Zeilen zeigen die Attribute des Eintrags. Die Namen der Attribute sind manchmal Abkürzungen für die häufigsten: "cn" für den allgemeinen Namen , "dc" für die Domänenkomponente , "sn" für den Nachnamen .
Ein Server enthält einen Teilbaum, dessen Stamm ein bestimmter Eintrag ist, und alle seine untergeordneten Elemente, z. B. "dc = Beispiel, dc = org". Server können auch Verweise auf andere Server enthalten, sodass der Zugriff auf einen Eintrag ("ou = ein Dienst, dc = Beispiel, dc = org") einen Verweis auf einen anderen Server zurückgeben kann, der den gewünschten Teilbaum enthält. Der Client kann dann (automatisch oder nicht) den anderen Server kontaktieren. Einige Server unterstützen die Verkettung, sodass der Server andere Server abfragen kann, um die gewünschten Informationen an den Client zurückzusenden.
Die vom Server zurückgegebenen Ergebnisse werden nicht sortiert, weder für die Einträge noch für die Attribute der Einträge oder für die Werte der Attribute.
Der Client gibt jeder Anfrage eine Nachrichten-ID , der Server antwortet auf die Anfrage mit derselben Kennung. Die Antwort enthält einen numerischen Ergebniscode, der den Status der Anforderung angibt (Erfolg, Misserfolg,…). Die Antwort enthält auch alle Daten, die sich aus einer Suche ergeben können. Es enthält auch einen ID-Code.
Die Bindungsoperation authentifiziert den Client innerhalb des Servers. Die einfache Bindung sendet den DN des Benutzers und sein Passwort klar, weshalb die Verbindung durch TLS gesichert werden muss . Der Server überprüft das Kennwort, indem er es (normalerweise) mit dem userPassword-Attribut des entsprechenden Eintrags vergleicht. Der Wert des Attributs, das das Kennwort enthält, beginnt mit dem Namen in Klammern des Algorithmus, der zum Codieren des Kennworts verwendet wird (z. B. userPassword: {md5} aGZh5…).
Die anonyme Bindung , dh ohne Angabe eines Benutzernamens oder Passworts, versetzt die Verbindung in einen anonymen Zustand. Der Kunde kann daher abhängig von den eingerichteten ACLs bestimmte Vorgänge für das gesamte Verzeichnis oder einen Teil davon nicht mehr ausführen .
Die SASL- Bindung ermöglicht die Verwendung anderer Authentifizierungsmechanismen: Kerberos , Clientzertifikat usw.
Der Bindeschritt ermöglicht es dem Client und dem Server auch, zu vereinbaren, welche Version des Protokolls verwendet werden soll. Normalerweise wird Version 3 verwendet. Es ist sogar möglich, dass der Server die Kommunikation mit Clients in einem niedrigeren Protokoll als seinem eigenen verweigert.
Die StartTLS- Operation stellt mithilfe der von SSL geerbten TLS- Technik eine sichere Verbindung zwischen dem Client und dem Server her . Diese Sicherheit basiert auf zwei Punkten: Vertraulichkeit (ein Dritter kann den Austausch nicht verstehen) und Datenintegrität (die Daten werden durch eine Signatur validiert). Während der TLS-Aushandlung sendet der Server sein X.509- Zertifikat an den Client, um seine Identität zu beweisen. Der Client kann mit dem Senden seines Zertifikats antworten, die Clientidentifikation ist jedoch optional. Es ist normalerweise möglich, Clients und Server so zu konfigurieren, dass sie wissen, ob die Zertifikate optional oder wesentlich sind.
Server unterstützen im Allgemeinen das nicht standardmäßige LDAPS- Protokoll ( LDAP over SSL ). Dieses Protokoll verwendet Port 636 im Gegensatz zu TLS, das Port 389 verwendet (dasselbe wie ungesichertes LDAP). Das LDAPS-Protokoll unterscheidet sich in zwei Punkten von LDAP:
Der Suchvorgang wird sowohl zum Suchen als auch zum Abrufen von Einträgen verwendet. Seine Parameter sind:
Der Server gibt die übereinstimmenden Einträge zurück, gefolgt vom Rückkehrcode des Befehls (Rückkehrcode).
Die Vergleichsoperation verwendet einen DN, einen Attributnamen und einen Attributwert als Argument und prüft dann, ob der entsprechende Eintrag tatsächlich ein Attribut mit diesem Wert enthält.
Hinweis : Es gibt keine Operation vom Typ Lesen . Der Suchvorgang wird für den direkten Zugriff auf einen Eintrag verwendet. In diesem Fall wird der baseobject Parameter ist die DN des Eintrags zu lesen, und der Umfang Parameter werden mit dem verwendeten Grundwert .
Das Hinzufügen , Löschen , Ändern Update - Operationen nehmen als Argument der DN des Eintrags aktualisiert werden.
Die Änderung muss zusätzlich zur Liste der zu ändernden Attribute sowie der durchzuführenden Änderung erfolgen: Löschen des Attributs oder bestimmter Werte des Attributs (die Attribute können mehrwertig sein), Hinzufügen eines Werts, Ersetzen ein Wert von.
Das Hinzufügen eines Eintrags kann auch eine Liste von Attributen und Werten enthalten, die dem Eintrag zugeordnet werden sollen.
Die Änderung von DN (Verschieben / Umbenennen) verwendet als Argument die RDN des Eintrags und optional die DN des neuen übergeordneten Elements sowie eine Markierung, die angibt, ob die alte RDN gelöscht werden soll oder nicht. Die Unterstützung für das Umbenennen eines gesamten Teilbaums ist serverabhängig.
Eine Aktualisierungsoperation ist atomar, dh andere Operationen sehen entweder den neuen oder den alten Eintrag. LDAP definiert jedoch kein Transaktionsprinzip, mit dem mehrere Clients gleichzeitig einen Eintrag ändern können. Server können jedoch Erweiterungen verwenden, um dies zu unterstützen.
Erweiterte Operationen sind generische Operationen, mit denen Sie neue Operationen definieren können. Zum Beispiel die Operationen Abbrechen , Kennwortänderung und StartTLS .
AufgabeDie Abbruchoperation sendet eine Anforderung an den Server, um ihn anzuweisen, eine Operation abzubrechen, indem er ihm seine Kennung gibt. Der Server ist nicht verpflichtet, der Anfrage nachzukommen. Leider gibt die Abbruchoperation sowie die tatsächliche Aufgabe einer Operation keine Antwort zurück. Daher wurde der erweiterte Abbruchvorgang so definiert, dass eine Antwort zurückgegeben wird, aber nicht alle Server unterstützen ihn.
Der Vorgang zum Aufheben der Bindung bricht jeden aktuellen Vorgang ab und schließt die Verbindung. Es gibt keine Antwort. Sein Name hat historische Gründe, es ist nicht die Operation, die Bind widerspricht .
Clients können eine Sitzung beenden, indem sie die Verbindung schließen . Die Verwendung von Unbind ist jedoch sauberer . Auf diese Weise kann der Server Netzwerkfehler von unhöflichen Clients unterscheiden.
Es gibt ein LDAP- URI- Format , das jedoch nicht von allen Clients unterstützt wird. Server verwenden es, um Clients über Verweise auf andere Server zu informieren. Das Format ist wie folgt:
ldap://hôte:port/DN?attributs?profondeur?filtre?extensionmit:
Wie in allen URIs müssen Sonderzeichen durch Befolgen des von RFC 3986 bereitgestellten Algorithmus maskiert werden .
Sie können auch auf URIs mit dem nicht standardmäßigen Muster " ldaps " stoßen .
Beispielsweise :
ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=comGibt alle Attribute des Eintrags "John Doe" zurück.
ldap:///dc=example,dc=com??sub?(givenName=John)sucht nach dem Eintrag mit dem Vornamen "John" im Verzeichnis ab dem Stammverzeichnis.
Der Inhalt von Einträgen in einem LDAP-Verzeichnis wird durch Schemas geregelt .
Schemas definieren die Arten von Attributen, die Verzeichniseinträge enthalten können. Die Definition eines Attributs umfasst die Syntax. Die meisten nicht-binären Attribute in LDAPv3 verwenden die UTF-8- Zeichenfolgensyntax . Beispielsweise kann das mail- Attribut " [email protected] " enthalten, das jpegPhoto- Attribut kann ein Foto im binären JPEG- Format enthalten , das member- Attribut kann den DN eines Verzeichniseintrags enthalten.
Die Definition eines Attributs gibt auch an, ob das Attribut einwertig oder mehrwertig ist, nach welchen Regeln die Suchen / Vergleiche durchgeführt werden (je nach Fall oder nicht, Suche nach Teilzeichenfolgen oder nicht).
Schemata definieren Objektklassen. Jeder Verzeichniseintrag muss mindestens einen Wert für das objectClass- Attribut haben , bei dem es sich um eine in den Schemas definierte Objektklasse handelt. Normalerweise ist das objectClass- Attribut mehrwertig und enthält die oberste Klasse sowie eine Reihe anderer Klassen.
Genau wie bei der objektorientierten Programmierung können Sie mit Klassen ein Objekt beschreiben, indem Sie ihm Attribute zuordnen. LDAP-Klassen repräsentieren Personen, Organisationen ... Die Tatsache, dass ein Eintrag zu einer Klasse gehört (daher enthält das objectClass-Attribut den Namen der Klasse), ermöglicht die Verwendung der Attribute dieser Klasse. Einige Attribute sind erforderlich, andere optional. Wenn beispielsweise der Eintrag der verwendete Person Klasse , muss es einen Wert für die hat sn und cn - Attribute , und kann optional einen Wert für den hat Userpassword und telephone Attribute . Da Einträge normalerweise mehrere Klassen haben, kann die Unterscheidung zwischen erforderlichen und optionalen Attributen sehr komplex sein.
Die Elemente eines Schemas haben einen Namen und eine eindeutige Kennung, die als Objektkennung ( OID ) bezeichnet wird.
Viele Server stellen Verzeichnisschemata als LDAP-Einträge bereit, auf die über das DN-Schema cn = zugegriffen werden kann. Administratoren können zusätzlich zu den Standardschemata ein eigenes Schema definieren.
Einige mögliche Vorgänge liegen im Ermessen des Entwicklers oder Administrators. Beispielsweise wird die Datenspeicherung nicht durch das Protokoll angegeben. Der Server kann Flatfiles oder ein RDBMS verwenden oder einfach ein Gateway zu einem anderen Server sein. Zugriffskontrollen (Access Controls, ACL ) sind ebenfalls nicht standardisiert, obwohl sich eine häufige Verwendung abzeichnet.
LDAP ist ein erweiterbares Protokoll, bei dem neue Vorgänge auf einigen Servern und nicht auf anderen Servern angezeigt werden. Zum Beispiel das Sortieren der Ergebnisse.
Das Hauptinteresse von LDAP ist die Standardisierung der Authentifizierung. Es ist sehr einfach, ein Authentifizierungsmodul mit LDAP aus einer Sprache mit einer LDAP- API zu programmieren . Es ist die Bindungsoperation , mit der ein Benutzer authentifiziert werden kann. Immer mehr Webanwendungen verfügen über ein Authentifizierungsmodul, das LDAP unterstützt.
Auf neueren GNU / Linux- Systemen wird zunehmend eine Datenbank verwendet, die LDAP anstelle von Passwd- und Shadow- Flat-Dateien verwendet . Auf die Daten können die PAM- und NSS- Module zugreifen .
LDAP wird durch eine Reihe von Anfragen nach Kommentaren definiert :
In den folgenden RFCs werden die Best Practices für LDAP beschrieben:
Das Folgende ist eine Liste mit RFCs, die LDAPv3-Erweiterungen definieren:
LDAPv2 wurde durch die folgenden RFCs definiert:
LDAPv2 wurde durch den folgenden RFC in den historischen Status versetzt :
Andere RFCs: