SelfLinux Linux im Netzwerk Das Lightweight Directory Access Protocol Abschnitt 2 | SelfLinux-0.13.0

| Das Lightweight Directory Access Protocol | Autoren Formatierung GFDL

#### 2 Eine kleine Einführung in LDAP

#### 2.1 Was ist LDAP?

LDAP ist die Abkürzung von "Lightweight Directory Access Protocol". Das LDAP entstand ursprünglich als Front-End für den X.500-Verzeichnisdienst. Da X.500 als kompletter OSI-Stack implementiert ist, war es nicht möglich, diesen Verzeichnisdienst flächendeckend zu implementieren. LDAP ist ein Verzeichnisdienst, der auf dem TCP/IP-Protokoll basiert und somit ressourcenschonender für die Netzwerk-Infrastruktur ist. Obwohl LDAP nur einen Teil der Funktionen des DAP zur Verfügung stellt, reicht es aus, um die fehlenden Funktionen vollständig zu emulieren. Basis für LDAP sind die im Abschnitt Literatur aufgeführten RFC's.

#### 2.2 Welche Informationen kann LDAP zur Verfügung stellen?

LDAP speichert seine Informationen in einer Baumhierarchie. Diese Hierarchie kann diverse Informationen enthalten. Einen Überblick verschafft RFC 2307, in dem mögliche Inhalte der LDAP Hierarchie spezifiziert sind:

- Benutzer
- Gruppen
- IP-Dienste
- IP-Protokolle
- RPC's
- NIS-Netzwerkgruppen
- Boot-Informationen
- Einhängepunkte für Dateisysteme
- IP-Hosts und Netzwerke
- RFC 822 konforme Mail-Aliase

#### 2.3 Strukturierung der Informationen

Hat man Daten in Datenbanken, so ist es wichtig, diese Informationen zu strukturieren. Besonders, wenn viele verschiedene Clients auf die Datenbank zugreifen wollen, zum Beispiel Netscape, Outlook und andere, muss die Struktur genau definiert sein. Wenn ein Mailclient eine eMail-Adresse braucht, muss er wissen, wie er diese bekommt.

Es gibt viele Definitionen, an die man sich halten muss, soll am Ende auch etwas funktionieren. Bei LDAP werden Objekte mit Eigenschaften verwendet. Jedes Objekt hat zunächst einen eindeutigen Namen, an dem es von allen anderen unterschieden werden kann ("distinguished name", kurz: DN). Die Eigenschaften eines Objekts hängen davon ab, zu welcher Klasse es gehört (es kann sogar zu mehreren Klassen gehören).

#### 2.3.1 Klassen von Objekten

Es sind nun Klassen für Personen definiert. Zu einer Person ("person") gehören zwingend objectClass (die Objektklasse selbst), sn (der Nachname) und cn (commonName, etwa: üblicher Name, hier wird üblicherweise Vor- und Nachname verwendet). Zusätzlich gibt es optionale Attribute, die nicht unbedingt angegeben werden müssen. Diese sind hier description (beliebige Beschreibung), seeAlso (verweist auf ein anderes Objekt), telephoneNumber (Telefonnummer), userPassword (ein Password). Da häufig noch mehr Attribute mit einer Person verknüpft sind, gibt es auch eine Objektklasse organizationalPerson. Diese hat die gleichen geforderten Eigenschaften wie Person, aber erlaubt viele optionale Eigenschaften, wie zum Beispiel Felder der Adresse und eine FAX-Nummer. Es gibt noch mehr Klassen, zum Beispiel newPilotPerson (die als optionale Eigenschaft eine eMail-Adresse mail einführt) und natürlich Klassen für Organisationen/Firmen, Abteilungen, Bilder, Dokumente, Geräte und so weiter.

#### 2.3.2 Eigenschaften von Klassen

Wenn man also irgendwo eine Person im Verzeichnis hat, ist klar, dass diese ein cn" haben muss, und eine Telefonnummer haben kann (und dass diese genau telephoneNumber heißt). Soll ein Programm eine eMail-Adresse suchen, muss es nur nachschauen, ob es ein Attribut mail gibt. Es kann eben nicht sein, dass diese Eigenschaft email oder anders heißt. mail ist vorgeschrieben, und nichts anderes.

An diesem Beispiel kann man zeigen, dass eine natürliche Person zu mehreren Klassen gehört: person, organizationalPerson und newPilotPerson. Eine weitere Klasse ist top. Im Prinzip gehört so ziemlich jedes Objekt auch zur Klasse top, die lediglich vorschreibt, dass die Eigenschaft objectClass gesetzt sein muss (was bei allen Personenklassen ohnehin gefordert ist).

Durch das Verwenden der Klassen definiert man, welche Eigenschaften vorhanden sein müssen, und welche vorhanden sein können. Eine Person darf zum Beispiel keine Farbtiefe haben, ein Bild hingegen schon. Verwendet man mehrere Klassen, so muss das entsprechende Objekt alle von mindestens einer Klasse geforderten Eigenschaften haben, und kann alle insgesamt erlaubten Eigenschaften haben.

#### 2.3.3 Typen von Eigenschaften

Den Eigenschaften sind Typen zugeordnet. Es gibt Typen, die eine Zeichenkette enthalten, und andere, die eine Telefonnummer enthalten. Diese Typen definieren weiterhin, wie Werte verglichen (und damit sortiert und gesucht) werden. Zeichenketten beispielsweise kann man abhängig von Groß- und Kleinschreibung vergleichen oder auch nicht. Bei Telefonnummer spielen gewisse Füllzeichen möglicherweise keine Rolle. Passwörter hingegen müssen genau übereinstimmen.

Es gibt nun also Objekte (die zu bestimmten Klassen gehören). Diese werden nun anderen Objekten untergeordnet (beziehungsweise werden anderen Objekte viele zugeordnet, dies ist die richtige Reihenfolge). Diese baumartige Struktur kann man (mit etwas Phantasie) auch in der Realität finden: In Ländern gibt es Firmen, in Firmen gibt es Abteilungen und in Abteilungen letztlich Personen. So wird das in LDAP auch gesehen. Die Baumstruktur wird hier "Directory Information Tree" genannt, kurz DIT. Es gibt Länder (also Objekte der Klasse country [Land]) mit u.A. der Eigenschaft c (kurz für country), Firmen (organisations mit der Eigenschaft o), Abteilungen (Organisations Einheit, organisationalUnit mit der Eigenschaft ou). Hierbei enthalten diese Objekte normalerweise viele weitere Eigenschaften; eine Firma hat zum Beispiel eine Postanschrift.

#### 2.3.4 Schema

Ein Schema ist eine Sammlung von Strukturdefinitionen. Dazu gehören die Schreibungen vieler Klassen und der verwendeten Typen. Es gibt verschiedene Schemata, und es ist möglich, eigene zu definieren (oder bestehende zu erweitern) was jedoch nicht interoperabel mit anderen Diensten sein muss. Das ist außerhalb der Betrachtungen dieses Dokumentes.

#### 2.3.5 Zusammenfassung

Der LDAP-Server speichert seine Informationen in einer baumartigen Struktur. Diese wird auch "Directory Information Tree" genannt, kurz DIT.

Zum Speichern benutzt der LDAP-Server Objekte, die er mit Attributen versehen kann. Dadurch kann man die Struktur flexibel an die eigenen Bedürfnisse anpassen. Das RFC 2256 spezifiziert die Standard-Objekte des LDAP-Servers. Man wird zwar von niemandem gezwungen, diese Vorgaben auch zu benutzen. Um aber eine möglichst große Konformität zu erzielen, sollte man diese Vorgaben einhalten.

#### 3 Technische Daten des LDAP Server

Der Zugriff auf den LDAP-Server erfolgt über das LDAP-Protokoll via TCP/IP. Per Default lauscht der slapd ("Stand-alone LDAP Daemon": Der LDAP-Dienst) auf dem Port 389. Dies ist im RFC 1777 spezifiziert.