VerzeichnisdienstLDAP/OpenLDAP

Stefan Drzazga02INF209440

1

Inhaltsverzeichnis

1 Der Verzeichnisdienst 3

1.1 Objektorientierte Strukturen 4

1.2 Der Weg zu LDAP 4

1.3 LDAP im Einsatz 7

1.4 Die Administration in Netzwerken mit LDAP 8

2 Grundlagen X.500 9

2.1 Objekte 10

2.2 Attribute 11

2.3 Verzeichniseinträge 11

2.4 Vererbung 12

2.5 Polymorphismus in Klassen 12

2.6 Standardisierung von Attributen und Objektklassen 13

2.7 Objektklassentypen 15

2.8 Verzeichnisbaum 15

2.9 Aliase 16

2.10 Referenzierung durch Namen 17

2.10.1 Relative Distinguished Name 17

2.10.2 Zusammengesetzter RDN 18

2.10.3 Überführung RDN zu DN 19

3 Die LDAP Sitzung 20

3.1 Messages und Operationen 20

4 Die Verteilung des Verzeichnisses 22

4.1 Naming Context 22

4.2 Referrals und Continuations 23

5 Sicherheit 24

5.1 Zugriffskontrolle im LDAP 24

5.2 Authentifizierung 25

5.3 Der Strong Bind 27

6 Schema – Klassen unter LDAP 28

6.1 Allgemeiner Aufbau eines Schemas 29

6.2 Eigene Schemata entwerfen 29

6.3 Referenzierung von Objekten durch Name oder OID 30

6.4 Der Object Identifyer (OID) 31

6.5 AttributeTypes 31

6.6 ObjectClasses 32

7 Das LDIF 33

7.1 Die Anweisungen 34

7.2 Versionsnummer 34

7.3 Datensatz 35

8 Ein Blick in die Zukunft 36

Literaturverzeichnis 38

2

1 Der Verzeichnisdienst

Für was und und warum brauchen wir eigentlich Verzeichnisdienste, wo wir doch die große

Auswahl zwischen relationalen Datenbanken, Textdateien oder andere Möglichkeiten für die

Haltung unserer Daten haben?

Dabei liegen die wesentlichen Vorteile auf der Hand:

• auf Verzeichnisse wird meist meistens eher lesend als scheibend zugegriffen,

• ein Verzeichnis organisiert seine Daten in einer baumartigen Hierarchie, dem

Verzeichnisbaum,

• die Teilbäume des Verzeichnisbaums können auf unterschiedliche Hosts verteilt sein,

• Teilbereichen des Verzeichnisbaums können durch Delegation einfach administriert

werden,

• durch den Verzeichnisbaum wird es ermöglicht, das Suchen von vornherein auf

interessante Teilbäume zu beschränken,

• viele Verzeichnisdienste basieren auf dem X.500-Modell und unterstützen damit von

vornherein ein objektorientiertes Datenmodell

Ein einfaches Beispiel für die Anwendung eines Verzeichnisses stellt das Domain Name

System dar. Selbst wenn man sich darauf beschränkt, das DNS nur als ein System zur

Abbildung von menschenlesbaren Zonennamen wie ,,www.fh-merseburg.de“ auf IPv4-

Adressen wie ,,191.122.234.17“ wahrzunehmen, dann erkennt man, dass zur Bewältigung

dieser Aufgabe ein System mit verteilter Datenhaltung und Administration notwendig ist.

Man erkennt auch, wie die oben aufgelisteten Vorzüge von Verzeichnisdiensten im Jahre

1984 gefällte Entscheidung beeinflussten, zur Verwaltung der Zonennamen in Zukunft einen

Verzeichnisdienst zu verwenden.

Ein deutlicher Anwendungsfall für Verzeichnisse ist die Abbildung von Organisationen. Die

Tatsache, dass Organisationen dazu neigen, hierarchisch aufgebaut zu sein, harmonisiert mit

dem hierarchischen Aufbau eines Verzeichnisbaumes.

In diesem Zusammenhang erweist sich auch die Option, die Verwaltung von Teilbäumen nach

unten zu delegieren als vorteilhaft:

In einem Konzern können kleinere Organisationseinheiten, z.B. die Niederlassungen einzelner

Teilfirmen, ihre eigenen Verzeichnisse aufbauen; Teilfirmen können die Verzeichnisse ihrer

einzelnen Niederlassungen oder Abteilungen zusammenfassen und die Verzeichnisse der

3

Teilfirmen werden auf der Ebene des Konzerns gemeinsam erfasst, so dass man ganz oben

den vollen Überblick hat. Die Administration eines solchen organisationsorientierten

Verzeichnisses kann bis zur Ebene der einzelnen Benutzer herunter delegiert werden:

Adressverzeichnisse, in denen die Benutzer ihre eigenen Adressbucheinträge unter Benutzung

eines Web-Frontends selber verwalten sind ein Beispiel für diese Art der Delegation(User

Based Administration).

1.1 Objektorientierte Strukturen

Aber welche Daten sollte eine Firma überhaupt in einem Verzeichnis erfassen wollen? Sehr

oft werden zum Beispiel die Daten der Angestellten einer Firma erfasst. Diese Datensätze

können Dinge wie Namen, Adressen, Telefonnummern, E-Mail-Adressen oder Ähnliches

enthalten.

In einer Tabelle muss für jedes Element des Datensatzes eine Tabellenspalte vorgesehen sein.

Bei Verzeichnisdiensten, die dem X.500-Standard entsprechen, verwendet man stattdessen so

genannte Objektklassen, um die Struktur der Datensätze zu beschreiben. Was geschieht nun,

wenn es notwendig wird, die Personendatensätze um eine neue Komponente zu erweitern? Es

wird zum Beispiel in der Praxis oft nötig, die Verwaltung von E-Mail-Adressen oder

kryptographischen Schlüsseln nachträglich in Verzeichnisse zu integrieren. Während eine

solche Änderung bei einer relationalen Datenbank entweder die Erweiterung oder das

Neuanlegen einer Tabelle erfordert – beides Änderungen, die zentral erfolgen müssen ; kann

man bei einem X.500-kompatiblen Verzeichnis durch Vererbung eine neue Objektklasse

erzeugen, die eine vorhandene Klasse um das entsprechende Feld erweitert. Diese

Veränderung des Verzeichnisses kann auch auf einer niedrigen administrativen Ebene

erfolgen, was es ermöglicht, Verzeichnisse ohne zentrale Eingriffe flexibel an die

Erfordernisse niedriger Hierarchieebenen anzupassen.

1.2 Der Weg zu LDAP

Mit den X.500-Standards und LDAP haben sich zwei Arten von Spezifikationen für

Verzeichnisdienste etabliert, die in einer sehr engen Beziehung zueinander stehen. Dies hat

vor allem historische Gründe, die bis auf das frühe PC- und Client/Server-Zeitalter

zurückgehen. In dieser Frühzeit vor und bis etwa zum Jahr 1985 existierten in den typischen

Firmennetzen allerlei historisch gewachsenen Systemarchitekturen nebeneinander her. Der

Datenaustausch zwischen verschiedenen Systemen gestaltete sich aber meist schwierig oder

4

war mitunter unmöglich, da es entweder keine oder nur sehr schlechte Schnittstellen zwischen

den verschiedenen Systemen gab. Mit der fortschreitenden Computerisierung der

Arbeitsplätze verstärkte sich aber das Bedürfnis, Daten auch zwischen verschiedenen

Systemen austauschen zu können. Typischerweise wollte man mit dem MAC, PC oder Amiga

am Arbeitsplatz auf einen Unix-Server bzw. eine Mainframe im Hintergrund zugreifen.

Bei der Entwicklung von Interfaces, die ad hoc zwei Architekturen miteinander verbanden,

geriet man schnell in ein Dilemma. Dieser Ansatz hat nämlich einen entscheidenden

Nachteil:Der Aufwand wuchs quadratisch mit der Anzahl der zu verbindenden Systeme.

Erschwerend kam hinzu, dass man zur Implementation eines Interfaces zwischen System A

und System B Kenntnisse der Systeme A und B haben musste. Die langfristig bessere

Alternative zum oben beschriebenen Interfacemodell stellt das Schichtenmodell dar. Dabei

wird ein zentrales Kommunikationsprotokoll definiert, so dass auf jedem der zu verbindenden

Systeme nur eine Schnittstelle zu diesem zentralen Protokoll implementiert werden muss.

Bekanntlich setzte sich im Laufe der 80er Jahre die Erkenntnis durch, dass der bessere Weg

zur gewünschten Interoperabilität ein solches gemeinsames Kommunikationsprotokoll zum

Datenaustausch ist.

Aus der Sicht dieser Zeit boten sich zwei Möglichkeiten an, um zu einer solchen universellen

Kommunikationsschicht zu kommen:

1. Der komplette Neuentwurf einer solchen Schicht.

2. Die Adaption der TCP/IP-Protokollfamilie.

Der Aufgabe des universellen Neuentwurfes widmete sich die CCITT(Comité consultatif

international télégraphique et téléphonique), eine Unterorganisation der Vereinten Nationen

mit Sitz in Genf, die später zur International Telecommunication Union (ITU) mutierte.

Die ITU produzierte im Laufe der Jahre zahlreiche Standards, die als X-Serien bekannt sind,

da sie Kurzbezeichnungen haben, die mit einem großen X beginnen(z.B. X.200, das ISO/OSI-

Modell). Auch für Verzeichnisdienste existieren eine Reihe von X Standards: die X.500

Serien. Diese X.500-Standards definieren, wie Verzeichnisdaten zur Verfügung gestellt und

abgerufen werden sollen, wie Verschlüsselung,Authentifizierung, Replikation und

Verwaltung der Verzeichnisdaten gehandhabt werden, und zu guter letzt liefern sie die

funktionalen Modelle und den Begriffsapparat auch für solche Verzeichnisdienste, die nicht

mehr vollkommen auf dem X.500-Standard beruhen, namentlich für LDAP.

X.500 definiert zwei Subprotokolle namens DSP und DAP. Ersteres steht für Directory

System Protocol, letzteres bedeutet Directory Access Protocol. Während das DSP zur

5

Kommunikation der Server untereinander gedacht ist, soll das DAP zur Interaktion zwischen

Benutzerprozess und Serverprozess dienen. (In der X.500-Terminologie wird die

Clientanwendung als Directory User Agent, kurz DUA, die Serveranwendung Directory

Server Agent oder kurz DSA genannt).

Das DAP erwies sich aber in gewisser Weise als Hemmschuh für die weitere Verbreitung von

X.500-basierten Directory Services. Während nämlich die X.500-Standards auf dem

komplizierten 7-schichtigen OSI Modell basieren, setzte sich in der Praxis das einfachere

TCP/IP-Modell als Standard für die Vernetzung unterschiedlicher Systeme durch. Ab Mitte

der 90er Jahre wurden immer mehr lokale Netze mittels der Protokolle aus dem TCP/IP-

Modell zu Intranets verbunden oder an das Internet angeschlossen.

Mit dieser Entwicklung hin zu großen, potenziell unübersichtlichen Netzen tat sich für

Verzeichnisdienste eine Fülle von neuen Einsatzmöglichkeiten bei der Verwaltung solcher

Netze auf. Die Entwicklung von Clients wurde aber durch die Komplexität des DAP-

Protokolls erschwert: DAP setzt auf der Transportschicht des ISO Protokollstacks, und nicht

auf dem verbreiteten TCP auf. Ein OSI Protokollstack war in den Desktop-Betriebssystemen

nicht implementiert und hätte wahrscheinlich auch die damalige Hardware völlig überfordert.

Ein TCP/IP-Stack konnte hingegen selbst bei den 16-bittigen DOS/Windows-Versionen

nachgerüstet werden. Heute findet man IP Stacks auch schon in Telefonen und Spielkonsolen.

Als Ausweg aus dem DAP-Dilemma wurde im Juli 1993 im RFC 1487 das Lightweight

Directory Access Protocol spezifiziert.

Die Essentials beim Entwurf dieses Protokolls waren:

1. Das LDAP sollte eine wesentliche Teilmenge des DAP-Protokolls

implementieren.

2. Das LDAP sollte direkt auf der TCP-Schicht aufsetzen, damit der

OSI-Overhead entfallen konnte.

Ebenfalls im Juli 1993 wurde von den Autoren des RFC 1473 an der University of Michigan

(UMich) die erste LDAP-Implementation ldapd vorgestellt.

Eine überarbeitete LDAP-Version LDAPv2 wurde im Jahr 1995 vorgestellt und in den ldapd

implementiert. LDAPv2 ist nach wie vor weit verbreitet und wird nur langsam durch LDAPv3

verdrängt.

Ein weiteres Update der LDAP-Spezifikation erfolgte 1997 mit RFC 2251, der die dritte

Version des LDAP (LDAPv3) spezifiziert.

6

Seit August 1998 wird das LDAP-Projekt der UMich unter dem Namen OpenLDAP von einer

eigens gegründeten Non-Profit-Organisation, der OpenLDAP Foundation koordiniert.

1.3 LDAP im Einsatz

Die ursprüngliche Idee hinter LDAP war, dass dieses Protokoll serverseitig

durch eine Middleware implementiert werden sollte, die per LDAP mit den Clients und über

die X.500-Protokolle mit einem oder mehreren X.500-DSP(s) kommuniziert. Abbildung XX

zeigt diesen typischen Anwendungsfall. Für den wachsenden Erfolg von LDAP ist aber auch

ein Paradigmenwechsel mitverantwortlich, durch den sich die Einsatzgebiete dieses

Protokolls verlagern, und zwar weg von einer Middleware, die zwischen TCP/IP und X.500

vermittelt, hin zu einer Serversoftware die LDAP-fähigen Clients den Zugriff auf eine fast

beliebige Datenbasis vermittelt. OpenLDAP enthält einen slapd genannten Standalone LDAP

Daemon, mit dem man auf verschiedene Backends zugreifen kann. Trotz der partiellen

Abkehr von der X.500-Datenhaltung kann LDAP aber seine Wurzeln nicht verleugnen, denn

wie auch immer das Backend geartet ist, die Grundlage für das zugrunde liegende

Datenmodell, basiert nach wie vor auf den X.500-Standards.

Die aktuelle LDAP-Version ist LDAP Version 3, kurz LDAPv3 genannt. LDAPv3 ergänzt die

Version 2 in vielerlei Hinsicht. Neuheiten umfassen u.a:

• starke Authentifizierung durch SASL,

• optionaler Integritätsschutz und Verschlüsselung durch das auf

SSL basierende TLS-Protokoll,

• Internationalisierung durch Unicode,

• Verweise auf andere LDAP-Server, so genannte Referrals und

Continuations,

• Veröffentlichung der Datendefinition durch den Server (Schema

Discovery).

Die Kernbestandteile von LDAPv3 werden in einer Reihe von RFCs, den so genannten

LDAPv3 Core Specifications beschrieben.

Der Name Core Specs lässt bereits ahnen, dass auf der Grundlage dieser Spezifikationen

weitere Spezifikationen entstanden sind. Die Internet Engineering Task Force (IETF) hat dazu

eine Expertengruppe, die LDAP Extension Working Group eingerichtet.

Die Intension dieser Gruppe ist es u.a. sich mit den Themen: Authentifizierung und

7

Verschlüsselung, Verarbeitung von Suchergebnissen, dynamische Verzeichnisse und

Standardisierung von APIs für die Cliententwicklung auseinander zu setzen.

1.4 Die Administration in Netzwerken mit LDAP

Obwohl man mit Verzeichnisdiensten und deren unaufwändigster Variante LDAP vom

Kaufhauskatalog bis zum weltweiten Telefonbuch allerlei schöne Dinge realisieren kann, ist

es der Einsatz von LDAP zur Verwaltung von Netzwerkinformation, der ein starkes Interesse

an LDAP auslöst. LDAP ist in die Verzeichnisdienste NDS (Novell) und ADS (Microsoft)

integriert und erlaubt es endlich, Benutzerinformationen für heterogene Netzwerke zentral zu

verwalten. Im Idealfall hat der Anwender mit einem Username und Passwort Zugriff auf alle

Informationen im Netz und der Administrator seine Ruhe, da er sich nicht mehr um die

Benutzerverwaltungen kümmern muss. RFC 2307 beschäftigt sich schon mit der zentralen

Verwaltung weiterer Netzwerkinformation mittels LDAP:

• Benutzer und Gruppen (/etc/passwd, etc/groups),

• IP-Dienste (Zuordnung zwischen Diensten, Portnummern),

• IP-Protokolle (/etc/protocols),

• RPCs (Zuordnung von Remote-Procedure-Call-Nummern zu

RPC-Diensten wie in /etc/rpc),

• NIS-Informationen,

• Boot-Informationen (MAC-Adressen und Boot-Parameter),

• Mountpoints für Dateisysteme (/etc/fstab),

• Mail-Aliase.

8

2 Grundlagen X.500

Die Welt der X.500 Protokolle und das davon abgeleitete LDAP besteht aus ,,Objekten“. Wer

Vorkenntnissen in objektorientiertem Design hat wird feststellen, dass wesentliche OO-

Konzepte wie ,,Objekte“, ,,Klassen“, ,,Vererbung“ , ,,Polymorphie“ und deren intensive

Wiederverwertung in der Welt des X.500 wichtige eine Rolle spielen, wenn auch manchmal

unter verändertem Namen.

Die Aufgabe des Verzeichnisses ist es, die Objekte abzubilden und miteinander in Beziehung

zu setzen. Ein Objekt wird im Verzeichnis durch einen Verzeichniseintrag repräsentiert. Der

Verzeichniseintrag besteht im Wesentlichen aus einer Liste von Eigenschaften des Objektes,

den so genannten Attributen, sowie aus einem Namen, dem Distinguished Name. Wie der

Name einer Datei im Dateisystem oder der Name einer Zone im DNS wird der Distinguished

Name in einen hierarchischen Namensraum eingeordnet. Auf diese Weise entsteht eine

Baumstruktur, in der die Einträge angeordnet sind, der Directory Information Tree.

Abbildung 1 zeigt einen Ausschnitt aus den Organisationsverzeichnis der Firma MySQL AB,

die aus einem Mitarbeiter und aus einem Notebook besteht.

Abbildung 1 - DIT der Firma MySQL

Im Verzeichnis der MySQL AB finden wir alle Elemente eines Verzeichnisses wieder:

• einen Verzeichnisbaum, der die Firma in der Hierarchie höher ansiedelt

als beispielsweise den Mitarbeiter oder den Notebook,

• Einträge für die Firma, den Mitarbeiter und den Notebook,

• viele Attribute:

• O, L und DESC für die Firma,

9

OrganisationO: MySQL ABL: HamburgDESC: MySQL NiederlassungDeutschland

Personcn: Michael Monty WideniustelephoneNumber: 01083726352

Devicecn: MyNotebookserialNumber: 01083726352

• CN und telephoneNumber für den Mitarbeiter,

• CN und serialNumber für das Notebook.

Man kann an diesem Beispiel auch erkennen, dass Einträge und Attribute einer

Standardisierung unterliegen: Einträge gehören zu bestimmten Objektklassen, die die

Attribute des Eintrages vorschreiben. Hier sind das die Objektklassen Organisation, Person

und Device für die Firma, den Mitarbeiter und das Notebook.

Auch die hier verwendeten Attribute sind standardisiert. Dies merkt u.a. daran, dass die

Namen der meist verwendeten Attribute bis zur Unkenntlichkeit abgekürzt sind, zum anderen

sieht man, dass das Attribut cn sowohl beim Mitarbeiter (Person) als auch beim Notebook

(Device) vorkommt. Die Bedeutung der nicht offensichtlichen Attributnamen ist die folgende:

O: Organisation, der Name einer Organisation.

L: Location, ein geographischer Ort.

DESC: Description, menschenlesbare Beschreibung.

CN: Common Name, der Name, unter dem das Objekt gewöhnlich angesprochen wird.

2.1 Objekte

Was ist ein Objekt? Diese Frage kann an dieser Stelle gar nicht wirklich beantwortet werden,

denn die Objekte der realen Welt sind etwas Vorgegebenes, etwas, das man zu akzeptieren

und mit dem man zu arbeiten hat. Trotzdem ist eine wichtige Eigenschaft die folgende:

Ein Objekt verfügt über einen Menge von Eigenschaften (Attribute).

Ein besonderes Attribut ist der Name des Objektes.

Natürlich hat ein Objekt in der realen Welt, wie z.B. ein Mensch, eine große Zahl von

Eigenschaften. Dies ist aber für die maschinelle Verwaltung von Objekten von geringer

Bedeutung, da es üblicherweise nur wenige standardisierte Attribute sind, die an einem

Objekt interessieren. Für die Postzustellung ist es eher uninteressant, ob ein Mensch eine

besondere musikalische Begabung hat, hier interessieren lediglich der Name und die

Anschrift. Man fasst daher Objekte zu Objektklassen (engl.: object classes) zusammen.

Eine solche Objektklasse besteht aus einem Satz von notwendigen und/oder optionalen

Attributen, mit denen sich ein Objekt dieser Klasse beschreiben lässt. Für die Postzustellung

könnte dies z.B. die standardisierte Objektklasse residential Person sein.

10

2.2 Attribute

Verglichen mit den Feldern eines Datensatzes im relationalen Modell sind die Attribute des

X.500-Modells recht komplexe Objekte. Ein Attribut besteht aus:

• einem Namen, mit dem das Attribut innerhalb des Objektes eindeutig

referenziert werden kann,

• keinem, genau einem oder einer Liste von Attributsausprägungen.

Um die Wiederverwendung von Attributen in verschiedenen Objektklassen zu unterstützen,

werden Attribute getrennt von den Objekten definiert, und zwar in Form von Attributtypen

(engl. Attribute Type) . Der Attributtyp enthält die folgenden Komponenten:

• Den Namen und/oder die OID, die den Attributtyp eindeutig bestimmt.

• Optional eine menschenlesbare Beschreibung (Description).

• Optional Definitionen darüber, welche Regeln für Gleichheit

(EQUALITY), Treffer von Teilzeichenketten (SUBSTR) und die

lexikalische Anordnung (ORDERING) dieses Attributes gelten sollen.

• Eine Syntaxbeschreibung, meist in Form einer OID. Dadurch

wird z.B festgelegt, ob es sich um eine Zahl, eine Zeichenkette,

ein binäres Objekt oder um etwas noch ausgefalleneres handelt.

• Einem Qualifier, der festlegt, ob ein Attribut einen einfachen Wert

(SINGLE-VALUE) oder eine Liste von Werten COLLECTIVE haben

kann. Im letzten Fall kann auch zusätzlich noch eine Listenlänge

(LENGTH) angegeben werden.

2.3 Verzeichniseinträge

Ein konkretes Objekt wird in einem Verzeichnisdienst durch einen Verzeichniseintrag (engl.

directory entry oder einfach entry) repräsentiert. Um einen solchen Eintrag von einer

bestimmten Objektklasse zu erhalten, weist man einfach den für diese Objektklasse

vorgesehenen Attributen bestimmte Werte zu. In diesem Sinne entsprechen die Einträge eines

Verzeichnisses den Ausprägungen im objektorientierten Design bzw. in der objektorientierten

Programmierung. Je nachdem, ob man mit dem Denken in Objekten vertraut ist oder nicht,

sollte man sich einen Eintrag wahlweise als eine Ausprägung von Objektklassen oder als eine

11

Menge von Attributen vorstellen:

Objektorientierte Definition: Ein Verzeichniseintrag ist eine Ausprägung einer oder

mehrerer Objektklassen. Er wird angelegt, indem man allen für diese Objektklassen

obligatorischen Attributen und einigen der fakultativen Attribute Werte zuweist.

Attributorientierte Definition: Ein Verzeichniseintrag besteht aus einer Menge von

Attributen und gehört einer oder mehreren Objektklassen an. Durch die Objektklassen wird

festgelegt, welche Attribute obligatorisch und welche Attribute fakultativ sind.

2.4 Vererbung

Ein weiteres Konzept, das auch in der Objektorientierten Welt eine zentrale Rolle spielt, ist

das Konzept der Vererbung. Eine Objektklasse kann als Unterklasse einer anderen Klasse

definiert werden und erbt dann deren Attributdefinitionen.

Ein Entwickler, der eine vorhandene Klasse um bestimmte Attribute erweitern will, leitet

einfach eine neue Klasse von ihr ab und braucht die schon vorhandenen Definitionen nicht zu

wiederholen. Wenn an der Superklasse nachträglich etwas geändert werden muss, dann

machen alle davon abgeleiteten Klassen diese Änderung automatisch mit, ohne dass weitere

Aktionen des Entwicklers notwendig wären. X.500 Objektklassen erlauben nur eine einfache

Vererbung, d.h., eine Objektklasse darf nur von einer anderen Objektklasse abgeleitet sein.

Hierin unterscheiden sich die X.500 Klassen von Klassen in einigen OOSprachen, die wie

C++ oder Perl die Mehrfachvererbung unterstützen.

2.5 Polymorphismus in Klassen

Ein Verzeichniseintrag hat ein Attribut mit Namen objectClass, das festlegt,

welchen Klassen der Eintrag angehört. Das objectClass-Attribut ist Mehrwertiges, so dass ein

Eintrag mehreren Objektklassen angehören und damit auch deren jeweilige Attributsätze

erben kann. Dieses Konzept ähnelt der umstrittenen Mehrfachvererbung in OO-Sprachen. Der

Unterschied ist aber, dass mehrfache Klassenzugehörigkeit im X.500-Modell bei den

Einträgen auftritt, während sie in C++ oder Perl auf der Ebene der Klassen stattfindet, die den

Objektklassen des X.500-Modells entsprechen.

Diese Polymorphie der Verzeichniseinträge ist nicht die Ausnahme, sondern die Regel, denn

jeder Eintrag muss entweder der Klasse top oder der Klasse alias angehören. Ein von top

abgeleiteter Eintrag ist ein ,,echter“ Eintrag, ein von alias abgeleiteter Eintrag ist nur ein

12

Verweis auf einen anderen Eintrag. Zu den beiden minimal vorhandenen Werten des

objectClass-Attributes können dann noch beliebig viele weitere geeignete Objektklassen

hinzugefügt werden.

2.6 Standardisierung von Attributen und Objektklassen

Häufig stellt sich in einem Anwendungsfall das Problem, Daten für ,,anonyme“

Clients bereitzustellen, d.h. Clientanwendungen, die beim Entwurf des Verzeichnisses noch

nicht bekannt waren und die ohne explizite Kenntnis des Verzeichnisses entworfen wurden.

Ein typisches Beispiel für eine solche Situation sind LDAP-Adressverzeichnisse, die von

Mailprogrammen, Web-Browsern oder Groupware benutzt werden.

X.500/LDAP stellt zwar einen Mechanismus bereit, mit dem man Informationen zwischen

Anwendung und Server austauschen kann, sagt aber nichts darüber aus, welche Struktur die

Objekte haben, die ausgetauscht werden sollen, obwohl eine gewisse Kenntnis der

vorhandenen Attribute (Namen, Vornamen, Telefonnummer, ...) für das Funktionieren einer

solchen Anwendung notwendig ist. Um die Interaktion von anonymen Clients und

Verzeichnissen zu ermöglichen, werden häufig gebrauchte Objektklassen und Attribute

standardisiert. Grundlegende Dokumente zu diesem Thema sind die X.500-Standards X.520

(The Directory: Selected Attribute types) und X.521 (The Directory: Selected Object classes).

Sie definieren eine Vielzahl von Standardattributen bzw. Standardklassen, unter anderem die

Klassen Person und organizationalPerson, die die Grundlage für die meisten

Benutzerverwaltungen bilden. Das RFC 2256 A summary of the X.500 User Schema for use

with LDAPv3 bietet auf zehn Seiten eine kompakte Zusammenfassung der wichtigsten

Attribut- und Objektklassen.

Viele weitere Standardklassen werden auch in anderen RFCs definiert. Zum Beispiel definiert

RFC 2798 die Klasse inetOrgPerson, die wahrscheinlich meist benutzte Klasse in der LDAP-

Welt überhaupt.

Aus den oben beschriebenen Gründen sollte man standardisierte Objekte verwenden, wo

immer das möglich ist. Dies ist in einer erstaunlich großen Mehrzahl der Anwendungsfälle

der Fall, denn eine sinnvolle Nutzung der Vererbungsmechanismen erlaubt es, gleichzeitig

Objekte flexibel zu entwerfen und standardisierte Schnittstellen zu verwenden:

Muss man z.B. ein Personenverzeichnis mit einer Personenklasse entwerfen, das zusätzliche

Attribute zu einer solchen Klasse hinzufügt (z.B. Ausbildungsstand), dann kann man eine

eigene Personenklasse von einer standardisierten Personenklasse ableiten und um eigene

Attribute ergänzen. Damit ist dann garantiert, dass alle Attribute, die die Standardsoftware

13

erwartet, auch tatsächlich zur Verfügung stehen und dass Standardsoftware mit diesem

Verzeichnis korrekt funktionieren kann.

Ein gutes Beispiel für diese Strategie liefert RFC 2798. Hier wird die noch nicht an das Leben

in einer vernetzten Welt angepasste X.500-Klasse organizationalPerson um zahlreiche

optionale Attribute erweitert.

Abbildung 2 - Objektklasse Person

14

2.7 Objektklassentypen

X.501 definiert drei Typen von Objektklassen:

• structural

• auxiliary

• abstract

Eine Objektklasse sollte als structural deklariert werden, wenn sie elementare

Attribute eines Objektes definiert. Beim Beispiel der Objektklassen zur Beschreibung von

Personen ist dies die Objektklasse Person und damit ihre Subklassen. X.501 fordert, dass ein

Eintrag immer von mindestens einer als structural deklarierten Klasse abgeleitet ist.

Andererseits legt X.501 auch fest, dass nur eine Klasse eines Eintrags überhaupt strukturelle

Klassen in ihrem Ableitungsbaum enthalten darf.

Eine als auxiliary definierte Objektklasse fügt neue Eigenschaften zu einem Eintrag hinzu,

determiniert aber nicht den Typ des Eintrages, der durch seine strukturelle Klasse bestimmt

wird. Es ist gewissermaßen der Regelfall, dass eine Objektklasse vom Typ auxiliary ist. Es ist

eigentlich nur dann gerechtfertigt, eine eigene Klasse als structural zu definieren, wenn

darauf eine völlig neue Objekthierarchie aufgebaut wird. Einige wenige Objektklassen sind

weder als structural, noch als auxiliary, sondern als abstract deklariert. Dieses Konzept

entspricht den abstrakten Klassen, wie sie aus Objektorientierten Programmierung bekannt

sind: Abstrakte Klassen sollen nicht initialisiert werden, sondern dienen als Vorlage, um von

ihnen abgeleiteten konkreten Klassen bestimmte Eigenschaften zu geben. Beispiele für

abstrakte Klassen sind die Objektklassen top und alias, die zur Beschreibung der Struktur des

Verzeichnisbaumes verwendet werden.

2.8 Verzeichnisbaum

Typisches Merkmal eines Verzeichnisdienstes ist die Anordnung von Objekten (bzw. der die

Objekte repräsentierenden Einträge) in einer baumartigen Struktur. Dieser Baum wird in

LDAP X.500-konform als Directory Information Tree oder kurz DIT bezeichnet. Der

Verzeichnisbaum kommt dadurch zustande, dass manche Verzeichniseinträge anderen

Einträgen übergeordnet sind.

In anderen Verzeichnisdiensten (z.B. Novell Directory oder Microsofts Active Directory)

werden solche übergeordneten Objekte auch Container genannt. Die Vorstellung dabei ist,

dass ein Container untergeordnete Objekte enthält. Objekte, die keine weiteren Objekte

enthalten, werden auch als Blätter bezeichnet. Jedes übergeordnete Objekt definiert durch die

15

in ihm enthaltenen Objekte einen Teilbaum des DIT. Die Suche nach Objekten und die

Definition von administrativen Verantwortungsbereichen erfolgt auf der Basis solcher

Teilbäume. So wird zum Beispiel im Verzeichnis einer Firmenhierarchie ein Eintrag für eine

,,Abteilung“ anderen Einträgen wie ,,Unterabteilung“ und ,,Unterunterabteilung“

übergeordnet werden.

2.9 Aliase

Genaugenommen ist der DIT nicht immer ein echter Baum, bei dem es nur Verbindungen von

einer untergeordneten Ebene auf eine höhere Ebene gibt, denn LDAP erlaubt auch so

genannte Aliase. Ein Aliaseintrag ist ein Eintrag in einem DIT, der nur auf einen anderen

Eintrag im DIT verweist, ähnlich wie ein Alias oder Softlink in einem Dateisystem nur auf ein

anderes Objekt verweist.

Abbildung 3 - Alias

Beliebige Aliase sind in LDAP nicht möglich, denn es müssen die so genannten Deadlocks

vermieden werden, bei denen ein Alias (möglicherweise über eine Reihe von weiteren

Aliasen) wieder im Kreis auf sich selbst verweist.

Abbildung 4 - Deadlock

16

Alias

Alias

2.10 Referenzierung durch Namen

Will man mit einem Eintrag im Verzeichnisbaum sinnvolle Dinge anstellen,

dann braucht man eine Möglichkeit, um den Eintrag eindeutig zu referenzieren. Der

Mechanismus zum Referenzieren von Einträgen basiert; ähnlich wie das Referenzieren von

Dateien in Dateisystemen auf einem System von absoluten und relativen Namen. Es wird in

der ITU-Empfehlung X.501 beschrieben.

Da der Name eines Eintrages im X.500-Modell dazu eingesetzt wird, um ihn von anderen

Einträgen zu unterscheiden, spricht man im X.500-Kontext von Distinguished Names. Der

häufig gebrauchte Begriff Distinguished Name wird meist mit DN abgekürzt.

2.10.1 Relative Distinguished Name

Die Distinguished Names setzen aus kleineren Bausteinen zusammen, den sogenannten

Relative Distinguished Names. Der häufig gebrauchte Ausdruck Relative Distinguished Name

wird in der Praxis meist mit RDN abgekürzt. Der RDN wird benutzt, um Einträge unterhalb

desselben übergeordneten Eintrages im Verzeichnisbaum eindeutig voneinander zu

unterscheiden. Einträge an anderen Stellen im DIT können durchaus denselben RDN

verwenden. Ein RDN besteht aus einem oder mehreren Attributen und ihren Werten. Diese

können im Prinzip beliebig gewählt sein, solange sichergestellt ist, dass sie hinreichen, um

einen Eintrag auf seiner Hierarchieebene eindeutig zu bestimmen. Häufig besitzen die

Objekte, die durch einen Eintrag modelliert werden sollen, auch in der realen Welt so etwas

wie einen Namen. Die meisten Europäer haben eine Kombination aus Vor- und Nachnamen,

den man zur Unterscheidung heranziehen kann. Dafür steht das standardisierte Attribut CN

zur Verfügung. Das Kürzel CN steht dabei für Common Name. Im Beispiel unserer Firma aus

Abbildung 1 bietet es sich an, das CN-Attribut mit dem Wert Michael Monty Widenius als

RDN für die Person und das CN-Attribut mit dem Wert MyNotebook für das Device

(Computer) zu verwenden. Es gibt allerdings auch andere Möglichkeiten.

Für Personen in überschaubaren Hierarchien, in denen es nicht vorkommt, dass zwei Personen

denselben Namen haben, ist der CN üblicherweise die adäquate Wahl für den RDN. Anders

sieht es aus, wenn Einträge andere Objekte, zum Beispiel Anlagen und Geräte, beschreiben.

Für Inventarstücke von geringerem ideellen Wert bietet sich stattdessen die Verwendung einer

Seriennummer als RDN an. Diese hat zudem den Vorteil, eindeutig zu sein.

Ähnlich liegen die Dinge bei der Firma MySQL AB, die durch ein Objekt der Klasse

17

Organization repräsentiert wird. Hier steht überhaupt kein CN-Attribut zur Verfügung,

stattdessen sollte hier das Attribut O (Organization) für den RDN verwendet werden.

2.10.2 Zusammengesetzter RDN

Leider reicht es nicht immer aus, ein einziges Attribut als RDN zu verwenden. In einer

Minifirma mag es vorkommen, dass in einer Organisationseinheit die Kombination von Vor-

und Nachnamen ausreicht, um eine Person eindeutig zu referenzieren. In den

Telefonverzeichnissen größerer Städte wird man aber bestimmte Namen (z.B. Klaus Müller)

mehr als einmal vorfinden. Dann stellt sich die Frage, wie man in solchen Fällen einen RDN

sinnvoll bestimmt.

Abbildung 5

Nehmen wir z.B. an, dass die Daten von Telefonkunden weltweit in einem Verzeichnis

verwaltet werden, wie es Abbildung 5 darstellt:

Unterhalb von top befinden sich Einträge für die Länder, darunter die Orte, repräsentiert

durch ein Objekt der Klasse Location. Ein Location-Objekt besitzt ein einfaches Attribut l

(Location), das wir als RDN verwenden können, was z.B. für Merseburg in Sachsen-Anhalt

wie folgt notiert wird:

{ l=Merseburg, Sachsen-Anhalt }

Unterhalb des Ortes werden die einzelnen Teilnehmer als Objekte der Klasse

residentialPerson verwaltet. Ist der Ort nicht allzu groß, dann kann man das Glück haben,

dass keine zwei Kunden mit dem gleichen Vor- und Nachnamen existieren. In diesem Fall

reicht es aus, das einfache Attribut CN als RDN zu verwenden.

Der RDN besteht dann einfach aus dem Wertepaar CN=<Name>, also z.B.:

18

TOP

C=DEC=US C=AT C=IT

C=DE

L=LeipzigL=Halle L=Merseburg

CN=Klaus Müller+STREET=Hallesche Str. 2

{ CN=Klaus Müller }

Wie erwähnt funktioniert dies natürlich nur dann, wenn die Namenskombinationen aller

Teilnehmer voneinander verschieden sind. Da dies in der Regel nicht der Fall ist, muss man

stattdessen den RDN aus einem Satz von mehreren Attributen bilden. In unserem Beispiel

verwenden wir das Attribut STREET als weiteres Unterscheidungskriterium. Solche

mehrfachen Attribute werden im RDN durch ein Pluszeichen »+« getrennt, so dass der RDN

wie folgt notiert wird:

{ CN=Klaus Müller+STREET=Hallesche Str. 2 }

2.10.3 Überführung RDN zu DN

Der Schritt vom RDN, mit dem ein Eintrag auf seiner eigenen Hierarchiestufe eindeutig

referenziert werden kann, zum DN, der einen Eintrag im gesamten Verzeichnisbaum

eindeutig referenziert, wird in einer relativ offensichtlichen Art und Weise vollzogen: Dazu

hängt man, ausgehend von der Wurzel des Verzeichnisbaumes, die RDNs aller

übergeordneten Einträge bis hinunter zum Eintrag, für den der DN bestimmt werden soll, in

einer kommaseparierten Liste aneinander und fügt dann noch den RDN des Eintrages dazu.

Der DN besteht also einfach aus einer kommaseparierten Liste der RDN, die in absteigender

Folge aufgelistet werden. Für die Person aus unserem Beispiel ergibt sich der DN:

{ C=DE, l=Merseburg, Sachsen-Anhalt, CN=Klaus Müller+STREET= Hallesche Str. 2 }

Der DN für den Ort sieht so aus:

{ C=DE, l=Merseburg, Sachsen-Anhalt }

Der DN des Landes ergibt sich zu:

{ C=DE }

Und nicht zu vergessen das Root-Element, das einen ziemlich trivialen

DN hat:

{ }

Einige Sonderzeichen die im Wesentlichen das Komma, das im DN die

Aufgabe hat, einzelne RDN-Komponenten voneinander zu trennen werden, wenn sie wie in

19

unserem Beispiel Merseburg, Sachsen-Anhalt als Bestandteil eines RDN-Wertes vorkommen,

durch einen Backslash maskiert. Auch der Backslash muss, wenn er nicht als Escape-Symbol

eingesetzt wird, ebenfalls durch einen weiteren Backslash maskiert sein. RFC 2253

beschäftigt sich ausführlich mit der Namenssyntax im LDAP.

3 Die LDAP Sitzung

Das LDAP ist ein Sitzungsbasiertes Protokoll. Das heißt, ähnlich wie bei FTP, SMTP und

POP muss zuerst eine Sitzung initialisiert werden, bevor Daten ausgetauscht werden können.

Der Ablauf einer regulären LDAP-Sitzung umfasst drei Phasen:

1. In einem ersten Schritt meldet sich der LDAP-Client beim LDAP-Server an. Neben

der Initialisierung werden auch Informationen darüber ausgetauscht, welche

(erweiterten) LDAP-Features der Client unterstützt und gegebenenfalls erfolgt auch

eine Authentifizierung und das Aushandeln der Verschlüsselung. Dieser Schritt wird

als Binding genannt.

2. Nach dem erfolgreichen Binding tauschen Client und Server sogenannte Nachrichten

(Messages) miteinander aus.

3. In einem letzten Schritt beendet der Client die Sitzung. Dieser Schritt wird unbinding

begannt.

3.1 Messages und Operationen

Die eigentliche LDAP-Sitzung besteht im wechselweisen Austausch von Nachrichten, den so

genannten Messages. So initiiert der Client bestimmte Operationen (requests), der Server

antwortet mit einer oder mehreren Antworten (responses).

Das LDAP spezifiziert die folgenden, in Tabelle 1 aufgelisteten Operationen.

Message Bedeutungbind Initialisierung einer Sitzung, bei der der Client die Protokollversion

spezifiziert und die Credentials für die Authentifizierung.unbind Beenden einer Sitzung.search Suche im Verzeichnis.modify Verändern (add, delete, replace)der Attribute eines Eintrags.add Hinzufügen eines neuen Eintrags. Client spezifiziert den Namen und

20

eine Liste der Attribute.delete Löscht einen Eintrag.modify RDN Ändern den RDN eines Eintrags bzw. ganzer Teilbäume.compare Testet, ob ein Eintrag ein bestimmtes Attribut-/Wertepaar hat.abandon Teilt dem Server mit, das der Client das Ergebnis einer bestimmten

Anfrage nicht mehr braucht.Tabelle 1 - DAP Messages

Im klassischen Anwendungsfall einer Middleware für X.500-DSPs hat der LDAP-Server

keinen lokalen Zugriff auf den vom Client nachgefragten oder manipulierten Datenbestand.

Stattdessen sind die Daten auf einer Reihe von verstreuten X.500-Servern verteilt. Der LDAP-

Server muss seinerseits die Anfrage oder Manipulation auf diesen Servern veranlassen und

alle Rückmeldungen abwarten, bevor eine Antwort an den Client gesendet werden kann. Es

muss also prinzipiell damit gerechnet werden, dass die Latenzzeit zwischen der Anfrage und

dem Eintreffen aller Antworten recht lang werden kann. Um diese ansonsten nutzlose

Latenzzeit auszufüllen, ermöglicht LDAP eine asynchrone Kommunikation zwischen Client

und Server. Der Client darf nach dem Abschicken einer ersten Anforderung schon weitere

Anforderungen abschicken, noch bevor die Antworten auf die erste Anforderung eingegangen

sind. Wenn die Antworten auf eine frühere Anforderung eintreffen, können sie dann wieder

der richtigen Anfrage zugeordnet werden, weil die Anfragen eine eindeutige Identifikation

MessageID bekommen., die von der Antwort referenziert wird. Ähnlich wie bei anderen

nachrichtenorientierten Protokollen nennt man den Teil einer Message, der administrative

Informationen wie die MessageID enthält, den Envelope (Briefumschlag).

Das Protokoll LDAP war von vornherein auf Erweiterbarkeit ausgelegt. Da in der LDAP-

Welt alles ein Objekt ist, werden auch Protokollerweiterungen (bzw. deren Beschreibung) als

Objekte behandelt. Objekte, die besondere Fähigkeiten von Client und/oder Server

beschreiben, nennt man Controls. Je nachdem, ob Fähigkeiten von Client oder Server

beschrieben werden, spricht man auch von clientcontrols oder servercontrols. Um die vom

Client bzw. Server unterstützten Fähigkeiten zu beschreiben, gibt es in den Message-

Envelopes besondere Felder, die eine Liste der Objekt-Identifier der unterstützten Controls

enthalten.

Es gib schon eine ganze Reihe von RFCs, die sich mit Controls zur Erweiterung des LDAP-

Core-Standards beschäftigen, beispielsweise:

• RFC 2649 definiert ein Control signedOperationControl, das es erlaubt, LDAP-

21

Operationen kryptographisch zu signieren,

• RFC 2696 definiert ein Control pagedResultsControl, mit dem sich ein Client

Auszüge aus einer Menge von Anfragen anzeigen lassen kann,

• RFC 2891 definiert Controls, die ein serverseitiges Sortierender Anfrageergebnisse

beeinflussen.

Bei der Kommunikation mit LDAP kommt natürlich die ASN.1 (Abstract Syntax Notation

Number 1) zu Einsatz. Die Bedeutung von ASN.1 für das LDAP liegt darin, dass ASN.1 zur

Beschreibung der X.500 Datentypen verwendet wird. Für das LDAP sind vor allem die Basic

Encoding Rules (BER) wichtig.

4 Die Verteilung des Verzeichnisses

Das Wort Partitionierung bezeichnet im X.500 Sprachgebrauch die Verteilung eines

Verzeichnisses auf mehrere Server. Dies dient der Vereinfachung der Administration und

verbessert die Lastverteilung. Partitionierung ist ein wesentliches Merkmal (und Pluspunkt)

von Verzeichnisdiensten. Mit dem Directory Server Protocol DSP stellt X.500 schon auf der

Protokollebene Unterstützung für die Partitionierung von Verzeichnissen bereit. Ein X.500-

kompatibler Directory System Provider, der von einem Client nach Objekten gefragt wird, die

sich auf einem anderen Server befinden, wird diese Daten mittels des DSP-Protokolls von den

entsprechenden anderen Servern einsammeln und an den Client schicken. Der Client merkt

bei dieser Vorgehensweise nichts von der verteilten Verzeichnisstruktur, das Verzeichnis ist

eine Blackbox, auf die er über einen einzigen Server (bzw. DSP) zugreifen kann. Im

klassischen Anwendungsfall einer Middleware zwischen TCP/IP-Netzwerk und X.500-

Verzeichnis ist also die Partitionierung von Verzeichnissen kein Thema für LDAP, das

lediglich die Client-Server-Kommunikation beschreibt und nicht die Kommunikation der

Server untereinander.

4.1 Naming Context

Ein Eintrag im DIT wird von genau einem Server aus administriert, dieser wird als

Administrative Authority, im X.500-Jargon auch als Master-DSA oder einfach Master

bezeichnet. Ein Naming Context ist ein maximaler Teilbaum des DIT, dessen Einträge alle

denselben Master haben. Maximaler Teilbaum heißt hier, dass der Naming Context bei einem

einzigen Eintrag startet und sich über alle im DIT unterhalb von diesem Eintrag gelegenen

22

Einträge erstreckt, die noch von demselben Master administriert werden. Der von einem

Master administrierte Ausschnitt aus dem DIT kann aus einem oder mehreren Naming

Contexts bestehen.

Der ganze DIT besteht also aus einer Menge von disjunkten Naming Contexts, wobei es

durchaus möglich ist, dass mehrere davon von demselben Master administriert werden.

Jeder Naming Context hat einen initialen Eintrag. Den Dinstinguished Name des des initialen

Eintrags, der damit auch Bestandteil des DN aller anderen Einträge in diesem Naming

Context ist, nennt man auch das Prefix oder Context Prefix dieses Naming Context.

4.2 Referrals und Continuations

Mit dem Paradigmenwechsel vom X.500-Frontend hin zum ,,Standalone-LDAP-Server“

ergeben sich aber auch Probleme: Die oben beschriebene elegante Vorgehensweise ist für

einen LDAP-Server nicht mehr möglich, wenn andere Backends als X.500-DSPs verwendet

werden, es fehlt dann schlicht an einem LDAP-Kommunikationsprotokoll für die Server. Die

Verwendung von DSP ist mangels OSI-Stack nicht möglich, und eine TCP/IP-basierte

Lösung würde faktisch zu einem neuen Protokoll führen.

Um diesen Problemen aus dem Weg zu gehen, wird die Navigation in verteilten

Verzeichnissen seit LDAPv3 auf die Clients abgewälzt. Der Server kann dem Client in

diesem Fall mit einem Referral antworten. Ein solches Referral ist ein Verweis auf einen Ort

an andere Server, der das nachgefragte Objekt bereitstellt.

Ähnlich wie bei Referrals funktionieren Continuations. Continuations sind Verweise auf

andere Server, die bei Suchoperationen auftreten. Sie geben einen Ort an, an dem die bereits

begonnene Suche fortgesetzt werden kann.

Für die Partitionierung von Verzeichnissen sind zwei Typen von Referrals wichtig:

• Subordinate Referrals: Ein solcher Verweis auf einen LDAP-Server, der einen

Teilbaum des DIT verwaltet, welcher unterhalb des vom verweisenden Server

verwalteten Teilbaums angesiedelt ist. Diese Verweise stellen gewissermaßen den

Leim bereit, der partitionierte Verzeichnisse zusammenhält.

• Superior Referrals: Ein solches Referral wird generiert, wenn der Server keine

Information über den zu durchsuchenden Namensraum hat, und verweist in der Regel

auf einen Server, der im DIT höher angesiedelt ist.

5 Sicherheit

23

Egal welcher Datenbasis ein LDAP-Server als Middleware vorgeschaltet ist, als Verbindung

zwischen Datenbasis und Außenwelt bildet er das Einfallstor für entfernte Angriffe gegen die

Datensicherheit. Diese kann im Wesentlichen auf zweierlei Arten beeinträchtigt werden:

• durch unautorisiertes Verändern von Daten,

• durch unautorisiertes (Mit-)Lesen von Daten, was im besonders schlimmen Fall das

unautorisierte Mitlesen von wiederverwendbaren Authentifizierungsdaten sein kann.

Autorisierung und Authentifizierung sind die zwei zentralen Begriffe beim Thema Sicherheit:

• Authentifizierung: Eine Authentifizierung befasst sich mit dem Problem, die Identität

eines Objekts zu überprüfen. Dies kann zum Beispiel geschehen, indem Passwörter

oder Schlüssel überprüft werden.

• Autorisierung: Die Autorisierung ist die Gewährung von Rechten. Dabei wird i.d.R.

Davon ausgegangen, dass das Objekt, dem Rechte gewährt werden, bereits eine

erfolgreiche Authentifizierung hinter sich gebracht hat.

Nehmen wir beispielsweise die Zugangskontrolle und Rechteverwaltung bei einem Multiuser-

Betriebssystem. Die Überprüfung der Identität des Benutzers beim Login ist eine

Authentifizierung. Die Frage, welche Rechte dem Benutzer beim Zugriff auf Dateien und

Prozessen zustehen, ist ein Problem der Autorisierung.

5.1 Zugriffskontrolle im LDAP

Ein einheitliches Konzept für die Zugriffskontrolle war im LDAP zunächst nicht spezifiziert.

Daran erkennt man die Tatsache, dass das LDAP nur ein Zugriffsprotokoll ist. Der Server

führt vom Client angeforderte Aktionen aus oder nicht, und er muss den Client informieren,

wenn eine Aktion wegen mangelnder Privilegien nicht ausgeführt werden wird. Die Frage,

wie ein Server Zugriffsprotokolle und Privilegienverwaltung implementiert, liegt eigentlich

schon ausserhalb der Reichweite des LDAP.

Obwohl es lange keinen offiziellen Standard gab, der sich mit der serverseitigen Organisation

der Zugriffsprotokolle befasst, verfügen natürlich alle wesentlichen LDAP-Implementationen

über eine solche. Bei den meisten Implementationen orientiert sich deren Design an der

Zugriffskontrolle des UMich-LDAP.

24

Unter dem Dach der IETF gibt es in letzter Zeit allerdings Bestrebungen, Zugriffsprotokolle

und Autorisierung zu vereinheitlichen: RFC 2820 beschreibt Anforderungen an ein

zukünftiges, auf Access Control Lists basierendes Modell der Zugriffskontrolle, draft-ietf-

ldapext-acl-model – Access Control Model for LDAP beschreibt ein Privilegiensystem.

Beides scheint aber noch weit von einer Umsetzung entfernt zu sein.

5.2 Authentifizierung

Auch wenn sich das LDAP nicht mit der Frage befasst, wie die Zugriffskontrolle realisiert

wird, geht es dennoch davon aus, dass eine Zugriffskontrolle stattfindet und dass deswegen

eine Authentifizierung des Clients beim Server notwendig ist. Seit den früheren LDAP-

Versionen gib es dafür ein einfaches Verfahren, beim dem eine BenutzterID und ein Passwort

im Klartext übermittelt werden. Dieses veraltete Verfahren wird heute oft als simple

authentificaton bezeichnet.

Einen Bind, der mit dieser Art von Authentifizierung durchgeführt wird, bezeichnet man als

simple bind. Der simple bind ist allerdings beim anonymen bind, mit dem man sich öffentlich

zugängliche Daten besorgt, nach wie vor Methode der Wahl.

Eine einfache Methode, Authentifizierungsdaten zu verwalten, ist es, diese in einem

Verzeichnis abzulegen und den DN des Objekts, das die Authentifizierungsdaten enthält, als

Benutzeridentifikation zu verwenden. In einem solchen Szenario redet man davon, dass ein

Benutzer sich als ein bestimmtes Objekt an das Verzeichnis bindet. Man findet die

Sprechweise zum Beispiel in den Manual Pages der LDAP-Utilities wieder, wo von der

BenutzerID als einem ,,bindDN“ die Rede ist. Die simple authentification kann in öffentlichen

Netzen längst nicht mehr als sicher angesehen werden, da Benutzername und Passwort im

Klartext über das Netz geschickt werden und mit geeigneten Sniffern wie ngrep oder ethereal

abgefangen werden können. Da die Datenübertragung während der laufenden Sitzung bei

LDAPv2 sowieso unverschlüsselt erfolgt, lassen sich mit derartigen Werkzeugen auch die

während einer Sitzung übertragende Daten abfangen.

25

Abbildung 6 - unverschlüsselte LDAP Sitzung

Moderne Gegenmaßnahmen gegen solche Angriffe beinhalten eine möglichst starke

Authentifizierung zu Beginn einer Sitzung, sowie eine Verschlüsselung der Datenströme

während einer Sitzung.

In den LDAPv3-Core-Specs war noch kein Subprotokoll für Authentifizierung und/oder

Verschlüsselung definiert. Stattdessen enthalten alle Core-Specs nur einen Hinweis auf das

vorläufige Fehlen derartiger Mechanismen.

Das erste RFC ließ aufgrund der Dringlichkeit zur Lösung dieses Problems lange auf sich

warten. Erst im Mai 2000 wurden zwei RFCs zu Verschlüsselsmechanismen für LDAP

veröffentlicht. Es wird aber kein eigener Mechanismus für Authentifizierung und

Verschlüsselung entwickelt. Verschlüsselung und Authentifizierung für LDAP werden

dedizierten Protokollen, den Protokollen SASL und der Kombination SSL/TLS überlassen.

26

RFC 2229 nennt u.a. vier Sicherheitsmechanismen, die in LDAP integriert sein sollen:

1. Client-Authentifizierung mittels SASL, optional zusätzlich durch SSL/TLS-

Mechanismen,

2. Server-Authentifizierung durch das TLS-Protokoll, optional zusätzlich durch SASL-

Mechanismen,

3. Schutz der Datenintegrität durch Integration von TLS- und/oder SASL-Mechanismen,

4. Schutz der Daten vor unautorisierten Mitlesen (snooping) durch Verschlüsselung mit

TLS- und/oder SASL-Mechanismen.

Zum Auslagern der Sicherheitsfunktionalität unterstützt LDAP das Simple Authentification

and Security Layer (SASL). SASL stellt entweder eigene Funktionen für Verschlüsselung

oder Authentifizierung zur Verfügung, oder die SASL-Implementierung wählt bei einer

Verbindungsanfrage aus einer Reihe von Authentifizierungsmechanismen einem vom Client

unterstützten externen Mechanismus (z.B. TLS) aus und führt damit die Authentifizierung

durch. Nach einer erfolgreichen Authentifizierung ist es mit SASL auch möglich, eine

Verschlüsselungsmethode auszuwählen, mit der die Sitzung verschlüsselt wird (z.B. IPSec

oder SSL/TLS). Die Auswahl des Protokolls erfolgt anhand eines Schlüsselwortes, das der

Client sendet. Die IANA (Internet Assigned Numbers Authority) pflegt eine Liste von

unterstützten Protokollen und der zugehörigen Keywords.

Wichtig im Zusammenhang mit LDAP/OpenLDAP sind insbesondere die folgenden

Mechanismen:

• KERBEROS_V4: Kerberos Version 4. Noch gelegentlich anzutreffende ältere

Version des Kerberos-Protokolls,

• GSSAPI: SASL-Mechanismus, mit dem Authentifizierungsmechanismen gestartet

werden, die auf GSSAPI nach RFC 2078 basieren,

• EXTERNAL: Externe Authentifizierung. Delegiert die Authentifizierung an eine

externe Anwendung. Wird bei der Benutzung von TLS oder IPSec gebraucht.

5.3 Der Strong Bind

Die SASL-Unterstützung machte es mit LDAPv3 notwendig, den Bind-Request zu ergänzen.

Wird eine stärkere Authentifizierung benötigt, dann steht seit LDAPv3 der sogenannte strong

bind zur Verfügung. Beim strong bind muss der Client angeben, welche

27

Authentifizierungsmethode er sich wünscht, und außerdem müssen die Credentials, d.h. die

an die jeweilige Authentifizierungsmethode angepassten Authentifizierungsdaten übergeben

werden.

6 Schema – Klassen unter LDAP

Ein Verzeichnisdienst besteht aus Daten und Metadaten. Unter Metadaten versteht man

konkret Informationen über die Struktur des Verzeichnisdienstes , zum Beispiel:

• Definition der verwendeten Attributtypen,

• Definition der verwendeten Objektklassen,

• Filter/Matching-Regeln bei Vergleichsoperationen,

• Rechte zum Anlegen oder Modifizieren von Datensätzen.

Die Information über die verwendeten Attributtypen und Objektklassen wird in einem

sogenannten Schema verwaltet. Ein eigenes Verzeichnis zu entwerfen bedeutet im

Wesentlichen, ein Schema zu entwerfen bzw. ein vordefiniertes Schema ganz oder teilweise

zu übernehmen.

X.501 beschäftigt sich mit Schemata für X.500-basierte Verzeichnisdienste. OpenLDAP

verwaltet die Schemata für den Server in Textdateien in einem eigenen Verzeichnis. Die

OpenLDAP-Distribution bringt standardmäßig eine Reihe von vordefinierten x.schema-

Dateien mit.

Schemaübersicht:

• corba.schema: Enthält Datendefinitionen aus RFC 2714 für Common Object Request

Broker Architekture (CORBA), einen offenen Standard zum Austausch von Objekten

zwischen verschiedenen Anwendungen.

• core.schema: Eine umfangreiche Sammlung von für den Betrieb des LDAP-Servers

wichtigen Schemata

• cosine.schema: Der RFC 1274 Cosine and Internet X.500 Schema definiert eine

gigantische Menge von Attributen und Klassen, die ursprünglich für einen

internetweiten Suchdienst gedacht waren. Einiges aus cosine.schema wird z.B. für

nis.schema und openldap.schema gebraucht.

28

• inetorgperson.schema: Die Klasse internetOrgPerson.

• java.schema: Die objektorientierte Programmiersprache Java definiert verschiedene

Methoden zur Speicherung von serialisierten Java-Objekten, zum netzweiten

Ansprechen von Objekten (RMI) sowie eine objektorientierte Schnittstelle zu

allgemeinen Verzeichnisdiensten(JNDI).

• misc.schema: Verschiedenes...

• nis.schema: Schemadaten für das Netzwerkinformationssystem auf Basis von LDAP

• openldap.schema: Intern von OpenLDAP verwendete Schemadaten.

6.1 Allgemeiner Aufbau eines Schemas

Schemata sind eigentlich recht einfach aufgebaut: Neben Kommentarzeilen, die im UNIX-Stil

mit einem Gatter (#) eingeleitet werden, listet ein Schema Definitionen für Attributtypen

und/oder Objektklassen auf. Die Definition für Objektklassen und Attributtypen werden durch

das Schlüsselwort Objectclass bzw. Attributeclass eingeleitet. Hinter diesen Schlüsselwörtern

folgt ein in runden Klammern eingefasster Bereich, der die weiteren Spezifikationen enthält.

6.2 Eigene Schemata entwerfen

Wenn es irgendwie möglich ist, sollte man aus Gründen der Wiederverwendbarkeit in eigenen

Verzeichnissen standardisierte Objekte verwenden. Es sollte einem Entwickler einigen

Aufwand wert sein, zu recherchieren ob es nicht doch möglich ist standardisierte Klassen zu

verwenden.

Eigene Schema-Elemente werde in eigenen Schemadokumenten definiert und durch den

Server eingebunden. Die Syntax der Schemadokumente/Schemadateien ist standardisiert, die

Verfahrensweise bei der Einbindung durch den Server nicht. Unter OpenLDAP geschieht das

durch entsprechende Direktiven in der Konfigurationsdatei slapd.conf.

Der Entwurf eines eigenen Schemas beinhaltet folgende Schritte:

• Auswahl eines so genannten Name-Prefix, d.h. einer Zeichenkette, mit der die Namen

aller Objekte im Schema beginnen,

• Zuweisung von ObjectIdentifiers (OIDs) für das Schema,

• Definition eigener AttributeTypes,

• Definition eigener ObjectClasses.

29

6.3 Referenzierung von Objekten durch Name oder OID

Ein in einem Schema definiertes Objekt kann auf zwei Arten referenziert werden:

1. Durch einen menschenlesbaren Namen, der im Prinzip nach Belieben vergeben

werden kann,

2. Durch einen Object Identifier, der Bestandteil einer weltweiten hierarchischen

Adressierungssystems ist.

Im folgenden Beispiel aus dem calendar.schema wird ein AttributeType definiert, dem OID

und Name zugewiesen werden:

attributetype (1.3.6.1.4.1.14658.2.2.12

NAME 'calCAPURI'

:

:

Der OID ist die punktseparierte Dezimalzahlfolge 1.3.6.1.4.1.14658.2.2.12 , der Name ist die

weitgehend frei gewählte Zeichenfolge 'calCAPURI'. Während der OID als Bestandteil eines

hierarchischen Identifizierungssystems eindeutig ist, kann es beim Namen zu Konflikten

kommen, die in anderen Schemata definiert sind. Ein solcher Namenskonflikt ist umso

wahrscheinlicher, je allgemeiner der Name für ein Objekt ist.

Eine empfehlenswerte Maßnahme, die Namensraumkonflikte zwar nicht sicher verhindert,

jedoch unwahrscheinlich macht, ist die Verwendung des so genannten Name-Prefix.

Ein Name-Prefix ist nichts weiter als eine Zeichenkette, mit der alle Namen eines Schemas

beginnen. Neben der Möglichkeit, aussagekräftige deskriptive Name-Prefixes zu verwenden,

hat sich als Alternative die Verwendung von Zonennamen aus dem Domain Name System

etabliert. Dabei wird den Namen der umgekehrte Zonenname der Institution vorangestellt, die

für das Schema verantwortlich ist. So ergibt sich beispielsweise das Prefix deMerseburg für

die Institution mit dem Domainnamen ,,Merseburg.de“. Die Verwendung von Zonennamen

als Domain-Prefixes erlaubt eine gute Absicherung gegen Namensraumkonflikte und

ermöglicht es dem Nutzer des Schemas, in einfacher Weise herauszufinden, wer dieses

Schema definiert hat und wo im Internet er nach Informationen über dieses Schema suchen

sollte.

30

6.4 Der Object Identifyer (OID)

Object Identifiers sind weltweit eindeutige Bezeichner für Objekte. OIDs sind in ein

hierarchisches bzw. baumartiges Namensschema eingebunden, das dem Domain Name

System ähnelt. Ähnlich wie beim DNS werden die obersten Hierarchieebenen der OIDs

zentral verwaltet und die Verwaltung von Teilbäumen sukzessive an verschiedene

Organisationen delegiert.

Während einige Teilbäume dieses Systems besonderen Aufgaben zugewiesen sind, können

Organisationen der IANA oder einigen anderen registrierten Organisationen die Zuweisung

bestimmter Teilbäume zur internen Verwendung beantragen.

Die Verwendung von OIDs ist nicht auf Verzeichnisdienste beschränkt, sondern generell in

ASN.1-basierten Protokollen verbreitet (z.B. SNMP).

6.5 AttributeTypes

Obwohl ein Attribut immer Bestandteil einer Objektklasse ist, werden die Attribute in einem

Schema unabhängig von den Objektklassen beschrieben. Auf diese Weise kann man einen

Attributtyp in vielen Objektklassen verwenden. Es macht zum Beispiel Sinn, den Attributtyp

Telefonnummer sowohl für Personen als auch für Organisationeinheiten wie Buchhaltung

oder Lager zu verwenden.

Da Objekte aus Attributen zusammengesetzt sind, enthält ein Schema zuerst die Definitionen

eventueller neuer Attributtypen und erst dann die Definitionen für neue Objektklassen, die auf

diesen Attributtypen aufbauen.

Ziel der Standardisierung von Verzeichnisdiensten mit Standards wie LDAP ist die

Interoperabilität. Es soll möglich sein, dass ein System, das beim Entwurf eines

Verzeichnisdienstes noch nicht bekannt war, diesen Verzeichnisdienst nutzen kann. Um dies

sicherzustellen, ist aber mehr nötig als nur die Möglichkeit, Daten auszutauschen. Es ist auch

wünschenswert, dass die Datensätze selber soweit standardisiert sind , dass sie von Client und

Server in derselben Art und Weise interpretiert werden.

Eine typische Attribute Type Definition liefert das standardisierte Attribut TelephoneNumber,

das in vielen Standard-Objektklassen gebraucht wird. Es wird im OpenLDAP core.schema

folgendermaßen beschrieben:

attributetype (2.5.4.20 NAME 'telephoneNumber'

DESC 'RFC 2256: Telephone Number'

31

EQUALITY telephoneNumberMatch

SUBSTR telephoneNumberSubstringsMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32})

Die einzelnen Elemente dieser Attribute Type Specification sind die OID, eine Beschreibung

des Attribute Type, die Definition der Matching-Rules für die Gleichheit und die Gleichheit

von Teilzeichenketten sowie die OID der verwendeten Syntax.

NAME: Der menschenlesbare Name zur Referenzierung des Objektes

DESC: Das Kürzel DESC steht für Description. Es handelt sich um eine menschenlesbare

Beschreibung.

EQUALITY: Die Matching-Rule für Gleichheit.

SUBSTR: Die Matching-Rule für die Gleichheit von Teilzeichenketten

SYNTAX: OID der verwendeten Syntax. Es handelt sich hier um die OID für Telephone

Number.

Neben den hier aufgelisteten Elementen für die Definition des telephoneNumber Attributs

kann eine Attribute Type Definition noch viele weitere Elemente enthalten.

6.6 ObjectClasses

Verglichen mit den Definitionen für Attributtypen sind die Definitionen für Objektklassen

recht einfach aufgebaut. Die Schema Datei inetorgperson.schema kommt für die Klasse

inetOrgPerson mit folgender Definition aus:

objectclass (2.16.840.1.113730.3.2.2

NAME 'inetOrgPerson'

DESC 'RFC 2798: Internet Organizational Person'

SUP organizationalPerson

STRUCTURAL

MAY (

audio $ businessCategory $ carLicense $ departmentNumber $

displayName $ employeeNumber $ employeeType $ givenName $

homePhone $ homePostalAddress $ initials $ jpegPhoto $

labeledURI $ mail $ manager $ mobile $ o $ pager $

32

photo $ roomNumber $ secretary $ uid $ userCertificate $

x500uniqueIdentifier $ preferredLanguage $

userSMIMECertificate $ userPKCS12)

)

Die meisten Elemente dieser ObjectClass Definition sind uns bereits von der Attribute Type

Definition her geläufig. Im Einzelnen besteht diese ObjectClass Definition aus folgenden

Elementen:

OID (2.16.840.1.113730.3.2.2 )

NAME inetOrgPerson

DESC Description, analog zur AttributeType Definition

SUP Verweis auf die Superklasse (hier: organizationalPerson)

STRUCTURAL Zeigt an, dass es sich um eine structural class handelt. Alternativ können die

Klasse durch die Schlüsselwörter ABSTRACT bzw. AUXILIARY als abstract class oder

auxiliary class deklariert sein.

MAY enthält eine durch Dollarzeichen ($) getrennte Liste von Attributen. Das Schlüsselwort

MAY zeigt an, dass es sich um optionale Attribute handelt. Hat die Objektklasse auch noch

obligatorische Attribute, dann werden diese in analoger Weise hinter dem Schlüsselwort

MUST aufgeführt.

7 Das LDIF

LDIF ist das LDAP Data Interchange Format, ein Format zum Austausch von Daten

zwischen LDAP-Implementationen. LDIF wurde ursprünglich für den UMich-lapd

entwickelt, wird aber inzwischen von allen wesentlichen LDAP-Implementationen

unterstützt. Ursprünglich war das LDIF nur zur Repräsentation von statischen

Verzeichnisdaten gedacht, später wurde es auch zur Beschreibung von LDAP-Operationen

erweitert. Eine LDIF-Datei besteht aus den folgenden Elementen:

• der Versionsnummer,

• einer Anweisung, wie der nachfolgende Datensatz zu behandeln ist, sowie

• einem oder mehreren Datensätzen

33

7.1 Die Anweisungen

Die Anweisungen beschreiben, welche LDAP-Operationen ausgeführt werden sollen.

Anweisungen können einen gesamten Datensatz betreffen oder aber auch nur einzelne

Elemente eines Datensatzes. In beiden Fällen sind die Anweisungen identisch. Es gibt

insgesamt fünf Anweisungen:

• add

• delete

• modify

• modrdn

• moddn

Wird eine Anweisung zu Beginn einer Datei ohne weitere Attribute angegeben, so betrifft

diese Anweisung die gesamte Datei. Steht z.B. zu Beginn einer Datei add ohne weitere

Attribute wie z.B. ,,:“, so werden die in dieser Datei enthaltenden Datensätze dem gesamten

Datenbestand hinzugefügt. Sollen nur Bestandteile eines bestehenden Datensatzes verändert

werden, so ist nach dem Distinguished Name das Attribut changetype: zu setzen. Einige

Beispiele sollen dies verdeutlichen:

{

dn: cn=Stefan Drzazga,ou=Student,o=fhMerseburg,c=de

changetype: modify

delete: userPassword

dn: cn=Stefan Drzazga,ou=Student,o=fhMerseburg,c=de

changetype: modify

add: userPassword

userPassword:\{SSHA\}iQx5hd86sgQkk75789gH6s8\}

7.2 Versionsnummer

Die Versionsnummer wird durch das Attribut Aversion: und dem Wert 1 beschrieben. Zur

Zeit ist nur die Version 1 gültig. Sofern die Version des LDIF nicht angegeben wird, kann

eine Anwendung den Datensatz so behandeln, als ob er in dem ursprünglichen, von UMich

LDAP 3.3 unterstützten Format erstellt sei.

34

7.3 Datensatz

Ein Datensatz besteht aus mehreren Zeilen, die den Inhalt des Datensatzes beschreiben. Etwas

genauer bedeutet dies, dass ein Datensatz aus einem Objekt und seinen Attributen besteht. Zur

Beschreibung eines Attributs wird jeweils eine Zeile benötigt, es können also nicht mehrere

Attribute in einer Zeile aufgelistet werden.

{mail:Tux@openldap.org telephoneNumber: 012345}

Wäre ein ungültiger Eintrag.

{mail:Tux@openldap.org

telephoneNumber: 012345}

Wäre ein gültiger Eintrag.

LDIF Dokumente müssen den folgenden Regeln gehorchen:

• Eine Zeile muss am Zeilenanfang beginnen.

• Jeder Datensatz wird durch eine Leerzeile getrennt.

• Das Zeichenformat für die Eingabe alphanumerischer Daten muss UTF-8 sein.

Beispiel:

# Beispiel einer *.ldif Datei

version: 1

objectclass:top

objectclass:person

dn: uid=Tux,ou=Chef,o=linux,c=de

jpegphoto:<file:///home/Tux/bild.jpg

userPassword::443Eg7js854=

35

8 Ein Blick in die Zukunft

Das LDAP unterliegt einer ständigen Weiterentwicklung. Dabei kümmern sich zwei

Arbeitsgruppen der IETF darum, die Verbesserung und Erweiterung von LDAP voran zu

treiben. Zum einen die Working Group LDAP Extensions und zum anderen die Working

Group LDAP Duplication/Replication/Update Protocols. Momentan arbeitet die Working

Group der LDAP Extensions an den folgenden Schwerpunkten:

• Dynamisierung des Verzeichnisdienstes: Bisher ist die Datenhaltung eines

Verzeichnisdienstes eher statisch, d.h. eine Aktualisierung des Datenbestandes in sehr

kurzen Zeitabständen kann zu Datenverlusten im DIT führen.

• Serverseitiges Sortieren der Suchergebnisse: bisher wurden die Suchergebnisse in

unsortierter Form zurück gegeben.

• Repräsentation von Referrals im Verzeichnisbaum: Es gab bisher noch keine

festen Regeln dafür, wie man Referrals im Verzeichnisdienst repräsentiert.

• Verifizierung des Verzeichnisdienstes: Es ist ein Message Control Protocol geplant,

das es Clients ermöglicht, die Quelle der Daten zu verifizieren und die Integrität der

Daten zu bestätigen.

• Propagierung des Verzeichnisdienstes im Netzwerk: Bisher gibt es keine Standards

dafür, wie Clients einen Netzwerkdienst und den dazugehörigen Namensraum

identifizieren können. Momentan wird dies noch durch die Benutzung von

Konfigurationsanweisungen getan.

Die Working Group LDAP Duplication/Replication/Update Protocols versucht unter anderem

Standards und Modelle für die folgenden Schwerpunkte zu definieren:

• Eine LDAPv3 Replikations Architektur. Diese soll die Interoperabilität zwischen

unterschiedlichen Verzeichnisdiensten gewährleisten und die Replikation des

Verzeichnisbaumes zwischen diesen Verzeichnisdiensten ermöglichen.

• Ein Replikations Informations Modell. Dieses Modell soll Schemata und Semantik

definieren, die die Funktion, Administration, Wartung und Bereitstellung von Daten

zwischen unterschiedlichen Verzeichnisdiensten ermöglichen.

• Ein LDAPv3 Replikations Transport Modell. Dieses Modell stellt erweiterte

Funktionen und Spezifikationen vor, die für den Datentransport bei der Replikation

zwischen unterschiedlichen Verzeichnisdiensten gebraucht werden.

• Ein LDAPv3 Replikations Management. Es sollen Spezifikationen erarbeitet

36

werden, die die Umsetzung der Replikationsmodelle in operable Kontrollfunktionen

und Schemata ermöglichen.

• LDAPv3 Update Überprüfungsprozeduren. Dies sollen Prozeduren sein, die

Update Konflikte zwischen einem oder mehreren Replikationsservern erkennen und

beheben kann.

• Ein LDAPv3 Client Update Protokoll. Dieses Protokoll soll es Clients ermöglichen,

den eigenen Datenbestand synchron zum Server zu halten und über Veränderungen

der Daten im DIT informiert zu werden.

Auf die Erweiterungen dieser beiden Arbeitsgruppen unter anderen das Directory Enabled

Networking bzw. Webbasierte Anwendungen aufsetzen. Das DEN ist eine Philosophie in der

es darum geht, Netzwerkdaten und -dienste an zentrale Stelle vorzuhalten und im Sinne von

verteilten Systemen zu propagieren. Diese Netzwerkdaten könen z.B. Routing Tabellen,

Zugriffsberechtigungen auf dedizierte Dienste oder Ähnliches sein.

Bei den Webbasierten Anwendungen ist die Kombination von Verzeichnissen mit

webbasierten Anwendungen von Interesse.

37

Literaturverzeichnis

Timothy Howes, Mark G. Smith, Gordon S. Good: Understanding and Deploying LDAP Directory Services (2nd Edition), Addison-Wesley

Brian Arkills: LDAP Directories Explained, Addison-Wesley

Gerald Carter: LDAP System Administration, O'Reilly Media

The OpenLDAP Project: OpenLDAP Administrator's Guide, http://www.openldap.org

Heinz Johner, Larry Brown, Franz-Stefan Hinner, Wolfgang Reis: White Paper: Unterstanding LDAP, http://ibm.com/redbooks/

RFC

RFC 1487 Lightweight Directory Access Protocol

RFC 1777 LDAPv2

RFC 1959 An LDAP URL Format

RFC 2251 LDAPv3

RFC 2252 LDAPv3 Attribute Syntax Definitions

RFC 2253 UTF-8 Representation of Distinguished Names

RFC 2254 The String Representation of LDAP Search Filters

RFC 2255 The LDAP URL Format

RFC 2256 A Summary of the X.500 User Schema for use with LDAPv3

RFC 2307 An Approach for Using LDAP as a Network Information System

RFC 2396 URI Generic Syntax

X.500-Standards

X.500 The Directory: Overview of concepts, models and services

X.501 The Directory: Models

X.509 The Directory: Public-key and attribute certificate frameworks

X.511 The Directory: Abstract Service Definition

X.518 The Directory: Procedures for distributed operation

X.519 The Directory: Protocol Specifications

X.520 The Directory: Selected attribute types

X.521 The Directory: Selected Object classes

X.525 The Directory: Replication

X.530 The Directory: Use of systems management for administration of the Directory

38