Lightweight Directory Access Protocol

LDAP im TCP/IP-Protokollstapel:
Anwendung	LDAP
Transport	UDP		TCP
Internet	IP (IPv4, IPv6)
Netzzugang	Ethernet	Token Bus	Token Ring	FDDI	…

Das Lightweight Directory Access Protocol (LDAP) /ˈlaɪtweɪt .../ ist in der Computertechnik ein Netzwerkprotokoll, das die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes (eine im Netzwerk verteilte hierarchische Datenbank) erlaubt. Die aktuelle Version ist in RFC 4511 spezifiziert.

Überblick

LDAP ist ein Netzwerkprotokoll, das bei so genannten Verzeichnisdiensten (engl. directories) zum Einsatz kommt. Es vermittelt die Kommunikation zwischen dem sogenannten LDAP-Client (zum Beispiel einem Mailserver, einem Mailclient wie Thunderbird oder einem digitalen Adressbuch wie im Outlook-Client) und dem Verzeichnis (Directory Server), aus dem (überwiegend) personenbezogene Daten ausgelesen werden.

Beispiel: Im Outlook Adressbuch (LDAP-Client) stößt ein User die Aktion Suche mir die Mailadresse von Joe User heraus an. Das Adressbuch formuliert eine LDAP-Abfrage an das Verzeichnis (Directory-Server), das diese Information bereitstellt. Das Verzeichnis formuliert die Antwort und übermittelt sie an das Adressbuch: joe.user@acme.com.

Mittlerweile hat sich im administrativen Sprachgebrauch eingebürgert, dass man von einem LDAP-Server spricht, dabei meint man einen Directory-Server, dessen Daten-Struktur der LDAP-Spezifikation entspricht und der über das Netzwerkprotokoll LDAPv3 Daten mit Client-Systemen austauschen kann.

Das Protokoll bietet alle Funktionen, die für eine solche Kommunikation notwendig sind: Anmeldung am Server (sog. bind), die Suchabfrage (Suche mir bitte alle Informationen zum Benutzer mit dem Namen 'Joe User') und die Modifikation der Daten (Beim Benutzer 'Joe Cool' ändere bitte das Passwort).

Neuere Implementierungen, die über RFC 2251 hinaus gehen und Gegenstand für eine mögliche Erweiterung des Protokolls sind, berücksichtigen die Replikation der Daten zwischen verschiedenen Directories.

Geschichte

LDAP wurde an der Universität von Michigan entwickelt und 1993 erstmals in einem RFC vorgeschlagen. Es stellt eine vereinfachte Form des Directory Access Protocol (DAP) dar, welches im X.500-Standard definiert ist. Der X.500-Standard ist sehr umfangreich und setzt auf einem vollständigen ISO/OSI-Stack auf, was die Implementierung schwierig und rechenintensiv machte und damit einen Erfolg verhinderte.

LDAP wurde mit dem Ziel entwickelt, Verzeichnisdienste einfacher und somit populärer zu machen. Aus diesem Grund setzt LDAP auf einem TCP/IP-Stack auf und implementiert nur einige der DAP-Funktionen und Datentypen. Trotzdem lassen sich mit den vorhandenen LDAP-Funktionen alle anderen emulieren.

LDAP und X.500

Während X.500 eine sehr strenge Implementierung der Directory-Daten erfordert und von der Protokollseite her mit DAP einen viel größeren Funktions- und Kontrollumfang als LDAP besitzt, hat sich gezeigt, dass diese Architektur gerade deswegen einer breiteren Verteilung in vielen Unternehmen im Wege steht. Die Entscheidung, eine „lightweight“-Version des DAP-Protokolls zu implementieren, führte zu einer hohen Flexibilität in den Netzwerken, so dass solche Verzeichnisse zum ersten Mal „Internet-tauglich“ wurden.

Funktionsweise

Um eine Übersicht über die Funktionsweise einer LDAP-Architektur zu bekommen, ist es notwendig, dass man zwischen der Organisation des LDAP-Verzeichnisses und dem Protokoll LDAP unterscheidet.

LDAP-Verzeichnis

Die Datenstruktur eines LDAP-Verzeichnisses ist durch einen hierarchischen Baum mit Wurzeln, Zweigen und Blättern gegeben. Die Wurzel (root, suffix) ist das oberste Datenobjekt, unter ihm verzweigen sich die höheren Strukturen. Beispiel: Wird ein LDAP-Verzeichnis in einem Unternehmen mit dem Namen ACME eingesetzt, kann die Organisation als Wurzel definiert werden: o=acme.

Personen können in Zweigen unterhalb dieser Wurzel hinterlegt werden: ou=Personen,o=acme

Gruppen können in anderen Zweigen unterhalb der Wurzel hinterlegt werden: ou=Gruppen,o=acme

Damit die Organisation der Daten nicht vollkommen willkürlich geschieht, verwendet jedes LDAP-Verzeichnis eine bestimmte (genormte und ggf. erweiterte) Struktur. Die Struktur wird durch das verwendete Schema definiert. Ein LDAP-Schema definiert jeweils Objekt-Klassen mit ihren Attributen, z. B. die Klasse person oder die Klasse organisation.

Die Verzeichniseinträge heißen bei LDAP Objekte. Jedes Objekt gehört zu mindestens einer, in der Regel aber zu mehreren Klassen. So sind für die Daten einer Person, ihrer E-Mail-Adresse und ihrer Passwörter nicht etwa drei Objekte notwendig, sondern dasselbe Objekt gehört zu drei Klassen. Diese könnten in diesem Beispiel person, inetOrgPerson und posixAccount heißen.

Es gibt drei Arten von Objektklassen: Da ein Objekt zu mindestens einer strukturellen Klasse gehören muss, ist dies die Standardeinstellung. Daneben gibt es noch Hilfsklassen, welche dazu benutzt werden können, verschiedenartigen Objekten gleiche Attribute zuzuweisen. Zuguterletzt existieren noch abstrakte Basisklassen, von denen keine Objekte, sondern nur untergeordnete Basisklassen erzeugt werden können.

Jedes Objekt ist eigenständig und aus Attributen zusammengesetzt. Ein einzelnes Objekt wird eindeutig durch den Distinguished Name (DN) identifiziert (z. B. uid=juser,ou=People,ou=webdesign,c=de,o=acme). Dieser setzt sich aus einzelnen Relative Distinguished Names (RDN) zusammen. Eine andere Schreibweise für den DN ist der canonical name, der keine Attribut-Tags (ou, c etc.) enthält und bei dem die Trennung zwischen den RDNs durch Schrägstriche erfolgt. Außerdem beginnt die Reihenfolge, im Gegensatz zum dn, mit dem obersten Eintrag, also z. B. acme/de/webdesign/People/juser.

Jedes Attribut eines Objekts hat einen bestimmten Typ und einen oder mehrere Werte. Die Typenbezeichnung eines Attributs sind meist einfach zu merkende Kürzel wie z. B. cn für common name, ou für organizational unit, s für state, c für country oder mail für e-mail address. Die erlaubten Werte eines Attributs sind vom Typ abhängig. So könnte ein mail-Attribut die Adresse hans.wurst@example.com enthalten, ein jpegPhoto-Attribut dagegen würde ein Foto als binäre Daten im JPEG-Format speichern. Die in der Objektklasse definierten Attribute können entweder obligatorisch (mandatory) oder optional sein.

Die Objekte werden in einer hierarchischen Struktur gespeichert, die politische, geographische oder organisatorische Grenzen widerspiegelt. Die größten Einheiten werden an die Spitze des Verzeichnisbaumes gestellt, der sich nach unten immer weiter auffächert. Während Objekte, die selbst Objekte enthalten, als Containerobjekte bezeichnet werden, heißen die „Enden“ des Baumes Blattobjekte.

Wenn einzelne LDAP-Server für einzelne Teile des Verzeichnisbaumes zuständig sind, spricht man von Partitionen. Stellt ein Client eine Anfrage, für die der Server nicht zuständig ist, kann der Server den Client an einen anderen Server verweisen. LDAP-Server lassen sich redundant aufbauen. Hierzu wird oft eine Master-Slave-Konfiguration verwendet. Versucht ein Client Daten auf einem Slave-Server zu ändern, wird er an den Master verwiesen. Die Änderungen auf dem Master-Server werden dann an alle Slave-Server weitergegeben.

Da viele verschiedene Schemata in verschiedenen Versionen in Benutzung sind, ist die Vorstellung eines „globalen“ alles umfassenden LDAP-Verzeichnisses nicht real. LDAP-Server werden als zentraler Verzeichnisdienst für verschiedene Zwecke in verschiedenen Größen eingesetzt, die Objekthierarchie bleibt aber in der Regel auf eine Organisation beschränkt.

LDAP-Protokoll

Das LDAP-Protokoll ist auf der obersten Netzwerkschicht angesiedelt und arbeitet mittels genau spezifizierter Zugriffs-Prozesse:

bind: Mit der bind -Direktive vermittelt man dem Directory-Server über eine dn, wer den Zugriff durchführen möchte (entweder anonym, per Password-Authentifizierung oder anders)
baseDN: Die BaseDN definiert, wo im Verzeichnisbaum abwärts die Suche nach bestimmten Objekten gestartet werden soll. Diese Suche kann festgelegt werden auf eine Suche über
- genau dieses Objekt (base)
- dieses Objekt und alles darunter (sub)
- eine Ebene unterhalb des BaseDNs (one)

Ansonsten gelten die notwendigen Such-Spezifikationen wie Such-Operator (Beispiel (&(mail=joe*)(ou=People))), Server-Benennung: (Beispiel ldap.acme.com), Port-Benennung usw.

Beispiel für eine LDAP-Suchanfrage durch ein einfaches Kommandozeilenprogramm:

ldapsearch -h ldap.acme.com -p 389 -s sub -D "cn=Directory Manager,o=acme" -W -b "ou=personen,o=acme" "(&(mail=joe*)(c=germany))" mail

Erklärung: Das Kommandozeilenprogramm kontaktiert über LDAP den Directoryserver ldap.acme.com (Port 389) und meldet sich über den Account des Directory Managers an diesem System an. Die Anfrage zielt auf alle Benutzer-Einträge (unterhalb des Zweiges ou=personen,o=acme) und sucht nach Personen aus Deutschland, deren Mailadresse mit joe beginnen ((&(mail=joe*)(c=germany))). Werden Personen gefunden, die auf diesen Filter passen, so wird deren Mailadresse zurückgegeben (mail)

Unterstützung von LDAP

Viele Anbieter von Verzeichnisdiensten unterstützen LDAP, z. B.:

Apple (durch Open Directory)
AT&T
Banyan Vines
Critical Path
Hewlett-Packard
IBM/Lotus
Microsoft (durch ADS)
Novell (durch NDS)
openLDAP (openSource Variante für eine Vielzahl unterschiedlicher Plattformen, so z. B. auch Linux)
Oracle (durch Oracle Internet Directory)
RedHat (openSource Variante Fedora Directory Server)
SGI
Siemens (durch Siemens DirX Directory Server)
Sun (durch Sun ONE Directory Server)

Auch Client- und Server-Software kann LDAP-Dienste benutzen: Mozillas E-Mail-Programm Thunderbird, IBMs Lotus Notes, Novell Evolution oder Microsoft Outlook können für das Adressbuch LDAP verwenden. Die Mailserver postfix, qmail, exim, Lotus Domino und sendmail können LDAP zur Authentifizierung oder zur Verwaltung von Aliasen verwenden. Squid, Lotus Domino und apache können LDAP als Authentifizierungssystem verwenden usw.

GQ [1] und Luma [2] ermöglichen das direkte Betrachten und Bearbeiten von LDAP-Verzeichnissen.

Der Export und Import erfolgt mittels LDIF.

Probleme von LDAP

LDAP hat aus der Sicht der relationalen Datenbanktheorie eine Reihe von systembedingten Konstruktionsfehlern, die größere LDAP-Umgebungen schwierig skalieren lassen und eine Reihe von Pflegeproblemen erzeugen. Metadirectories und die damit verbundenen Mechanismen versuchen, diese Probleme zu mildern (können sie aber nicht lösen, da die Probleme strukturell sind).

Keine erste Normalform, sondern Arrays

LDAP implementiert eine hierarchische Datenbank. Daten sind nicht einmal in erster Normalform gespeichert (multivalued attributes können erlaubt sein). Das macht es sehr schwer, LDAP-Systeme mit SQL-Systemen interagieren zu lassen, etwa LDAP mit einem SQL-Backend effizient zu realisieren.

Keine erste Normalform, sondern Strings mit Format

LDAP implementiert eine Reihe von Attributen, bei denen im Wert des Attributes mehr als ein Datum gespeichert ist. In Passworten ist zum Beispiel im Passwortstring vorne in geschweiften Klammern die Passwortcodierung gespeichert: {crypt}blafasel ist ein Unix-Passwort, {md5}blafasel ein MD5-codiertes Passwort und {clear}secret ein Klartextpasswort.

In LDAP ACLs-Attributen sind die ACEs als Multivalue-Attribute gespeichert, wobei jeder Wert als dreiwertiges Tupel als String gespeichert ist. Das macht es nahezu unmöglich, eine Query zu formulieren, die alle Knoten liefert, ab denen der User „kris“ bestimmte Rechte hat.

DN nicht stabil

LDAP verwendet den DN eines Records als Primärschlüssel im Baum. Der DN ist aber nicht opak, sondern ein Pfad aus RDNs, die wiederum Kopien von strukturbildenden Attributen auf jedem Level enthalten. Ändern sich die Werte dieser strukturbildenden Attribute, ändert sich der DN des Records, damit ändert sich der Wert eines Primärschlüssels.

Wenn Verweise auf den Record existieren, dessen DN sich ändert, dann werden diese dadurch ungültig, denn es existiert im Standard kein Mechanismus, der so etwas konsistent halten kann (Active Directory versucht dieses Problem zu beheben, und im Netscape Server existiert mit dem Referential Integrity Plugin ebenfalls ein Versuch, das zu fixen). Das wiederum führt zu einer großen Anzahl von Updates im ganzen LDAP-Baum und in einem verteilten Setup mit Replikation zu einem Replikationssturm.

Beispiel: CN=Erika Verheiratet, OU=Kiel, O=ACME, C=DE heiratet und heißt nun wieder CN=Erika Mustermann, OU=Kiel, O=ACME, C=DE. Erika ist Mitglied von vielen Mailinglisten, eingetragen mit ihrem DN, darunter auch der Mailingliste "all" mit 9000 Subscribern. Das geänderte "all"-Objekt mit Erikas neuem DN wird geschrieben und repliziert. Es ist 480 KB groß.

Alternativ werden Erikas DNs in den Mailinglisten nicht angepasst und sie fällt von allen Mailinglisten.

Partitionierung und Baumstruktur sind gekoppelt

Relationale Datenbanken können Tabellen entlang beliebiger Attribute und Ranges partitionieren (MySQL implementiert SQL92 und bietet die folgenden Optionen http://dev.mysql.com/doc/refman/5.1/en/partitioning-types.html).

In LDAP ist eine Partition und Teilreplikation nur entlang eines Subtrees moeglich, d.h. die Partitionierung erfordert die Einführung einer Hierarchieebene im DN (Es ist möglich, OU=Kiel, O=ACME, C=DE zu replizieren, aber es ist nicht möglich, alle Mitarbeiterrecords zu replizieren, bei denen das Standort-Attribut den Wert „Kiel“ hat.).

Dadurch entsteht aber wieder Struktur im DN, und der DN ist nicht mehr opak. Man muss den DN eines Mitarbeiters ändern, der nach Kiel versetzt wird (anstatt einfach sein Standort-Attribut zu ändern).

Hierarchische Datenbank für relationale Probleme

LDAP implementiert eine hierarchische Datenbank, und ist mithin nicht in der Lage, n:m-Beziehungen zu modellieren. Es ist zum Beispiel nicht möglich, in einer LDAP-Datenbank sinnvoll eine Assetliste zu modellieren. Zwar kann man eine Liste von Personen und eine Liste von Rechnern haben, es ist aber schon nicht mehr sinnvoll möglich, die Beziehung zwischen Rechnern und Personen zu modellieren (etwa mit "bezahlt", "steht bei" und "kann benutzen"-Relationen, wie sie in Betrieben notwendig wären, um eine Maschine zu beschreiben).

Abfragesprache limitiert

Von den relationalen Operationen Projektion (Spaltenauswahl), Selektion (Zeilenauswahl), Kreuzprodukt (Join), Spaltenumbenennung (Rename, AS) und Aggregation (GROUP BY) beherrscht LDAP nur Projektion (ohne Erzeugung von errechneten Attributen) und Selektion. Ein Join oder einen "Dereferenziere diesen DN"-Operator gibt es nicht, ein Rename (und damit ein Selfjoin) existiert nicht und Aggregation muss mit Schleifen im Client auscodiert werden.

Insgesamt ist die LDAP-Abfragesprache etwa im Gegensatz zu SQL keine Algebra, d. h. Abfrageergebnisse von LDAP-Anfragen sind keine LDAP-Bäume, sondern Knotenmengen und die LDAP-Abfragesprache ist auf LDAP-Ergebnisse nicht wieder anwendbar, um die Ergebnisse zu verfeinern.

Diese Einschränkungen limitieren die Mächtigkeit der Abfragesprache von LDAP extrem, was wiederum auf LDAP-Servern in der Regel sehr hohe Queries-per-Second-Werte erzeugt, da die entsprechenden Queries in der Anwendung ausprogrammiert werden müssen. So erzeugt ein Sendmail mit LDAP-Support mindestens 4, aber bis zu 7 Queries bei der Zustellung einer Mail an einen einzelnen lokalen Empfänger, und noch weitaus mehr Queries bei der Zustellung an eine Mailingliste.

Aus diesem Grund ist für die effiziente Operation von LDAP fast immer eine lokale Replikationskopie des LDAP-Baumes notwendig, damit Netzwerklatenzen das System nicht über Gebühr verlangsamen.