2 Das X.500-Datenmodell

Transkript

1 15 2 Das X.500-Datenmodell Die Welt der X.500-Protokolle und des davon abgeleitete LDAP besteht aus»objekten«. Ein Leser mit Vorkenntnissen in objektorientiertem Design wird feststellen, dass wesentliche OO-Konzepte wie»objekte«,»klassen«,»vererbung«,»polymorphie«und deren intensive Wiederverwertung in der X.500-Welt 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 2.1 zeigt einen Ausschnitt aus den Organisationsverzeichnis der hoffnungsvollen Firma»Advanced Virtual Cottage Industries«, die aus einem Kleinwagen und aus einem Mitarbeiter besteht. Alles ist ein Objekt! Organisation O: AVCI L: Woebbelin DESC: Advanced Virtual Cottage Industries Abbildung 2.1 Das Verzeichnis der Firma»AVCI«Device cn: Rostlaube serialnumber: LWL X 500 Person cn: Thomas Kali telephonenumber:

2 16 2 Das X.500-Datenmodell Im Verzeichnis der kleinen AVCI finden wir alle Elemente eines ausgewachsenen Verzeichnisses wieder: einen Verzeichnisbaum, der die Firma in der Hierarchie höher ansiedelt als den Firmenwagen und den Mitarbeiter, Einträge für die Firma, den Mitarbeiter und den Kleinwagen, viele Attribute: O, L und DESC für die Firma, CN und telephonenumber für den Mitarbeiter, CN und serialnumber für den Firmenwagen. 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 Firmenauto. Auch die hier verwendeten Attribute sind standardisiert. Dies merkt man zum einen daran, dass die Namen der meistverwendeten Attribute bis zur Unkenntlichkeit abgerkürzt sind, zum anderen daran, dass das Attribut cn sowohl beim Mitarbeiter (Person) als auch beim Firmenwagen (Device) vorkommt. Die Bedeutung der nicht offensichtlichen Attributnamen in diesem Beispiel sei dem Leser nicht verschwiegen: 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. Den Rest dieses Kapitels werden wir jetzt darauf verwenden, die einzelnen Komponenten eines Verzeichnisses detaillierter zu untersuchen. 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. Wir halten aber eine wichtige Eigenschaft(!) von Objekten fest: Ein Objekt verfügt über einen Satz von Eigenschaften (Attribute). Ein besonderes Attribut ist der Name des Objektes.

3 2.2 Attribute 17 Natürlich hat ein Objekt in der realen Welt, z.b. ein Mensch, eine unermesslich große Zahl von Eigenschaften, oder wenn man so will Attributen. Dies ist aber für die maschinelle Verwaltung von Objekten (z.b. Menschen) 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 musische Begabung hat, hier interessieren Name und 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. 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: In der Tat: Attribute sind Objekte, denn alles ist ein Objekt...! einem Namen, mit dem das Attribut innerhalb des Objektes eindeutig referenziert werden kann, keinem, genau einem oder einer Liste von Werten. Um die Wiederverwendung von Attributen in verschiedenen Objektklassen zu fördern, 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 be- OID=Object IDentifier. stimmt (OIDs werden noch ausführlich im Abschnitt besprochen). Eine Zahlenkombination, Optional eine menschenlesbare Beschreibung (Description). die ein Objekt eindeutig Optional Definitionen darüber, welche Regeln für Gleichheit (EQUALITY), Treffer von Teilzeichenketten (SUBSTR) und die lexikalische Anordnung (ORDERING) dieses Attributes gelten sollen. bestimmt. 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.

4 18 2 Das X.500-Datenmodell 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 Instanzen im objektorientierten Design (OOD) bzw. in der objektorientierten Programmierung (OOP). Je nachdem, ob man mit dem Denken in Objekten vertraut ist oder nicht, sollte man sich einen Eintrag wahlweise als eine Instanz von Objektklassen oder als eine Menge von Attributen vorstellen:»objektorientierte«definition: Ein Verzeichniseintrag ist eine Instanz 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 OOD/OOP-Welt eine zentrale Rolle spielt, ist das Konzept der Vererbung. Eine Objektklasse kann als Subklasse einer anderen Klasse definiert werden und erbt dann deren Attributdefinitionen. (Die Klasse, von der geerbt wird, heißt Superklasse.) 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 OO- Sprachen, die wie C++ oder Perl die Mehrfachvererbung unterstützen.

5 2.5 Klassenzugehörigkeit und Polymorphie Klassenzugehörigkeit und Polymorphie Ein Verzeichniseintrag hat ein Attribut mit Namen objectclass,dasfestlegt, welchen Klassen der Eintrag angehört. Das objectclass-attribut ist multivalued, 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 (in OO-Terminologie: den Instanzen) auftritt, während sie in C++ oder Perl auf der Ebene der Klassen stattfindet, die den Objektklassen des X.500-Modells entsprechen. Diese»Vielgestaltigkeit«(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 Das abgeleiteter Eintrag ist ein»echter«eintrag, ein von alias abgeleiteter Eintrag ist»nur«ein 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. Im Kapitel 7 über Schemas werden wir noch sehen, dass da im X.500-Modell alles ein Objekt ist auch Attributtypen als Subklassen anderer Attributtypen deklariert werden können und dann deren Eigenschaften erben. objectclass-attribut wird in RFC 2256 beschrieben. 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

6 20 2 Das X.500-Datenmodell Abbildung 2.2 Objektklasse Person "X521" Person +CommonName : (MUST) +Surname: (MUST) +description: (MAY) +telephonenumber: (MAY) +userpassword: (MAY) +seealso: (MAY) "X521" organizational Person +LocaleAtributeSet: (MAY) +PostalAttributeSet: (MAY) +TelecommunicationAttributeSet: (MAY) +organizationalunitname: (MAY) +title: (MAY) "RFC2798" inetorgperson +audio: (MAY) + businesscategory: +carlicense: (MAY) +departmentnumber: (MAY) +displayname: (MAY) +employeenumber: (MAY) +employeetype: (MAY) +givenname : (MAY) +homephone: (MAY) +homepostaladdress: (MAY) +initials: (MAY) +jpegphoto: (MAY) +labeleduri: (MAY) +mail: (MAY) +manager : (MAY) +mobile: (MAY) +pager : (MAY) +photo: (MAY) +roomnumber: (MAY) +secretary: (MAY) + uid : (MAY) +usercertificate: (MAY) + x500uniqueidentifier: (MAY) +preferredlanguage : (MAY) +usersmimecertificate: (MAY) + userpkcs12: "X521" residentialperson +localityname: (MUST) +PostalAttributeSet: (MAY) +preferreddeliverymethod: (MAY) +TelecomunicationsAttributeSet: (MAY) +businesscategory: (MAY) Vererbungshierarchie der Objektklassen inetorgperson und ResidentialPerson, mit obligatorischen (MUST) und fakultativen (MAY) Attributen.

7 2.7 Typen von Objektklassen: structural, auxiliary und abstract 21 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. Erfreulicherweise ist es aber nicht unbedingt notwendig, für diese beiden Dokumente zum Scheckbuch zu greifen, denn 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 meistbenutzte 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 überwältigenden 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 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 Hier wird die noch nicht an das Leben in einer vernetzten Welt angepasste X.500- Klasse organizationalperson um zahlreiche optionale Attribute erweitert. (Vergleiche hierzu auch Abschnitt 2.2.) 2.7 Typen von Objektklassen: structural, auxiliary und abstract 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

8 22 2 Das X.500-Datenmodell Die Restriktion auf einen einzigen Ableitungsbaum mit strukturellen Klassen wurde in den OpenLDAP-Versionen vor 2.1 nicht abgeprüft, was beim Upgrade auf neuere OpenLDAP-Versionen Probleme bereiten kann. Mehr Information zu Aliasen gibt es später im Abschnitt 2.9 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 OOD/OOP 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 Der 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. Sofern wir im Folgenden nicht das bequeme Kürzel DIT verwenden, bezeichnen wir dieses Objekt als Verzeichnisbaum. 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 (können), werden auch als Blattobjekte oder Blätter (engl. leaves) bezeichnet. Jedes übergeordnete Objekt definiert durch die 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.

9 2.9 Aliase 23 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. Alias Abbildung 2.3 Ein Aliaseintrag A 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. A B Abbildung 2.4 Deadlock: Der Alias verweist über A und B auf sich selbst Alias 2.10 Distinguished Name und Relative Distinguished Name 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

10 24 2 Das X.500-Datenmodell englisch: unterscheiden =todistinguish 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. Das werden wir im Folgenden auch tun. 2.11»Relative«Namen Weil sich aber die Distinguished Names aus kleineren Bausteinen, den Relative Distinguished Names zusammensetzen, werden wir zunächst das Konzept der Relative Distinguished Names näher untersuchen. Der häufig gebrauchte Ausdruck Relative Distinguished Name wird in der Praxis meist mit RDN abgekürzt. Dies werden wir im Folgenden auch tun. Der RDN wird benutzt, um Einträge unterhalb desselben übergeordneten Eintrages im Verzeichnisbaum 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. Common Names als RDN 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 Minifirma aus Abbildung 2.1 bietet es sich an, das CN-Attribut mit dem Wert Thomas Kali als RDN für die Person und das CN-Attribut mit dem Wert Rostlaube für das Device (Kleinwagen) zu verwenden. Es gibt allerdings auch andere Möglichkeiten. Andere Attribute als RDN 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

11 2.11»Relative«Namen 25 Einträge andere Objekte, zum Beispiel Anlagen und Geräte, beschreiben. Nicht jedes Inventarstück bekommt einen derartig zärtlichen Kosenamen wie der Kleinwagen Rostlaube der Firma AVCI. 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 AVCI, die durch ein Objekt der Klasse 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 Zusammengesetzte 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. Peter Müller) mehr als einmal vorfinden. Dann stellt sich die Frage, wie man in solchen Fällen einen RDN sinnvoll bestimmt. TOP C=DE C=US C=TV Abbildung 2.5 Relative Distinguished Names C=DE L=Berlin L=Bonn L=Kuhpoeddelskoog L=Kuhpoeddelskoog CN=Peter Mueller+STREET=Deichweg 2a Nehmen wir z.b. an, dass die Daten von Telefonkunden weltweit in einem Verzeichnis verwaltet werden, wie es Abbildung 2.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

12 26 2 Das X.500-Datenmodell verwenden können, was z.b. für Kuhpöddelskoog in Südfriesland wie folgt notiert wird: { l=kuhpoeddelskoog, Suedfriesland } 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.: { CN=Peter Mueller } 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=Peter Mueller+STREET=Deichweg 2a } Vom RDN zum 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=kuhpoeddelskoog, Suedfriesland, CN=Peter Mueller+STREET=Deichweg 2a } Der DN für den Ort sieht so aus: { C=DE, l=kuhpoeddelskoog, Suedfriesland }

13 2.11»Relative«Namen 27 Der DN des Landes ergibt sich zu: { C=DE } Und nicht zu vergessen das Root-Element, das einen ziemlich trivialen DN hat: { } Kodierung von RDN Einige Sonderzeichen im Wesentlichen das Komma, das im DN die Aufgabe hat, einzelne RDN-Komponenten voneinander zu trennen werden, wenn sie wie in unserem Beispiel Kuhpoeddelskoog, Suedfriesland 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:»òò«. In den vorangegangenen Beispielen haben wir uns feige um das Problem der Kodierung nationaler Sonderzeichen herumgedrückt, indem wir das»ö«in»kuhpöddelskoog«durch ein»oe«ersetzt haben. Dies ist immer dann angebracht, wenn Benutzer mit Tastaturen ohne die jeweiligen nationalen Sonderzeichen auf das Verzeichnis zugreifen sollen. Ist dies nicht der Fall, dann kann man seit LDAPv3 die im Anhang B beschriebene UTF-8-Kodierung verwenden und die Daten wie dort beschrieben mit dem Utility iconv konvertieren. RFC 2253 beschäftigt sich ausführlich mit der Namenssyntax im LDAP. RFC 2253 UTF-8 String Representation of Distinguished Names