Post on 15-Sep-2019
transcript
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