Anwendung | LDAP | ||||
Transport | UDP | TCP | |||
Internet | IP (IPv4, IPv6) | ||||
Netzzugang | Ethernet | Token Bus |
Token Ring |
FDDI | … |
Das Lightweight Directory Access Protocol (LDAP), deutsch etwa Leichtgewichtiges Verzeichniszugriffsprotokoll, ist ein Netzwerkprotokoll zur Abfrage und Änderung von Informationen verteilter Verzeichnisdienste. Seine aktuelle und dritte Version ist in RFC 4510 bis RFC 4532 spezifiziert, das eigentliche Protokoll in RFC 4511.[1]
LDAP ist der De-facto-Industriestandard für Authentifizierung, Autorisierung sowie Adress- und Benutzerverzeichnisse. Die meisten Softwareprodukte, die mit Benutzerdaten umgehen müssen und am Markt relevant sind, unterstützen LDAP.
Standardport ist:
Verbindungsloses LDAP wie per UDP war nie weit verbreitet und ist längst außerhalb der Standardisierung.[4]
LDAP basiert auf dem Client-Server-Modell[5] und wird bei Verzeichnisdiensten (englisch directories oder directory services) eingesetzt.[6] Es beschreibt die Kommunikation zwischen dem LDAP-Client und dem Verzeichnis-(Directory-)Server. Aus einem solchen Verzeichnis können objektbezogene Daten, z. B. Personendaten oder Rechnerkonfigurationen, ausgelesen werden.[7] Die Kommunikation erfolgt auf Basis von Abfragen.[8]
Hierbei ist „Verzeichnis“ im Sinne beispielsweise eines Telefonbuches gemeint und nicht im Sinne von „Dateiordner“.
Das Verzeichnis kann beispielsweise ein Adressbuch enthalten: In seinem E-Mail-Client stößt ein Nutzer die Aktion Suche die Mailadresse von Joe User an. Der E-Mail-Client formuliert eine LDAP-Abfrage an das Verzeichnis, das die Adressinformationen bereitstellt. Das Verzeichnis formuliert die Antwort und übermittelt sie an den Client: joe.user@example.org.
LDAP bietet alle Funktionen, die für eine solche Kommunikation notwendig sind:
Mittlerweile hat sich im administrativen Sprachgebrauch eingebürgert, dass man von einem LDAP-Server spricht,[9] wenn man einen Directory-Server meint, dessen Datenstruktur der LDAP-Spezifikation entspricht und der über das LDAPv3-Protokoll, das in RFC 2251[10] festgelegt wurde, Daten austauschen kann.
Neuere Implementierungen, die über RFC 2251[10] hinausgehen, indem sie zusätzlich die Replikation der Daten zwischen verschiedenen Verzeichnissen berücksichtigen, sind Gegenstand für eine mögliche Erweiterung des Protokolls.[11]
LDAP wurde an der Universität von Michigan (UMich) entwickelt und 1993 erstmals im RFC 1487[12] vorgeschlagen.[13] Gleichzeitig stellte die UMich die erste Serverimplementierung vor, die heute als „UMich-LDAP“ bekannt ist.
LDAP ist eine vereinfachte ("lightweight") Alternative zum Directory Access Protocol (DAP), das als Teil des X.500-Standard spezifiziert ist.[14] Der X.500-Standard ist sehr umfangreich und setzt auf einem vollständigen ISO/OSI-Stack auf, was die Implementierung schwierig und hardwareintensiv machte.
LDAP wurde mit dem Ziel entwickelt, Verzeichnisdienste einfacher und somit populärer zu machen. LDAP setzt auf einen TCP/IP-Stack auf und implementiert nur eine Auswahl der DAP-Funktionen und -Datentypen.[15] Dadurch ließ sich LDAP auch auf Arbeitsplatzrechnern der frühen 1990er Jahre implementieren und gewann eine breite Anwendungsbasis.
LDAP ist ein Zugriffsmechanismus gemäß X.500 und äußerlich auf dessen Dienst- und Datenmodelle festgelegt.[16] Im Hintergrund jedoch lässt LDAP alles offen und jegliches Verzeichnissystem zu. Es gibt auch keine Festlegung vom LDAP auf einen bestimmten Unterbau wie TCP oder IP.
Wo X.500 in seinem Directory Access Protocol (DAP) mehrere aufeinander aufbauende Nachrichten erfordert, kann im LDAP eine einzige zusammengefasste Nachricht genügen.[17]
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.
Die Datenstruktur eines LDAP-Verzeichnisses ist durch einen hierarchischen Baum mit Wurzeln, Zweigen und Blättern gegeben.[18] Dieser Baum wird auch Directory Information Tree (DIT) genannt.[19] Die Wurzel (root, suffix) ist das oberste Datenobjekt, unter ihm verzweigen sich die höheren Strukturen.[20]
Beispiel: Wird ein LDAP-Verzeichnis in einem Unternehmen mit dem Namen ACME eingesetzt, so 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 willkürlich geschieht, verwendet jedes LDAP-Verzeichnis eine bestimmte, genormte und gegebenenfalls erweiterte Struktur. Die Struktur wird durch das verwendete Schema definiert.[21] Ein LDAP-Schema definiert jeweils Objekt-Klassen mit ihren Attributen, z. B. die Klasse person oder die Klasse organisation.
Die Verzeichniseinträge heißen LDAP-Objekte.[22] Jedes Objekt gehört zu mindestens einer, in der Regel aber zu mehreren Klassen.[23] 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 POSIX-Benutzerkonto heißen.
Es gibt drei Arten von Objektklassen:
Jedes Objekt ist eigenständig und aus Attributen zusammengesetzt.[24] Ein einzelnes Objekt wird eindeutig durch den Distinguished Name (DN) identifiziert,[25] z. B. uid=juser,ou=People,ou=webdesign,c=de,o=acme. Dieser setzt sich aus einzelnen Relative Distinguished Names (RDN) zusammen.[26]
Eine andere Schreibweise für den DN ist der canonical name, der keine Attribut-Tags wie ou oder c enthält und bei dem die Trennung zwischen den RDNs durch Schrägstriche erfolgt;[27] 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 Typenbezeichnungen der Attribute sind meist einfach zu merkende Kürzel, z. B.:
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 Wurzel 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.[28]
Wenn einzelne LDAP-Server für einzelne Teile des Verzeichnisbaumes zuständig sind, spricht man von Partitionen.[29] Stellt ein Client eine Anfrage, für die der Server nicht zuständig ist, so 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, so 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 ist ein Protokoll der Anwendungsschicht (Applicationlayer) nach dem für TCP verwendeten DoD-Vier-Schichten-Modell und arbeitet mittels genau spezifizierter Zugriffs-Prozesse:
Ansonsten gelten die notwendigen Such-Spezifikationen wie Suchoperator (Beispiel (&(mail=joe*)(ou=people))), Server-Benennung (z. B. ldap.acme.com) oder Port-Benennung.
Beispiel für eine LDAP-Suchanfrage durch ein Kommandozeilenprogramm:
ldapsearch -h ldap.acme.com -p 389 -s sub -D "cn=Directory Manager,o=acme" -W -b "ou=people,o=acme" "(&(mail=joe*)(c=de))" mail
Erklärung: Das Kommandozeilenprogramm kontaktiert über LDAP
ldap.acme.com
389
Directory Managers
an diesem System an;-W
).-s sub
, d. h. unterhalb, des Zweiges (englisch branch, daher das -b) ou=people,o=acme
)joe
beginnt ((&(mail=joe*)(c=de))
).mail
).LDAP wird heutzutage in vielen Bereichen eingesetzt, beispielsweise:
LDAP agiert als Frontend zu hierarchischen Datenbanken. LDAP an sich ist keine Datenbank, sondern lediglich das Protokoll zur Kommunikation.
Hierarchische Datenbanken erzwingen keine Normalformen, z. B. können multivalued attributes erlaubt sein.
LDAP unterstützt nicht alle relationalen Operationen:
Anders als SQL ist die LDAP-Abfragesprache keine Algebra, weil ihr die Abgeschlossenheit fehlt: Abfrageergebnisse von LDAP-Anfragen sind keine LDAP-Bäume, sondern Knotenmengen; daher ist die LDAP-Abfragesprache auch nicht auf LDAP-Ergebnisse anwendbar, um sie zu verfeinern.
Das Protokoll und LDAP-Server sind auf Authentifizierung (Passwortprüfung), Autorisierung (Rechteprüfung) und Adressbuch-Suchen optimiert. Der schnelle Verbindungsauf- und -abbau, das einfach strukturierte Protokoll und die knappe Abfragesprache sorgen für eine schnelle Verarbeitung.
Durch seine nicht normalisierte Datenspeicherung kann auf alle Daten eines LDAP-Datensatzes sehr schnell zugegriffen werden, weil alle Daten sofort mit einem einzigen Lesezugriff ausgelesen werden können.
LDAP bietet verteilte Datenhaltung, z. B. redundante lokale Datenspeicherung an verteilten Standorten, lose gekoppelte Replikation zum Datenabgleich zwischen den Standorten und extrem hohe Verfügbarkeit ohne komplexe Konfiguration oder hohe Kosten.
LDAP erbt vom X.500-Standard das objektorientierte Datenmodell. Damit können LDAP-Verzeichnisse flexibel an volatile Anforderungen angepasst werden, ohne dass bereits im Verzeichnis implementierte Funktionalität verlorengeht.
Viele Hersteller bieten LDAP-Server, beispielsweise:
Client-Software erlaubt den Zugriff auf die Verzeichnisdaten, zum Beispiel: