mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
2916 lines
106 KiB
Plaintext
2916 lines
106 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group K. Zeilenga
|
|||
|
Request for Comments: 4512 OpenLDAP Foundation
|
|||
|
Obsoletes: 2251, 2252, 2256, 3674 June 2006
|
|||
|
Category: Standards Track
|
|||
|
|
|||
|
|
|||
|
Lightweight Directory Access Protocol (LDAP):
|
|||
|
Directory Information Models
|
|||
|
|
|||
|
Status of This Memo
|
|||
|
|
|||
|
This document specifies an Internet standards track protocol for the
|
|||
|
Internet community, and requests discussion and suggestions for
|
|||
|
improvements. Please refer to the current edition of the "Internet
|
|||
|
Official Protocol Standards" (STD 1) for the standardization state
|
|||
|
and status of this protocol. Distribution of this memo is unlimited.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2006).
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
The Lightweight Directory Access Protocol (LDAP) is an Internet
|
|||
|
protocol for accessing distributed directory services that act in
|
|||
|
accordance with X.500 data and service models. This document
|
|||
|
describes the X.500 Directory Information Models, as used in LDAP.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 1]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
1. Introduction ....................................................3
|
|||
|
1.1. Relationship to Other LDAP Specifications ..................3
|
|||
|
1.2. Relationship to X.501 ......................................4
|
|||
|
1.3. Conventions ................................................4
|
|||
|
1.4. Common ABNF Productions ....................................4
|
|||
|
2. Model of Directory User Information .............................6
|
|||
|
2.1. The Directory Information Tree .............................7
|
|||
|
2.2. Structure of an Entry ......................................7
|
|||
|
2.3. Naming of Entries ..........................................8
|
|||
|
2.4. Object Classes .............................................9
|
|||
|
2.5. Attribute Descriptions ....................................12
|
|||
|
2.6. Alias Entries .............................................16
|
|||
|
3. Directory Administrative and Operational Information ...........17
|
|||
|
3.1. Subtrees ..................................................17
|
|||
|
3.2. Subentries ................................................18
|
|||
|
3.3. The 'objectClass' attribute ...............................18
|
|||
|
3.4. Operational Attributes ....................................19
|
|||
|
4. Directory Schema ...............................................22
|
|||
|
4.1. Schema Definitions ........................................23
|
|||
|
4.2. Subschema Subentries ......................................32
|
|||
|
4.3. 'extensibleObject' object class ...........................35
|
|||
|
4.4. Subschema Discovery .......................................35
|
|||
|
5. DSA (Server) Informational Model ...............................36
|
|||
|
5.1. Server-Specific Data Requirements .........................36
|
|||
|
6. Other Considerations ...........................................40
|
|||
|
6.1. Preservation of User Information ..........................40
|
|||
|
6.2. Short Names ...............................................41
|
|||
|
6.3. Cache and Shadowing .......................................41
|
|||
|
7. Implementation Guidelines ......................................42
|
|||
|
7.1. Server Guidelines .........................................42
|
|||
|
7.2. Client Guidelines .........................................42
|
|||
|
8. Security Considerations ........................................43
|
|||
|
9. IANA Considerations ............................................43
|
|||
|
10. Acknowledgements ..............................................44
|
|||
|
11. Normative References ..........................................45
|
|||
|
Appendix A. Changes ...............................................47
|
|||
|
A.1. Changes to RFC 2251 .......................................47
|
|||
|
A.2. Changes to RFC 2252 .......................................49
|
|||
|
A.3. Changes to RFC 2256 .......................................50
|
|||
|
A.4. Changes to RFC 3674 .......................................51
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 2]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
This document discusses the X.500 Directory Information Models
|
|||
|
[X.501], as used by the Lightweight Directory Access Protocol (LDAP)
|
|||
|
[RFC4510].
|
|||
|
|
|||
|
The Directory is "a collection of open systems cooperating to provide
|
|||
|
directory services" [X.500]. The information held in the Directory
|
|||
|
is collectively known as the Directory Information Base (DIB). A
|
|||
|
Directory user, which may be a human or other entity, accesses the
|
|||
|
Directory through a client (or Directory User Agent (DUA)). The
|
|||
|
client, on behalf of the directory user, interacts with one or more
|
|||
|
servers (or Directory System Agents (DSA)). A server holds a
|
|||
|
fragment of the DIB.
|
|||
|
|
|||
|
The DIB contains two classes of information:
|
|||
|
|
|||
|
1) user information (e.g., information provided and administrated
|
|||
|
by users). Section 2 describes the Model of User Information.
|
|||
|
|
|||
|
2) administrative and operational information (e.g., information
|
|||
|
used to administer and/or operate the directory). Section 3
|
|||
|
describes the model of Directory Administrative and Operational
|
|||
|
Information.
|
|||
|
|
|||
|
These two models, referred to as the generic Directory Information
|
|||
|
Models, describe how information is represented in the Directory.
|
|||
|
These generic models provide a framework for other information
|
|||
|
models. Section 4 discusses the subschema information model and
|
|||
|
subschema discovery. Section 5 discusses the DSA (Server)
|
|||
|
Informational Model.
|
|||
|
|
|||
|
Other X.500 information models (such as access control distribution
|
|||
|
knowledge and replication knowledge information models) may be
|
|||
|
adapted for use in LDAP. Specification of how these models apply to
|
|||
|
LDAP is left to future documents.
|
|||
|
|
|||
|
1.1. Relationship to Other LDAP Specifications
|
|||
|
|
|||
|
This document is a integral part of the LDAP technical specification
|
|||
|
[RFC4510], which obsoletes the previously defined LDAP technical
|
|||
|
specification, RFC 3377, in its entirety.
|
|||
|
|
|||
|
This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
|
|||
|
portions of Sections 4 and 6. Appendix A.1 summarizes changes to
|
|||
|
these sections. The remainder of RFC 2251 is obsoleted by the
|
|||
|
[RFC4511], [RFC4513], and [RFC4510] documents.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 3]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2
|
|||
|
summarizes changes to these sections. The remainder of RFC 2252 is
|
|||
|
obsoleted by [RFC4517].
|
|||
|
|
|||
|
This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
|
|||
|
Appendix A.3 summarizes changes to these sections. The remainder of
|
|||
|
RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
|
|||
|
|
|||
|
This document obsoletes RFC 3674 in its entirety. Appendix A.4
|
|||
|
summarizes changes since RFC 3674.
|
|||
|
|
|||
|
1.2. Relationship to X.501
|
|||
|
|
|||
|
This document includes material, with and without adaptation, from
|
|||
|
[X.501] as necessary to describe this protocol. These adaptations
|
|||
|
(and any other differences herein) apply to this protocol, and only
|
|||
|
this protocol.
|
|||
|
|
|||
|
1.3. Conventions
|
|||
|
|
|||
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
document are to be interpreted as described in BCP 14 [RFC2119].
|
|||
|
|
|||
|
Schema definitions are provided using LDAP description formats (as
|
|||
|
defined in Section 4.1). Definitions provided here are formatted
|
|||
|
(line wrapped) for readability. Matching rules and LDAP syntaxes
|
|||
|
referenced in these definitions are specified in [RFC4517].
|
|||
|
|
|||
|
1.4. Common ABNF Productions
|
|||
|
|
|||
|
A number of syntaxes in this document are described using Augmented
|
|||
|
Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a
|
|||
|
number of syntaxes defined in other documents) rely on the following
|
|||
|
common productions:
|
|||
|
|
|||
|
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 " "
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 4]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
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)
|
|||
|
|
|||
|
Object identifiers (OIDs) [X.680] are represented in LDAP using a
|
|||
|
dot-decimal format conforming to the ABNF:
|
|||
|
|
|||
|
numericoid = number 1*( DOT number )
|
|||
|
|
|||
|
Short names, also known as descriptors, are used as more readable
|
|||
|
aliases for object identifiers. Short names are case insensitive and
|
|||
|
conform to the ABNF:
|
|||
|
|
|||
|
descr = keystring
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 5]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Where either an object identifier or a short name may be specified,
|
|||
|
the following production is used:
|
|||
|
|
|||
|
oid = descr / numericoid
|
|||
|
|
|||
|
While the <descr> form is generally preferred when the usage is
|
|||
|
restricted to short names referring to object identifiers that
|
|||
|
identify like kinds of objects (e.g., attribute type descriptions,
|
|||
|
matching rule descriptions, object class descriptions), the
|
|||
|
<numericoid> form should be used when the object identifiers may
|
|||
|
identify multiple kinds of objects or when an unambiguous short name
|
|||
|
(descriptor) is not available.
|
|||
|
|
|||
|
Implementations SHOULD treat short names (descriptors) used in an
|
|||
|
ambiguous manner (as discussed above) as unrecognized.
|
|||
|
|
|||
|
Short Names (descriptors) are discussed further in Section 6.2.
|
|||
|
|
|||
|
2. Model of Directory User Information
|
|||
|
|
|||
|
As [X.501] states:
|
|||
|
|
|||
|
The purpose of the Directory is to hold, and provide access to,
|
|||
|
information about objects of interest (objects) in some 'world'.
|
|||
|
An object can be anything which is identifiable (can be named).
|
|||
|
|
|||
|
An object class is an identified family of objects, or conceivable
|
|||
|
objects, which share certain characteristics. Every object
|
|||
|
belongs to at least one class. An object class may be a subclass
|
|||
|
of other object classes, in which case the members of the former
|
|||
|
class, the subclass, are also considered to be members of the
|
|||
|
latter classes, the superclasses. There may be subclasses of
|
|||
|
subclasses, etc., to an arbitrary depth.
|
|||
|
|
|||
|
A directory entry, a named collection of information, is the basic
|
|||
|
unit of information held in the Directory. There are multiple kinds
|
|||
|
of directory entries.
|
|||
|
|
|||
|
An object entry represents a particular object. An alias entry
|
|||
|
provides alternative naming. A subentry holds administrative and/or
|
|||
|
operational information.
|
|||
|
|
|||
|
The set of entries representing the DIB are organized hierarchically
|
|||
|
in a tree structure known as the Directory Information Tree (DIT).
|
|||
|
|
|||
|
Section 2.1 describes the Directory Information Tree.
|
|||
|
Section 2.2 discusses the structure of entries.
|
|||
|
Section 2.3 discusses naming of entries.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 6]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Section 2.4 discusses object classes.
|
|||
|
Section 2.5 discusses attribute descriptions.
|
|||
|
Section 2.6 discusses alias entries.
|
|||
|
|
|||
|
2.1. The Directory Information Tree
|
|||
|
|
|||
|
As noted above, the DIB is composed of a set of entries organized
|
|||
|
hierarchically in a tree structure known as the Directory Information
|
|||
|
Tree (DIT); specifically, a tree where vertices are the entries.
|
|||
|
|
|||
|
The arcs between vertices define relations between entries. If an
|
|||
|
arc exists from X to Y, then the entry at X is the immediate superior
|
|||
|
of Y, and Y is the immediate subordinate of X. An entry's superiors
|
|||
|
are the entry's immediate superior and its superiors. An entry's
|
|||
|
subordinates are all of its immediate subordinates and their
|
|||
|
subordinates.
|
|||
|
|
|||
|
Similarly, the superior/subordinate relationship between object
|
|||
|
entries can be used to derive a relation between the objects they
|
|||
|
represent. DIT structure rules can be used to govern relationships
|
|||
|
between objects.
|
|||
|
|
|||
|
Note: An entry's immediate superior is also known as the entry's
|
|||
|
parent, and an entry's immediate subordinate is also known as
|
|||
|
the entry's child. Entries that have the same parent are known
|
|||
|
as siblings.
|
|||
|
|
|||
|
2.2. Structure of an Entry
|
|||
|
|
|||
|
An entry consists of a set of attributes that hold information about
|
|||
|
the object that the entry represents. Some attributes represent user
|
|||
|
information and are called user attributes. Other attributes
|
|||
|
represent operational and/or administrative information and are
|
|||
|
called operational attributes.
|
|||
|
|
|||
|
An attribute is an attribute description (a type and zero or more
|
|||
|
options) with one or more associated values. An attribute is often
|
|||
|
referred to by its attribute description. For example, the
|
|||
|
'givenName' attribute is the attribute that consists of the attribute
|
|||
|
description 'givenName' (the 'givenName' attribute type [RFC4519] and
|
|||
|
zero options) and one or more associated values.
|
|||
|
|
|||
|
The attribute type governs whether the attribute can have multiple
|
|||
|
values, the syntax and matching rules used to construct and compare
|
|||
|
values of that attribute, and other functions. Options indicate
|
|||
|
subtypes and other functions.
|
|||
|
|
|||
|
Attribute values conform to the defined syntax of the attribute type.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 7]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
No two values of an attribute may be equivalent. Two values are
|
|||
|
considered equivalent if and only if they would match according to
|
|||
|
the equality matching rule of the attribute type. Or, if the
|
|||
|
attribute type is defined with no equality matching rule, two values
|
|||
|
are equivalent if and only if they are identical. (See 2.5.1 for
|
|||
|
other restrictions.)
|
|||
|
|
|||
|
For example, a 'givenName' attribute can have more than one value,
|
|||
|
they must be Directory Strings, and they are case insensitive. A
|
|||
|
'givenName' attribute cannot hold both "John" and "JOHN", as these
|
|||
|
are equivalent values per the equality matching rule of the attribute
|
|||
|
type.
|
|||
|
|
|||
|
Additionally, no attribute is to have a value that is not equivalent
|
|||
|
to itself. For example, the 'givenName' attribute cannot have as a
|
|||
|
value a directory string that includes the REPLACEMENT CHARACTER
|
|||
|
(U+FFFD) code point, as matching involving that directory string is
|
|||
|
Undefined per this attribute's equality matching rule.
|
|||
|
|
|||
|
When an attribute is used for naming of the entry, one and only one
|
|||
|
value of the attribute is used in forming the Relative Distinguished
|
|||
|
Name. This value is known as a distinguished value.
|
|||
|
|
|||
|
2.3. Naming of Entries
|
|||
|
|
|||
|
2.3.1. Relative Distinguished Names
|
|||
|
|
|||
|
Each entry is named relative to its immediate superior. This
|
|||
|
relative name, known as its Relative Distinguished Name (RDN)
|
|||
|
[X.501], is composed of an unordered set of one or more attribute
|
|||
|
value assertions (AVA) consisting of an attribute description with
|
|||
|
zero options and an attribute value. These AVAs are chosen to match
|
|||
|
attribute values (each a distinguished value) of the entry.
|
|||
|
|
|||
|
An entry's relative distinguished name must be unique among all
|
|||
|
immediate subordinates of the entry's immediate superior (i.e., all
|
|||
|
siblings).
|
|||
|
|
|||
|
The following are examples of string representations of RDNs
|
|||
|
[RFC4514]:
|
|||
|
|
|||
|
UID=12345
|
|||
|
OU=Engineering
|
|||
|
CN=Kurt Zeilenga+L=Redwood Shores
|
|||
|
|
|||
|
The last is an example of a multi-valued RDN; that is, an RDN
|
|||
|
composed of multiple AVAs.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 8]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
2.3.2. Distinguished Names
|
|||
|
|
|||
|
An entry's fully qualified name, known as its Distinguished Name (DN)
|
|||
|
[X.501], is the concatenation of its RDN and its immediate superior's
|
|||
|
DN. A Distinguished Name unambiguously refers to an entry in the
|
|||
|
tree. The following are examples of string representations of DNs
|
|||
|
[RFC4514]:
|
|||
|
|
|||
|
UID=nobody@example.com,DC=example,DC=com
|
|||
|
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
|
|||
|
|
|||
|
2.3.3. Alias Names
|
|||
|
|
|||
|
An alias, or alias name, is "an name for an object, provided by the
|
|||
|
use of alias entries" [X.501]. Alias entries are described in
|
|||
|
Section 2.6.
|
|||
|
|
|||
|
2.4. Object Classes
|
|||
|
|
|||
|
An object class is "an identified family of objects (or conceivable
|
|||
|
objects) that share certain characteristics" [X.501].
|
|||
|
|
|||
|
As defined in [X.501]:
|
|||
|
|
|||
|
Object classes are used in the Directory for a number of purposes:
|
|||
|
|
|||
|
- describing and categorizing objects and the entries that
|
|||
|
correspond to these objects;
|
|||
|
|
|||
|
- where appropriate, controlling the operation of the Directory;
|
|||
|
|
|||
|
- regulating, in conjunction with DIT structure rule
|
|||
|
specifications, the position of entries in the DIT;
|
|||
|
|
|||
|
- regulating, in conjunction with DIT content rule
|
|||
|
specifications, the attributes that are contained in entries;
|
|||
|
|
|||
|
- identifying classes of entry that are to be associated with a
|
|||
|
particular policy by the appropriate administrative authority.
|
|||
|
|
|||
|
An object class (a subclass) may be derived from an object class
|
|||
|
(its direct superclass) which is itself derived from an even more
|
|||
|
generic object class. For structural object classes, this process
|
|||
|
stops at the most generic object class, 'top' (defined in Section
|
|||
|
2.4.1). An ordered set of superclasses up to the most superior
|
|||
|
object class of an object class is its superclass chain.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 9]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
An object class may be derived from two or more direct
|
|||
|
superclasses (superclasses not part of the same superclass chain).
|
|||
|
This feature of subclassing is termed multiple inheritance.
|
|||
|
|
|||
|
Each object class identifies the set of attributes required to be
|
|||
|
present in entries belonging to the class and the set of attributes
|
|||
|
allowed to be present in entries belonging to the class. As an entry
|
|||
|
of a class must meet the requirements of each class it belongs to, it
|
|||
|
can be said that an object class inherits the sets of allowed and
|
|||
|
required attributes from its superclasses. A subclass can identify
|
|||
|
an attribute allowed by its superclass as being required. If an
|
|||
|
attribute is a member of both sets, it is required to be present.
|
|||
|
|
|||
|
Each object class is defined to be one of three kinds of object
|
|||
|
classes: Abstract, Structural, or Auxiliary.
|
|||
|
|
|||
|
Each object class is identified by an object identifier (OID) and,
|
|||
|
optionally, one or more short names (descriptors).
|
|||
|
|
|||
|
2.4.1. Abstract Object Classes
|
|||
|
|
|||
|
An abstract object class, as the name implies, provides a base of
|
|||
|
characteristics from which other object classes can be defined to
|
|||
|
inherit from. An entry cannot belong to an abstract object class
|
|||
|
unless it belongs to a structural or auxiliary class that inherits
|
|||
|
from that abstract class.
|
|||
|
|
|||
|
Abstract object classes cannot derive from structural or auxiliary
|
|||
|
object classes.
|
|||
|
|
|||
|
All structural object classes derive (directly or indirectly) from
|
|||
|
the 'top' abstract object class. Auxiliary object classes do not
|
|||
|
necessarily derive from 'top'.
|
|||
|
|
|||
|
The following is the object class definition (see Section 4.1.1) for
|
|||
|
the 'top' object class:
|
|||
|
|
|||
|
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
|
|||
|
|
|||
|
All entries belong to the 'top' abstract object class.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 10]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
2.4.2. Structural Object Classes
|
|||
|
|
|||
|
As stated in [X.501]:
|
|||
|
|
|||
|
An object class defined for use in the structural specification of
|
|||
|
the DIT is termed a structural object class. Structural object
|
|||
|
classes are used in the definition of the structure of the names
|
|||
|
of the objects for compliant entries.
|
|||
|
|
|||
|
An object or alias entry is characterized by precisely one
|
|||
|
structural object class superclass chain which has a single
|
|||
|
structural object class as the most subordinate object class.
|
|||
|
This structural object class is referred to as the structural
|
|||
|
object class of the entry.
|
|||
|
|
|||
|
Structural object classes are related to associated entries:
|
|||
|
|
|||
|
- an entry conforming to a structural object class shall
|
|||
|
represent the real-world object constrained by the object
|
|||
|
class;
|
|||
|
|
|||
|
- DIT structure rules only refer to structural object classes;
|
|||
|
the structural object class of an entry is used to specify the
|
|||
|
position of the entry in the DIT;
|
|||
|
|
|||
|
- the structural object class of an entry is used, along with an
|
|||
|
associated DIT content rule, to control the content of an
|
|||
|
entry.
|
|||
|
|
|||
|
The structural object class of an entry shall not be changed.
|
|||
|
|
|||
|
Each structural object class is a (direct or indirect) subclass of
|
|||
|
the 'top' abstract object class.
|
|||
|
|
|||
|
Structural object classes cannot subclass auxiliary object classes.
|
|||
|
|
|||
|
Each entry is said to belong to its structural object class as well
|
|||
|
as all classes in its structural object class's superclass chain.
|
|||
|
|
|||
|
2.4.3. Auxiliary Object Classes
|
|||
|
|
|||
|
Auxiliary object classes are used to augment the characteristics of
|
|||
|
entries. They are commonly used to augment the sets of attributes
|
|||
|
required and allowed to be present in an entry. They can be used to
|
|||
|
describe entries or classes of entries.
|
|||
|
|
|||
|
Auxiliary object classes cannot subclass structural object classes.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 11]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
An entry can belong to any subset of the set of auxiliary object
|
|||
|
classes allowed by the DIT content rule associated with the
|
|||
|
structural object class of the entry. If no DIT content rule is
|
|||
|
associated with the structural object class of the entry, the entry
|
|||
|
cannot belong to any auxiliary object class.
|
|||
|
|
|||
|
The set of auxiliary object classes that an entry belongs to can
|
|||
|
change over time.
|
|||
|
|
|||
|
2.5. Attribute Descriptions
|
|||
|
|
|||
|
An attribute description is composed of an attribute type (see
|
|||
|
Section 2.5.1) and a set of zero or more attribute options (see
|
|||
|
Section 2.5.2).
|
|||
|
|
|||
|
An attribute description is represented by the ABNF:
|
|||
|
|
|||
|
attributedescription = attributetype options
|
|||
|
attributetype = oid
|
|||
|
options = *( SEMI option )
|
|||
|
option = 1*keychar
|
|||
|
|
|||
|
where <attributetype> identifies the attribute type and each <option>
|
|||
|
identifies an attribute option. Both <attributetype> and <option>
|
|||
|
productions are case insensitive. The order in which <option>s
|
|||
|
appear is irrelevant. That is, any two <attributedescription>s that
|
|||
|
consist of the same <attributetype> and same set of <option>s are
|
|||
|
equivalent.
|
|||
|
|
|||
|
Examples of valid attribute descriptions:
|
|||
|
|
|||
|
2.5.4.0
|
|||
|
cn;lang-de;lang-en
|
|||
|
owner
|
|||
|
|
|||
|
An attribute description with an unrecognized attribute type is to be
|
|||
|
treated as unrecognized. Servers SHALL treat an attribute
|
|||
|
description with an unrecognized attribute option as unrecognized.
|
|||
|
Clients MAY treat an unrecognized attribute option as a tagging
|
|||
|
option (see Section 2.5.2.1).
|
|||
|
|
|||
|
All attributes of an entry must have distinct attribute descriptions.
|
|||
|
|
|||
|
2.5.1. Attribute Types
|
|||
|
|
|||
|
An attribute type governs whether the attribute can have multiple
|
|||
|
values, the syntax and matching rules used to construct and compare
|
|||
|
values of that attribute, and other functions.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 12]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
If no equality matching is specified for the attribute type:
|
|||
|
|
|||
|
- the attribute (of the type) cannot be used for naming;
|
|||
|
- when adding the attribute (or replacing all values), no two
|
|||
|
values may be equivalent (see 2.2);
|
|||
|
- individual values of a multi-valued attribute are not to be
|
|||
|
independently added or deleted;
|
|||
|
- attribute value assertions (such as matching in search filters
|
|||
|
and comparisons) using values of such a type cannot be
|
|||
|
performed.
|
|||
|
|
|||
|
Otherwise, the specified equality matching rule is to be used to
|
|||
|
evaluate attribute value assertions concerning the attribute type.
|
|||
|
The specified equality rule is to be transitive and commutative.
|
|||
|
|
|||
|
The attribute type indicates whether the attribute is a user
|
|||
|
attribute or an operational attribute. If operational, the attribute
|
|||
|
type indicates the operational usage and whether or not the attribute
|
|||
|
is modifiable by users. Operational attributes are discussed in
|
|||
|
Section 3.4.
|
|||
|
|
|||
|
An attribute type (a subtype) may derive from a more generic
|
|||
|
attribute type (a direct supertype). The following restrictions
|
|||
|
apply to subtyping:
|
|||
|
|
|||
|
- a subtype must have the same usage as its direct supertype,
|
|||
|
- a subtype's syntax must be the same, or a refinement of, its
|
|||
|
supertype's syntax, and
|
|||
|
- a subtype must be collective [RFC3671] if its supertype is
|
|||
|
collective.
|
|||
|
|
|||
|
An attribute description consisting of a subtype and no options is
|
|||
|
said to be the direct description subtype of the attribute
|
|||
|
description consisting of the subtype's direct supertype and no
|
|||
|
options.
|
|||
|
|
|||
|
Each attribute type is identified by an object identifier (OID) and,
|
|||
|
optionally, one or more short names (descriptors).
|
|||
|
|
|||
|
2.5.2. Attribute Options
|
|||
|
|
|||
|
There are multiple kinds of attribute description options. The LDAP
|
|||
|
technical specification details one kind: tagging options.
|
|||
|
|
|||
|
Not all options can be associated with attributes held in the
|
|||
|
directory. Tagging options can be.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 13]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Not all options can be used in conjunction with all attribute types.
|
|||
|
In such cases, the attribute description is to be treated as
|
|||
|
unrecognized.
|
|||
|
|
|||
|
An attribute description that contains mutually exclusive options
|
|||
|
shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
|
|||
|
"x-foo" and "x-bar" are mutually exclusive, is to be treated as
|
|||
|
unrecognized.
|
|||
|
|
|||
|
Other kinds of options may be specified in future documents. These
|
|||
|
documents must detail how new kinds of options they define relate to
|
|||
|
tagging options. In particular, these documents must detail whether
|
|||
|
or not new kinds of options can be associated with attributes held in
|
|||
|
the directory, how new kinds of options affect transfer of attribute
|
|||
|
values, and how new kinds of options are treated in attribute
|
|||
|
description hierarchies.
|
|||
|
|
|||
|
Options are represented as short, case-insensitive textual strings
|
|||
|
conforming to the <option> production defined in Section 2.5 of this
|
|||
|
document.
|
|||
|
|
|||
|
Procedures for registering options are detailed in BCP 64, RFC 4520
|
|||
|
[RFC4520].
|
|||
|
|
|||
|
2.5.2.1. Tagging Options
|
|||
|
|
|||
|
Attributes held in the directory can have attribute descriptions with
|
|||
|
any number of tagging options. Tagging options are never mutually
|
|||
|
exclusive.
|
|||
|
|
|||
|
An attribute description with N tagging options is a direct
|
|||
|
(description) subtype of all attribute descriptions of the same
|
|||
|
attribute type and all but one of the N options. If the attribute
|
|||
|
type has a supertype, then the attribute description is also a direct
|
|||
|
(description) subtype of the attribute description of the supertype
|
|||
|
and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
|
|||
|
(description) subtype of 'cn;lang-de', 'cn;lang-en', and
|
|||
|
'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
|
|||
|
in [RFC4519]).
|
|||
|
|
|||
|
2.5.3. Attribute Description Hierarchies
|
|||
|
|
|||
|
An attribute description can be the direct subtype of zero or more
|
|||
|
other attribute descriptions as indicated by attribute type subtyping
|
|||
|
(as described in Section 2.5.1) or attribute tagging option subtyping
|
|||
|
(as described in Section 2.5.2.1). These subtyping relationships are
|
|||
|
used to form hierarchies of attribute descriptions and attributes.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 14]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
As adapted from [X.501]:
|
|||
|
|
|||
|
Attribute hierarchies allow access to the DIB with varying degrees
|
|||
|
of granularity. This is achieved by allowing the value components
|
|||
|
of attributes to be accessed by using either their specific
|
|||
|
attribute description (a direct reference to the attribute) or a
|
|||
|
more generic attribute description (an indirect reference).
|
|||
|
|
|||
|
Semantically related attributes may be placed in a hierarchical
|
|||
|
relationship, the more specialized being placed subordinate to the
|
|||
|
more generalized. Searching for or retrieving attributes and
|
|||
|
their values is made easier by quoting the more generalized
|
|||
|
attribute description; a filter item so specified is evaluated for
|
|||
|
the more specialized descriptions as well as for the quoted
|
|||
|
description.
|
|||
|
|
|||
|
Where subordinate specialized descriptions are selected to be
|
|||
|
returned as part of a search result these descriptions shall be
|
|||
|
returned if available. Where the more general descriptions are
|
|||
|
selected to be returned as part of a search result both the
|
|||
|
general and the specialized descriptions shall be returned, if
|
|||
|
available. An attribute value shall always be returned as a value
|
|||
|
of its own attribute description.
|
|||
|
|
|||
|
All of the attribute descriptions in an attribute hierarchy are
|
|||
|
treated as distinct and unrelated descriptions for user
|
|||
|
modification of entry content.
|
|||
|
|
|||
|
An attribute value stored in an object or alias entry is of
|
|||
|
precisely one attribute description. The description is indicated
|
|||
|
when the value is originally added to the entry.
|
|||
|
|
|||
|
For the purpose of subschema administration of the entry, a
|
|||
|
specification that an attribute is required is fulfilled if the entry
|
|||
|
contains a value of an attribute description belonging to an
|
|||
|
attribute hierarchy where the attribute type of that description is
|
|||
|
the same as the required attribute's type. That is, a "MUST name"
|
|||
|
specification is fulfilled by 'name' or 'name;x-tag-option', but is
|
|||
|
not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
|
|||
|
subtype of 'name'). Likewise, an entry may contain a value of an
|
|||
|
attribute description belonging to an attribute hierarchy where the
|
|||
|
attribute type of that description is either explicitly included in
|
|||
|
the definition of an object class to which the entry belongs or
|
|||
|
allowed by the DIT content rule applicable to that entry. That is,
|
|||
|
'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
|
|||
|
name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
|
|||
|
(or by "MUST name").
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 15]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
For the purposes of other policy administration, unless stated
|
|||
|
otherwise in the specification of the particular administrative
|
|||
|
model, all of the attribute descriptions in an attribute hierarchy
|
|||
|
are treated as distinct and unrelated descriptions.
|
|||
|
|
|||
|
2.6. Alias Entries
|
|||
|
|
|||
|
As adapted from [X.501]:
|
|||
|
|
|||
|
An alias, or an alias name, for an object is an alternative name
|
|||
|
for an object or object entry which is provided by the use of
|
|||
|
alias entries.
|
|||
|
|
|||
|
Each alias entry contains, within the 'aliasedObjectName'
|
|||
|
attribute (known as the 'aliasedEntryName' attribute in X.500), a
|
|||
|
name of some object. The distinguished name of the alias entry is
|
|||
|
thus also a name for this object.
|
|||
|
|
|||
|
NOTE - The name within the 'aliasedObjectName' is said to be
|
|||
|
pointed to by the alias. It does not have to be the
|
|||
|
distinguished name of any entry.
|
|||
|
|
|||
|
The conversion of an alias name to an object name is termed
|
|||
|
(alias) dereferencing and comprises the systematic replacement of
|
|||
|
alias names, where found within a purported name, by the value of
|
|||
|
the corresponding 'aliasedObjectName' attribute. The process may
|
|||
|
require the examination of more than one alias entry.
|
|||
|
|
|||
|
Any particular entry in the DIT may have zero or more alias names.
|
|||
|
It therefore follows that several alias entries may point to the
|
|||
|
same entry. An alias entry may point to an entry that is not a
|
|||
|
leaf entry and may point to another alias entry.
|
|||
|
|
|||
|
An alias entry shall have no subordinates, so that an alias entry
|
|||
|
is always a leaf entry.
|
|||
|
|
|||
|
Every alias entry shall belong to the 'alias' object class.
|
|||
|
|
|||
|
An entry with the 'alias' object class must also belong to an object
|
|||
|
class (or classes), or be governed by a DIT content rule, which
|
|||
|
allows suitable naming attributes to be present.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
dn: cn=bar,dc=example,dc=com
|
|||
|
objectClass: top
|
|||
|
objectClass: alias
|
|||
|
objectClass: extensibleObject
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 16]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
cn: bar
|
|||
|
aliasedObjectName: cn=foo,dc=example,dc=com
|
|||
|
|
|||
|
2.6.1. 'alias' Object Class
|
|||
|
|
|||
|
Alias entries belong to the 'alias' object class.
|
|||
|
|
|||
|
( 2.5.6.1 NAME 'alias'
|
|||
|
SUP top STRUCTURAL
|
|||
|
MUST aliasedObjectName )
|
|||
|
|
|||
|
2.6.2. 'aliasedObjectName' Attribute Type
|
|||
|
|
|||
|
The 'aliasedObjectName' attribute holds the name of the entry an
|
|||
|
alias points to. The 'aliasedObjectName' attribute is known as the
|
|||
|
'aliasedEntryName' attribute in X.500.
|
|||
|
|
|||
|
( 2.5.4.1 NAME 'aliasedObjectName'
|
|||
|
EQUALITY distinguishedNameMatch
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
|
|||
|
SINGLE-VALUE )
|
|||
|
|
|||
|
The 'distinguishedNameMatch' matching rule and the DistinguishedName
|
|||
|
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
|
|||
|
|
|||
|
3. Directory Administrative and Operational Information
|
|||
|
|
|||
|
This section discusses select aspects of the X.500 Directory
|
|||
|
Administrative and Operational Information model [X.501]. LDAP
|
|||
|
implementations MAY support other aspects of this model.
|
|||
|
|
|||
|
3.1. Subtrees
|
|||
|
|
|||
|
As defined in [X.501]:
|
|||
|
|
|||
|
A subtree is a collection of object and alias entries situated at
|
|||
|
the vertices of a tree. Subtrees do not contain subentries. The
|
|||
|
prefix sub, in subtree, emphasizes that the base (or root) vertex
|
|||
|
of this tree is usually subordinate to the root of the DIT.
|
|||
|
|
|||
|
A subtree begins at some vertex and extends to some identifiable
|
|||
|
lower boundary, possibly extending to leaves. A subtree is always
|
|||
|
defined within a context which implicitly bounds the subtree. For
|
|||
|
example, the vertex and lower boundaries of a subtree defining a
|
|||
|
replicated area are bounded by a naming context.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 17]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
3.2. Subentries
|
|||
|
|
|||
|
A subentry is a "special sort of entry, known by the Directory, used
|
|||
|
to hold information associated with a subtree or subtree refinement"
|
|||
|
[X.501]. Subentries are used in Directory to hold for administrative
|
|||
|
and operational purposes as defined in [X.501]. Their use in LDAP is
|
|||
|
detailed in [RFC3672].
|
|||
|
|
|||
|
The term "(sub)entry" in this specification indicates that servers
|
|||
|
implementing X.500(93) models are, in accordance with X.500(93) as
|
|||
|
described in [RFC3672], to use a subentry and that other servers are
|
|||
|
to use an object entry belonging to the appropriate auxiliary class
|
|||
|
normally used with the subentry (e.g., 'subschema' for subschema
|
|||
|
subentries) to mimic the subentry. This object entry's RDN SHALL be
|
|||
|
formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
|
|||
|
all subentries are named with 'cn').
|
|||
|
|
|||
|
3.3. The 'objectClass' attribute
|
|||
|
|
|||
|
Each entry in the DIT has an 'objectClass' attribute.
|
|||
|
|
|||
|
( 2.5.4.0 NAME 'objectClass'
|
|||
|
EQUALITY objectIdentifierMatch
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
|
|||
|
|
|||
|
The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
|
|||
|
(1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
|
|||
|
|
|||
|
The 'objectClass' attribute specifies the object classes of an entry,
|
|||
|
which (among other things) are used in conjunction with the
|
|||
|
controlling schema to determine the permitted attributes of an entry.
|
|||
|
Values of this attribute can be modified by clients, but the
|
|||
|
'objectClass' attribute cannot be removed.
|
|||
|
|
|||
|
Servers that follow X.500(93) models SHALL restrict modifications of
|
|||
|
this attribute to prevent the basic structural class of the entry
|
|||
|
from being changed. That is, one cannot change a 'person' into a
|
|||
|
'country'.
|
|||
|
|
|||
|
When creating an entry or adding an 'objectClass' value to an entry,
|
|||
|
all superclasses of the named classes SHALL be implicitly added as
|
|||
|
well if not already present. That is, if the auxiliary class 'x-a'
|
|||
|
is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
|
|||
|
causes 'x-b' to be implicitly added (if is not already present).
|
|||
|
|
|||
|
Servers SHALL restrict modifications of this attribute to prevent
|
|||
|
superclasses of remaining 'objectClass' values from being deleted.
|
|||
|
That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 18]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
|
|||
|
an attempt to delete only 'x-b' from the 'objectClass' attribute is
|
|||
|
an error.
|
|||
|
|
|||
|
3.4. Operational Attributes
|
|||
|
|
|||
|
Some attributes, termed operational attributes, are used or
|
|||
|
maintained by servers for administrative and operational purposes.
|
|||
|
As stated in [X.501]: "There are three varieties of operational
|
|||
|
attributes: Directory operational attributes, DSA-shared operational
|
|||
|
attributes, and DSA-specific operational attributes".
|
|||
|
|
|||
|
A directory operational attribute is used to represent operational
|
|||
|
and/or administrative information in the Directory Information Model.
|
|||
|
This includes operational attributes maintained by the server (e.g.,
|
|||
|
'createTimestamp') as well as operational attributes that hold values
|
|||
|
administrated by the user (e.g., 'ditContentRules').
|
|||
|
|
|||
|
A DSA-shared operational attribute is used to represent information
|
|||
|
of the DSA Information Model that is shared between DSAs.
|
|||
|
|
|||
|
A DSA-specific operational attribute is used to represent information
|
|||
|
of the DSA Information Model that is specific to the DSA (though, in
|
|||
|
some cases, may be derived from information shared between DSAs;
|
|||
|
e.g., 'namingContexts').
|
|||
|
|
|||
|
The DSA Information Model operational attributes are detailed in
|
|||
|
[X.501].
|
|||
|
|
|||
|
Operational attributes are not normally visible. They are not
|
|||
|
returned in search results unless explicitly requested by name.
|
|||
|
|
|||
|
Not all operational attributes are user modifiable.
|
|||
|
|
|||
|
Entries may contain, among others, the following operational
|
|||
|
attributes:
|
|||
|
|
|||
|
- creatorsName: the Distinguished Name of the user who added this
|
|||
|
entry to the directory,
|
|||
|
|
|||
|
- createTimestamp: the time this entry was added to the directory,
|
|||
|
|
|||
|
- modifiersName: the Distinguished Name of the user who last
|
|||
|
modified this entry, and
|
|||
|
|
|||
|
- modifyTimestamp: the time this entry was last modified.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 19]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
|
|||
|
'modifiersName', and 'modifyTimestamp' attributes for all entries of
|
|||
|
the DIT.
|
|||
|
|
|||
|
3.4.1. 'creatorsName'
|
|||
|
|
|||
|
This attribute appears in entries that were added using the protocol
|
|||
|
(e.g., using the Add operation). The value is the distinguished name
|
|||
|
of the creator.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The 'distinguishedNameMatch' matching rule and the DistinguishedName
|
|||
|
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
|
|||
|
|
|||
|
3.4.2. 'createTimestamp'
|
|||
|
|
|||
|
This attribute appears in entries that were added using the protocol
|
|||
|
(e.g., using the Add operation). The value is the time the entry was
|
|||
|
added.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
|
|||
|
matching rules and the GeneralizedTime
|
|||
|
(1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
|
|||
|
|
|||
|
3.4.3. 'modifiersName'
|
|||
|
|
|||
|
This attribute appears in entries that have been modified using the
|
|||
|
protocol (e.g., using the Modify operation). The value is the
|
|||
|
distinguished name of the last modifier.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 20]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
The 'distinguishedNameMatch' matching rule and the DistinguishedName
|
|||
|
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
|
|||
|
|
|||
|
3.4.4. 'modifyTimestamp'
|
|||
|
|
|||
|
This attribute appears in entries that have been modified using the
|
|||
|
protocol (e.g., using the Modify operation). The value is the time
|
|||
|
the entry was last modified.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
|
|||
|
matching rules and the GeneralizedTime
|
|||
|
(1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
|
|||
|
|
|||
|
3.4.5. 'structuralObjectClass'
|
|||
|
|
|||
|
This attribute indicates the structural object class of the entry.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
|
|||
|
(1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
|
|||
|
|
|||
|
3.4.6. 'governingStructureRule'
|
|||
|
|
|||
|
This attribute indicates the structure rule governing the entry.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The 'integerMatch' matching rule and INTEGER
|
|||
|
(1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 21]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
4. Directory Schema
|
|||
|
|
|||
|
As defined in [X.501]:
|
|||
|
|
|||
|
The Directory Schema is a set of definitions and constraints
|
|||
|
concerning the structure of the DIT, the possible ways entries are
|
|||
|
named, the information that can be held in an entry, the
|
|||
|
attributes used to represent that information and their
|
|||
|
organization into hierarchies to facilitate search and retrieval
|
|||
|
of the information and the ways in which values of attributes may
|
|||
|
be matched in attribute value and matching rule assertions.
|
|||
|
|
|||
|
NOTE 1 - The schema enables the Directory system to, for example:
|
|||
|
|
|||
|
- prevent the creation of subordinate entries of the wrong
|
|||
|
object-class (e.g., a country as a subordinate of a person);
|
|||
|
|
|||
|
- prevent the addition of attribute-types to an entry
|
|||
|
inappropriate to the object-class (e.g., a serial number to a
|
|||
|
person's entry);
|
|||
|
|
|||
|
- prevent the addition of an attribute value of a syntax not
|
|||
|
matching that defined for the attribute-type (e.g., a printable
|
|||
|
string to a bit string).
|
|||
|
|
|||
|
Formally, the Directory Schema comprises a set of:
|
|||
|
|
|||
|
a) Name Form definitions that define primitive naming relations
|
|||
|
for structural object classes;
|
|||
|
|
|||
|
b) DIT Structure Rule definitions that define the names that
|
|||
|
entries may have and the ways in which the entries may be
|
|||
|
related to one another in the DIT;
|
|||
|
|
|||
|
c) DIT Content Rule definitions that extend the specification of
|
|||
|
allowable attributes for entries beyond those indicated by the
|
|||
|
structural object classes of the entries;
|
|||
|
|
|||
|
d) Object Class definitions that define the basic set of mandatory
|
|||
|
and optional attributes that shall be present, and may be
|
|||
|
present, respectively, in an entry of a given class, and which
|
|||
|
indicate the kind of object class that is being defined;
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 22]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
e) Attribute Type definitions that identify the object identifier
|
|||
|
by which an attribute is known, its syntax, associated matching
|
|||
|
rules, whether it is an operational attribute and if so its
|
|||
|
type, whether it is a collective attribute, whether it is
|
|||
|
permitted to have multiple values and whether or not it is
|
|||
|
derived from another attribute type;
|
|||
|
|
|||
|
f) Matching Rule definitions that define matching rules.
|
|||
|
|
|||
|
And in LDAP:
|
|||
|
|
|||
|
g) LDAP Syntax definitions that define encodings used in LDAP.
|
|||
|
|
|||
|
4.1. Schema Definitions
|
|||
|
|
|||
|
Schema definitions in this section are described using ABNF and rely
|
|||
|
on the common productions specified in Section 1.2 as well as these:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
Schema definitions in this section also share a number of common
|
|||
|
terms.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 23]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
The NAME field provides a set of short names (descriptors) that are
|
|||
|
to be used as aliases for the OID.
|
|||
|
|
|||
|
The DESC field optionally allows a descriptive string to be provided
|
|||
|
by the directory administrator and/or implementor. While
|
|||
|
specifications may suggest a descriptive string, there is no
|
|||
|
requirement that the suggested (or any) descriptive string be used.
|
|||
|
|
|||
|
The OBSOLETE field, if present, indicates the element is not active.
|
|||
|
|
|||
|
Implementors should note that future versions of this document may
|
|||
|
expand these definitions to include additional terms. Terms whose
|
|||
|
identifier begins with "X-" are reserved for private experiments and
|
|||
|
are followed by <SP> and <qdstrings> tokens.
|
|||
|
|
|||
|
4.1.1. Object Class Definitions
|
|||
|
|
|||
|
Object Class definitions are written according to the ABNF:
|
|||
|
|
|||
|
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"
|
|||
|
|
|||
|
where:
|
|||
|
<numericoid> is object identifier assigned to this object class;
|
|||
|
NAME <qdescrs> are short names (descriptors) identifying this
|
|||
|
object class;
|
|||
|
DESC <qdstring> is a short descriptive string;
|
|||
|
OBSOLETE indicates this object class is not active;
|
|||
|
SUP <oids> specifies the direct superclasses of this object class;
|
|||
|
the kind of object class is indicated by one of ABSTRACT,
|
|||
|
STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
|
|||
|
MUST and MAY specify the sets of required and allowed attribute
|
|||
|
types, respectively; and
|
|||
|
<extensions> describe extensions.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 24]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
4.1.2. Attribute Types
|
|||
|
|
|||
|
Attribute Type definitions are written according to the ABNF:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
where:
|
|||
|
<numericoid> is object identifier assigned to this attribute type;
|
|||
|
NAME <qdescrs> are short names (descriptors) identifying this
|
|||
|
attribute type;
|
|||
|
DESC <qdstring> is a short descriptive string;
|
|||
|
OBSOLETE indicates this attribute type is not active;
|
|||
|
SUP oid specifies the direct supertype of this type;
|
|||
|
EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
|
|||
|
ordering, and substrings matching rules, respectively;
|
|||
|
SYNTAX identifies value syntax by object identifier and may suggest
|
|||
|
a minimum upper bound;
|
|||
|
SINGLE-VALUE indicates attributes of this type are restricted to a
|
|||
|
single value;
|
|||
|
COLLECTIVE indicates this attribute type is collective
|
|||
|
[X.501][RFC3671];
|
|||
|
NO-USER-MODIFICATION indicates this attribute type is not user
|
|||
|
modifiable;
|
|||
|
USAGE indicates the application of this attribute type; and
|
|||
|
<extensions> describe extensions.
|
|||
|
|
|||
|
Each attribute type description must contain at least one of the SUP
|
|||
|
or SYNTAX fields. If no SYNTAX field is provided, the attribute type
|
|||
|
description takes its value from the supertype.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 25]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
|
|||
|
fields, if not specified, take their value from the supertype.
|
|||
|
|
|||
|
Usage of userApplications, the default, indicates that attributes of
|
|||
|
this type represent user information. That is, they are user
|
|||
|
attributes.
|
|||
|
|
|||
|
A usage of directoryOperation, distributedOperation, or dSAOperation
|
|||
|
indicates that attributes of this type represent operational and/or
|
|||
|
administrative information. That is, they are operational
|
|||
|
attributes.
|
|||
|
|
|||
|
directoryOperation usage indicates that the attribute of this type is
|
|||
|
a directory operational attribute. distributedOperation usage
|
|||
|
indicates that the attribute of this type is a DSA-shared usage
|
|||
|
operational attribute. dSAOperation usage indicates that the
|
|||
|
attribute of this type is a DSA-specific operational attribute.
|
|||
|
|
|||
|
COLLECTIVE requires usage userApplications. Use of collective
|
|||
|
attribute types in LDAP is discussed in [RFC3671].
|
|||
|
|
|||
|
NO-USER-MODIFICATION requires an operational usage.
|
|||
|
|
|||
|
Note that the <AttributeTypeDescription> does not list the matching
|
|||
|
rules that can be used with that attribute type in an extensibleMatch
|
|||
|
search filter [RFC4511]. This is done using the 'matchingRuleUse'
|
|||
|
attribute described in Section 4.1.4.
|
|||
|
|
|||
|
This document refines the schema description of X.501 by requiring
|
|||
|
that the SYNTAX field in an <AttributeTypeDescription> be a string
|
|||
|
representation of an object identifier for the LDAP string syntax
|
|||
|
definition, with an optional indication of the suggested minimum
|
|||
|
bound of a value of this attribute.
|
|||
|
|
|||
|
A suggested minimum upper bound on the number of characters in a
|
|||
|
value with a string-based syntax, or the number of bytes in a value
|
|||
|
for all other syntaxes, may be indicated by appending this bound
|
|||
|
count inside of curly braces following the syntax's OBJECT IDENTIFIER
|
|||
|
in an Attribute Type Description. This bound is not part of the
|
|||
|
syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests
|
|||
|
that server implementations should allow a string to be 64 characters
|
|||
|
long, although they may allow longer strings. Note that a single
|
|||
|
character of the Directory String syntax may be encoded in more than
|
|||
|
one octet since UTF-8 [RFC3629] is a variable-length encoding.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 26]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
4.1.3. Matching Rules
|
|||
|
|
|||
|
Matching rules are used in performance of attribute value assertions,
|
|||
|
such as in performance of a Compare operation. They are also used in
|
|||
|
evaluating search filters, determining which individual values are to
|
|||
|
be added or deleted during performance of a Modify operation, and in
|
|||
|
comparing distinguished names.
|
|||
|
|
|||
|
Each matching rule is identified by an object identifier (OID) and,
|
|||
|
optionally, one or more short names (descriptors).
|
|||
|
|
|||
|
Matching rule definitions are written according to the ABNF:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
where:
|
|||
|
<numericoid> is object identifier assigned to this matching rule;
|
|||
|
NAME <qdescrs> are short names (descriptors) identifying this
|
|||
|
matching rule;
|
|||
|
DESC <qdstring> is a short descriptive string;
|
|||
|
OBSOLETE indicates this matching rule is not active;
|
|||
|
SYNTAX identifies the assertion syntax (the syntax of the assertion
|
|||
|
value) by object identifier; and
|
|||
|
<extensions> describe extensions.
|
|||
|
|
|||
|
4.1.4. Matching Rule Uses
|
|||
|
|
|||
|
A matching rule use lists the attribute types that are suitable for
|
|||
|
use with an extensibleMatch search filter.
|
|||
|
|
|||
|
Matching rule use descriptions are written according to the following
|
|||
|
ABNF:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 27]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
where:
|
|||
|
<numericoid> is the object identifier of the matching rule
|
|||
|
associated with this matching rule use description;
|
|||
|
NAME <qdescrs> are short names (descriptors) identifying this
|
|||
|
matching rule use;
|
|||
|
DESC <qdstring> is a short descriptive string;
|
|||
|
OBSOLETE indicates this matching rule use is not active;
|
|||
|
APPLIES provides a list of attribute types the matching rule
|
|||
|
applies to; and
|
|||
|
<extensions> describe extensions.
|
|||
|
|
|||
|
4.1.5. LDAP Syntaxes
|
|||
|
|
|||
|
LDAP Syntaxes of (attribute and assertion) values are described in
|
|||
|
terms of ASN.1 [X.680] and, optionally, have an octet string encoding
|
|||
|
known as the LDAP-specific encoding. Commonly, the LDAP-specific
|
|||
|
encoding is constrained to a string of Unicode [Unicode] characters
|
|||
|
in UTF-8 [RFC3629] form.
|
|||
|
|
|||
|
Each LDAP syntax is identified by an object identifier (OID).
|
|||
|
|
|||
|
LDAP syntax definitions are written according to the ABNF:
|
|||
|
|
|||
|
SyntaxDescription = LPAREN WSP
|
|||
|
numericoid ; object identifier
|
|||
|
[ SP "DESC" SP qdstring ] ; description
|
|||
|
extensions WSP RPAREN ; extensions
|
|||
|
|
|||
|
where:
|
|||
|
<numericoid> is the object identifier assigned to this LDAP syntax;
|
|||
|
DESC <qdstring> is a short descriptive string; and
|
|||
|
<extensions> describe extensions.
|
|||
|
|
|||
|
4.1.6. DIT Content Rules
|
|||
|
|
|||
|
A DIT content rule is a "rule governing the content of entries of a
|
|||
|
particular structural object class" [X.501].
|
|||
|
|
|||
|
For DIT entries of a particular structural object class, a DIT
|
|||
|
content rule specifies which auxiliary object classes the entries are
|
|||
|
allowed to belong to and which additional attributes (by type) are
|
|||
|
required, allowed, or not allowed to appear in the entries.
|
|||
|
|
|||
|
The list of precluded attributes cannot include any attribute listed
|
|||
|
as mandatory in the rule, the structural object class, or any of the
|
|||
|
allowed auxiliary object classes.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 28]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Each content rule is identified by the object identifier, as well as
|
|||
|
any short names (descriptors), of the structural object class it
|
|||
|
applies to.
|
|||
|
|
|||
|
An entry may only belong to auxiliary object classes listed in the
|
|||
|
governing content rule.
|
|||
|
|
|||
|
An entry must contain all attributes required by the object classes
|
|||
|
the entry belongs to as well as all attributes required by the
|
|||
|
governing content rule.
|
|||
|
|
|||
|
An entry may contain any non-precluded attributes allowed by the
|
|||
|
object classes the entry belongs to as well as all attributes allowed
|
|||
|
by the governing content rule.
|
|||
|
|
|||
|
An entry cannot include any attribute precluded by the governing
|
|||
|
content rule.
|
|||
|
|
|||
|
An entry is governed by (if present and active in the subschema) the
|
|||
|
DIT content rule that applies to the structural object class of the
|
|||
|
entry (see Section 2.4.2). If no active rule is present for the
|
|||
|
entry's structural object class, the entry's content is governed by
|
|||
|
the structural object class (and possibly other aspects of user and
|
|||
|
system schema). DIT content rules for superclasses of the structural
|
|||
|
object class of an entry are not applicable to that entry.
|
|||
|
|
|||
|
DIT content rule descriptions are written according to the ABNF:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
where:
|
|||
|
<numericoid> is the object identifier of the structural object
|
|||
|
class associated with this DIT content rule;
|
|||
|
NAME <qdescrs> are short names (descriptors) identifying this DIT
|
|||
|
content rule;
|
|||
|
DESC <qdstring> is a short descriptive string;
|
|||
|
OBSOLETE indicates this DIT content rule use is not active;
|
|||
|
AUX specifies a list of auxiliary object classes that entries
|
|||
|
subject to this DIT content rule may belong to;
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 29]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
MUST, MAY, and NOT specify lists of attribute types that are
|
|||
|
required, allowed, or precluded, respectively, from appearing
|
|||
|
in entries subject to this DIT content rule; and
|
|||
|
<extensions> describe extensions.
|
|||
|
|
|||
|
4.1.7. DIT Structure Rules and Name Forms
|
|||
|
|
|||
|
It is sometimes desirable to regulate where object and alias entries
|
|||
|
can be placed in the DIT and how they can be named based upon their
|
|||
|
structural object class.
|
|||
|
|
|||
|
4.1.7.1. DIT Structure Rules
|
|||
|
|
|||
|
A DIT structure rule is a "rule governing the structure of the DIT by
|
|||
|
specifying a permitted superior to subordinate entry relationship. A
|
|||
|
structure rule relates a name form, and therefore a structural object
|
|||
|
class, to superior structure rules. This permits entries of the
|
|||
|
structural object class identified by the name form to exist in the
|
|||
|
DIT as subordinates to entries governed by the indicated superior
|
|||
|
structure rules" [X.501].
|
|||
|
|
|||
|
DIT structure rule descriptions are written according to the ABNF:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
where:
|
|||
|
<ruleid> is the rule identifier of this DIT structure rule;
|
|||
|
NAME <qdescrs> are short names (descriptors) identifying this DIT
|
|||
|
structure rule;
|
|||
|
DESC <qdstring> is a short descriptive string;
|
|||
|
OBSOLETE indicates this DIT structure rule use is not active;
|
|||
|
FORM is specifies the name form associated with this DIT structure
|
|||
|
rule;
|
|||
|
SUP identifies superior rules (by rule id); and
|
|||
|
<extensions> describe extensions.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 30]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
If no superior rules are identified, the DIT structure rule applies
|
|||
|
to an autonomous administrative point (e.g., the root vertex of the
|
|||
|
subtree controlled by the subschema) [X.501].
|
|||
|
|
|||
|
4.1.7.2. Name Forms
|
|||
|
|
|||
|
A name form "specifies a permissible RDN for entries of a particular
|
|||
|
structural object class. A name form identifies a named object class
|
|||
|
and one or more attribute types to be used for naming (i.e., for the
|
|||
|
RDN). Name forms are primitive pieces of specification used in the
|
|||
|
definition of DIT structure rules" [X.501].
|
|||
|
|
|||
|
Each name form indicates the structural object class to be named, a
|
|||
|
set of required attribute types, and a set of allowed attribute
|
|||
|
types. A particular attribute type cannot be in both sets.
|
|||
|
|
|||
|
Entries governed by the form must be named using a value from each
|
|||
|
required attribute type and zero or more values from the allowed
|
|||
|
attribute types.
|
|||
|
|
|||
|
Each name form is identified by an object identifier (OID) and,
|
|||
|
optionally, one or more short names (descriptors).
|
|||
|
|
|||
|
Name form descriptions are written according to the ABNF:
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
where:
|
|||
|
<numericoid> is object identifier that identifies this name form;
|
|||
|
NAME <qdescrs> are short names (descriptors) identifying this name
|
|||
|
form;
|
|||
|
DESC <qdstring> is a short descriptive string;
|
|||
|
OBSOLETE indicates this name form is not active;
|
|||
|
OC identifies the structural object class this rule applies to,
|
|||
|
MUST and MAY specify the sets of required and allowed,
|
|||
|
respectively, naming attributes for this name form; and
|
|||
|
<extensions> describe extensions.
|
|||
|
|
|||
|
All attribute types in the required ("MUST") and allowed ("MAY")
|
|||
|
lists shall be different.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 31]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
4.2. Subschema Subentries
|
|||
|
|
|||
|
Subschema (sub)entries are used for administering information about
|
|||
|
the directory schema. A single subschema (sub)entry contains all
|
|||
|
schema definitions (see Section 4.1) used by entries in a particular
|
|||
|
part of the directory tree.
|
|||
|
|
|||
|
Servers that follow X.500(93) models SHOULD implement subschema using
|
|||
|
the X.500 subschema mechanisms (as detailed in Section 12 of
|
|||
|
[X.501]), so these are not ordinary object entries but subentries
|
|||
|
(see Section 3.2). LDAP clients SHOULD NOT assume that servers
|
|||
|
implement any of the other aspects of X.500 subschema.
|
|||
|
|
|||
|
Servers MAY allow subschema modification. Procedures for subschema
|
|||
|
modification are discussed in Section 14.5 of [X.501].
|
|||
|
|
|||
|
A server that masters entries and permits clients to modify these
|
|||
|
entries SHALL implement and provide access to these subschema
|
|||
|
(sub)entries including providing a 'subschemaSubentry' attribute in
|
|||
|
each modifiable entry. This is so clients may discover the
|
|||
|
attributes and object classes that are permitted to be present. It
|
|||
|
is strongly RECOMMENDED that all other servers implement this as
|
|||
|
well.
|
|||
|
|
|||
|
The value of the 'subschemaSubentry' attribute is the name of the
|
|||
|
subschema (sub)entry holding the subschema controlling the entry.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The 'distinguishedNameMatch' matching rule and the DistinguishedName
|
|||
|
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
|
|||
|
|
|||
|
Subschema is held in (sub)entries belonging to the subschema
|
|||
|
auxiliary object class.
|
|||
|
|
|||
|
( 2.5.20.1 NAME 'subschema' AUXILIARY
|
|||
|
MAY ( dITStructureRules $ nameForms $ ditContentRules $
|
|||
|
objectClasses $ attributeTypes $ matchingRules $
|
|||
|
matchingRuleUse ) )
|
|||
|
|
|||
|
The 'ldapSyntaxes' operational attribute may also be present in
|
|||
|
subschema entries.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 32]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Servers MAY provide additional attributes (described in other
|
|||
|
documents) in subschema (sub)entries.
|
|||
|
|
|||
|
Servers SHOULD provide the attributes 'createTimestamp' and
|
|||
|
'modifyTimestamp' in subschema (sub)entries, in order to allow
|
|||
|
clients to maintain their caches of schema information.
|
|||
|
|
|||
|
The following subsections provide attribute type definitions for each
|
|||
|
of schema definition attribute types.
|
|||
|
|
|||
|
4.2.1. 'objectClasses'
|
|||
|
|
|||
|
This attribute holds definitions of object classes.
|
|||
|
|
|||
|
( 2.5.21.6 NAME 'objectClasses'
|
|||
|
EQUALITY objectIdentifierFirstComponentMatch
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
|
|||
|
USAGE directoryOperation )
|
|||
|
|
|||
|
The 'objectIdentifierFirstComponentMatch' matching rule and the
|
|||
|
ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
4.2.2. 'attributeTypes'
|
|||
|
|
|||
|
This attribute holds definitions of attribute types.
|
|||
|
|
|||
|
( 2.5.21.5 NAME 'attributeTypes'
|
|||
|
EQUALITY objectIdentifierFirstComponentMatch
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
|
|||
|
USAGE directoryOperation )
|
|||
|
|
|||
|
The 'objectIdentifierFirstComponentMatch' matching rule and the
|
|||
|
AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
4.2.3. 'matchingRules'
|
|||
|
|
|||
|
This attribute holds definitions of matching rules.
|
|||
|
|
|||
|
( 2.5.21.4 NAME 'matchingRules'
|
|||
|
EQUALITY objectIdentifierFirstComponentMatch
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
|
|||
|
USAGE directoryOperation )
|
|||
|
|
|||
|
The 'objectIdentifierFirstComponentMatch' matching rule and the
|
|||
|
MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 33]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
4.2.4 'matchingRuleUse'
|
|||
|
|
|||
|
This attribute holds definitions of matching rule uses.
|
|||
|
|
|||
|
( 2.5.21.8 NAME 'matchingRuleUse'
|
|||
|
EQUALITY objectIdentifierFirstComponentMatch
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
|
|||
|
USAGE directoryOperation )
|
|||
|
|
|||
|
The 'objectIdentifierFirstComponentMatch' matching rule and the
|
|||
|
MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
4.2.5. 'ldapSyntaxes'
|
|||
|
|
|||
|
This attribute holds definitions of LDAP syntaxes.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The 'objectIdentifierFirstComponentMatch' matching rule and the
|
|||
|
SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
|
|||
|
in [RFC4517].
|
|||
|
|
|||
|
4.2.6. 'dITContentRules'
|
|||
|
|
|||
|
This attribute lists DIT Content Rules that are present in the
|
|||
|
subschema.
|
|||
|
|
|||
|
( 2.5.21.2 NAME 'dITContentRules'
|
|||
|
EQUALITY objectIdentifierFirstComponentMatch
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
|
|||
|
USAGE directoryOperation )
|
|||
|
|
|||
|
The 'objectIdentifierFirstComponentMatch' matching rule and the
|
|||
|
DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 34]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
4.2.7. 'dITStructureRules'
|
|||
|
|
|||
|
This attribute lists DIT Structure Rules that are present in the
|
|||
|
subschema.
|
|||
|
|
|||
|
( 2.5.21.1 NAME 'dITStructureRules'
|
|||
|
EQUALITY integerFirstComponentMatch
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
|
|||
|
USAGE directoryOperation )
|
|||
|
|
|||
|
The 'integerFirstComponentMatch' matching rule and the
|
|||
|
DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax
|
|||
|
are defined in [RFC4517].
|
|||
|
|
|||
|
4.2.8 'nameForms'
|
|||
|
|
|||
|
This attribute lists Name Forms that are in force.
|
|||
|
|
|||
|
( 2.5.21.7 NAME 'nameForms'
|
|||
|
EQUALITY objectIdentifierFirstComponentMatch
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
|
|||
|
USAGE directoryOperation )
|
|||
|
|
|||
|
The 'objectIdentifierFirstComponentMatch' matching rule and the
|
|||
|
NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
4.3. 'extensibleObject' object class
|
|||
|
|
|||
|
The 'extensibleObject' auxiliary object class allows entries that
|
|||
|
belong to it to hold any user attribute. The set of allowed
|
|||
|
attribute types of this object class is implicitly the set of all
|
|||
|
attribute types of userApplications usage.
|
|||
|
|
|||
|
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
|
|||
|
SUP top AUXILIARY )
|
|||
|
|
|||
|
The mandatory attributes of the other object classes of this entry
|
|||
|
are still required to be present, and any precluded attributes are
|
|||
|
still not allowed to be present.
|
|||
|
|
|||
|
4.4. Subschema Discovery
|
|||
|
|
|||
|
To discover the DN of the subschema (sub)entry holding the subschema
|
|||
|
controlling a particular entry, a client reads that entry's
|
|||
|
'subschemaSubentry' operational attribute. To read schema attributes
|
|||
|
from the subschema (sub)entry, clients MUST issue a Search operation
|
|||
|
[RFC4511] where baseObject is the DN of the subschema (sub)entry,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 35]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
|
|||
|
and the attributes field lists the names of the desired schema
|
|||
|
attributes (as they are operational). Note: the
|
|||
|
"(objectClass=subschema)" filter allows LDAP servers that gateway to
|
|||
|
X.500 to detect that subentry information is being requested.
|
|||
|
|
|||
|
Clients SHOULD NOT assume that a published subschema is complete,
|
|||
|
that the server supports all of the schema elements it publishes, or
|
|||
|
that the server does not support an unpublished element.
|
|||
|
|
|||
|
5. DSA (Server) Informational Model
|
|||
|
|
|||
|
The LDAP protocol assumes there are one or more servers that jointly
|
|||
|
provide access to a Directory Information Tree (DIT). The server
|
|||
|
holding the original information is called the "master" (for that
|
|||
|
information). Servers that hold copies of the original information
|
|||
|
are referred to as "shadowing" or "caching" servers.
|
|||
|
|
|||
|
|
|||
|
As defined in [X.501]:
|
|||
|
|
|||
|
context prefix: The sequence of RDNs leading from the Root of the
|
|||
|
DIT to the initial vertex of a naming context; corresponds to
|
|||
|
the distinguished name of that vertex.
|
|||
|
|
|||
|
naming context: A subtree of entries held in a single master DSA.
|
|||
|
|
|||
|
That is, a naming context is the largest collection of entries,
|
|||
|
starting at an entry that is mastered by a particular server, and
|
|||
|
including all its subordinates and their subordinates, down to the
|
|||
|
entries that are mastered by different servers. The context prefix
|
|||
|
is the name of the initial entry.
|
|||
|
|
|||
|
The root of the DIT is a DSA-specific Entry (DSE) and not part of any
|
|||
|
naming context (or any subtree); each server has different attribute
|
|||
|
values in the root DSE.
|
|||
|
|
|||
|
5.1. Server-Specific Data Requirements
|
|||
|
|
|||
|
An LDAP server SHALL provide information about itself and other
|
|||
|
information that is specific to each server. This is represented as
|
|||
|
a group of attributes located in the root DSE, which is named with
|
|||
|
the DN with zero RDNs (whose [RFC4514] representation is as the
|
|||
|
zero-length string).
|
|||
|
|
|||
|
These attributes are retrievable, subject to access control and other
|
|||
|
restrictions, if a client performs a Search operation [RFC4511] with
|
|||
|
an empty baseObject, scope of baseObject, the filter
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 36]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
"(objectClass=*)" [RFC4515], and the attributes field listing the
|
|||
|
names of the desired attributes. It is noted that root DSE
|
|||
|
attributes are operational and, like other operational attributes,
|
|||
|
are not returned in search requests unless requested by name.
|
|||
|
|
|||
|
The root DSE SHALL NOT be included if the client performs a subtree
|
|||
|
search starting from the root.
|
|||
|
|
|||
|
Servers may allow clients to modify attributes of the root DSE, where
|
|||
|
appropriate.
|
|||
|
|
|||
|
The following attributes of the root DSE are defined below.
|
|||
|
Additional attributes may be defined in other documents.
|
|||
|
|
|||
|
- altServer: alternative servers;
|
|||
|
|
|||
|
- namingContexts: naming contexts;
|
|||
|
|
|||
|
- supportedControl: recognized LDAP controls;
|
|||
|
|
|||
|
- supportedExtension: recognized LDAP extended operations;
|
|||
|
|
|||
|
- supportedFeatures: recognized LDAP features;
|
|||
|
|
|||
|
- supportedLDAPVersion: LDAP versions supported; and
|
|||
|
|
|||
|
- supportedSASLMechanisms: recognized Simple Authentication and
|
|||
|
Security Layers (SASL) [RFC4422] mechanisms.
|
|||
|
|
|||
|
The values provided for these attributes may depend on session-
|
|||
|
specific and other factors. For example, a server supporting the
|
|||
|
SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
|
|||
|
identity has been established by a lower level. See [RFC4513].
|
|||
|
|
|||
|
The root DSE may also include a 'subschemaSubentry' attribute. If it
|
|||
|
does, the attribute refers to the subschema (sub)entry holding the
|
|||
|
schema controlling the root DSE. Clients SHOULD NOT assume that this
|
|||
|
subschema (sub)entry controls other entries held by the server.
|
|||
|
General subschema discovery procedures are provided in Section 4.4.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 37]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
5.1.1. 'altServer'
|
|||
|
|
|||
|
The 'altServer' attribute lists URIs referring to alternative servers
|
|||
|
that may be contacted when this server becomes unavailable. URIs for
|
|||
|
servers implementing the LDAP are written according to [RFC4516].
|
|||
|
Other kinds of URIs may be provided. If the server does not know of
|
|||
|
any other servers that could be used, this attribute will be absent.
|
|||
|
Clients may cache this information in case their preferred server
|
|||
|
later becomes unavailable.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
|
|||
|
[RFC4517].
|
|||
|
|
|||
|
5.1.2. 'namingContexts'
|
|||
|
|
|||
|
The 'namingContexts' attribute lists the context prefixes of the
|
|||
|
naming contexts the server masters or shadows (in part or in whole).
|
|||
|
If the server is a first-level DSA [X.501], it should list (in
|
|||
|
addition) an empty string (indicating the root of the DIT). If the
|
|||
|
server does not master or shadow any information (e.g., it is an LDAP
|
|||
|
gateway to a public X.500 directory) this attribute will be absent.
|
|||
|
If the server believes it masters or shadows the entire directory,
|
|||
|
the attribute will have a single value, and that value will be the
|
|||
|
empty string (indicating the root of the DIT).
|
|||
|
|
|||
|
This attribute may be used, for example, to select a suitable entry
|
|||
|
name for subsequent operations with this server.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
5.1.3. 'supportedControl'
|
|||
|
|
|||
|
The 'supportedControl' attribute lists object identifiers identifying
|
|||
|
the request controls [RFC4511] the server supports. If the server
|
|||
|
does not support any request controls, this attribute will be absent.
|
|||
|
Object identifiers identifying response controls need not be listed.
|
|||
|
|
|||
|
Procedures for registering object identifiers used to discovery of
|
|||
|
protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 38]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
5.1.4. 'supportedExtension'
|
|||
|
|
|||
|
The 'supportedExtension' attribute lists object identifiers
|
|||
|
identifying the extended operations [RFC4511] that the server
|
|||
|
supports. If the server does not support any extended operations,
|
|||
|
this attribute will be absent.
|
|||
|
|
|||
|
An extended operation generally consists of an extended request and
|
|||
|
an extended response but may also include other protocol data units
|
|||
|
(such as intermediate responses). The object identifier assigned to
|
|||
|
the extended request is used to identify the extended operation.
|
|||
|
Other object identifiers used in the extended operation need not be
|
|||
|
listed as values of this attribute.
|
|||
|
|
|||
|
Procedures for registering object identifiers used to discovery of
|
|||
|
protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
5.1.5. 'supportedFeatures'
|
|||
|
|
|||
|
The 'supportedFeatures' attribute lists object identifiers
|
|||
|
identifying elective features that the server supports. If the
|
|||
|
server does not support any discoverable elective features, this
|
|||
|
attribute will be absent.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
Procedures for registering object identifiers used to discovery of
|
|||
|
protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
|
|||
|
|
|||
|
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
|
|||
|
objectIdentifierMatch matching rule are defined in [RFC4517].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 39]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
5.1.6. 'supportedLDAPVersion'
|
|||
|
|
|||
|
The 'supportedLDAPVersion' attribute lists the versions of LDAP that
|
|||
|
the server supports.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in
|
|||
|
[RFC4517].
|
|||
|
|
|||
|
5.1.7. 'supportedSASLMechanisms'
|
|||
|
|
|||
|
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
|
|||
|
[RFC4422] that the server recognizes and/or supports [RFC4513]. The
|
|||
|
contents of this attribute may depend on the current session state.
|
|||
|
If the server does not support any SASL mechanisms, this attribute
|
|||
|
will not be present.
|
|||
|
|
|||
|
( 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 )
|
|||
|
|
|||
|
The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
|
|||
|
defined in [RFC4517].
|
|||
|
|
|||
|
6. Other Considerations
|
|||
|
|
|||
|
6.1. Preservation of User Information
|
|||
|
|
|||
|
Syntaxes may be defined that have specific value and/or value form
|
|||
|
(representation) preservation requirements. For example, a syntax
|
|||
|
containing digitally signed data can mandate that the server preserve
|
|||
|
both the value and form of value presented to ensure that the
|
|||
|
signature is not invalidated.
|
|||
|
|
|||
|
Where such requirements have not been explicitly stated, servers
|
|||
|
SHOULD preserve the value of user information but MAY return the
|
|||
|
value in a different form. And where a server is unable (or
|
|||
|
unwilling) to preserve the value of user information, the server
|
|||
|
SHALL ensure that an equivalent value (per Section 2.3) is returned.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 40]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
6.2. Short Names
|
|||
|
|
|||
|
Short names, also known as descriptors, are used as more readable
|
|||
|
aliases for object identifiers and are used to identify various
|
|||
|
schema elements. However, it is not expected that LDAP
|
|||
|
implementations with human user interface would display these short
|
|||
|
names (or the object identifiers they refer to) to the user.
|
|||
|
Instead, they would most likely be performing translations (such as
|
|||
|
expressing the short name in one of the local national languages).
|
|||
|
For example, the short name "st" (stateOrProvinceName) might be
|
|||
|
displayed to a German-speaking user as "Land".
|
|||
|
|
|||
|
The same short name might have different meaning in different
|
|||
|
subschemas, and, within a particular subschema, the same short name
|
|||
|
might refer to different object identifiers each identifying a
|
|||
|
different kind of schema element.
|
|||
|
|
|||
|
Implementations MUST be prepared that the same short name might be
|
|||
|
used in a subschema to refer to the different kinds of schema
|
|||
|
elements. That is, there might be an object class 'x-fubar' and an
|
|||
|
attribute type 'x-fubar' in a subschema.
|
|||
|
|
|||
|
Implementations MUST be prepared that the same short name might be
|
|||
|
used in the different subschemas to refer to the different schema
|
|||
|
elements. That is, there might be two matching rules 'x-fubar', each
|
|||
|
in different subschemas.
|
|||
|
|
|||
|
Procedures for registering short names (descriptors) are detailed in
|
|||
|
BCP 64, RFC 4520 [RFC4520].
|
|||
|
|
|||
|
6.3. Cache and Shadowing
|
|||
|
|
|||
|
Some servers may hold cache or shadow copies of entries, which can be
|
|||
|
used to answer search and comparison queries, but will return
|
|||
|
referrals or contact other servers if modification operations are
|
|||
|
requested. Servers that perform shadowing or caching MUST ensure
|
|||
|
that they do not violate any access control constraints placed on the
|
|||
|
data by the originating server.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 41]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
7. Implementation Guidelines
|
|||
|
|
|||
|
7.1. Server Guidelines
|
|||
|
|
|||
|
Servers MUST recognize all names of attribute types and object
|
|||
|
classes defined in this document but, unless stated otherwise, need
|
|||
|
not support the associated functionality. Servers SHOULD recognize
|
|||
|
all the names of attribute types and object classes defined in
|
|||
|
Section 3 and 4, respectively, of [RFC4519].
|
|||
|
|
|||
|
Servers MUST ensure that entries conform to user and system schema
|
|||
|
rules or other data model constraints.
|
|||
|
|
|||
|
Servers MAY support DIT Content Rules. Servers MAY support DIT
|
|||
|
Structure Rules and Name Forms.
|
|||
|
|
|||
|
Servers MAY support alias entries.
|
|||
|
|
|||
|
Servers MAY support the 'extensibleObject' object class.
|
|||
|
|
|||
|
Servers MAY support subentries. If so, they MUST do so in accordance
|
|||
|
with [RFC3672]. Servers that do not support subentries SHOULD use
|
|||
|
object entries to mimic subentries as detailed in Section 3.2.
|
|||
|
|
|||
|
Servers MAY implement additional schema elements. Servers SHOULD
|
|||
|
provide definitions of all schema elements they support in subschema
|
|||
|
(sub)entries.
|
|||
|
|
|||
|
7.2. Client Guidelines
|
|||
|
|
|||
|
In the absence of prior agreements with servers, clients SHOULD NOT
|
|||
|
assume that servers support any particular schema elements beyond
|
|||
|
those referenced in Section 7.1. The client can retrieve subschema
|
|||
|
information as described in Section 4.4.
|
|||
|
|
|||
|
Clients MUST NOT display or attempt to decode a value as ASN.1 if the
|
|||
|
value's syntax is not known. Clients MUST NOT assume the LDAP-
|
|||
|
specific string encoding is restricted to a UTF-8 encoded string of
|
|||
|
Unicode characters or any particular subset of Unicode (such as a
|
|||
|
printable subset) unless such restriction is explicitly stated.
|
|||
|
Clients SHOULD NOT send attribute values in a request that are not
|
|||
|
valid according to the syntax defined for the attributes.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 42]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
8. Security Considerations
|
|||
|
|
|||
|
Attributes of directory entries are used to provide descriptive
|
|||
|
information about the real-world objects they represent, which can be
|
|||
|
people, organizations, or devices. Most countries have privacy laws
|
|||
|
regarding the publication of information about people.
|
|||
|
|
|||
|
General security considerations for accessing directory information
|
|||
|
with LDAP are discussed in [RFC4511] and [RFC4513].
|
|||
|
|
|||
|
9. IANA Considerations
|
|||
|
|
|||
|
The Internet Assigned Numbers Authority (IANA) has updated the LDAP
|
|||
|
descriptors registry as indicated in the following template:
|
|||
|
|
|||
|
Subject: Request for LDAP Descriptor Registration Update
|
|||
|
Descriptor (short name): see comment
|
|||
|
Object Identifier: see comment
|
|||
|
Person & email address to contact for further information:
|
|||
|
Kurt Zeilenga <kurt@OpenLDAP.org>
|
|||
|
Usage: see comment
|
|||
|
Specification: RFC 4512
|
|||
|
Author/Change Controller: IESG
|
|||
|
Comments:
|
|||
|
|
|||
|
The following descriptors (short names) has been added to
|
|||
|
the registry.
|
|||
|
|
|||
|
NAME Type OID
|
|||
|
------------------------ ---- -----------------
|
|||
|
governingStructureRule A 2.5.21.10
|
|||
|
structuralObjectClass A 2.5.21.9
|
|||
|
|
|||
|
The following descriptors (short names) have been updated to
|
|||
|
refer to this RFC.
|
|||
|
|
|||
|
NAME Type 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 43]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
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. Acknowledgements
|
|||
|
|
|||
|
This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
|
|||
|
S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
|
|||
|
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
|
|||
|
Indexing of Directories (ASID) Working Group. This document is also
|
|||
|
based in part on "The Directory: Models" [X.501], a product of the
|
|||
|
International Telephone Union (ITU). Additional text was borrowed
|
|||
|
from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
|
|||
|
|
|||
|
This document is a product of the IETF LDAP Revision (LDAPBIS)
|
|||
|
Working Group.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 44]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
11. Normative References
|
|||
|
|
|||
|
[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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 45]
|
|||
|
|
|||
|
RFC 4512 LDAP Models 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).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 46]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Appendix A. Changes
|
|||
|
|
|||
|
This appendix is non-normative.
|
|||
|
|
|||
|
This document amounts to nearly a complete rewrite of portions of RFC
|
|||
|
2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
|
|||
|
overall clarity of technical specification. This appendix provides a
|
|||
|
summary of substantive changes made to the portions of these
|
|||
|
documents incorporated into this document. Readers should consult
|
|||
|
[RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of
|
|||
|
remaining portions of these documents.
|
|||
|
|
|||
|
A.1. Changes to RFC 2251
|
|||
|
|
|||
|
This document incorporates from RFC 2251, Sections 3.2 and 3.4, and
|
|||
|
portions of Sections 4 and 6 as summarized below.
|
|||
|
|
|||
|
A.1.1. Section 3.2 of RFC 2251
|
|||
|
|
|||
|
Section 3.2 of RFC 2251 provided a brief introduction to the X.500
|
|||
|
data model, as used by LDAP. The previous specification relied on
|
|||
|
[X.501] but lacked clarity in how X.500 models are adapted for use by
|
|||
|
LDAP. This document describes the X.500 data models, as used by
|
|||
|
LDAP, in greater detail, especially in areas where adaptation is
|
|||
|
needed.
|
|||
|
|
|||
|
Section 3.2.1 of RFC 2251 described an attribute as "a type with one
|
|||
|
or more associated values". In LDAP, an attribute is better
|
|||
|
described as an attribute description, a type with zero or more
|
|||
|
options, and one or more associated values.
|
|||
|
|
|||
|
Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
|
|||
|
objectClasses and attributeTypes attributes, yet X.500(93) treats
|
|||
|
these attributes as optional. While generally all implementations
|
|||
|
that support X.500(93) subschema mechanisms will provide both of
|
|||
|
these attributes, it is not absolutely required for interoperability
|
|||
|
that all servers do. The mandate was removed for consistency with
|
|||
|
X.500(93). The subschema discovery mechanism was also clarified to
|
|||
|
indicate that subschema controlling an entry is obtained by reading
|
|||
|
the (sub)entry referred to by that entry's 'subschemaSubentry'
|
|||
|
attribute.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 47]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
A.1.2. Section 3.4 of RFC 2251
|
|||
|
|
|||
|
Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
|
|||
|
This material, with changes, was incorporated in Section 5.1 of this
|
|||
|
document.
|
|||
|
|
|||
|
Changes:
|
|||
|
|
|||
|
- Clarify that attributes of the root DSE are subject to "other
|
|||
|
restrictions" in addition to access controls.
|
|||
|
|
|||
|
- Clarify that only recognized extended requests need to be
|
|||
|
enumerated 'supportedExtension'.
|
|||
|
|
|||
|
- Clarify that only recognized request controls need to be enumerated
|
|||
|
'supportedControl'.
|
|||
|
|
|||
|
- Clarify that root DSE attributes are operational and, like other
|
|||
|
operational attributes, will not be returned in search requests
|
|||
|
unless requested by name.
|
|||
|
|
|||
|
- Clarify that not all root DSE attributes are user modifiable.
|
|||
|
|
|||
|
- Remove inconsistent text regarding handling of the
|
|||
|
'subschemaSubentry' attribute within the root DSE. The previous
|
|||
|
specification stated that the 'subschemaSubentry' attribute held in
|
|||
|
the root DSE referred to "subschema entries (or subentries) known
|
|||
|
by this server". This is inconsistent with the attribute's
|
|||
|
intended use as well as its formal definition as a single valued
|
|||
|
attribute [X.501]. It is also noted that a simple (possibly
|
|||
|
incomplete) list of subschema (sub)entries is not terribly useful.
|
|||
|
This document (in Section 5.1) specifies that the
|
|||
|
'subschemaSubentry' attribute of the root DSE refers to the
|
|||
|
subschema controlling the root DSE. It is noted that the general
|
|||
|
subschema discovery mechanism remains available (see Section 4.4 of
|
|||
|
this document).
|
|||
|
|
|||
|
A.1.3. Section 4 of RFC 2251
|
|||
|
|
|||
|
Portions of Section 4 of RFC 2251 detailing aspects of the
|
|||
|
information model used by LDAP were incorporated in this document,
|
|||
|
including:
|
|||
|
|
|||
|
- Restriction of distinguished values to attributes whose
|
|||
|
descriptions have no options (from Section 4.1.3);
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 48]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
- Data model aspects of Attribute Types (from Section 4.1.4),
|
|||
|
Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
|
|||
|
Matching Rule Identifier (from 4.1.9); and
|
|||
|
|
|||
|
- User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
|
|||
|
|
|||
|
Clarifications to these portions include:
|
|||
|
|
|||
|
- Subtyping and AttributeDescriptions with options.
|
|||
|
|
|||
|
A.1.4. Section 6 of RFC 2251
|
|||
|
|
|||
|
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
|
|||
|
where incorporated into this document.
|
|||
|
|
|||
|
A.2. Changes to RFC 2252
|
|||
|
|
|||
|
This document incorporates Sections 4, 5, and 7 from RFC 2252.
|
|||
|
|
|||
|
A.2.1. Section 4 of RFC 2252
|
|||
|
|
|||
|
The specification was updated to use Augmented BNF [RFC4234]. The
|
|||
|
string representation of an OBJECT IDENTIFIER was tightened to
|
|||
|
disallow leading zeros as described in RFC 2252.
|
|||
|
|
|||
|
The <descr> syntax was changed to disallow semicolon (U+003B)
|
|||
|
characters in order to appear to be consistent its natural language
|
|||
|
specification "descr is the syntactic representation of an object
|
|||
|
descriptor, which consists of letters and digits, starting with a
|
|||
|
letter". In a related change, the statement "an AttributeDescription
|
|||
|
can be used as the value in a NAME part of an
|
|||
|
AttributeTypeDescription" was deleted. RFC 2252 provided no
|
|||
|
specification of the semantics of attribute options appearing in NAME
|
|||
|
fields.
|
|||
|
|
|||
|
RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
|
|||
|
over the <numericoid> form. However, <descr> form can be ambiguous.
|
|||
|
To address this issue, the imperative was replaced with a statement
|
|||
|
(in Section 1.4) that while the <descr> form is generally preferred,
|
|||
|
<numericoid> should be used where an unambiguous <descr> is not
|
|||
|
available. Additionally, an expanded discussion of descriptor issues
|
|||
|
is in Section 6.2 ("Short Names").
|
|||
|
|
|||
|
The ABNF for a quoted string (qdstring) was updated to reflect
|
|||
|
support for the escaping mechanism described in Section 4.3 of RFC
|
|||
|
2252.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 49]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
A.2.2. Section 5 of RFC 2252
|
|||
|
|
|||
|
Definitions of operational attributes provided in Section 5 of RFC
|
|||
|
2252 where incorporated into this document.
|
|||
|
|
|||
|
The 'namingContexts' description was clarified. A first-level DSA
|
|||
|
should publish, in addition to other values, "" indicating the root
|
|||
|
of the DIT.
|
|||
|
|
|||
|
The 'altServer' description was clarified. It may hold any URI.
|
|||
|
|
|||
|
The 'supportedExtension' description was clarified. A server need
|
|||
|
only list the OBJECT IDENTIFIERs associated with the extended
|
|||
|
requests of the extended operations it recognizes.
|
|||
|
|
|||
|
The 'supportedControl' description was clarified. A server need only
|
|||
|
list the OBJECT IDENTIFIERs associated with the request controls it
|
|||
|
recognizes.
|
|||
|
|
|||
|
Descriptions for the 'structuralObjectClass' and
|
|||
|
'governingStructureRule' operational attribute types were added.
|
|||
|
|
|||
|
The attribute definition of 'subschemaSubentry' was corrected to list
|
|||
|
the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
|
|||
|
|
|||
|
A.2.3. Section 7 of RFC 2252
|
|||
|
|
|||
|
Section 7 of RFC 2252 provides definitions of the 'subschema' and
|
|||
|
'extensibleObject' object classes. These definitions where
|
|||
|
integrated into Section 4.2 and Section 4.3 of this document,
|
|||
|
respectively. Section 7 of RFC 2252 also contained the object class
|
|||
|
implementation requirement. This was incorporated into Section 7 of
|
|||
|
this document.
|
|||
|
|
|||
|
The specification of 'extensibleObject' was clarified regarding how
|
|||
|
it interacts with precluded attributes.
|
|||
|
|
|||
|
A.3. Changes to RFC 2256
|
|||
|
|
|||
|
This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
|
|||
|
2256.
|
|||
|
|
|||
|
Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
|
|||
|
attribute type. This was integrated into Section 2.4.1 of this
|
|||
|
document. The statement "One of the values is either 'top' or
|
|||
|
'alias'" was replaced with statement that one of the values is 'top'
|
|||
|
as entries belonging to 'alias' also belong to 'top'.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 50]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Section 5.2 of RFC 2256 provided the definition of the
|
|||
|
'aliasedObjectName' attribute type. This was integrated into Section
|
|||
|
2.6.2 of this document.
|
|||
|
|
|||
|
Section 7.1 of RFC 2256 provided the definition of the 'top' object
|
|||
|
class. This was integrated into Section 2.4.1 of this document.
|
|||
|
|
|||
|
Section 7.2 of RFC 2256 provided the definition of the 'alias' object
|
|||
|
class. This was integrated into Section 2.6.1 of this document.
|
|||
|
|
|||
|
A.4. Changes to RFC 3674
|
|||
|
|
|||
|
This document made no substantive change to the 'supportedFeatures'
|
|||
|
technical specification provided in RFC 3674.
|
|||
|
|
|||
|
Editor's Address
|
|||
|
|
|||
|
Kurt D. Zeilenga
|
|||
|
OpenLDAP Foundation
|
|||
|
|
|||
|
EMail: Kurt@OpenLDAP.org
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 51]
|
|||
|
|
|||
|
RFC 4512 LDAP Models June 2006
|
|||
|
|
|||
|
|
|||
|
Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (2006).
|
|||
|
|
|||
|
This document is subject to the rights, licenses and restrictions
|
|||
|
contained in BCP 78, and except as set forth therein, the authors
|
|||
|
retain all their rights.
|
|||
|
|
|||
|
This document and the information contained herein are provided on an
|
|||
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|||
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|||
|
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|||
|
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|||
|
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|||
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|||
|
Intellectual Property
|
|||
|
|
|||
|
The IETF takes no position regarding the validity or scope of any
|
|||
|
Intellectual Property Rights or other rights that might be claimed to
|
|||
|
pertain to the implementation or use of the technology described in
|
|||
|
this document or the extent to which any license under such rights
|
|||
|
might or might not be available; nor does it represent that it has
|
|||
|
made any independent effort to identify any such rights. Information
|
|||
|
on the procedures with respect to rights in RFC documents can be
|
|||
|
found in BCP 78 and BCP 79.
|
|||
|
|
|||
|
Copies of IPR disclosures made to the IETF Secretariat and any
|
|||
|
assurances of licenses to be made available, or the result of an
|
|||
|
attempt made to obtain a general license or permission for the use of
|
|||
|
such proprietary rights by implementers or users of this
|
|||
|
specification can be obtained from the IETF on-line IPR repository at
|
|||
|
http://www.ietf.org/ipr.
|
|||
|
|
|||
|
The IETF invites any interested party to bring to its attention any
|
|||
|
copyrights, patents or patent applications, or other proprietary
|
|||
|
rights that may cover technology that may be required to implement
|
|||
|
this standard. Please address the information to the IETF at
|
|||
|
ietf-ipr@ietf.org.
|
|||
|
|
|||
|
Acknowledgement
|
|||
|
|
|||
|
Funding for the RFC Editor function is provided by the IETF
|
|||
|
Administrative Support Activity (IASA).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga Standards Track [Page 52]
|
|||
|
|