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.
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.