RFC 4512 - LDAP: Verzeichnisinformationsmodelle
Netzwerk-Arbeitsgruppe K. Zeilenga Bitte um Kommentare: 4512 OpenLDAP Foundation Obsoletiert: 2251, 2252, 2256, 3674 Juni 2006 Kategorie: Standardisierungsverfahren
Lightweight Directory Access Protocol (LDAP):
Verzeichnisinformationsmodelle
Status dieses Dokuments
Dieses Dokument spezifiziert ein Protokoll des Internet- Standardisierungsverfahrens für die Internetgemeinschaft und bittet um Diskussion und Verbesserungsvorschläge. Der jeweils aktuellen Ausgabe der „Internet Official Protocol Standards“ (STD 1) sind der Standardisierungsstand und der Status dieses Protokolls zu entnehmen. Dieses Dokument darf uneingeschränkt verteilt werden.
Urheberrechtshinweis
Copyright (C) The Internet Society (2006).
Zusammenfassung
Das Lightweight Directory Access Protocol (LDAP) ist ein Internetprotokoll für den Zugriff auf verteilte Verzeichnisdienste, die nach den Daten- und Dienstmodellen von X.500 arbeiten. Dieses Dokument beschreibt die in LDAP verwendeten X.500- Verzeichnisinformationsmodelle.
Inhaltsverzeichnis
-
Einleitung .......................................................3 1.1. Beziehung zu anderen LDAP-Spezifikationen ...................3 1.2. Beziehung zu X.501 ..........................................4 1.3. Konventionen ................................................4 1.4. Gemeinsame ABNF-Produktionen ................................4
-
Modell der Verzeichnisbenutzerinformationen ......................6 2.1. Verzeichnisinformationsbaum .................................7 2.2. Struktur eines Eintrags .....................................7 2.3. Benennung von Einträgen .....................................8 2.4. Objektklassen ...............................................9 2.5. Attributbeschreibungen .....................................12 2.6. Alias-Einträge .............................................16
-
Administrative und betriebliche Verzeichnisinformationen .......17 3.1. Teilbäume ..................................................17 3.2. Untereinträge ..............................................18 3.3. Das Attribut 'objectClass' .................................18 3.4. Betriebsattribute ..........................................19
-
Verzeichnisschema ...............................................22 4.1. Schemadefinitionen .........................................23 4.2. Unterschema-Untereinträge ....................................32 4.3. Objektklasse 'extensibleObject' ............................35 4.4. Unterschema-Ermittlung .......................................35
-
DSA-(Server-)Informationsmodell .................................36 5.1. Serverspezifische Datenanforderungen .......................36
-
Weitere Überlegungen ............................................40 6.1. Erhaltung von Benutzerinformationen .......................40 6.2. Kurznamen ..................................................41 6.3. Zwischenspeicherung und Spiegelung ..........................41
-
Implementierungsrichtlinien .....................................42 7.1. Serverrichtlinien ..........................................42 7.2. Clientrichtlinien ..........................................42
-
Sicherheitsüberlegungen .........................................43
-
IANA-Erwägungen .................................................43
-
Danksagungen ...................................................44
-
Normative Referenzen ...........................................45 Anhang A. Änderungen ...............................................47 A.1. Änderungen gegenüber RFC 2251 ..............................47 A.2. Änderungen gegenüber RFC 2252 ..............................49 A.3. Änderungen gegenüber RFC 2256 ..............................50 A.4. Änderungen gegenüber RFC 3674 ..............................51
-
Einleitung
Dieses Dokument behandelt die X.500-Verzeichnisinformationsmodelle [X.501], wie sie vom Lightweight Directory Access Protocol (LDAP) [RFC4510] verwendet werden.
Das Verzeichnis ist „eine Sammlung offener Systeme, die bei der Bereitstellung von Verzeichnisdiensten zusammenarbeiten“ [X.500]. Die im Verzeichnis enthaltenen Informationen werden zusammenfassend als Verzeichnisinformationsbasis (Directory Information Base, DIB) bezeichnet. Ein Verzeichnisbenutzer, bei dem es sich um einen Menschen oder eine andere Entität handeln kann, greift über einen Client (oder Verzeichnisbenutzeragenten (Directory User Agent, DUA)) auf das Verzeichnis zu. Der Client interagiert im Namen des Verzeichnisbenutzers mit einem oder mehreren Servern (oder Verzeichnissystemagenten (Directory System Agents, DSA)). Ein Server hält ein Fragment der DIB vor.
Die DIB enthält zwei Klassen von Informationen:
1) Benutzerinformationen (z. B. Informationen, die von Benutzern
bereitgestellt und verwaltet werden). Abschnitt 2 beschreibt
das Modell der Benutzerinformationen.
2) administrative und betriebliche Informationen (z. B.
Informationen, die zur Verwaltung und/oder zum Betrieb des
Verzeichnisses verwendet werden). Abschnitt 3 beschreibt das
Modell der administrativen und betrieblichen
Verzeichnisinformationen.
Diese beiden Modelle, die als allgemeine Verzeichnisinformationsmodelle bezeichnet werden, beschreiben, wie Informationen im Verzeichnis dargestellt werden. Sie bilden einen Rahmen für weitere Informationsmodelle. Abschnitt 4 behandelt das Unterschema-Informationsmodell und die Unterschema-Ermittlung. Abschnitt 5 behandelt das DSA-(Server-)Informationsmodell.
Andere X.500-Informationsmodelle (beispielsweise Informationsmodelle für Zugriffssteuerung, Verteilungswissen und Replikationswissen) können für die Verwendung in LDAP angepasst werden. Die Spezifikation, wie diese Modelle auf LDAP anzuwenden sind, bleibt zukünftigen Dokumenten vorbehalten.
1.1. Beziehung zu anderen LDAP-Spezifikationen
Dieses Dokument ist ein integraler Bestandteil der technischen LDAP-Spezifikation [RFC4510], welche die zuvor in RFC 3377 definierte technische LDAP-Spezifikation vollständig obsoletiert.
Dieses Dokument obsoletiert die Abschnitte 3.2 und 3.4 von RFC 2251 sowie Teile der Abschnitte 4 und 6. Anhang A.1 fasst die Änderungen an diesen Abschnitten zusammen. Der verbleibende Teil von RFC 2251 wird durch die Dokumente [RFC4511], [RFC4513] und [RFC4510] obsoletiert.
Dieses Dokument obsoletiert die Abschnitte 4, 5 und 7 von RFC 2252. Anhang A.2 fasst die Änderungen an diesen Abschnitten zusammen. Der verbleibende Teil von RFC 2252 wird durch [RFC4517] obsoletiert.
Dieses Dokument obsoletiert die Abschnitte 5.1, 5.2, 7.1 und 7.2 von RFC 2256. Anhang A.3 fasst die Änderungen an diesen Abschnitten zusammen. Der verbleibende Teil von RFC 2256 wird durch [RFC4519] und [RFC4517] obsoletiert.
Dieses Dokument obsoletiert RFC 3674 vollständig. Anhang A.4 fasst die Änderungen seit RFC 3674 zusammen.
1.2. Beziehung zu X.501
Dieses Dokument übernimmt Material aus [X.501] mit und ohne Anpassung, soweit dies zur Beschreibung dieses Protokolls erforderlich ist. Diese Anpassungen (und alle weiteren hier enthaltenen Unterschiede) gelten für dieses Protokoll und nur für dieses Protokoll.
1.3. Konventionen
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind entsprechend der Beschreibung in BCP 14 [RFC2119] auszulegen.
Schemadefinitionen werden in LDAP-Beschreibungsformaten (wie in Abschnitt 4.1 definiert) angegeben. Die hier angegebenen Definitionen sind zur besseren Lesbarkeit formatiert (mit Zeilenumbrüchen versehen). Die in diesen Definitionen referenzierten Übereinstimmungsregeln und LDAP-Syntaxen sind in [RFC4517] spezifiziert.
1.4. Gemeinsame ABNF-Produktionen
Mehrere Syntaxen in diesem Dokument werden mithilfe der erweiterten Backus-Naur-Form (Augmented Backus-Naur Form, ABNF) [RFC4234] beschrieben. Diese Syntaxen (sowie eine Reihe von in anderen Dokumenten definierten Syntaxen) beruhen auf den folgenden gemeinsamen Produktionen:
keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""")
SHARP = %x23 ; octothorpe (or sharp sign) ("#")
DOLLAR = %x24 ; dollar sign ("$")
SQUOTE = %x27 ; single quote ("'")
LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",")
HYPHEN = %x2D ; hyphen ("-")
DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (";")
LANGLE = %x3C ; left angle bracket ("<")
EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket (">")
ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}"
; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
OCTET = %x00-FF ; Any octet (8-bit data unit)
Objektbezeichner (OIDs) [X.680] werden in LDAP in einem Punkt-Dezimalformat dargestellt, das der folgenden ABNF entspricht:
numericoid = number 1*( DOT number )
Kurznamen, auch als Deskriptoren bezeichnet, werden als besser lesbare Aliase für Objektbezeichner verwendet. Bei Kurznamen wird die Groß- und Kleinschreibung nicht berücksichtigt; sie entsprechen der folgenden ABNF:
descr = keystring
Wenn entweder ein Objektbezeichner oder ein Kurzname angegeben werden kann, wird die folgende Produktion verwendet:
oid = descr / numericoid
Während die Form
Implementierungen SHOULD mehrdeutig verwendete Kurznamen (Deskriptoren) (wie oben erörtert) als nicht erkannt behandeln.
Kurznamen (Deskriptoren) werden in Abschnitt 6.2 ausführlicher behandelt. 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. 3. Administrative und betriebliche Verzeichnisinformationen
Dieser Abschnitt behandelt ausgewählte Aspekte des Modells administrativer und betrieblicher Informationen des X.500-Verzeichnisses [X.501]. LDAP-Implementierungen DÜRFEN (MAY) weitere Aspekte dieses Modells unterstützen.
3.1. Teilbäume
Nach [X.501] gilt:
Ein Teilbaum (subtree) ist eine Sammlung von Objekt- und Aliaseinträgen an den Knoten eines Baums. Teilbäume enthalten keine Untereinträge. Das Präfix sub in subtree betont, dass der Basis- oder Wurzelknoten dieses Baums gewöhnlich der Wurzel des DIT untergeordnet ist.
Ein Teilbaum beginnt an einem Knoten und reicht bis zu einer identifizierbaren unteren Grenze, möglicherweise bis zu den Blättern. Er ist stets in einem Kontext definiert, der ihn implizit begrenzt. Beispielsweise werden Knoten und untere Grenzen eines Teilbaums für einen replizierten Bereich durch einen Namenskontext begrenzt.
3.2. Untereinträge
Ein Untereintrag ist eine „besondere, dem Verzeichnis bekannte Art von Eintrag, die Informationen zu einem Teilbaum oder einer Teilbaumverfeinerung enthält“ [X.501]. Untereinträge speichern im Verzeichnis Informationen für die in [X.501] definierten administrativen und betrieblichen Zwecke. Ihre LDAP-Verwendung beschreibt [RFC3672].
„(sub)entry“ bedeutet hier, dass Server mit X.500(93)-Modellen gemäß [RFC3672] einen Untereintrag verwenden und andere Server ihn durch einen Objekteintrag der passenden, gewöhnlich mit ihm verwendeten Hilfsklasse nachbilden (z. B. 'subschema' für Unterschema-Untereinträge). Der RDN dieses Objekteintrags MUSS (SHALL) aus einem Wert des Attributs 'cn' (commonName) [RFC4519] gebildet werden (alle Untereinträge werden mit 'cn' benannt).
3.3. Das Attribut 'objectClass'
Jeder DIT-Eintrag besitzt ein Attribut 'objectClass'.
( 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
Die Übereinstimmungsregel 'objectIdentifierMatch' und die Syntax OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) sind in [RFC4517] definiert.
'objectClass' gibt die Objektklassen eines Eintrags an, die unter anderem zusammen mit dem steuernden Schema dessen zulässige Attribute bestimmen. Clients können Werte ändern, das Attribut selbst aber nicht entfernen.
Server nach X.500(93) MÜSSEN (SHALL) Änderungen beschränken, damit die grundlegende strukturelle Klasse des Eintrags nicht geändert wird; eine 'person' kann also nicht zu einem 'country' werden.
Beim Erstellen eines Eintrags oder Hinzufügen eines 'objectClass'-Werts MÜSSEN (SHALL) alle noch fehlenden Oberklassen der genannten Klassen implizit hinzugefügt werden. Ist die Hilfsklasse 'x-a' Unterklasse von 'x-b', bewirkt das Hinzufügen von 'x-a' somit auch das implizite Hinzufügen von 'x-b'.
Server MÜSSEN (SHALL) Änderungen beschränken, damit Oberklassen verbleibender 'objectClass'-Werte nicht gelöscht werden. Ist 'x-a' Unterklasse der Hilfsklasse 'x-b' und enthält 'objectClass' beide Werte, ist das alleinige Löschen von 'x-b' ein Fehler.
3.4. Betriebsattribute
Betriebsattribute werden von Servern für administrative und betriebliche Zwecke verwendet oder gepflegt. [X.501] nennt drei Arten: Verzeichnis-Betriebsattribute, DSA-übergreifend gemeinsam genutzte Betriebsattribute und DSA-spezifische Betriebsattribute.
Ein Verzeichnis-Betriebsattribut repräsentiert betriebliche und/oder administrative Informationen im Verzeichnisinformationsmodell. Dazu gehören vom Server gepflegte Attribute (z. B. 'createTimestamp') und Attribute mit vom Benutzer administrierten Werten (z. B. 'ditContentRules').
Ein gemeinsam genutztes DSA-Betriebsattribut repräsentiert zwischen DSAs geteilte Informationen des DSA-Informationsmodells. Ein DSA-spezifisches Betriebsattribut repräsentiert DSA-spezifische Informationen (mitunter aus geteilten Informationen abgeleitet; z. B. 'namingContexts'). Details enthält [X.501].
Betriebsattribute sind normalerweise unsichtbar und werden nur auf ausdrückliche namentliche Anforderung in Suchergebnissen zurückgegeben. Nicht alle sind durch Benutzer änderbar.
Einträge können unter anderem enthalten:
- creatorsName: Distinguished Name des Benutzers, der den Eintrag hinzufügte;
- createTimestamp: Zeitpunkt des Hinzufügens;
- modifiersName: Distinguished Name des letzten Ändernden;
- modifyTimestamp: Zeitpunkt der letzten Änderung.
Server SOLLTEN (SHOULD) diese vier Attribute für alle DIT-Einträge pflegen.
3.4.1. 'creatorsName'
Dieses Attribut erscheint in mittels Protokoll hinzugefügten Einträgen (z. B. Add-Operation). Sein Wert ist der Distinguished Name des Erstellers.
( 2.5.18.3 NAME 'creatorsName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
'distinguishedNameMatch' und DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) sind in [RFC4517] definiert.
3.4.2. 'createTimestamp'
Dieses Attribut erscheint in mittels Protokoll hinzugefügten Einträgen (z. B. Add-Operation). Sein Wert ist der Zeitpunkt des Hinzufügens.
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
'generalizedTimeMatch', 'generalizedTimeOrderingMatch' und GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) sind in [RFC4517] definiert.
3.4.3. 'modifiersName'
Dieses Attribut erscheint in mittels Protokoll geänderten Einträgen (z. B. Modify-Operation). Sein Wert ist der Distinguished Name des letzten Ändernden.
( 2.5.18.4 NAME 'modifiersName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
'distinguishedNameMatch' und DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) sind in [RFC4517] definiert.
3.4.4. 'modifyTimestamp'
Dieses Attribut erscheint in mittels Protokoll geänderten Einträgen (z. B. Modify-Operation). Sein Wert ist der Zeitpunkt der letzten Änderung.
( 2.5.18.2 NAME 'modifyTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
'generalizedTimeMatch', 'generalizedTimeOrderingMatch' und GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) sind in [RFC4517] definiert.
3.4.5. 'structuralObjectClass'
Dieses Attribut gibt die strukturelle Objektklasse des Eintrags an.
( 2.5.21.9 NAME 'structuralObjectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
'objectIdentifierMatch' und OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) sind in [RFC4517] definiert.
3.4.6. 'governingStructureRule'
Dieses Attribut gibt die für den Eintrag maßgebliche Strukturregel an.
( 2.5.21.10 NAME 'governingStructureRule'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
'integerMatch' und INTEGER (1.3.6.1.4.1.1466.115.121.1.27) sind in [RFC4517] definiert. 4. Verzeichnisschema
Wie in [X.501] definiert:
Das Verzeichnisschema ist eine Menge von Definitionen und
Beschränkungen hinsichtlich der Struktur des DIT, der möglichen
Arten der Benennung von Einträgen, der Informationen, die in einem
Eintrag enthalten sein können, der zur Darstellung dieser
Informationen verwendeten Attribute und ihrer Anordnung in
Hierarchien zur Vereinfachung der Suche und des Abrufs der
Informationen sowie der Arten, wie Attributwerte in
Attributwertbehauptungen und Behauptungen von Übereinstimmungsregeln
abgeglichen werden können.
HINWEIS 1 - Das Schema ermöglicht dem Verzeichnissystem zum Beispiel:
- die Erstellung untergeordneter Einträge mit der falschen
Objektklasse zu verhindern (z. B. ein Land als untergeordneter
Eintrag einer Person);
- das Hinzufügen von Attributtypen zu einem Eintrag zu verhindern,
die für die Objektklasse ungeeignet sind (z. B. eine Seriennummer
zum Eintrag einer Person);
- das Hinzufügen eines Attributwerts mit einer Syntax zu verhindern,
die nicht der für den Attributtyp definierten Syntax entspricht
(z. B. eine druckbare Zeichenfolge zu einer Bitfolge).
Formal umfasst das Verzeichnisschema eine Menge von:
a) Namensformdefinitionen, die elementare Benennungsbeziehungen für
strukturelle Objektklassen definieren;
b) DIT-Strukturregeldefinitionen, die festlegen, welche Namen
Einträge haben dürfen und wie die Einträge im DIT miteinander in
Beziehung stehen dürfen;
c) DIT-Inhaltsregeldefinitionen, welche die Spezifikation der für
Einträge zulässigen Attribute über die durch die strukturellen
Objektklassen der Einträge angegebenen Attribute hinaus erweitern;
d) Objektklassendefinitionen, welche die grundlegende Menge der
obligatorischen und optionalen Attribute definieren, die in einem
Eintrag einer bestimmten Klasse vorhanden sein müssen bzw.
vorhanden sein dürfen, und die angeben, welche Art von
Objektklasse definiert wird;
e) Attributtypdefinitionen, welche den Objektbezeichner, unter dem
ein Attribut bekannt ist, seine Syntax, die zugehörigen
Übereinstimmungsregeln, die Eigenschaft als Betriebsattribut und
gegebenenfalls dessen Typ, die Eigenschaft als kollektives
Attribut, die Zulässigkeit mehrerer Werte und die etwaige
Ableitung von einem anderen Attributtyp bestimmen;
f) Definitionen von Übereinstimmungsregeln, welche
Übereinstimmungsregeln definieren.
Und in LDAP:
g) LDAP-Syntaxdefinitionen, welche die in LDAP verwendeten
Codierungen definieren.
4.1. Schemadefinitionen
Die Schemadefinitionen in diesem Abschnitt werden mithilfe von ABNF beschrieben und beruhen auf den in Abschnitt 1.2 angegebenen gemeinsamen Produktionen sowie auf den folgenden Produktionen:
noidlen = numericoid [ LCURLY len RCURLY ]
len = number
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )
extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
; Any UTF-8 encoded Unicode character
; except %x27 ("\'") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB
; Any ASCII character except %x27 ("\'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F
Die Schemadefinitionen in diesem Abschnitt verwenden außerdem eine Reihe gemeinsamer Begriffe.
Das Feld NAME stellt eine Menge von Kurznamen (Deskriptoren) bereit, die als Aliase für den OID verwendet werden sollen.
Das Feld DESC ermöglicht dem Verzeichnisadministrator und/oder Implementierer optional die Angabe einer beschreibenden Zeichenfolge. Spezifikationen können zwar eine beschreibende Zeichenfolge vorschlagen, es besteht jedoch keine Anforderung, die vorgeschlagene (oder irgendeine) beschreibende Zeichenfolge zu verwenden.
Das Feld OBSOLETE zeigt, sofern vorhanden, an, dass das Element nicht aktiv ist.
Implementierer sollten beachten, dass zukünftige Versionen dieses
Dokuments diese Definitionen um zusätzliche Begriffe erweitern können.
Begriffe, deren Bezeichner mit "X-" beginnt, sind für private
Experimente reserviert; ihnen folgen die Token
4.1.1. Objektklassendefinitionen
Objektklassendefinitionen werden gemäß der folgenden ABNF geschrieben:
ObjectClassDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
Dabei gilt:
4.1.2. Attributtypen
Attributtypdefinitionen werden gemäß der folgenden ABNF geschrieben:
AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; supertype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions
usage = "userApplications" / ; user
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational
Dabei gilt:
Jede Attributtypbeschreibung muss mindestens eines der Felder SUP oder SYNTAX enthalten. Wenn kein Feld SYNTAX angegeben ist, übernimmt die Attributtypbeschreibung ihren Wert vom Obertyp.
Wenn das Feld SUP angegeben ist, übernehmen die Felder EQUALITY, ORDERING und SUBSTRING, sofern nicht angegeben, ihren Wert vom Obertyp.
Die standardmäßige Verwendung userApplications zeigt an, dass Attribute dieses Typs Benutzerinformationen darstellen. Das heißt, es handelt sich um Benutzerattribute.
Eine Verwendung von directoryOperation, distributedOperation oder dSAOperation zeigt an, dass Attribute dieses Typs betriebliche und/oder administrative Informationen darstellen. Das heißt, es handelt sich um Betriebsattribute.
Die Verwendung directoryOperation zeigt an, dass das Attribut dieses Typs ein Verzeichnisbetriebsattribut ist. Die Verwendung distributedOperation zeigt an, dass das Attribut dieses Typs ein von DSAs gemeinsam genutztes Betriebsattribut ist. Die Verwendung dSAOperation zeigt an, dass das Attribut dieses Typs ein DSA-spezifisches Betriebsattribut ist.
COLLECTIVE erfordert die Verwendung userApplications. Die Verwendung kollektiver Attributtypen in LDAP wird in [RFC3671] behandelt.
NO-USER-MODIFICATION erfordert eine betriebliche Verwendung.
Zu beachten ist, dass
Dieses Dokument präzisiert die Schemabeschreibung von X.501, indem es
verlangt, dass das Feld SYNTAX in einer
Eine vorgeschlagene minimale Obergrenze für die Anzahl der Zeichen in einem Wert mit zeichenfolgenbasierter Syntax bzw. die Anzahl der Bytes in einem Wert für alle anderen Syntaxen kann angegeben werden, indem diese Grenze in einer Attributtypbeschreibung in geschweiften Klammern an den OBJECT IDENTIFIER der Syntax angehängt wird. Diese Grenze ist nicht Bestandteil des Syntaxnamens selbst. Beispielsweise empfiehlt "1.3.6.4.1.1466.0{64}", dass Serverimplementierungen eine Zeichenfolge mit einer Länge von 64 Zeichen zulassen sollten, wenngleich sie längere Zeichenfolgen zulassen können. Zu beachten ist, dass ein einzelnes Zeichen der Directory String-Syntax in mehr als einem Oktett codiert sein kann, da UTF-8 [RFC3629] eine Codierung variabler Länge ist.
4.1.3. Übereinstimmungsregeln
Übereinstimmungsregeln werden bei der Ausführung von Attributwertbehauptungen verwendet, beispielsweise bei der Ausführung einer Compare-Operation. Sie werden außerdem bei der Auswertung von Suchfiltern, bei der Bestimmung der einzelnen Werte, die während einer Modify-Operation hinzugefügt oder gelöscht werden sollen, sowie beim Vergleich von Distinguished Names verwendet.
Jede Übereinstimmungsregel wird durch einen Objektbezeichner (OID) und optional durch einen oder mehrere Kurznamen (Deskriptoren) identifiziert.
Definitionen von Übereinstimmungsregeln werden gemäß der folgenden ABNF geschrieben:
MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; assertion syntax
extensions WSP RPAREN ; extensions
Dabei gilt:
Eine Verwendung einer Übereinstimmungsregel führt die Attributtypen auf, die für die Verwendung mit einem extensibleMatch-Suchfilter geeignet sind.
Beschreibungen der Verwendung von Übereinstimmungsregeln werden gemäß der folgenden ABNF geschrieben:
MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "APPLIES" SP oids ; attribute types
extensions WSP RPAREN ; extensions
Dabei gilt:
4.1.5. LDAP-Syntaxen
LDAP-Syntaxen von Werten (Attribut- und Behauptungswerten) werden mittels ASN.1 [X.680] beschrieben und haben optional eine Oktettzeichenketten- Kodierung, die als LDAP-spezifische Kodierung bezeichnet wird. Üblicherweise ist die LDAP-spezifische Kodierung auf eine Zeichenfolge aus Unicode- Zeichen [Unicode] in UTF-8-Form [RFC3629] beschränkt.
Jede LDAP-Syntax wird durch einen Objektbezeichner (OID) bezeichnet.
LDAP-Syntaxdefinitionen werden gemäß der folgenden ABNF geschrieben:
SyntaxDescription = LPAREN WSP
numericoid ; object identifier
[ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensions
Dabei gilt:
4.1.6. DIT-Inhaltsregeln
Eine DIT-Inhaltsregel ist eine „Regel, die den Inhalt von Einträgen einer bestimmten strukturellen Objektklasse bestimmt“ [X.501].
Für DIT-Einträge einer bestimmten strukturellen Objektklasse legt eine DIT-Inhaltsregel fest, welchen Hilfsobjektklassen die Einträge angehören dürfen und welche zusätzlichen Attribute (nach Typ) in den Einträgen erforderlich, zulässig oder unzulässig sind.
Die Liste ausgeschlossener Attribute darf kein Attribut enthalten, das in der Regel, der strukturellen Objektklasse oder einer der zulässigen Hilfsobjektklassen als obligatorisch aufgeführt ist.
Jede Inhaltsregel wird durch den Objektbezeichner sowie etwaige Kurznamen (Deskriptoren) der strukturellen Objektklasse bezeichnet, auf die sie anzuwenden ist.
Ein Eintrag darf nur Hilfsobjektklassen angehören, die in der für ihn geltenden Inhaltsregel aufgeführt sind.
Ein Eintrag muss alle Attribute enthalten, die von den Objektklassen, denen er angehört, sowie von der für ihn geltenden Inhaltsregel verlangt werden.
Ein Eintrag darf alle nicht ausgeschlossenen Attribute enthalten, die von den Objektklassen, denen er angehört, zugelassen werden, sowie alle von der für ihn geltenden Inhaltsregel zugelassenen Attribute.
Ein Eintrag darf kein Attribut enthalten, das durch die für ihn geltende Inhaltsregel ausgeschlossen ist.
Für einen Eintrag gilt die DIT-Inhaltsregel, die auf die strukturelle Objektklasse des Eintrags anzuwenden ist, sofern diese Regel im Unterschema vorhanden und aktiv ist (siehe Abschnitt 2.4.2). Ist für die strukturelle Objektklasse des Eintrags keine aktive Regel vorhanden, wird der Inhalt des Eintrags durch die strukturelle Objektklasse (und möglicherweise durch andere Aspekte des Benutzer- und Systemschemas) bestimmt. DIT-Inhaltsregeln für Oberklassen der strukturellen Objektklasse eines Eintrags sind auf diesen Eintrag nicht anwendbar.
Beschreibungen von DIT-Inhaltsregeln werden gemäß der folgenden ABNF geschrieben:
DITContentRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "AUX" SP oids ] ; auxiliary object classes
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions
Dabei gilt:
MUST, MAY und NOT geben jeweils Listen von Attributtypen an, deren
Vorhandensein in Einträgen, die dieser DIT-Inhaltsregel unterliegen,
erforderlich, zulässig beziehungsweise ausgeschlossen ist.
<extensions> beschreibt Erweiterungen.
4.1.7. DIT-Strukturregeln und Namensformen
Mitunter ist es wünschenswert, anhand ihrer strukturellen Objektklasse zu regeln, an welcher Stelle Objekt- und Alias-Einträge in der DIT platziert und wie sie benannt werden dürfen.
4.1.7.1. DIT-Strukturregeln
Eine DIT-Strukturregel ist eine „Regel, die die Struktur der DIT bestimmt, indem sie eine zulässige Beziehung zwischen übergeordneten und untergeordneten Einträgen festlegt. Eine Strukturregel setzt eine Namensform und damit eine strukturelle Objektklasse zu übergeordneten Strukturregeln in Beziehung. Dadurch können Einträge der durch die Namensform bezeichneten strukturellen Objektklasse in der DIT als untergeordnete Einträge von Einträgen existieren, die den angegebenen übergeordneten Strukturregeln unterliegen“ [X.501].
Beschreibungen von DIT-Strukturregeln werden gemäß der folgenden ABNF geschrieben:
DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules
extensions WSP RPAREN ; extensions
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number
Dabei gilt:
Sind keine übergeordneten Regeln bezeichnet, ist die DIT-Strukturregel auf einen autonomen Verwaltungspunkt anzuwenden (z. B. den Wurzelknoten des vom Unterschema gesteuerten Teilbaums) [X.501].
4.1.7.2. Namensformen
Eine Namensform „legt einen zulässigen RDN für Einträge einer bestimmten strukturellen Objektklasse fest. Eine Namensform bezeichnet eine benannte Objektklasse und einen oder mehrere Attributtypen, die zur Namensgebung (d. h. für den RDN) verwendet werden. Namensformen sind grundlegende Spezifikationselemente, die bei der Definition von DIT-Strukturregeln verwendet werden“ [X.501].
Jede Namensform gibt die zu benennende strukturelle Objektklasse, eine Menge erforderlicher Attributtypen und eine Menge zulässiger Attributtypen an. Ein bestimmter Attributtyp darf nicht in beiden Mengen enthalten sein.
Einträge, die der Form unterliegen, müssen unter Verwendung jeweils eines Werts aus jedem erforderlichen Attributtyp und null oder mehr Werten aus den zulässigen Attributtypen benannt werden.
Jede Namensform wird durch einen Objektbezeichner (OID) und optional einen oder mehrere Kurznamen (Deskriptoren) bezeichnet.
Beschreibungen von Namensformen werden gemäß der folgenden ABNF geschrieben:
NameFormDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "OC" SP oid ; structural object class
SP "MUST" SP oids ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions
Dabei gilt:
Alle Attributtypen in den Listen der erforderlichen ("MUST") und zulässigen ("MAY") Attribute müssen voneinander verschieden sein.
4.2. Unterschema-Untereinträge
Unterschema-(Unter-)Einträge werden zur Verwaltung von Informationen über das Verzeichnisschema verwendet. Ein einzelner Unterschema-(Unter-)Eintrag enthält alle Schemadefinitionen (siehe Abschnitt 4.1), die von Einträgen in einem bestimmten Teil des Verzeichnisbaums verwendet werden.
Server, die X.500(93)-Modellen folgen, sollten (SHOULD) das Unterschema mittels der X.500-Unterschemamechanismen implementieren (wie in Abschnitt 12 von [X.501] ausführlich beschrieben), sodass es sich nicht um gewöhnliche Objekteinträge, sondern um Untereinträge handelt (siehe Abschnitt 3.2). LDAP-Clients sollten nicht (SHOULD NOT) davon ausgehen, dass Server andere Aspekte des X.500-Unterschemas implementieren.
Server dürfen (MAY) Änderungen am Unterschema zulassen. Verfahren zur Änderung des Unterschemas werden in Abschnitt 14.5 von [X.501] behandelt.
Ein Server, der Einträge als Master verwaltet und Clients die Änderung dieser Einträge gestattet, muss (SHALL) diese Unterschema-(Unter-)Einträge implementieren und den Zugriff darauf ermöglichen; dazu gehört die Bereitstellung eines Attributs 'subschemaSubentry' in jedem änderbaren Eintrag. Dadurch können Clients ermitteln, welche Attribute und Objektklassen vorhanden sein dürfen. Es wird dringend empfohlen (RECOMMENDED), dass auch alle anderen Server dies implementieren.
Der Wert des Attributs 'subschemaSubentry' ist der Name des Unterschema-(Unter-)Eintrags, der das für den Eintrag maßgebliche Unterschema enthält.
( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Die Übereinstimmungsregel 'distinguishedNameMatch' und die Syntax DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) sind in [RFC4517] definiert.
Das Unterschema wird in (Unter-)Einträgen gespeichert, die der Hilfsobjektklasse subschema angehören.
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
Das Betriebsattribut 'ldapSyntaxes' darf ebenfalls in Unterschemaeinträgen vorhanden sein.
Server dürfen (MAY) in Unterschema-(Unter-)Einträgen zusätzliche Attribute bereitstellen, die in anderen Dokumenten beschrieben sind.
Server sollten (SHOULD) die Attribute 'createTimestamp' und 'modifyTimestamp' in Unterschema-(Unter-)Einträgen bereitstellen, damit Clients ihre Zwischenspeicher mit Schemainformationen verwalten können.
Die folgenden Unterabschnitte enthalten Attributtypdefinitionen für jeden der Schemadefinitions-Attributtypen. 4.2.1. 'objectClasses'
Dieses Attribut enthält Definitionen von Objektklassen.
( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' und ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) sind in [RFC4517] definiert.
4.2.2. 'attributeTypes'
Dieses Attribut enthält Definitionen von Attributtypen.
( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' und AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) sind in [RFC4517] definiert.
4.2.3. 'matchingRules'
Dieses Attribut enthält Definitionen von Übereinstimmungsregeln.
( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' und MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) sind in [RFC4517] definiert.
4.2.4 'matchingRuleUse'
Dieses Attribut enthält Definitionen der Verwendung von Übereinstimmungsregeln.
( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' und MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) sind in [RFC4517] definiert.
4.2.5. 'ldapSyntaxes'
Dieses Attribut enthält Definitionen von LDAP-Syntaxen.
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' und SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) sind in [RFC4517] definiert.
4.2.6. 'dITContentRules'
Dieses Attribut listet die im Unterschema vorhandenen DIT-Inhaltsregeln auf.
( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' und DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) sind in [RFC4517] definiert.
4.2.7. 'dITStructureRules'
Dieses Attribut listet die im Unterschema vorhandenen DIT-Strukturregeln auf.
( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation )
'integerFirstComponentMatch' und DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) sind in [RFC4517] definiert.
4.2.8 'nameForms'
Dieses Attribut listet die geltenden Namensformen auf.
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )
'objectIdentifierFirstComponentMatch' und NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) sind in [RFC4517] definiert.
4.3. Objektklasse 'extensibleObject'
Die Hilfsobjektklasse 'extensibleObject' erlaubt ihren Einträgen, beliebige Benutzerattribute zu enthalten. Ihre zulässigen Attributtypen sind implizit alle Attributtypen mit der Verwendung userApplications.
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )
Die erforderlichen Attribute der anderen Objektklassen des Eintrags bleiben erforderlich; ausgeschlossene Attribute bleiben unzulässig.
4.4. Ermittlung des Unterschemas
Zum Ermitteln des DN des Unterschema-(Unter-)Eintrags, der das für einen bestimmten Eintrag maßgebliche Unterschema enthält, liest ein Client dessen Betriebsattribut 'subschemaSubentry'. Zum Lesen von Schemaattributen MÜSSEN (MUST) Clients eine Search-Operation [RFC4511] ausführen: baseObject ist der DN des Unterschema-(Unter-)Eintrags, scope ist baseObject, filter ist "(objectClass=subschema)" [RFC4515] und attributes listet die gewünschten Schemaattribute auf. Hinweis: Der Filter "(objectClass=subschema)" ermöglicht LDAP-Servern mit X.500-Gateway, eine Anforderung von Untereintragsinformationen zu erkennen.
Clients SOLLTEN NICHT (SHOULD NOT) annehmen, dass ein veröffentlichtes Unterschema vollständig ist, der Server alle veröffentlichten Schemaelemente unterstützt oder kein unveröffentlichtes Element unterstützt.
- DSA-(Server-)Informationsmodell
LDAP nimmt an, dass ein oder mehrere Server gemeinsam Zugriff auf einen DIT bereitstellen. Der Server mit der ursprünglichen Information heißt deren Master. Server mit Kopien heißen Spiegelungs- ("shadowing") oder Zwischenspeicherungsserver ("caching").
Nach [X.501] gilt:
Kontextpräfix (context prefix): Folge der RDNs von der DIT-Wurzel zum Anfangsknoten eines Namenskontexts; entspricht dem Distinguished Name dieses Knotens.
Namenskontext (naming context): Teilbaum von Einträgen in einem einzelnen Master-DSA.
Ein Namenskontext ist somit die größte Sammlung von Einträgen, die bei einem von einem bestimmten Server verwalteten Eintrag beginnt und alle Untergeordneten bis zu Einträgen umfasst, die von anderen Servern verwaltet werden. Das Kontextpräfix ist der Name des Anfangseintrags.
Die DIT-Wurzel ist ein DSA-spezifischer Eintrag (DSA-specific Entry, DSE) und gehört zu keinem Namenskontext oder Teilbaum; jeder Server hat im Wurzel-DSE andere Attributwerte.
5.1. Anforderungen an serverspezifische Daten
Ein LDAP-Server MUSS (SHALL) Informationen über sich und weitere serverspezifische Informationen bereitstellen. Sie werden als Attributgruppe im Wurzel-DSE dargestellt, der mit dem DN aus null RDNs benannt ist (in [RFC4514] als Zeichenkette der Länge null dargestellt).
Vorbehaltlich Zugriffskontrolle und anderer Einschränkungen sind diese Attribute über eine Search-Operation [RFC4511] mit leerem baseObject, scope baseObject, filter "(objectClass=*)" [RFC4515] und den gewünschten Namen in attributes abrufbar. Wurzel-DSE-Attribute sind Betriebsattribute und werden nur auf namentliche Anforderung zurückgegeben.
Der Wurzel-DSE DARF NICHT (SHALL NOT) in eine an der Wurzel beginnende Teilbaumsuche einbezogen werden.
Server können Clients gegebenenfalls die Änderung seiner Attribute erlauben.
Folgende Wurzel-DSE-Attribute werden nachstehend definiert; andere Dokumente können weitere definieren.
- altServer: alternative Server;
- namingContexts: Namenskontexte;
- supportedControl: erkannte LDAP-Steuerelemente;
- supportedExtension: erkannte erweiterte LDAP-Operationen;
- supportedFeatures: erkannte LDAP-Funktionen;
- supportedLDAPVersion: unterstützte LDAP-Versionen;
- supportedSASLMechanisms: erkannte Mechanismen der Simple Authentication and Security Layers (SASL) [RFC4422].
Die Werte können von sitzungsbezogenen und anderen Faktoren abhängen. Ein Server mit SASL EXTERNAL listet "EXTERNAL" etwa möglicherweise nur, wenn die Clientidentität durch eine niedrigere Schicht festgestellt wurde. Siehe [RFC4513].
Der Wurzel-DSE kann auch 'subschemaSubentry' enthalten. Dann verweist es auf den Unterschema-(Unter-)Eintrag mit dem für den Wurzel-DSE maßgeblichen Schema. Clients SOLLTEN NICHT (SHOULD NOT) annehmen, dass dieser auch andere vom Server gehaltene Einträge steuert. Abschnitt 4.4 enthält das allgemeine Ermittlungsverfahren. 5.1.1. 'altServer'
Das Attribut 'altServer' führt URIs auf, die auf alternative Server verweisen, die kontaktiert werden können, wenn dieser Server nicht mehr verfügbar ist. URIs für Server, die LDAP implementieren, werden gemäß [RFC4516] geschrieben. Andere Arten von URIs können bereitgestellt werden. Kennt der Server keine anderen verwendbaren Server, ist dieses Attribut nicht vorhanden. Clients können diese Informationen für den Fall zwischenspeichern, dass ihr bevorzugter Server später nicht mehr verfügbar ist.
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation )
Die Syntax IA5String (1.3.6.1.4.1.1466.115.121.1.26) ist in [RFC4517] definiert.
5.1.2. 'namingContexts'
Das Attribut 'namingContexts' führt die Kontextpräfixe der Namenskontexte auf, für die der Server ganz oder teilweise die Master- oder eine Schattenkopie verwaltet. Ist der Server ein DSA der ersten Ebene [X.501], sollte er zusätzlich eine leere Zeichenfolge aufführen, die die Wurzel der DIT bezeichnet. Verwaltet der Server keine Informationen als Master- oder Schattenkopie (z. B. weil er ein LDAP-Gateway zu einem öffentlichen X.500-Verzeichnis ist), ist dieses Attribut nicht vorhanden. Ist der Server der Auffassung, dass er für das gesamte Verzeichnis die Master- oder eine Schattenkopie verwaltet, hat das Attribut genau einen Wert; dieser Wert ist die leere Zeichenfolge, die die Wurzel der DIT bezeichnet.
Dieses Attribut kann beispielsweise dazu verwendet werden, einen geeigneten Eintragsnamen für nachfolgende Operationen mit diesem Server auszuwählen.
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation )
Die Syntax DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) ist in [RFC4517] definiert.
5.1.3. 'supportedControl'
Das Attribut 'supportedControl' führt Objektbezeichner auf, die vom Server unterstützte Anfragesteuerungen [RFC4511] bezeichnen. Unterstützt der Server keine Anfragesteuerungen, ist dieses Attribut nicht vorhanden. Objektbezeichner, die Antwortsteuerungen bezeichnen, müssen nicht aufgeführt werden.
Verfahren zur Registrierung von Objektbezeichnern, die zur Ermittlung von Protokollmechanismen verwendet werden, sind in BCP 64, RFC 4520 [RFC4520] ausführlich beschrieben.
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
Die Syntax OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) ist in [RFC4517] definiert.
5.1.4. 'supportedExtension'
Das Attribut 'supportedExtension' führt Objektbezeichner auf, die vom Server unterstützte erweiterte Operationen [RFC4511] bezeichnen. Unterstützt der Server keine erweiterten Operationen, ist dieses Attribut nicht vorhanden.
Eine erweiterte Operation besteht im Allgemeinen aus einer erweiterten Anfrage und einer erweiterten Antwort, kann aber auch andere Protokolldateneinheiten enthalten, etwa Zwischenantworten. Der der erweiterten Anfrage zugewiesene Objektbezeichner wird zur Bezeichnung der erweiterten Operation verwendet. Andere in der erweiterten Operation verwendete Objektbezeichner müssen nicht als Werte dieses Attributs aufgeführt werden.
Verfahren zur Registrierung von Objektbezeichnern, die zur Ermittlung von Protokollmechanismen verwendet werden, sind in BCP 64, RFC 4520 [RFC4520] ausführlich beschrieben.
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
Die Syntax OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) ist in [RFC4517] definiert.
5.1.5. 'supportedFeatures'
Das Attribut 'supportedFeatures' führt Objektbezeichner auf, die vom Server unterstützte optionale Merkmale bezeichnen. Unterstützt der Server keine ermittelbaren optionalen Merkmale, ist dieses Attribut nicht vorhanden.
( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
Verfahren zur Registrierung von Objektbezeichnern, die zur Ermittlung von Protokollmechanismen verwendet werden, sind in BCP 64, RFC 4520 [RFC4520] ausführlich beschrieben.
Die Syntax OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) und die Übereinstimmungsregel objectIdentifierMatch sind in [RFC4517] definiert.
5.1.6. 'supportedLDAPVersion'
Das Attribut 'supportedLDAPVersion' führt die vom Server unterstützten LDAP-Versionen auf.
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation )
Die Syntax INTEGER (1.3.6.1.4.1.1466.115.121.1.27) ist in [RFC4517] definiert.
5.1.7. 'supportedSASLMechanisms'
Das Attribut 'supportedSASLMechanisms' führt die SASL-Mechanismen [RFC4422] auf, die der Server erkennt und/oder unterstützt [RFC4513]. Der Inhalt dieses Attributs kann vom aktuellen Sitzungszustand abhängen. Unterstützt der Server keine SASL-Mechanismen, ist dieses Attribut nicht vorhanden.
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )
Die Syntax Directory String (1.3.6.1.4.1.1466.115.121.1.15) ist in [RFC4517] definiert.
- Weitere Überlegungen
6.1. Erhaltung von Benutzerinformationen
Es können Syntaxen definiert werden, für die besondere Anforderungen an die Erhaltung des Werts und/oder seiner Wertform (Darstellung) gelten. Beispielsweise kann eine Syntax, die digital signierte Daten enthält, vorschreiben, dass der Server sowohl den vorgelegten Wert als auch dessen Form erhält, um sicherzustellen, dass die Signatur nicht ungültig wird.
Wo solche Anforderungen nicht ausdrücklich festgelegt wurden, sollten (SHOULD) Server den Wert der Benutzerinformationen erhalten, dürfen (MAY) ihn jedoch in einer anderen Form zurückgeben. Ist ein Server nicht in der Lage (oder nicht gewillt), den Wert der Benutzerinformationen zu erhalten, muss (SHALL) er sicherstellen, dass ein gleichwertiger Wert gemäß Abschnitt 2.3 zurückgegeben wird.
6.2. Kurznamen
Kurznamen, auch als Deskriptoren bezeichnet, werden als besser lesbare Aliasse für Objektbezeichner und zur Bezeichnung verschiedener Schemaelemente verwendet. Es wird jedoch nicht erwartet, dass LDAP- Implementierungen mit einer Benutzeroberfläche für Menschen diese Kurznamen (oder die Objektbezeichner, auf die sie verweisen) dem Benutzer anzeigen. Stattdessen würden sie höchstwahrscheinlich Übersetzungen vornehmen, etwa den Kurznamen in einer der lokalen Landessprachen ausdrücken. Beispielsweise könnte der Kurzname "st" (stateOrProvinceName) einem deutschsprachigen Benutzer als "Land" angezeigt werden.
Derselbe Kurzname kann in verschiedenen Unterschemas unterschiedliche Bedeutungen haben, und innerhalb eines bestimmten Unterschemas kann derselbe Kurzname auf verschiedene Objektbezeichner verweisen, die jeweils eine andere Art von Schemaelement bezeichnen.
Implementierungen müssen (MUST) darauf vorbereitet sein, dass derselbe Kurzname in einem Unterschema für verschiedene Arten von Schemaelementen verwendet wird. Das heißt, in einem Unterschema kann es eine Objektklasse 'x-fubar' und einen Attributtyp 'x-fubar' geben.
Implementierungen müssen (MUST) darauf vorbereitet sein, dass derselbe Kurzname in verschiedenen Unterschemas für verschiedene Schemaelemente verwendet wird. Das heißt, es kann zwei Übereinstimmungsregeln 'x-fubar' geben, die sich jeweils in unterschiedlichen Unterschemas befinden.
Verfahren zur Registrierung von Kurznamen (Deskriptoren) sind in BCP 64, RFC 4520 [RFC4520] ausführlich beschrieben.
6.3. Zwischenspeicherung und Spiegelung
Einige Server können zwischengespeicherte Kopien oder Schattenkopien von Einträgen vorhalten, die zur Beantwortung von Such- und Vergleichsanfragen verwendet werden können; werden jedoch Änderungsoperationen angefordert, geben sie Verweise zurück oder kontaktieren andere Server. Server, die Spiegelung oder Zwischenspeicherung durchführen, müssen (MUST) sicherstellen, dass sie keine vom Ursprungsserver für die Daten festgelegten Zugriffskontrollbeschränkungen verletzen.
- Implementierungsrichtlinien
7.1. Richtlinien für Server
Server müssen (MUST) alle in diesem Dokument definierten Namen von Attributtypen und Objektklassen erkennen, brauchen jedoch, sofern nichts anderes angegeben ist, die zugehörige Funktionalität nicht zu unterstützen. Server sollten (SHOULD) alle Namen von Attributtypen und Objektklassen erkennen, die in den Abschnitten 3 beziehungsweise 4 von [RFC4519] definiert sind.
Server müssen (MUST) sicherstellen, dass Einträge den Benutzer- und Systemschemaregeln oder anderen Datenmodellbeschränkungen entsprechen.
Server dürfen (MAY) DIT-Inhaltsregeln unterstützen. Server dürfen (MAY) DIT-Strukturregeln und Namensformen unterstützen.
Server dürfen (MAY) Alias-Einträge unterstützen.
Server dürfen (MAY) die Objektklasse 'extensibleObject' unterstützen.
Server dürfen (MAY) Untereinträge unterstützen. In diesem Fall müssen (MUST) sie dies gemäß [RFC3672] tun. Server, die keine Untereinträge unterstützen, sollten (SHOULD) Objekteinträge verwenden, um Untereinträge gemäß der ausführlichen Beschreibung in Abschnitt 3.2 nachzubilden.
Server dürfen (MAY) zusätzliche Schemaelemente implementieren. Server sollten (SHOULD) Definitionen aller von ihnen unterstützten Schemaelemente in Unterschema-(Unter-)Einträgen bereitstellen.
7.2. Richtlinien für Clients
Ohne vorherige Vereinbarungen mit Servern sollten Clients nicht (SHOULD NOT) davon ausgehen, dass Server bestimmte Schemaelemente über die in Abschnitt 7.1 genannten hinaus unterstützen. Der Client kann Unterschemainformationen wie in Abschnitt 4.4 beschrieben abrufen.
Clients dürfen (MUST NOT) einen Wert weder als ASN.1 anzeigen noch zu dekodieren versuchen, wenn die Syntax des Werts nicht bekannt ist. Clients dürfen (MUST NOT) nicht annehmen, dass die LDAP-spezifische Zeichenfolgenkodierung auf eine UTF-8-kodierte Zeichenfolge aus Unicode- Zeichen oder eine bestimmte Unicode-Teilmenge (etwa eine druckbare Teilmenge) beschränkt ist, sofern eine solche Beschränkung nicht ausdrücklich angegeben wird. Clients sollten (SHOULD NOT) in einer Anfrage keine Attributwerte senden, die gemäß der für die Attribute definierten Syntax ungültig sind.
- Sicherheitsüberlegungen
Attribute von Verzeichniseinträgen dienen dazu, beschreibende Informationen über die von ihnen dargestellten realen Objekte bereitzustellen. Dabei kann es sich um Personen, Organisationen oder Geräte handeln. In den meisten Ländern gelten Datenschutzgesetze für die Veröffentlichung von Informationen über Personen.
Allgemeine Sicherheitsüberlegungen zum Zugriff auf Verzeichnisinformationen mit LDAP werden in [RFC4511] und [RFC4513] behandelt.
- IANA-Erwägungen
Die Internet Assigned Numbers Authority (IANA) hat die Registrierung der LDAP-Deskriptoren gemäß der folgenden Vorlage aktualisiert:
Betreff: Antrag auf Aktualisierung einer LDAP-Deskriptorregistrierung
Deskriptor (Kurzname): siehe Kommentar
Objektbezeichner: siehe Kommentar
Kontaktperson und E-Mail-Adresse für weitere Informationen:
Kurt Zeilenga <[email protected]>
Verwendung: siehe Kommentar
Spezifikation: RFC 4512
Autor/Änderungsverantwortlicher: IESG
Kommentare:
Die folgenden Deskriptoren (Kurznamen) wurden der Registrierung hinzugefügt.
NAME Typ OID
------------------------ ---- -----------------
governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.9
Die folgenden Deskriptoren (Kurznamen) wurden so aktualisiert, dass
sie auf diesen RFC verweisen.
NAME Typ OID
------------------------ ---- -----------------
alias O 2.5.6.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0
10. Danksagungen
Dieses Dokument beruht teilweise auf RFC 2251 von M. Wahl, T. Howes und S. Kille, RFC 2252 von M. Wahl, A. Coulbeck, T. Howes und S. Kille sowie RFC 2556 von M. Wahl. Diese Dokumente sind sämtlich Ergebnisse der IETF-Arbeitsgruppe Access, Searching and Indexing of Directories (ASID). Dieses Dokument beruht außerdem teilweise auf "The Directory: Models" [X.501], einem Ergebnis der International Telephone Union (ITU). Zusätzlicher Text wurde aus RFC 2253 von M. Wahl, T. Howes und S. Kille übernommen.
Dieses Dokument ist ein Ergebnis der IETF-Arbeitsgruppe LDAP Revision (LDAPBIS).
- Normative Referenzen
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, December 2003.
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594- 2:1994).
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
Anhang A. Änderungen
Dieser Anhang ist nicht normativ.
Dieses Dokument schreibt Teile von RFC 2251, RFC 2252 und RFC 2256 nahezu vollständig neu, um die technische Spezifikation insgesamt klarer zu gestalten. Der Anhang fasst die wesentlichen Änderungen der hier übernommenen Teile zusammen. Für die übrigen Teile siehe [RFC4510], [RFC4511], [RFC4517] und [RFC4519].
A.1. Änderungen gegenüber RFC 2251
Übernommen wurden die Abschnitte 3.2 und 3.4 sowie Teile der Abschnitte 4 und 6.
A.1.1. Abschnitt 3.2 von RFC 2251
Abschnitt 3.2 führte kurz in das von LDAP verwendete X.500-Datenmodell ein. Die frühere Spezifikation stützte sich auf [X.501], erklärte aber die Anpassung der X.500-Modelle an LDAP nicht klar. Dieses Dokument beschreibt sie ausführlicher, insbesondere wo Anpassungen nötig sind.
Abschnitt 3.2.1 beschrieb ein Attribut als „einen Typ mit einem oder mehreren zugeordneten Werten“. Für LDAP ist die Beschreibung als Attributbeschreibung — ein Typ mit null oder mehr Optionen — und einem oder mehreren zugeordneten Werten genauer.
Abschnitt 3.2.2 schrieb objectClasses und attributeTypes in Unterschema-Untereinträgen vor, obwohl X.500(93) sie als optional behandelt. Implementierungen der X.500(93)-Mechanismen stellen gewöhnlich beide bereit, doch die Interoperabilität verlangt dies nicht zwingend von jedem Server. Die Vorgabe wurde zur Übereinstimmung mit X.500(93) entfernt. Außerdem wurde klargestellt, dass das für einen Eintrag maßgebliche Unterschema durch Lesen des von dessen 'subschemaSubentry' referenzierten (Unter-)Eintrags ermittelt wird.
A.1.2. Abschnitt 3.4 von RFC 2251
Abschnitt 3.4 enthielt „serverspezifische Datenanforderungen“. Das Material wurde geändert in Abschnitt 5.1 übernommen.
Änderungen:
- Klarstellung, dass Wurzel-DSE-Attribute neben Zugriffskontrollen „weiteren Einschränkungen“ unterliegen;
- nur erkannte erweiterte Anforderungen müssen in 'supportedExtension' aufgeführt werden;
- nur erkannte Anforderungs-Steuerelemente müssen in 'supportedControl' aufgeführt werden;
- Wurzel-DSE-Attribute sind Betriebsattribute und werden nur auf namentliche Anforderung zurückgegeben;
- nicht alle Wurzel-DSE-Attribute sind benutzeränderbar;
- widersprüchlicher Text zu 'subschemaSubentry' im Wurzel-DSE wurde entfernt. Die frühere Spezifikation sagte, es verweise auf „diesem Server bekannte Unterschemaeinträge (oder Untereinträge)“. Dies widerspricht der beabsichtigten Verwendung und der formalen Definition als einwertiges Attribut [X.501]. Eine einfache, möglicherweise unvollständige Liste ist zudem wenig nützlich. Abschnitt 5.1 legt fest, dass es auf das für den Wurzel-DSE maßgebliche Unterschema verweist. Das allgemeine Ermittlungsverfahren bleibt verfügbar (siehe Abschnitt 4.4).
A.1.3. Abschnitt 4 von RFC 2251
Folgende Teile zum LDAP-Informationsmodell wurden übernommen:
- Beschränkung von Distinguished Values auf Attribute, deren Beschreibungen keine Optionen besitzen (Abschnitt 4.1.3);
- Datenmodellaspekte von Attributtypen (4.1.4), Attributbeschreibungen (4.1.5), Attributen (4.1.8) und Übereinstimmungsregel-Bezeichnern (4.1.9);
- Anforderungen an Benutzerschemata (4.1.6, 4.5.1 und 4.7).
Klarstellungen umfassen:
- Untertypbildung und AttributeDescriptions mit Optionen.
A.1.4. Abschnitt 6 von RFC 2251
Abschnitt 6.1 und der zweite Absatz von Abschnitt 6.2 wurden übernommen.
A.2. Änderungen gegenüber RFC 2252
Dieses Dokument übernimmt die Abschnitte 4, 5 und 7 von RFC 2252.
A.2.1. Abschnitt 4 von RFC 2252
Die Spezifikation wurde auf Augmented BNF [RFC4234] aktualisiert. Die Zeichenkettendarstellung eines OBJECT IDENTIFIER wurde verschärft, um wie in RFC 2252 beschrieben führende Nullen auszuschließen.
Die Syntax
RFC 2252 sagte, die
Die ABNF für eine Zeichenkette in Anführungszeichen (qdstring) wurde aktualisiert, um den Escape-Mechanismus aus Abschnitt 4.3 von RFC 2252 abzubilden.
A.2.2. Abschnitt 5 von RFC 2252
Die dortigen Definitionen von Betriebsattributen wurden übernommen.
'namingContexts' wurde klargestellt: Ein DSA erster Ebene sollte zusätzlich zu anderen Werten "" für die DIT-Wurzel veröffentlichen.
'altServer' kann eine beliebige URI enthalten.
Bei 'supportedExtension' muss ein Server nur die OBJECT IDENTIFIER der erweiterten Anforderungen erkannter erweiterter Operationen auflisten.
Bei 'supportedControl' muss er nur die OBJECT IDENTIFIER erkannter Anforderungs-Steuerelemente auflisten.
Beschreibungen für 'structuralObjectClass' und 'governingStructureRule' wurden hinzugefügt.
Die Definition von 'subschemaSubentry' wurde korrigiert, damit SINGLE-VALUE und NO-USER-MODIFICATION in der richtigen Reihenfolge stehen.
A.2.3. Abschnitt 7 von RFC 2252
Dieser Abschnitt definierte 'subschema' und 'extensibleObject'; die Definitionen wurden in die Abschnitte 4.2 beziehungsweise 4.3 integriert. Seine Implementierungsanforderung an Objektklassen wurde in Abschnitt 7 übernommen.
Das Zusammenwirken von 'extensibleObject' mit ausgeschlossenen Attributen wurde klargestellt.
A.3. Änderungen gegenüber RFC 2256
Dieses Dokument übernimmt die Abschnitte 5.1, 5.2, 7.1 und 7.2 von RFC 2256.
Die Definition von 'objectClass' aus Abschnitt 5.1 wurde in Abschnitt 2.4.1 integriert. „Einer der Werte ist entweder 'top' oder 'alias'“ wurde durch die Aussage ersetzt, dass einer der Werte 'top' ist, da 'alias'-Einträge ebenfalls 'top' angehören.
Die Definition von 'aliasedObjectName' aus Abschnitt 5.2 wurde in Abschnitt 2.6.2 integriert.
Die Definition der Objektklasse 'top' aus Abschnitt 7.1 wurde in Abschnitt 2.4.1 integriert.
Die Definition der Objektklasse 'alias' aus Abschnitt 7.2 wurde in Abschnitt 2.6.1 integriert.
A.4. Änderungen gegenüber RFC 3674
Dieses Dokument nimmt keine wesentliche Änderung an der technischen Spezifikation von 'supportedFeatures' aus RFC 3674 vor.
Anschrift des Herausgebers
Kurt D. Zeilenga OpenLDAP Foundation
EMail: [email protected]
Vollständiger Urheberrechtshinweis
Copyright (C) The Internet Society (2006).
Dieses Dokument unterliegt den in BCP 78 enthaltenen Rechten, Lizenzen und Beschränkungen; soweit dort nichts anderes bestimmt ist, behalten die Autoren alle ihre Rechte.
DIESES DOKUMENT UND DIE DARIN ENTHALTENEN INFORMATIONEN WERDEN „WIE BESEHEN“ BEREITGESTELLT. DER BEITRAGENDE, DIE VON IHM/IHR VERTRETENE ODER IHN/SIE FÖRDERNDE ORGANISATION (FALLS VORHANDEN), THE INTERNET SOCIETY UND THE INTERNET ENGINEERING TASK FORCE LEHNEN ALLE AUSDRÜCKLICHEN ODER STILLSCHWEIGENDEN GARANTIEN AB, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF JEDE GARANTIE, DASS DIE VERWENDUNG DIESER INFORMATIONEN KEINE RECHTE VERLETZT, SOWIE JEDE STILLSCHWEIGENDE GARANTIE DER MARKTGÄNGIGKEIT ODER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.
Geistiges Eigentum
Die IETF nimmt keine Stellung zur Gültigkeit oder zum Umfang von Rechten an geistigem Eigentum oder anderen Rechten, deren Geltung für Implementierung oder Nutzung der beschriebenen Technologie behauptet werden könnte, oder dazu, inwieweit eine Lizenz unter solchen Rechten verfügbar sein könnte; sie erklärt auch nicht, unabhängige Anstrengungen zu deren Ermittlung unternommen zu haben. Verfahren zu Rechten in RFC-Dokumenten stehen in BCP 78 und BCP 79.
Kopien der beim IETF-Sekretariat eingereichten IPR-Offenlegungen, Zusicherungen verfügbarer Lizenzen oder Ergebnisse von Versuchen, eine allgemeine Lizenz oder Erlaubnis zur Nutzung solcher Schutzrechte durch Implementierer oder Benutzer dieser Spezifikation zu erhalten, sind im Online-IPR-Repository der IETF unter http://www.ietf.org/ipr erhältlich.
Die IETF bittet alle Interessierten, sie auf Urheberrechte, Patente, Patentanmeldungen oder andere Schutzrechte hinzuweisen, die für die Implementierung dieses Standards erforderliche Technologie abdecken könnten. Informationen sind an [email protected] zu richten.
Danksagung
Die Tätigkeit des RFC Editor wird durch die IETF Administrative Support Activity (IASA) finanziert.