Zum Inhalt springen

Lightweight Directory Access Protocol

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 12. Oktober 2004 um 11:51 Uhr durch 212.8.6.6 (Diskussion) (→Weblinks). Sie kann sich erheblich von der aktuellen Version unterscheiden.
LDAP im TCP/IP-Protokollstapel
Anwendung LDAP
Transport TCP / UDP
Netzwerk IP
Netzzugang Ethernet Token
Ring 		FDDI ...

Das Lightweight Directory Access Protocol (LDAP) ist in der Computertechnik ein Netzwerkprotokoll, das die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes erlaubt. Die aktuelle Version ist in RFC 2251 spezifiziert.

Überblick

LDAP ist ein Netzwerkprotokoll, das bei so genannten Directorys zum Einsatz kommt. Es vermittelt die Kommunikation zwischen dem LDAP-Client (beispielsweise einem Mailserver oder digitalen Adressbuch) mit dem Directory Server. Dabei werden alle protokoll-spezifischen Funktionen geboten, die für eine solche Kommunikation notwendig sind: Anmeldung an dem 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 führen, berücksichtigen die Replikation der Daten zwischen verschiedenen Directorys.

Geschichte

LDAP wurde 1995 an der Universität von Michigan entwickelt und 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 stringente Implementierung der Directory Daten erfordert und von Protokoll-Seite her mit DAP (Directory Access Protocol) einen viel größeren Funktions- und Kontroll-Umfang 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.

Trotz allem hat X.500 einen entscheidenden Beitrag zur Entwicklung von Verzeichnissen geliefert und viele X.500-Directorys bieten eine LDAP-Schnittstelle, über die die LDAP-Clients Informationen aus dem Directory abfragen können. Tatsächlich ist es so, dass die ersten Implementierungen von LDAP-fähigen Directory-Servern darauf beruhten, dass X.500-Servern ein Interface vorgeschaltet wurde, über das das LDAP-Protokoll angesprochen wurde. Erst im Laufe der späteren Entwicklungen emanzipierte sich der dahinter liegende Server zu einer eigenständigen und von X.500 unabhängigen Architektur.

Grundsätzlich sollte man zwischen dem Protokoll und dem zugrundeliegenden Service unterscheiden. Oft spricht man von LDAP als Verzeichnis-Dienst, während der Begriff lediglich das Zugriffs-Protokoll beschreibt.

Funktionsweise

Jedes LDAP Verzeichnis hat eine bestimmte Struktur. Die Struktur wird definiert von den verwendeten Schemata. Ein Schema definiert jeweils Objekt-Klassen. Jeder Verzeichniseintrag gehört zu einer Klasse.

Jeder Verzeichniseintrag wird als eigenständiges Objekt behandelt, das aus Attributen zusammengesetzt ist. Ein einzelner Eintrag wird eindeutig durch den Distinguished Name (DN) identifiziert.

Jedes Attribut eines Eintrages 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 donald.duck@disney.com enthalten, ein jpegPhoto-Attribut dagegen würde ein Photo als binäre Daten im JPEG-Format speichern.

Die Verzeichniseinträge 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.

Einzelne LDAP-Server sind für einzelne Teile des Verzeichnisbaumes zuständig, seine Partition. Stellt ein Client eine Anfrage, für die der Server nicht zuständig ist, kann der Server den Client an einen anderen Server verweisen. Dass der Server den anderen Server selbst nach den Information fragt, ist bei LDAP nicht möglich. LDAP-Server lassen sich redundant aufbauen. Hierzu wird eine Master-Slave-Konfiguration verwendet. Versucht ein Client Daten auf einem Slave-Server zu ändern, wird er an den Master verwiesen. Diese Änderungen werden dann an alle anderen 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 Objekt-Hierarchie bleibt aber in der Regel auf eine Organisation beschränkt.

Unterstützung von LDAP

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

Auch Client- und Server-Software kann LDAP-Dienste benutzen: Mozillas E-Mail-Programm oder Microsoft Outlook kann für das Adressbuch LDAP verwenden. Die Mailserver qmail, exim und sendmail können LDAP zur Authentifizierung oder zur Verwaltung von Aliasen verwenden usw.

Der Export und Import erfolgt mittels LDIF.

Siehe auch: RFC 1777, RFC 1778, RFC 1823, RFC 1959, RFC 1960, RFC 2251

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Lightweight_Directory_Access_Protocol&oldid=2853391“