2. Modell der Verzeichnis-Benutzerinformationen
In [X.501] heißt es:
Der Zweck des Verzeichnisses besteht darin, Informationen über
interessierende Objekte (objects) in einer bestimmten „Welt“ zu
speichern und zugänglich zu machen. Ein Objekt kann alles sein, was
identifizierbar (benennbar) ist.
Eine Objektklasse (object class) ist eine identifizierte Familie von
Objekten oder vorstellbaren Objekten, die bestimmte Merkmale gemeinsam
haben. Jedes Objekt gehört mindestens einer Klasse an. Eine Objektklasse
kann eine Unterklasse anderer Objektklassen sein. In diesem Fall gelten
die Mitglieder der erstgenannten Klasse, der Unterklasse, zugleich als
Mitglieder der letztgenannten Klassen, der Oberklassen. Unterklassen
können wiederum Unterklassen haben, und dies bis zu beliebiger Tiefe.
Ein Verzeichniseintrag (directory entry), also eine benannte Sammlung von Informationen, ist die grundlegende Informationseinheit im Verzeichnis. Es gibt mehrere Arten von Verzeichniseinträgen.
Ein Objekteintrag (object entry) repräsentiert ein bestimmtes Objekt. Ein Aliaseintrag (alias entry) stellt eine alternative Benennung bereit. Ein Untereintrag (subentry) enthält administrative und/oder betriebliche Informationen.
Die Einträge, welche die Verzeichnisinformationsbasis (Directory Information Base, DIB) repräsentieren, sind hierarchisch in einer Baumstruktur angeordnet, die als Verzeichnisinformationsbaum (Directory Information Tree, DIT) bezeichnet wird.
Abschnitt 2.1 beschreibt den Verzeichnisinformationsbaum. Abschnitt 2.2 behandelt den Aufbau von Einträgen. Abschnitt 2.3 behandelt die Benennung von Einträgen.
Abschnitt 2.4 behandelt Objektklassen. Abschnitt 2.5 behandelt Attributbeschreibungen. Abschnitt 2.6 behandelt Aliaseinträge.
2.1. Der Verzeichnisinformationsbaum
Wie oben erwähnt, besteht die DIB aus Einträgen, die hierarchisch in einer als Verzeichnisinformationsbaum (DIT) bezeichneten Baumstruktur angeordnet sind; genauer gesagt handelt es sich um einen Baum, dessen Knoten die Einträge sind.
Die Kanten zwischen den Knoten definieren Beziehungen zwischen Einträgen. Existiert eine Kante von X nach Y, so ist der Eintrag an X der unmittelbar übergeordnete Eintrag von Y und Y der unmittelbar untergeordnete Eintrag von X. Zu den übergeordneten Einträgen eines Eintrags gehören sein unmittelbar übergeordneter Eintrag sowie dessen übergeordnete Einträge. Zu den untergeordneten Einträgen gehören alle unmittelbar untergeordneten Einträge und deren untergeordnete Einträge.
Entsprechend lässt sich aus der Über-/Unterordnungsbeziehung zwischen Objekteinträgen eine Beziehung zwischen den von ihnen repräsentierten Objekten ableiten. DIT-Strukturregeln können die Beziehungen zwischen Objekten regeln.
Hinweis: Der unmittelbar übergeordnete Eintrag eines Eintrags wird auch als dessen Elternknoten und ein unmittelbar untergeordneter Eintrag als dessen Kindknoten bezeichnet. Einträge mit demselben Elternknoten heißen Geschwister.
2.2. Aufbau eines Eintrags
Ein Eintrag besteht aus Attributen, die Informationen über das von ihm repräsentierte Objekt enthalten. Einige Attribute repräsentieren Benutzerinformationen und heißen Benutzerattribute (user attributes). Andere repräsentieren betriebliche und/oder administrative Informationen und heißen Betriebsattribute (operational attributes).
Ein Attribut besteht aus einer Attributbeschreibung (einem Typ und null oder mehr Optionen) und einem oder mehreren zugeordneten Werten. Häufig wird ein Attribut anhand seiner Attributbeschreibung bezeichnet. Das Attribut 'givenName' besteht beispielsweise aus der Attributbeschreibung 'givenName' (dem Attributtyp 'givenName' [RFC4519] und null Optionen) sowie einem oder mehreren zugeordneten Werten.
Der Attributtyp bestimmt, ob das Attribut mehrere Werte besitzen darf, welche Syntax und Übereinstimmungsregeln zum Erzeugen und Vergleichen seiner Werte verwendet werden und welche weiteren Funktionen gelten. Optionen geben Untertypen und weitere Funktionen an.
Attributwerte entsprechen der für den Attributtyp definierten Syntax.
Zwei Werte eines Attributs dürfen nicht äquivalent sein. Zwei Werte gelten genau dann als äquivalent, wenn sie gemäß der Gleichheits-Übereinstimmungsregel des Attributtyps übereinstimmen würden. Ist für den Attributtyp keine Gleichheits-Übereinstimmungsregel definiert, sind zwei Werte genau dann äquivalent, wenn sie identisch sind. (Weitere Einschränkungen enthält Abschnitt 2.5.1.)
Ein 'givenName'-Attribut kann beispielsweise mehrere Werte besitzen; diese müssen Directory Strings sein und Groß-/Kleinschreibung wird nicht berücksichtigt. Ein 'givenName'-Attribut kann nicht zugleich "John" und "JOHN" enthalten, weil diese Werte gemäß der Gleichheits-Übereinstimmungsregel des Attributtyps äquivalent sind.
Außerdem darf ein Attribut keinen Wert besitzen, der nicht zu sich selbst äquivalent ist. So darf das Attribut 'givenName' keinen Directory String mit dem Codepunkt REPLACEMENT CHARACTER (U+FFFD) als Wert besitzen, weil ein Abgleich unter Beteiligung dieses Directory String gemäß der Gleichheits-Übereinstimmungsregel dieses Attributs Undefined ist.
Wird ein Attribut zur Benennung des Eintrags verwendet, wird genau einer seiner Werte zur Bildung des Relative Distinguished Name verwendet. Dieser Wert wird als Distinguished Value bezeichnet.
2.3. Benennung von Einträgen
2.3.1. Relative Distinguished Names
Jeder Eintrag wird relativ zu seinem unmittelbar übergeordneten Eintrag benannt. Dieser relative Name, der als Relative Distinguished Name (RDN) [X.501] bezeichnet wird, besteht aus einer ungeordneten Menge einer oder mehrerer Attributwert-Assertions (attribute value assertions, AVA), die jeweils aus einer Attributbeschreibung mit null Optionen und einem Attributwert bestehen. Diese AVAs werden so gewählt, dass sie mit Attributwerten des Eintrags (jeweils einem Distinguished Value) übereinstimmen.
Der Relative Distinguished Name eines Eintrags muss unter allen unmittelbar untergeordneten Einträgen seines unmittelbar übergeordneten Eintrags (also unter allen Geschwistern) eindeutig sein.
Beispiele für Zeichenkettendarstellungen von RDNs [RFC4514] sind:
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
Das letzte Beispiel ist ein mehrwertiger RDN, also ein RDN aus mehreren AVAs.
2.3.2. Distinguished Names
Der vollständig qualifizierte Name eines Eintrags, sein Distinguished Name (DN) [X.501], ist die Verkettung seines RDN mit dem DN seines unmittelbar übergeordneten Eintrags. Ein Distinguished Name verweist eindeutig auf einen Eintrag im Baum. Beispiele für Zeichenkettendarstellungen von DNs [RFC4514] sind:
[email protected],DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
2.3.3. Aliasnamen
Ein Alias beziehungsweise Aliasname ist „ein durch die Verwendung von Aliaseinträgen bereitgestellter Name für ein Objekt“ [X.501]. Aliaseinträge werden in Abschnitt 2.6 beschrieben.
2.4. Objektklassen
Eine Objektklasse ist „eine identifizierte Familie von Objekten (oder vorstellbaren Objekten), die bestimmte Merkmale gemeinsam haben“ [X.501].
Nach der Definition in [X.501] gilt:
Objektklassen dienen im Verzeichnis mehreren Zwecken:
- Beschreibung und Kategorisierung von Objekten und den diesen
Objekten entsprechenden Einträgen;
- gegebenenfalls Steuerung des Verzeichnisbetriebs;
- Regelung der Position von Einträgen im DIT in Verbindung mit den
Spezifikationen der DIT-Strukturregeln;
- Regelung der in Einträgen enthaltenen Attribute in Verbindung mit
den Spezifikationen der DIT-Inhaltsregeln;
- Identifizierung von Eintragsklassen, die von der zuständigen
Verwaltungsinstanz einer bestimmten Richtlinie zugeordnet werden.
Eine Objektklasse (Unterklasse) kann von einer Objektklasse (ihrer
direkten Oberklasse) abgeleitet werden, die ihrerseits von einer noch
allgemeineren Objektklasse abgeleitet ist. Bei strukturellen
Objektklassen endet dieser Vorgang bei der allgemeinsten Objektklasse
'top' (in Abschnitt 2.4.1 definiert). Eine geordnete Menge der
Oberklassen bis hin zur obersten Objektklasse einer Objektklasse bildet
deren Oberklassenkette (superclass chain).
Eine Objektklasse kann von zwei oder mehr direkten Oberklassen
(Oberklassen, die nicht derselben Oberklassenkette angehören) abgeleitet
werden. Dieses Merkmal der Unterklassenbildung heißt Mehrfachvererbung
(multiple inheritance).
Jede Objektklasse bestimmt die Attribute, die in Einträgen dieser Klasse vorhanden sein müssen, und die Attribute, die vorhanden sein dürfen. Da ein Eintrag einer Klasse die Anforderungen jeder Klasse erfüllen muss, der er angehört, erbt eine Objektklasse die Mengen der zulässigen und erforderlichen Attribute von ihren Oberklassen. Eine Unterklasse kann ein von ihrer Oberklasse zugelassenes Attribut als erforderlich festlegen. Gehört ein Attribut beiden Mengen an, muss es vorhanden sein.
Jede Objektklasse wird als eine von drei Arten definiert: abstrakt (Abstract), strukturell (Structural) oder Hilfsklasse (Auxiliary).
Jede Objektklasse wird durch einen Objektbezeichner (object identifier, OID) und optional durch einen oder mehrere Kurznamen (Deskriptoren) identifiziert.
2.4.1. Abstrakte Objektklassen
Eine abstrakte Objektklasse stellt, wie der Name andeutet, eine Grundlage von Merkmalen bereit, von der erbende Objektklassen definiert werden können. Ein Eintrag kann einer abstrakten Objektklasse nur angehören, wenn er einer strukturellen oder Hilfsobjektklasse angehört, die von dieser abstrakten Klasse erbt.
Abstrakte Objektklassen können nicht von strukturellen oder Hilfsobjektklassen abgeleitet werden.
Alle strukturellen Objektklassen werden direkt oder indirekt von der abstrakten Objektklasse 'top' abgeleitet. Hilfsobjektklassen müssen nicht von 'top' abgeleitet sein.
Die Objektklassendefinition (siehe Abschnitt 4.1.1) der Objektklasse 'top' lautet:
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
Alle Einträge gehören der abstrakten Objektklasse 'top' an.
2.4.2. Strukturelle Objektklassen
In [X.501] heißt es:
Eine Objektklasse, die zur Verwendung in der strukturellen Spezifikation
des DIT definiert ist, wird als strukturelle Objektklasse bezeichnet.
Strukturelle Objektklassen dienen zur Definition der Namensstruktur der
Objekte konformer Einträge.
Ein Objekt- oder Aliaseintrag ist durch genau eine Oberklassenkette
struktureller Objektklassen charakterisiert, deren unterste Objektklasse
genau eine strukturelle Objektklasse ist. Diese strukturelle Objektklasse
wird als strukturelle Objektklasse des Eintrags bezeichnet.
Strukturelle Objektklassen stehen zu den zugeordneten Einträgen in
folgender Beziehung:
- Ein Eintrag, der einer strukturellen Objektklasse entspricht, muss
das durch diese Objektklasse eingeschränkte reale Objekt
repräsentieren;
- DIT-Strukturregeln beziehen sich ausschließlich auf strukturelle
Objektklassen; die strukturelle Objektklasse eines Eintrags dient
dazu, dessen Position im DIT festzulegen;
- die strukturelle Objektklasse eines Eintrags dient zusammen mit
einer zugeordneten DIT-Inhaltsregel zur Steuerung des Inhalts eines
Eintrags.
Die strukturelle Objektklasse eines Eintrags darf nicht geändert werden.
Jede strukturelle Objektklasse ist eine direkte oder indirekte Unterklasse der abstrakten Objektklasse 'top'.
Strukturelle Objektklassen können keine Unterklassen von Hilfsobjektklassen sein.
Jeder Eintrag gehört sowohl seiner strukturellen Objektklasse als auch allen Klassen in deren Oberklassenkette an.
2.4.3. Hilfsobjektklassen
Hilfsobjektklassen dienen zur Erweiterung der Merkmale von Einträgen. Sie werden üblicherweise verwendet, um die Mengen der in einem Eintrag erforderlichen und zulässigen Attribute zu erweitern. Mit ihnen lassen sich Einträge oder Klassen von Einträgen beschreiben.
Hilfsobjektklassen können keine Unterklassen struktureller Objektklassen sein.
Ein Eintrag kann einer beliebigen Teilmenge der Hilfsobjektklassen angehören, die durch die der strukturellen Objektklasse des Eintrags zugeordnete DIT-Inhaltsregel zugelassen sind. Ist der strukturellen Objektklasse des Eintrags keine DIT-Inhaltsregel zugeordnet, kann der Eintrag keiner Hilfsobjektklasse angehören.
Die Menge der Hilfsobjektklassen, denen ein Eintrag angehört, kann sich im Laufe der Zeit ändern.
2.5. Attributbeschreibungen
Eine Attributbeschreibung setzt sich aus einem Attributtyp (siehe Abschnitt 2.5.1) und einer Menge von null oder mehr Attributoptionen (siehe Abschnitt 2.5.2) zusammen.
Eine Attributbeschreibung wird durch die folgende ABNF dargestellt:
attributedescription = attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar
Dabei bezeichnet
Beispiele gültiger Attributbeschreibungen:
2.5.4.0
cn;lang-de;lang-en
owner
Eine Attributbeschreibung mit einem nicht erkannten Attributtyp ist als nicht erkannt zu behandeln. Server müssen (SHALL) eine Attributbeschreibung mit einer nicht erkannten Attributoption als nicht erkannt behandeln. Clients dürfen (MAY) eine nicht erkannte Attributoption als Kennzeichnungsoption behandeln (siehe Abschnitt 2.5.2.1).
Alle Attribute eines Eintrags müssen unterschiedliche Attributbeschreibungen haben.
2.5.1. Attributtypen
Ein Attributtyp bestimmt, ob das Attribut mehrere Werte haben kann, welche Syntax und Übereinstimmungsregeln zum Aufbau und Vergleich der Werte dieses Attributs verwendet werden, sowie weitere Funktionen.
Ist für den Attributtyp kein Gleichheitsvergleich festgelegt, gilt:
- Das Attribut (dieses Typs) kann nicht zur Namensgebung verwendet
werden.
- Beim Hinzufügen des Attributs (oder beim Ersetzen aller Werte) dürfen
keine zwei Werte gleichwertig sein (siehe 2.2).
- Einzelne Werte eines mehrwertigen Attributs dürfen nicht unabhängig
voneinander hinzugefügt oder gelöscht werden.
- Attributwertbehauptungen (wie Übereinstimmungen in Suchfiltern und
Vergleiche), die Werte eines solchen Typs verwenden, können nicht
ausgeführt werden.
Andernfalls ist die angegebene Gleichheits-Übereinstimmungsregel zur Auswertung von Attributwertbehauptungen bezüglich des Attributtyps zu verwenden. Die angegebene Gleichheitsregel muss transitiv und kommutativ sein.
Der Attributtyp gibt an, ob es sich um ein Benutzerattribut oder ein Betriebsattribut handelt. Bei einem Betriebsattribut gibt der Attributtyp den betrieblichen Verwendungszweck an und ob das Attribut von Benutzern geändert werden kann. Betriebsattribute werden in Abschnitt 3.4 behandelt.
Ein Attributtyp (ein Untertyp) kann von einem allgemeineren Attributtyp (einem direkten Obertyp) abgeleitet werden. Für die Bildung von Untertypen gelten folgende Einschränkungen:
- Ein Untertyp muss denselben Verwendungszweck wie sein direkter Obertyp
haben.
- Die Syntax eines Untertyps muss mit der Syntax seines Obertyps
übereinstimmen oder eine Verfeinerung davon sein.
- Ein Untertyp muss kollektiv [RFC3671] sein, wenn sein Obertyp kollektiv
ist.
Eine Attributbeschreibung, die aus einem Untertyp und keinen Optionen besteht, wird als direkter Beschreibungsuntertyp der Attributbeschreibung bezeichnet, die aus dem direkten Obertyp des Untertyps und keinen Optionen besteht.
Jeder Attributtyp wird durch einen Objektbezeichner (OID) und optional durch einen oder mehrere Kurznamen (Deskriptoren) bezeichnet.
2.5.2. Attributoptionen
Es gibt mehrere Arten von Attributbeschreibungsoptionen. Die technische LDAP-Spezifikation beschreibt eine Art im Einzelnen: Kennzeichnungsoptionen.
Nicht alle Optionen können Attributen zugeordnet werden, die im Verzeichnis gespeichert sind. Kennzeichnungsoptionen können dies.
Nicht alle Optionen können zusammen mit allen Attributtypen verwendet werden. In solchen Fällen ist die Attributbeschreibung als nicht erkannt zu behandeln.
Eine Attributbeschreibung, die sich gegenseitig ausschließende Optionen enthält, ist als nicht erkannt zu behandeln. Das heißt, "cn;x-bar;x-foo" ist als nicht erkannt zu behandeln, wenn "x-foo" und "x-bar" sich gegenseitig ausschließen.
Andere Arten von Optionen können in zukünftigen Dokumenten festgelegt werden. Diese Dokumente müssen im Einzelnen darlegen, in welcher Beziehung die von ihnen definierten neuen Arten von Optionen zu Kennzeichnungsoptionen stehen. Insbesondere müssen sie darlegen, ob neue Arten von Optionen Attributen zugeordnet werden können, die im Verzeichnis gespeichert sind, wie neue Arten von Optionen die Übertragung von Attributwerten beeinflussen und wie sie in Attributbeschreibungshierarchien behandelt werden.
Optionen werden als kurze, nicht zwischen Groß- und Kleinschreibung unterscheidende Textzeichenfolgen dargestellt, die der in Abschnitt 2.5 dieses Dokuments definierten Produktion
Die Verfahren zur Registrierung von Optionen sind in BCP 64, RFC 4520 [RFC4520] ausführlich beschrieben.
2.5.2.1. Kennzeichnungsoptionen
Im Verzeichnis gespeicherte Attribute können Attributbeschreibungen mit einer beliebigen Anzahl von Kennzeichnungsoptionen haben. Kennzeichnungsoptionen schließen sich niemals gegenseitig aus.
Eine Attributbeschreibung mit N Kennzeichnungsoptionen ist ein direkter (Beschreibungs-)Untertyp aller Attributbeschreibungen mit demselben Attributtyp und allen N Optionen bis auf eine. Hat der Attributtyp einen Obertyp, ist die Attributbeschreibung außerdem ein direkter (Beschreibungs-)Untertyp der Attributbeschreibung aus dem Obertyp und den N Kennzeichnungsoptionen. Das heißt, 'cn;lang-de;lang-en' ist ein direkter (Beschreibungs-)Untertyp von 'cn;lang-de', 'cn;lang-en' und 'name;lang-de;lang-en' ('cn' ist ein Untertyp von 'name'; beide sind in [RFC4519] definiert).
2.5.3. Attributbeschreibungshierarchien
Eine Attributbeschreibung kann der direkte Untertyp von null oder mehr anderen Attributbeschreibungen sein, wie durch die Untertypbildung bei Attributtypen (beschrieben in Abschnitt 2.5.1) oder die Untertypbildung bei Attribut-Kennzeichnungsoptionen (beschrieben in Abschnitt 2.5.2.1) vorgegeben. Diese Untertypbeziehungen werden verwendet, um Hierarchien von Attributbeschreibungen und Attributen zu bilden.
In Anlehnung an [X.501]:
Attributhierarchien ermöglichen den Zugriff auf die DIB mit
unterschiedlichen Granularitätsgraden. Dies wird dadurch erreicht,
dass auf die Wertkomponenten von Attributen entweder über ihre
spezifische Attributbeschreibung (ein direkter Verweis auf das
Attribut) oder über eine allgemeinere Attributbeschreibung (ein
indirekter Verweis) zugegriffen werden kann.
Semantisch zusammengehörige Attribute können in eine hierarchische
Beziehung gestellt werden, wobei die spezialisierteren den
allgemeineren untergeordnet werden. Die Suche nach oder das Abrufen von
Attributen und ihren Werten wird erleichtert, indem die allgemeinere
Attributbeschreibung angegeben wird; ein derart angegebenes
Filterelement wird sowohl für die spezialisierteren Beschreibungen als
auch für die angegebene Beschreibung ausgewertet.
Werden untergeordnete spezialisierte Beschreibungen zur Rückgabe als
Teil eines Suchergebnisses ausgewählt, sind diese Beschreibungen
zurückzugeben, sofern sie verfügbar sind. Werden die allgemeineren
Beschreibungen zur Rückgabe als Teil eines Suchergebnisses ausgewählt,
sind sowohl die allgemeinen als auch die spezialisierten Beschreibungen
zurückzugeben, sofern sie verfügbar sind. Ein Attributwert ist stets
als Wert seiner eigenen Attributbeschreibung zurückzugeben.
Für Änderungen des Eintragsinhalts durch Benutzer werden alle
Attributbeschreibungen in einer Attributhierarchie als verschiedene,
nicht miteinander zusammenhängende Beschreibungen behandelt.
Ein in einem Objekt- oder Alias-Eintrag gespeicherter Attributwert
gehört zu genau einer Attributbeschreibung. Die Beschreibung wird
angegeben, wenn der Wert ursprünglich zum Eintrag hinzugefügt wird.
Für die Verwaltung des Unterschemas des Eintrags gilt eine Festlegung, nach der ein Attribut erforderlich ist, als erfüllt, wenn der Eintrag einen Wert einer Attributbeschreibung enthält, die zu einer Attributhierarchie gehört und deren Attributtyp mit dem Typ des erforderlichen Attributs übereinstimmt. Das heißt, eine Festlegung "MUST name" wird durch 'name' oder 'name;x-tag-option' erfüllt, nicht aber durch 'CN' oder 'CN;x-tag-option' (obwohl 'CN' ein Untertyp von 'name' ist). Ebenso darf ein Eintrag den Wert einer Attributbeschreibung aus einer Attributhierarchie enthalten, wenn der Attributtyp dieser Beschreibung entweder ausdrücklich in der Definition einer Objektklasse enthalten ist, zu der der Eintrag gehört, oder durch die für den Eintrag geltende DIT-Inhaltsregel zugelassen wird. Das heißt, 'name' und 'name;x-tag-option' sind durch "MAY name" (oder "MUST name") zugelassen, 'CN' und 'CN;x-tag-option' dagegen nicht durch "MAY name" (oder durch "MUST name").
Für die Verwaltung anderer Richtlinien werden alle Attributbeschreibungen in einer Attributhierarchie als verschiedene, nicht miteinander zusammenhängende Beschreibungen behandelt, sofern die Spezifikation des jeweiligen Verwaltungsmodells nichts anderes bestimmt.
2.6. Alias-Einträge
In Anlehnung an [X.501]:
Ein Alias oder Aliasname für ein Objekt ist ein alternativer Name für
ein Objekt oder einen Objekteintrag, der durch die Verwendung von
Alias-Einträgen bereitgestellt wird.
Jeder Alias-Eintrag enthält im Attribut 'aliasedObjectName' (in X.500
als Attribut 'aliasedEntryName' bezeichnet) einen Namen eines Objekts.
Der Distinguished Name des Alias-Eintrags ist somit ebenfalls ein Name
für dieses Objekt.
HINWEIS - Der Name in 'aliasedObjectName' wird als der Name
bezeichnet, auf den der Alias verweist. Er muss nicht der
Distinguished Name eines Eintrags sein.
Die Umwandlung eines Aliasnamens in einen Objektnamen wird als
(Alias-)Dereferenzierung bezeichnet und besteht aus der systematischen
Ersetzung von Aliasnamen, die in einem vorgeblichen Namen gefunden
werden, durch den Wert des entsprechenden Attributs
'aliasedObjectName'. Der Vorgang kann die Untersuchung mehrerer
Alias-Einträge erfordern.
Jeder bestimmte Eintrag in der DIT kann null oder mehr Aliasnamen
besitzen. Daraus folgt, dass mehrere Alias-Einträge auf denselben
Eintrag verweisen können. Ein Alias-Eintrag kann auf einen Eintrag
verweisen, der kein Blatteintrag ist, und kann auf einen anderen
Alias-Eintrag verweisen.
Ein Alias-Eintrag darf keine untergeordneten Einträge haben, sodass ein
Alias-Eintrag immer ein Blatteintrag ist.
Jeder Alias-Eintrag muss zur Objektklasse 'alias' gehören.
Ein Eintrag mit der Objektklasse 'alias' muss außerdem einer oder mehreren Objektklassen angehören, die das Vorhandensein geeigneter Namensattribute zulassen, oder einer DIT-Inhaltsregel unterliegen, die diese zulässt.
Beispiel:
dn: cn=bar,dc=example,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
cn: bar
aliasedObjectName: cn=foo,dc=example,dc=com
2.6.1. Objektklasse 'alias'
Alias-Einträge gehören zur Objektklasse 'alias'.
( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL
MUST aliasedObjectName )
2.6.2. Attributtyp 'aliasedObjectName'
Das Attribut 'aliasedObjectName' enthält den Namen des Eintrags, auf den ein Alias verweist. Das Attribut 'aliasedObjectName' ist in X.500 als Attribut 'aliasedEntryName' bekannt.
( 2.5.4.1 NAME 'aliasedObjectName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
Die Übereinstimmungsregel 'distinguishedNameMatch' und die Syntax DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) sind in [RFC4517] definiert.