next up previous contents
Next: Authentifizierung Up: Verzeichnisdienste Previous: X.500   Contents


LDAP

Schon der Name LDAP, ausgesprochen Lightweight Directory Access Protocol, erinnert an die Entwicklungsnähe zu X.500. Diesem ISO-Standard wurde oft seine Komplexität auf Grund der Anlehnung an den OSI-Standard angelastet. In den Anfangszeiten war damit ein gewaltiger Mehraufwand verbunden, denn die üblichen Arbeitsplatzrechner waren mit Hilfe der PC-Netze verbunden, die mit NetBIOS oder IPX/SPX arbeiteten, gelegentlich dem aufkeimenden TCP/IP. LDAP war dabei der Versuch, die Vorteile eines offenen Verzeichnisdienstes mit der einfacheren Netzinfrastruktur des TCP/IP-Protokollstacks zu verbinden. LDAP war dabei nicht der erste Versuch, ist aber aus heutiger Sicht der erfolgreichste. Weitere Vertreter waren der Directory Assistance-Dienst mit seinem Frontend fred und der Serverkomponente dad, aber auch DIXIE der direkte Vorgänger von LDAP.

LDAP war in seinen ersten Ausprägungen als Middleware zwischen einem X.500-DSA und einem auf TCP/IP-basierenden Klienten gedacht. Allgemein stand LDAP als Protokollkonverter zwischen einem TCP/IP-Klienten und verschiedenen Verzeichnissen - neben X.500 in LDAPv3 auch zum Beispiel Lotus Notes, MS Exchange oder Novell Directory Service. Die Platzierung in der Kommunikation liegt also zwischen dem Nutzer-Agenten und dem Verzeichnisserver, wobei sein Betrieb sowohl auf dedizierten Servern aber auch auf dem Verzeichnisserver angedacht war. Abbildung 2.3 verdeutlicht diesen Einsatz grafisch.

Figure 2.3: LDAP als Protokollkonverter
\resizebox*{0.6\textwidth}{0.12\textheight}{\includegraphics{images/LDAPKonverter}} \resizebox*{0.6\textwidth}{0.12\textheight}{\includegraphics{images/LDAPKonverter.eps}}

Aufgrund dieser Vorstellung eines LDAP-Dienstes unterscheidet [MR99] auch noch zwischen einem LDAP-Server und den SLAP-Servern. Erstgenannte sind diese Middleware-Protokollkonverter, während letztere für Standalone LDAP Server stehen und LDAP-Server mit eigenem Backend bezeichnen. Erste SLAP-Implementierungen entstanden in einem späten Stadium von LDAPv2 und waren in LDAPv3 dann Teil der Vereinbarung. Da LDAP auf Bestreben und in der ASID-Arbeitsgruppe (Access, Searching and Indexing of Directories) der IETF entstand, ist es in RFCs vereinbart, nicht wirklich standardisiert. Die Reference-Implementierung eines SLAP-Daemons entstand an der University of Michigan, die stark an der Erarbeitung der RFCs beteiligt war und deren Entwicklungen später in das OpenLDAP-Projekt (siehe [Ope05b]) übergingen.
Mit der wachsenden Verbreitung von SLAP-Servern entfiel zunehmend die Unterscheidung zwischen LDAP als Protokollkonverter und einem eigenständigen Verzeichnisdienst-Server. So findet sich in [Car03] zwar immer noch die Erwähnung, dass LDAP die Vereinfachung von DAP im Sinne des Protokollstacks darstelle, ergänzt um die Reduzierung auf 9 wesentliche Operationen des DAP-Protokolls, die Unterscheidung von LDAP als Konverter beziehungsweise als eigenständiger Server findet sich dort allerdings nur noch indirekt, in dem gesagt wird, dass LDAP keinerlei Aussage über die Datenablage trifft, ausschließlich über den Datenzugriff. Vielmehr vertieft der Author sich stark in die Erläuterungen des aktuellen Stands des OpenLDAP-Projekts und die administrativen Feinheiten derer SLAP-Serverkomponente.
Ein weiterer Aspekt, der mit LDAPv3 eingeführt wurde, ist das in RFC 2849 definierte LDIF, das LDAP Interchange Format. LDIF ist ein textbasiertes Format, welches dem Austausch von Daten zwischen verschiedenen Verzeichnissen dient. Jede Datei dieses Formats enthält 3 wesentliche Merkmale, eine Sammlung von Verzeichniseinträgen, jeweils durch eine Leerzeile getrennt, einer Zuordnung von Werten zu Attributnamen und Anweisungen für den LDAP-Parser zum Umgang mit den Daten. Dieses Format kann eventuell in der späteren Betrachtung interessant sein, um Informationen in das AD zu importieren.

Wie bei jedem Dienst stellt sich auch bei einem Verzeichnisdienst die Frage der Authentifizierung und Authorisierung. Ein Verzeichnisdienst bietet, wie bereits anfangs angesprochen, die Möglichkeit einer dezentralen Datenpflege. Dabei kann beispielsweise vorgesehen werden, dass jeder Nutzer seine Personen gebundenen Daten selbst pflegt oder Abteilungen für ihre eigenen Datenbestände zuständig sind. Außerdem ist zu regeln, wer Zugriff auf welche im Verzeichnis abgelegten Informationen bekommt. Dazu wird bei LDAP die Operation der Bindung genutzt und je nach Implementierung bieten sich verschiedene Sicherungsmechanismen. OpenLDAP bietet unter anderem einen anonymen Zugriff, den Zugriff mittels Nutzer und Passwort, wobei dies beides Informationen sind, die im Verzeichnis enthalten sein müssen und sowohl unverschlüsselt oder per SSL/TLS-Sicherung übertragen werden können, und die Anbindung an die SASL-Funktionalität. SASL ist eine Erweiterung, die die Anbindung verschiedener Authentifizierungsmechanismen über eine einheitliche Schnittstelle an eine System ermöglicht. So ist darüber auch eine "`Kerberisierung"' des OpenLDAP erreichbar.
Ebenfalls ist LDAP wie X.500 als verteiltes Verzeichnis angelegt. Gründe für die Verteilung finden sich in der Performance, der geografischen und der administrativen Verteilung. Die Verteilung wird im Standard durch zwei Referenz-Zeiger gelöst, einer subordinate- und einer superior-knowlegde-reference, die auf den Rechner mit dem Teilbaumwissen über darunter liegende beziehungsweise darüber liegende Informationen verweisen.

Da das Leistungsangebot von LDAP mit dem von X.500 vergleichbar ist, dabei die starke Nähe zu TCP/IP besteht und mit dem Siegeszug des Internets die Verbreitung auch von LDAP stieg, stellt LDAP zunehmend auch in Umgebungen großer Datendienstleistungen eine Konkurrenz dar und wird weithin als der Standard für Verzeichnisse angesehen. Gerade das Aufkommen der eigenständigen SLAP-Server unterstützte diese Tendenz. So hat sich Microsoft mit der Einführung eines Verzeichnisdienstes nach X.500 mit einer LDAP-Standardschnittstelle diesem Trend angeschlossen. Näheres findet sich dazu in Kapitel 4.


next up previous contents
Next: Authentifizierung Up: Verzeichnisdienste Previous: X.500   Contents
Marko Damaschke 2006-03-25