Lightweight Directory Access Protocol (LDAP)

Wie kann ein LDAP-Verzeichnis die Arbeit im Netzwerk erleichtern?

Wenn man sich bewusst macht, dass in einem Netzwerk schon alle möglichen Verzeichnisse nebeneinander existieren, wird einem klar, dass viele Informationen mehrfach abgelegt sind. Auf 'datenbankchinesisch' sagt man, dass die Daten nicht normalisiert sind: Daten müssen an mehreren Orten geändert werden, wenn sich zugehörige Informationen ändern. Eine Aktualisierung ist nicht nur mühsam und zeitaufwändig, sondern auch fehlerträchtig.

Außerdem müssen sich die Administratoren jeder einzelnen Passwortdatenbank Gedanken um eine sichere Passwortpolicy, sichere Transportprotokolle, sichere Autorisierungsmechanismen und die ausreichende Verfügbarkeit des Authentifizierungs- und Autorisierungsdienstes machen. Und wie geht man mit sich wiedersprechenden Sicherheitsrichtlinien um?

Irgendwann wünscht man sich eine Zusammenführung aller Verzeichnisse - und das ist genau der Einsatzzweck, für den LDAP konzipiert wurde.
 
LDAP ermöglicht einfach und schnell:
  • Normalisierte Datenhaltung
  • Zentrale Verwaltung der Informationen
  • Konsistenz in der Schnittstelle zum User
  • Konsistenz in den Richtlinien für das Netzwerkmanagement
  • Konsistenz in den Security Policies
LDAP erreicht diese Ziele durch folgende Eigenschaften (hier beziehe ich mich auf die Version 3):

  • LDAP bietet ein Universaldesign für Verzeichnisdienste.
    LDAP basiert auf der Definition von sog. Schemas. Ein Schema ist ein objektorientiertes Konzept, das auch Vererbung unterstützt. Daher lassen sich aus Standardschemas, auf die man sich in der IETF geeinigt hat, nach eigenen Anforderungen spezialisierte Schemas ableiten.
  • LDAP ist ein einfaches Protokoll.
    Ein wichtiger Aspekt bei LDAP als Nachfolger des komplizierten DAP war die Entwicklung eines simplen Protokolls, das einfach zu implementieren und leicht zu benutzen sein sollte. Das hat schon Früchte getragen: Die meisten Programmiersprachen unterstützen LDAP, genauso wie die meisten Betriebssysteme.
  • LDAP erlaubt verteilte Architektur
    Durch Replikation ist es möglich, Teile oder auch den ganzen LDAP-Server auf physisch getrennten Rechnern mehrfach vorzuhalten. Über Referrals können LDAP-Server auf andere LDAP-Server zugreifen. Verzeichnisse kann man so in logischen Portionen auf verschiedenen LDAP-Servern verteilt halten, wobei jede Portion von einer anderen Institution gewartet wird.
  • LDAP ermöglicht die Integration von Sicherheitskonzepten
    Für einen sicheren Zugang (Access) unterstützt LDAP Transport Layer Security (TLS), womit die gesamte Kommunikation zwischen Client und Server verschlüsselt ablaufen kann.
    Für eine sichere Authentifizierung kann unter LDAP auf den Simple Authentication and Security Layer (SASL) aufgesetzt werden. Für die Autorisierung wird sich höchstwahrscheinlich das ACL-Konzept durchsetzen. Unter ACL (Access Control List) versteht man eine Liste mit Zugangsrechten. Anhand dieser Liste entscheidet das Betriebssystem, welchen Zugriff eine Benutzer auf die einzelnen Ressourcen wie zum Beispiel ein Verzeichnis oder eine Datei hat.
  • LDAP ist ein offener Standard
    Weil LDAP als offener Standard von der IETF (Internet Engineering Task Force) entwickelt wird, kann es von jedem Entwickler, jeder Firma und jedem Administrator genutzt werden. Man kettet sich nicht an ein proprietäres Protokoll oder einen Hersteller. Und auch hier zeigt sich ein typischer Vorteil offener Standards: Die LDAP-Benutzer bestimmen mit, in welche Richtung die Entwicklung vorangetrieben wird.
  • LDAP Server müssen Auskunft über ihre Funktionalität und Schemas geben
    Die     LDAP Spezifikation verlangt, dass LDAP-Clients von jedem LDAP-Server verlangen können, die komplette Liste seiner Funktionen und Schemas einzusehen. Das ermöglicht die Abstimmung der Funktionalität im Client auf die Funktionen, die der Server bietet, und erlaubt bessere Interoperabilität über unterschiedliche Implementationen oder LDAP-Versionen hinweg.
  • Extensions
    Zusätzlich zu dem Repertoire an vordefinierten Standardoperationen (wie "search" und "modify") erlaubt LDAP v3 außerdem so genannte "extended" Operations. Eine "extended" Operation nimmt einen Request als Argument an und gibt eine Response zurück. Der Request enthält einen Identifier, der den Request und die von ihm übergebenen Argumente eindeutig identifiziert. Die Response enthält die Ergebnisse aus der Operation, die der Request gefordert hat. Ein solches Request-Response-Paar in einer "extended" Operation nennt man eine Extension. Beispiel: Es gibt eine Extension definieren um TLS zu starten ("Start TLS"). Vom Client kommt diese "Forderung" an den Server und veranlasst diesen, das TLS-Protokoll zu starten. Solche Extensions können standardisiert sein - also von der LDAP-Gemeinde abgesegnet - oder proprietär - also nur von einem speziellen Hersteller oder nur auf einem speziellen Server eingesetzt.
  • Controls
    Eine andere Möglichkeit, neue Funktionalität hinzuzufügen, ist das Verwenden von Steuerbefehlen, so genannten Controls. LDAP v3 erlaubt es, das Verhalten einer beliebigen Operation zu modifizieren - eben durch ein solche Control. Mit einer Operation können beliebig viele Controls verschickt werden, und ebenso können beliebig viele Controls mit den Ergebnissen zurückgegeben werden. Man kann beispielsweise eine 'Sort Control' zusammen mit einer 'Search'-Operation versenden, die dem Server sagt, er soll die Suchergebnisse nach dem Attribut 'name' sortieren. Wie Extensions können Controls standardisiert oder proprietär sein.
  • Internationalisierung
    LDAP benutzt für die interne Repräsentation von Strings UTF-8, so dass alle Sprachen benutzt werden können.

Was ist LDAP jetzt - ein Protokoll oder ein Verzeichnis?

Wie das P in LDAP schon sagt: LDAP ist ein Kommunikationsprokoll, d.h. LDAP definiert den Transport und das Format von Nachrichten, die zwischen einem Client und einem X.500-artigen Verzeichnis ausgetauscht werden. LDAP definiert nicht das Directory selbst.

Trotzdem wird oft der Begriff LDAP-Directory gebraucht. Was hat man sich darunter vorzustellen?
Ein Client-Programm initiiert eine Nachricht, in der es eine LDAP-API aufruft. Ein X.500-Verzeichnisdienst selbst versteht aber gar keine LDAP-Messages. Und in der Tat benutzen LDAP Client und X.500-Server verschiedene Kommunikationsprotokolle (TCP/IP der eine, OSI der andere): Der LDAP-Client braucht einen Gateway-Prozess (man kann es auch Proxy oder Front-End nennen), der seine Requests an den X.500 Server 'übersetzt' weiterleitet. Und dieser Gateway ist ein LDAP-Server. Er ist wiederum Client des X.500-Servers, mit dem er über OSI kommuniziert.

LDAP-SErver als Gateway für einen X.500-Server
Standalone-LDAP-Server

Immer mehr Leute, die gar keinen X.500-Server hatten, wollten auch von den Vorteilen des LDAP-Protokoll profitieren. Warum also nicht die Informationen direkt im LDAP-Server ablegen, statt ihn nur als Gateway zu einem X.500-Server zu benutzen? Damit wäre auch die OSI-Protokollschicht nicht mehr notwendig. Das macht den ursprünglich ja nur als Proxy gedachten LDAP-Server komplizierter.
Man nennt diese Art LDAP-Server manchmal auch explizit Standalone-LDAP-Server, weil sie unabhängig von einem X.500-Server arbeiten.
Für den Client spielt es allerdings keine Rolle: er 'redet' nur mit dem LDAP-Server, egal, wo dieser seine Informationen herholt.