Definition Was ist LDAP (Lightweight Directory Access Protocol)?

Das "Lightweight Directory Access Protocol" (LDAP) ist ein Netzwerkprotokoll zur Durchführung von Abfragen und Änderungen in einem verteilten Verzeichnisdienst. Das Protokoll aus dem TCP/IP-Protokollstapel ist in den RFCs 4510, 4511 und 4532 spezifiziert.

Anbieter zum Thema

Lenovo Global Technology Germany GmbH

Southern Tech GmbH

Eines gleich vorweg: LDAP selbst ist kein Verzeichnis, sondern das Protokoll, über das es mit einer bestimmten Syntax möglich ist, Informationen eines LDAP-Verzeichnisses abzufragen. Für eine fehlerlose Zusammenarbeit ist es bei LDAP erforderlich, dass alle beteiligten Systeme auf Port 389 für eine ungesicherte Übertragung und auf Port 636 in einer TLS gesicherten Verbindung Daten austauschen können. Historisch betrachtet geht die Entwicklung von LDAP auf die Universität von Michigan zurück. Dort wurde im Jahr 1993 erstmals ein Vorschlag für die vereinfachte Variante des DAP (Directory Access Protocol) als RFC definiert.

Die Idee hinter LDAP ist einfach: Ein über verschiedene Server verteiltes Verzeichnis in einer Baumstruktur soll einfach durchsucht werden können.

Bildergalerie

Die Baumstruktur des Verzeichnisses ist in groben Zügen vorgegeben: Der Ursprung ist stets das "Root Directory" und dieses verzweigt in Länder, Organisationen, Organisationseinheiten und Individuen. Bei den letzteren kann es sich um Benutzer, Personen, Drucker, Scanner, Computer, Server oder dergleichen handeln kann. Obwohl das System eine hohe Flexibilität bei der Abbildung von Strukturen erlaubt, ist die Definition der Elemente im Schema eher strikt.

Mögliche Anwendungsfälle für LDAP können sein:

   - Benutzerverwaltung
   - Systemverwaltung
   - Protokollzuordnung
   - RFC-Zuordnungen
   - NIS-Informationen
   - Boot-Informationen
   - Verwaltung von Mountpoints im Dateisystem
   - Organisation von Alias-Namen in E-Mail-Systemen
   - Verwaltung von DNS Zonendaten
   - Organisation von DHCP-Servern

LDAP-Implementierung Active Directory

Insgesamt war die Idee der Universität Michigan erfolgsversprechend, denn viele Firmen etablierten das Konzept in ihre Software. Die bekannteste und verbreitetste LDAP-Implementierung dürfte das Microsoft Active Directory (AD) darstellen. LDAP stellt, neben Kerberos, CIFS und DNS die vierte Hauptkomponente des Active Directory dar. Im AD stellt das LDAP-Verzeichnis die Informationen über Benutzer, Computer und deren Gruppenzugehörigkeit bereit. Aber auch andere Objekte, wie zum Beispiel die Zertifikate eines Computers, werden in dem Verzeichnis gespeichert.

Der Aufbau von LDAP

Der grundlegende Aufbau im LDAP-Datenmodell ist einfach. LDAP besteht aus Objekten und folgt weitgehend dem Ansatz der objektorientierten Programmierung mit Klassen, Vererbung, Polymorphie und den Objekten selbst. Ein Verzeichnisdiensteintrag besteht aus einer Liste von Attributen und einem "Pflichtobjekt" – der Bezeichnung des Objekts selbst, dem "Distinguished Name".

Diese Bezeichnung entspricht ein wenig einem Dateinamen und teilt sich eine Eigenschaft mit der Dateinamenkonvention: In derselben Ebene ist kein gleichlautendes Objekt mit demselben Namen möglich. Objekte mit der Bezeichnung "OU" stellen Container dar, in denen weitere Objekte erzeugt sein können. Sie bilden das Grundgerüst beim Aufbau der Struktur. Gemäß dem Standard RFC 2253 mit dem Titel "UTF-8 String Representation of Distinguished Names" existieren unter anderem folgende Attributtypen:

CN: commonName
L: localityName
ST: stateOrProvinceName
O: organizationName
OU: organizationalUnitName
C: countryName
STREET: streetAddress
DC: domainComponent
UID: userid

Das sieht auf den ersten Blick reichlich unübersichtlich und komplex aus – dass ist dem universellen Ansatz von LDAP geschuldet. Mit Blick auf eine Struktur in einem Active Directory lichtet sich die Unübersichtlichkeit jedoch rasch.

Bildergalerie

Man stelle sich ein Active Directory mit dem Namen test.local vor. Es wird ein neuer Benutzer mit dem Namen "Mustermann, Hans" während die Auswahl auf dem Wurzelverzeichnis test.local stand angelegt. In der Darstellung als distinguished Name:

CN=Hans Mustermann,DC=test,DC=local

Nun wird das Objekt in einen OU mit dem Titel "Personen“ verschoben und der DN noch einmal betrachtet:

CN=Hans Mustermann,OU=Personen,DC=test,DC=local

Innerhalb der OU Personen erstellt der Administrator nun eine weitere OU, um eine bessere Orientierung zu haben. Diese soll "Fiktive Mitarbeiter" heißen und das Benutzerobjekt von Herrn Mustermann wird dieser neuen OU zugeordnet. Somit lautet der DN:

CN=Hans Mustermann,OU=Fiktive Mitarbeiter,OU=Personen,DC=test,DC=local

Nun ergibt es sich die Logik fast schon von allein. Der commonName, die Bezeichnung des Objekts selbst, steht auf der linken Seite, während die Zuordnung von der rechten Seite ausgehend mit der Domänenstruktur local, gefolgt von test beginnt. Wieder von rechts gelesen findet der Administrator das Benutzerobjekt für Herrn Mustermann in der OU "Fiktive Mitarbeiter", die sich in der OU "Personen" befindet, die in der Wurzelstruktur der Domäne zu finden ist.

Praktischerweise gibt es eine große Anzahl von Programmen, mit denen eine Verzeichnisstruktur mithilfe von LDAP abgefragt werden kann; für Microsoft Windows ist bspw. der "LDAP Admin" von T. Karlovic eine kompakte und praktische Lösung. Auf der anderen Seite gibt es viele Script-Varianten, um via LDAP Informationen zu ermitteln.

Sehr bekannt ist hier folgendes PowerShell-Script:

Es liefert die Benutzernamen der Mitarbeiter aus der Abteilung (siehe erste Zeile Department=Redaktion). Soll das Script etwas anderes Suchen, zum Beispiel Mitarbeiter, deren Anmeldenamen eine besondere Buchstabenfolge enthält, so sieht die erste Zeile in etwa so aus:

$strFilter = "(&(objectCategory=User)( sAMAccountName=Mich*))"

Das Sternchen hinter „Mich“ fungiert hier als Jokerzeichen. Der untere Bereich dieser PS-Befehlsabfolge (stammt von der Microsoft Homepage) lässt sich somit auch für andere Einsatzzwecke recht gut nutzen. Aber, es geht auch viel, viel einfacher – mit einem Einzeiler in der PowerShell:

Get-ADUser -Filter { Name -Like "*" } -Searchbase "OU=PERSONEN,DC=test,DC=local"

Möchte der Administrator zum Beispiel noch die Telefonnummern auslesen, erweitert sich dieser eine Befehl ein wenig:

Get-ADUser -filter { Surname -Like "*" } -properties cn,telephoneNumber -SearchScope Subtree-SearchBase "OU=Personen,DC=test,DC=local" | select-object Surname,Givenname,telephoneNumber

Surname ist hier der Nachname, während Givenname den Vornamen repräsentiert.

(ID:44521652)