7
Network Working Group K. Zeilenga
8
Request for Comments: 4512 OpenLDAP Foundation
9
Obsoletes: 2251, 2252, 2256, 3674 June 2006
10
Category: Standards Track
13
Lightweight Directory Access Protocol (LDAP):
14
Directory Information Models
18
This document specifies an Internet standards track protocol for the
19
Internet community, and requests discussion and suggestions for
20
improvements. Please refer to the current edition of the "Internet
21
Official Protocol Standards" (STD 1) for the standardization state
22
and status of this protocol. Distribution of this memo is unlimited.
26
Copyright (C) The Internet Society (2006).
30
The Lightweight Directory Access Protocol (LDAP) is an Internet
31
protocol for accessing distributed directory services that act in
32
accordance with X.500 data and service models. This document
33
describes the X.500 Directory Information Models, as used in LDAP.
58
Zeilenga Standards Track [Page 1]
60
RFC 4512 LDAP Models June 2006
65
1. Introduction ....................................................3
66
1.1. Relationship to Other LDAP Specifications ..................3
67
1.2. Relationship to X.501 ......................................4
68
1.3. Conventions ................................................4
69
1.4. Common ABNF Productions ....................................4
70
2. Model of Directory User Information .............................6
71
2.1. The Directory Information Tree .............................7
72
2.2. Structure of an Entry ......................................7
73
2.3. Naming of Entries ..........................................8
74
2.4. Object Classes .............................................9
75
2.5. Attribute Descriptions ....................................12
76
2.6. Alias Entries .............................................16
77
3. Directory Administrative and Operational Information ...........17
78
3.1. Subtrees ..................................................17
79
3.2. Subentries ................................................18
80
3.3. The 'objectClass' attribute ...............................18
81
3.4. Operational Attributes ....................................19
82
4. Directory Schema ...............................................22
83
4.1. Schema Definitions ........................................23
84
4.2. Subschema Subentries ......................................32
85
4.3. 'extensibleObject' object class ...........................35
86
4.4. Subschema Discovery .......................................35
87
5. DSA (Server) Informational Model ...............................36
88
5.1. Server-Specific Data Requirements .........................36
89
6. Other Considerations ...........................................40
90
6.1. Preservation of User Information ..........................40
91
6.2. Short Names ...............................................41
92
6.3. Cache and Shadowing .......................................41
93
7. Implementation Guidelines ......................................42
94
7.1. Server Guidelines .........................................42
95
7.2. Client Guidelines .........................................42
96
8. Security Considerations ........................................43
97
9. IANA Considerations ............................................43
98
10. Acknowledgements ..............................................44
99
11. Normative References ..........................................45
100
Appendix A. Changes ...............................................47
101
A.1. Changes to RFC 2251 .......................................47
102
A.2. Changes to RFC 2252 .......................................49
103
A.3. Changes to RFC 2256 .......................................50
104
A.4. Changes to RFC 3674 .......................................51
114
Zeilenga Standards Track [Page 2]
116
RFC 4512 LDAP Models June 2006
121
This document discusses the X.500 Directory Information Models
122
[X.501], as used by the Lightweight Directory Access Protocol (LDAP)
125
The Directory is "a collection of open systems cooperating to provide
126
directory services" [X.500]. The information held in the Directory
127
is collectively known as the Directory Information Base (DIB). A
128
Directory user, which may be a human or other entity, accesses the
129
Directory through a client (or Directory User Agent (DUA)). The
130
client, on behalf of the directory user, interacts with one or more
131
servers (or Directory System Agents (DSA)). A server holds a
134
The DIB contains two classes of information:
136
1) user information (e.g., information provided and administrated
137
by users). Section 2 describes the Model of User Information.
139
2) administrative and operational information (e.g., information
140
used to administer and/or operate the directory). Section 3
141
describes the model of Directory Administrative and Operational
144
These two models, referred to as the generic Directory Information
145
Models, describe how information is represented in the Directory.
146
These generic models provide a framework for other information
147
models. Section 4 discusses the subschema information model and
148
subschema discovery. Section 5 discusses the DSA (Server)
151
Other X.500 information models (such as access control distribution
152
knowledge and replication knowledge information models) may be
153
adapted for use in LDAP. Specification of how these models apply to
154
LDAP is left to future documents.
156
1.1. Relationship to Other LDAP Specifications
158
This document is a integral part of the LDAP technical specification
159
[RFC4510], which obsoletes the previously defined LDAP technical
160
specification, RFC 3377, in its entirety.
162
This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
163
portions of Sections 4 and 6. Appendix A.1 summarizes changes to
164
these sections. The remainder of RFC 2251 is obsoleted by the
165
[RFC4511], [RFC4513], and [RFC4510] documents.
170
Zeilenga Standards Track [Page 3]
172
RFC 4512 LDAP Models June 2006
175
This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2
176
summarizes changes to these sections. The remainder of RFC 2252 is
177
obsoleted by [RFC4517].
179
This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
180
Appendix A.3 summarizes changes to these sections. The remainder of
181
RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
183
This document obsoletes RFC 3674 in its entirety. Appendix A.4
184
summarizes changes since RFC 3674.
186
1.2. Relationship to X.501
188
This document includes material, with and without adaptation, from
189
[X.501] as necessary to describe this protocol. These adaptations
190
(and any other differences herein) apply to this protocol, and only
195
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
196
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
197
document are to be interpreted as described in BCP 14 [RFC2119].
199
Schema definitions are provided using LDAP description formats (as
200
defined in Section 4.1). Definitions provided here are formatted
201
(line wrapped) for readability. Matching rules and LDAP syntaxes
202
referenced in these definitions are specified in [RFC4517].
204
1.4. Common ABNF Productions
206
A number of syntaxes in this document are described using Augmented
207
Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a
208
number of syntaxes defined in other documents) rely on the following
211
keystring = leadkeychar *keychar
213
keychar = ALPHA / DIGIT / HYPHEN
214
number = DIGIT / ( LDIGIT 1*DIGIT )
216
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
217
DIGIT = %x30 / LDIGIT ; "0"-"9"
218
LDIGIT = %x31-39 ; "1"-"9"
219
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
221
SP = 1*SPACE ; one or more " "
222
WSP = 0*SPACE ; zero or more " "
226
Zeilenga Standards Track [Page 4]
228
RFC 4512 LDAP Models June 2006
231
NULL = %x00 ; null (0)
232
SPACE = %x20 ; space (" ")
233
DQUOTE = %x22 ; quote (""")
234
SHARP = %x23 ; octothorpe (or sharp sign) ("#")
235
DOLLAR = %x24 ; dollar sign ("$")
236
SQUOTE = %x27 ; single quote ("'")
237
LPAREN = %x28 ; left paren ("(")
238
RPAREN = %x29 ; right paren (")")
239
PLUS = %x2B ; plus sign ("+")
240
COMMA = %x2C ; comma (",")
241
HYPHEN = %x2D ; hyphen ("-")
242
DOT = %x2E ; period (".")
243
SEMI = %x3B ; semicolon (";")
244
LANGLE = %x3C ; left angle bracket ("<")
245
EQUALS = %x3D ; equals sign ("=")
246
RANGLE = %x3E ; right angle bracket (">")
247
ESC = %x5C ; backslash ("\")
248
USCORE = %x5F ; underscore ("_")
249
LCURLY = %x7B ; left curly brace "{"
250
RCURLY = %x7D ; right curly brace "}"
252
; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
254
UTFMB = UTF2 / UTF3 / UTF4
258
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
259
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
260
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
263
OCTET = %x00-FF ; Any octet (8-bit data unit)
265
Object identifiers (OIDs) [X.680] are represented in LDAP using a
266
dot-decimal format conforming to the ABNF:
268
numericoid = number 1*( DOT number )
270
Short names, also known as descriptors, are used as more readable
271
aliases for object identifiers. Short names are case insensitive and
282
Zeilenga Standards Track [Page 5]
284
RFC 4512 LDAP Models June 2006
287
Where either an object identifier or a short name may be specified,
288
the following production is used:
290
oid = descr / numericoid
292
While the <descr> form is generally preferred when the usage is
293
restricted to short names referring to object identifiers that
294
identify like kinds of objects (e.g., attribute type descriptions,
295
matching rule descriptions, object class descriptions), the
296
<numericoid> form should be used when the object identifiers may
297
identify multiple kinds of objects or when an unambiguous short name
298
(descriptor) is not available.
300
Implementations SHOULD treat short names (descriptors) used in an
301
ambiguous manner (as discussed above) as unrecognized.
303
Short Names (descriptors) are discussed further in Section 6.2.
305
2. Model of Directory User Information
309
The purpose of the Directory is to hold, and provide access to,
310
information about objects of interest (objects) in some 'world'.
311
An object can be anything which is identifiable (can be named).
313
An object class is an identified family of objects, or conceivable
314
objects, which share certain characteristics. Every object
315
belongs to at least one class. An object class may be a subclass
316
of other object classes, in which case the members of the former
317
class, the subclass, are also considered to be members of the
318
latter classes, the superclasses. There may be subclasses of
319
subclasses, etc., to an arbitrary depth.
321
A directory entry, a named collection of information, is the basic
322
unit of information held in the Directory. There are multiple kinds
323
of directory entries.
325
An object entry represents a particular object. An alias entry
326
provides alternative naming. A subentry holds administrative and/or
327
operational information.
329
The set of entries representing the DIB are organized hierarchically
330
in a tree structure known as the Directory Information Tree (DIT).
332
Section 2.1 describes the Directory Information Tree.
333
Section 2.2 discusses the structure of entries.
334
Section 2.3 discusses naming of entries.
338
Zeilenga Standards Track [Page 6]
340
RFC 4512 LDAP Models June 2006
343
Section 2.4 discusses object classes.
344
Section 2.5 discusses attribute descriptions.
345
Section 2.6 discusses alias entries.
347
2.1. The Directory Information Tree
349
As noted above, the DIB is composed of a set of entries organized
350
hierarchically in a tree structure known as the Directory Information
351
Tree (DIT); specifically, a tree where vertices are the entries.
353
The arcs between vertices define relations between entries. If an
354
arc exists from X to Y, then the entry at X is the immediate superior
355
of Y, and Y is the immediate subordinate of X. An entry's superiors
356
are the entry's immediate superior and its superiors. An entry's
357
subordinates are all of its immediate subordinates and their
360
Similarly, the superior/subordinate relationship between object
361
entries can be used to derive a relation between the objects they
362
represent. DIT structure rules can be used to govern relationships
365
Note: An entry's immediate superior is also known as the entry's
366
parent, and an entry's immediate subordinate is also known as
367
the entry's child. Entries that have the same parent are known
370
2.2. Structure of an Entry
372
An entry consists of a set of attributes that hold information about
373
the object that the entry represents. Some attributes represent user
374
information and are called user attributes. Other attributes
375
represent operational and/or administrative information and are
376
called operational attributes.
378
An attribute is an attribute description (a type and zero or more
379
options) with one or more associated values. An attribute is often
380
referred to by its attribute description. For example, the
381
'givenName' attribute is the attribute that consists of the attribute
382
description 'givenName' (the 'givenName' attribute type [RFC4519] and
383
zero options) and one or more associated values.
385
The attribute type governs whether the attribute can have multiple
386
values, the syntax and matching rules used to construct and compare
387
values of that attribute, and other functions. Options indicate
388
subtypes and other functions.
390
Attribute values conform to the defined syntax of the attribute type.
394
Zeilenga Standards Track [Page 7]
396
RFC 4512 LDAP Models June 2006
399
No two values of an attribute may be equivalent. Two values are
400
considered equivalent if and only if they would match according to
401
the equality matching rule of the attribute type. Or, if the
402
attribute type is defined with no equality matching rule, two values
403
are equivalent if and only if they are identical. (See 2.5.1 for
406
For example, a 'givenName' attribute can have more than one value,
407
they must be Directory Strings, and they are case insensitive. A
408
'givenName' attribute cannot hold both "John" and "JOHN", as these
409
are equivalent values per the equality matching rule of the attribute
412
Additionally, no attribute is to have a value that is not equivalent
413
to itself. For example, the 'givenName' attribute cannot have as a
414
value a directory string that includes the REPLACEMENT CHARACTER
415
(U+FFFD) code point, as matching involving that directory string is
416
Undefined per this attribute's equality matching rule.
418
When an attribute is used for naming of the entry, one and only one
419
value of the attribute is used in forming the Relative Distinguished
420
Name. This value is known as a distinguished value.
422
2.3. Naming of Entries
424
2.3.1. Relative Distinguished Names
426
Each entry is named relative to its immediate superior. This
427
relative name, known as its Relative Distinguished Name (RDN)
428
[X.501], is composed of an unordered set of one or more attribute
429
value assertions (AVA) consisting of an attribute description with
430
zero options and an attribute value. These AVAs are chosen to match
431
attribute values (each a distinguished value) of the entry.
433
An entry's relative distinguished name must be unique among all
434
immediate subordinates of the entry's immediate superior (i.e., all
437
The following are examples of string representations of RDNs
442
CN=Kurt Zeilenga+L=Redwood Shores
444
The last is an example of a multi-valued RDN; that is, an RDN
445
composed of multiple AVAs.
450
Zeilenga Standards Track [Page 8]
452
RFC 4512 LDAP Models June 2006
455
2.3.2. Distinguished Names
457
An entry's fully qualified name, known as its Distinguished Name (DN)
458
[X.501], is the concatenation of its RDN and its immediate superior's
459
DN. A Distinguished Name unambiguously refers to an entry in the
460
tree. The following are examples of string representations of DNs
463
UID=nobody@example.com,DC=example,DC=com
464
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
468
An alias, or alias name, is "an name for an object, provided by the
469
use of alias entries" [X.501]. Alias entries are described in
474
An object class is "an identified family of objects (or conceivable
475
objects) that share certain characteristics" [X.501].
477
As defined in [X.501]:
479
Object classes are used in the Directory for a number of purposes:
481
- describing and categorizing objects and the entries that
482
correspond to these objects;
484
- where appropriate, controlling the operation of the Directory;
486
- regulating, in conjunction with DIT structure rule
487
specifications, the position of entries in the DIT;
489
- regulating, in conjunction with DIT content rule
490
specifications, the attributes that are contained in entries;
492
- identifying classes of entry that are to be associated with a
493
particular policy by the appropriate administrative authority.
495
An object class (a subclass) may be derived from an object class
496
(its direct superclass) which is itself derived from an even more
497
generic object class. For structural object classes, this process
498
stops at the most generic object class, 'top' (defined in Section
499
2.4.1). An ordered set of superclasses up to the most superior
500
object class of an object class is its superclass chain.
506
Zeilenga Standards Track [Page 9]
508
RFC 4512 LDAP Models June 2006
511
An object class may be derived from two or more direct
512
superclasses (superclasses not part of the same superclass chain).
513
This feature of subclassing is termed multiple inheritance.
515
Each object class identifies the set of attributes required to be
516
present in entries belonging to the class and the set of attributes
517
allowed to be present in entries belonging to the class. As an entry
518
of a class must meet the requirements of each class it belongs to, it
519
can be said that an object class inherits the sets of allowed and
520
required attributes from its superclasses. A subclass can identify
521
an attribute allowed by its superclass as being required. If an
522
attribute is a member of both sets, it is required to be present.
524
Each object class is defined to be one of three kinds of object
525
classes: Abstract, Structural, or Auxiliary.
527
Each object class is identified by an object identifier (OID) and,
528
optionally, one or more short names (descriptors).
530
2.4.1. Abstract Object Classes
532
An abstract object class, as the name implies, provides a base of
533
characteristics from which other object classes can be defined to
534
inherit from. An entry cannot belong to an abstract object class
535
unless it belongs to a structural or auxiliary class that inherits
536
from that abstract class.
538
Abstract object classes cannot derive from structural or auxiliary
541
All structural object classes derive (directly or indirectly) from
542
the 'top' abstract object class. Auxiliary object classes do not
543
necessarily derive from 'top'.
545
The following is the object class definition (see Section 4.1.1) for
546
the 'top' object class:
548
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
550
All entries belong to the 'top' abstract object class.
562
Zeilenga Standards Track [Page 10]
564
RFC 4512 LDAP Models June 2006
567
2.4.2. Structural Object Classes
569
As stated in [X.501]:
571
An object class defined for use in the structural specification of
572
the DIT is termed a structural object class. Structural object
573
classes are used in the definition of the structure of the names
574
of the objects for compliant entries.
576
An object or alias entry is characterized by precisely one
577
structural object class superclass chain which has a single
578
structural object class as the most subordinate object class.
579
This structural object class is referred to as the structural
580
object class of the entry.
582
Structural object classes are related to associated entries:
584
- an entry conforming to a structural object class shall
585
represent the real-world object constrained by the object
588
- DIT structure rules only refer to structural object classes;
589
the structural object class of an entry is used to specify the
590
position of the entry in the DIT;
592
- the structural object class of an entry is used, along with an
593
associated DIT content rule, to control the content of an
596
The structural object class of an entry shall not be changed.
598
Each structural object class is a (direct or indirect) subclass of
599
the 'top' abstract object class.
601
Structural object classes cannot subclass auxiliary object classes.
603
Each entry is said to belong to its structural object class as well
604
as all classes in its structural object class's superclass chain.
606
2.4.3. Auxiliary Object Classes
608
Auxiliary object classes are used to augment the characteristics of
609
entries. They are commonly used to augment the sets of attributes
610
required and allowed to be present in an entry. They can be used to
611
describe entries or classes of entries.
613
Auxiliary object classes cannot subclass structural object classes.
618
Zeilenga Standards Track [Page 11]
620
RFC 4512 LDAP Models June 2006
623
An entry can belong to any subset of the set of auxiliary object
624
classes allowed by the DIT content rule associated with the
625
structural object class of the entry. If no DIT content rule is
626
associated with the structural object class of the entry, the entry
627
cannot belong to any auxiliary object class.
629
The set of auxiliary object classes that an entry belongs to can
632
2.5. Attribute Descriptions
634
An attribute description is composed of an attribute type (see
635
Section 2.5.1) and a set of zero or more attribute options (see
638
An attribute description is represented by the ABNF:
640
attributedescription = attributetype options
642
options = *( SEMI option )
645
where <attributetype> identifies the attribute type and each <option>
646
identifies an attribute option. Both <attributetype> and <option>
647
productions are case insensitive. The order in which <option>s
648
appear is irrelevant. That is, any two <attributedescription>s that
649
consist of the same <attributetype> and same set of <option>s are
652
Examples of valid attribute descriptions:
658
An attribute description with an unrecognized attribute type is to be
659
treated as unrecognized. Servers SHALL treat an attribute
660
description with an unrecognized attribute option as unrecognized.
661
Clients MAY treat an unrecognized attribute option as a tagging
662
option (see Section 2.5.2.1).
664
All attributes of an entry must have distinct attribute descriptions.
666
2.5.1. Attribute Types
668
An attribute type governs whether the attribute can have multiple
669
values, the syntax and matching rules used to construct and compare
670
values of that attribute, and other functions.
674
Zeilenga Standards Track [Page 12]
676
RFC 4512 LDAP Models June 2006
679
If no equality matching is specified for the attribute type:
681
- the attribute (of the type) cannot be used for naming;
682
- when adding the attribute (or replacing all values), no two
683
values may be equivalent (see 2.2);
684
- individual values of a multi-valued attribute are not to be
685
independently added or deleted;
686
- attribute value assertions (such as matching in search filters
687
and comparisons) using values of such a type cannot be
690
Otherwise, the specified equality matching rule is to be used to
691
evaluate attribute value assertions concerning the attribute type.
692
The specified equality rule is to be transitive and commutative.
694
The attribute type indicates whether the attribute is a user
695
attribute or an operational attribute. If operational, the attribute
696
type indicates the operational usage and whether or not the attribute
697
is modifiable by users. Operational attributes are discussed in
700
An attribute type (a subtype) may derive from a more generic
701
attribute type (a direct supertype). The following restrictions
704
- a subtype must have the same usage as its direct supertype,
705
- a subtype's syntax must be the same, or a refinement of, its
706
supertype's syntax, and
707
- a subtype must be collective [RFC3671] if its supertype is
710
An attribute description consisting of a subtype and no options is
711
said to be the direct description subtype of the attribute
712
description consisting of the subtype's direct supertype and no
715
Each attribute type is identified by an object identifier (OID) and,
716
optionally, one or more short names (descriptors).
718
2.5.2. Attribute Options
720
There are multiple kinds of attribute description options. The LDAP
721
technical specification details one kind: tagging options.
723
Not all options can be associated with attributes held in the
724
directory. Tagging options can be.
730
Zeilenga Standards Track [Page 13]
732
RFC 4512 LDAP Models June 2006
735
Not all options can be used in conjunction with all attribute types.
736
In such cases, the attribute description is to be treated as
739
An attribute description that contains mutually exclusive options
740
shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
741
"x-foo" and "x-bar" are mutually exclusive, is to be treated as
744
Other kinds of options may be specified in future documents. These
745
documents must detail how new kinds of options they define relate to
746
tagging options. In particular, these documents must detail whether
747
or not new kinds of options can be associated with attributes held in
748
the directory, how new kinds of options affect transfer of attribute
749
values, and how new kinds of options are treated in attribute
750
description hierarchies.
752
Options are represented as short, case-insensitive textual strings
753
conforming to the <option> production defined in Section 2.5 of this
756
Procedures for registering options are detailed in BCP 64, RFC 4520
759
2.5.2.1. Tagging Options
761
Attributes held in the directory can have attribute descriptions with
762
any number of tagging options. Tagging options are never mutually
765
An attribute description with N tagging options is a direct
766
(description) subtype of all attribute descriptions of the same
767
attribute type and all but one of the N options. If the attribute
768
type has a supertype, then the attribute description is also a direct
769
(description) subtype of the attribute description of the supertype
770
and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
771
(description) subtype of 'cn;lang-de', 'cn;lang-en', and
772
'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
775
2.5.3. Attribute Description Hierarchies
777
An attribute description can be the direct subtype of zero or more
778
other attribute descriptions as indicated by attribute type subtyping
779
(as described in Section 2.5.1) or attribute tagging option subtyping
780
(as described in Section 2.5.2.1). These subtyping relationships are
781
used to form hierarchies of attribute descriptions and attributes.
786
Zeilenga Standards Track [Page 14]
788
RFC 4512 LDAP Models June 2006
791
As adapted from [X.501]:
793
Attribute hierarchies allow access to the DIB with varying degrees
794
of granularity. This is achieved by allowing the value components
795
of attributes to be accessed by using either their specific
796
attribute description (a direct reference to the attribute) or a
797
more generic attribute description (an indirect reference).
799
Semantically related attributes may be placed in a hierarchical
800
relationship, the more specialized being placed subordinate to the
801
more generalized. Searching for or retrieving attributes and
802
their values is made easier by quoting the more generalized
803
attribute description; a filter item so specified is evaluated for
804
the more specialized descriptions as well as for the quoted
807
Where subordinate specialized descriptions are selected to be
808
returned as part of a search result these descriptions shall be
809
returned if available. Where the more general descriptions are
810
selected to be returned as part of a search result both the
811
general and the specialized descriptions shall be returned, if
812
available. An attribute value shall always be returned as a value
813
of its own attribute description.
815
All of the attribute descriptions in an attribute hierarchy are
816
treated as distinct and unrelated descriptions for user
817
modification of entry content.
819
An attribute value stored in an object or alias entry is of
820
precisely one attribute description. The description is indicated
821
when the value is originally added to the entry.
823
For the purpose of subschema administration of the entry, a
824
specification that an attribute is required is fulfilled if the entry
825
contains a value of an attribute description belonging to an
826
attribute hierarchy where the attribute type of that description is
827
the same as the required attribute's type. That is, a "MUST name"
828
specification is fulfilled by 'name' or 'name;x-tag-option', but is
829
not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
830
subtype of 'name'). Likewise, an entry may contain a value of an
831
attribute description belonging to an attribute hierarchy where the
832
attribute type of that description is either explicitly included in
833
the definition of an object class to which the entry belongs or
834
allowed by the DIT content rule applicable to that entry. That is,
835
'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
836
name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
842
Zeilenga Standards Track [Page 15]
844
RFC 4512 LDAP Models June 2006
847
For the purposes of other policy administration, unless stated
848
otherwise in the specification of the particular administrative
849
model, all of the attribute descriptions in an attribute hierarchy
850
are treated as distinct and unrelated descriptions.
854
As adapted from [X.501]:
856
An alias, or an alias name, for an object is an alternative name
857
for an object or object entry which is provided by the use of
860
Each alias entry contains, within the 'aliasedObjectName'
861
attribute (known as the 'aliasedEntryName' attribute in X.500), a
862
name of some object. The distinguished name of the alias entry is
863
thus also a name for this object.
865
NOTE - The name within the 'aliasedObjectName' is said to be
866
pointed to by the alias. It does not have to be the
867
distinguished name of any entry.
869
The conversion of an alias name to an object name is termed
870
(alias) dereferencing and comprises the systematic replacement of
871
alias names, where found within a purported name, by the value of
872
the corresponding 'aliasedObjectName' attribute. The process may
873
require the examination of more than one alias entry.
875
Any particular entry in the DIT may have zero or more alias names.
876
It therefore follows that several alias entries may point to the
877
same entry. An alias entry may point to an entry that is not a
878
leaf entry and may point to another alias entry.
880
An alias entry shall have no subordinates, so that an alias entry
881
is always a leaf entry.
883
Every alias entry shall belong to the 'alias' object class.
885
An entry with the 'alias' object class must also belong to an object
886
class (or classes), or be governed by a DIT content rule, which
887
allows suitable naming attributes to be present.
891
dn: cn=bar,dc=example,dc=com
894
objectClass: extensibleObject
898
Zeilenga Standards Track [Page 16]
900
RFC 4512 LDAP Models June 2006
904
aliasedObjectName: cn=foo,dc=example,dc=com
906
2.6.1. 'alias' Object Class
908
Alias entries belong to the 'alias' object class.
910
( 2.5.6.1 NAME 'alias'
912
MUST aliasedObjectName )
914
2.6.2. 'aliasedObjectName' Attribute Type
916
The 'aliasedObjectName' attribute holds the name of the entry an
917
alias points to. The 'aliasedObjectName' attribute is known as the
918
'aliasedEntryName' attribute in X.500.
920
( 2.5.4.1 NAME 'aliasedObjectName'
921
EQUALITY distinguishedNameMatch
922
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
925
The 'distinguishedNameMatch' matching rule and the DistinguishedName
926
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
928
3. Directory Administrative and Operational Information
930
This section discusses select aspects of the X.500 Directory
931
Administrative and Operational Information model [X.501]. LDAP
932
implementations MAY support other aspects of this model.
936
As defined in [X.501]:
938
A subtree is a collection of object and alias entries situated at
939
the vertices of a tree. Subtrees do not contain subentries. The
940
prefix sub, in subtree, emphasizes that the base (or root) vertex
941
of this tree is usually subordinate to the root of the DIT.
943
A subtree begins at some vertex and extends to some identifiable
944
lower boundary, possibly extending to leaves. A subtree is always
945
defined within a context which implicitly bounds the subtree. For
946
example, the vertex and lower boundaries of a subtree defining a
947
replicated area are bounded by a naming context.
954
Zeilenga Standards Track [Page 17]
956
RFC 4512 LDAP Models June 2006
961
A subentry is a "special sort of entry, known by the Directory, used
962
to hold information associated with a subtree or subtree refinement"
963
[X.501]. Subentries are used in Directory to hold for administrative
964
and operational purposes as defined in [X.501]. Their use in LDAP is
965
detailed in [RFC3672].
967
The term "(sub)entry" in this specification indicates that servers
968
implementing X.500(93) models are, in accordance with X.500(93) as
969
described in [RFC3672], to use a subentry and that other servers are
970
to use an object entry belonging to the appropriate auxiliary class
971
normally used with the subentry (e.g., 'subschema' for subschema
972
subentries) to mimic the subentry. This object entry's RDN SHALL be
973
formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
974
all subentries are named with 'cn').
976
3.3. The 'objectClass' attribute
978
Each entry in the DIT has an 'objectClass' attribute.
980
( 2.5.4.0 NAME 'objectClass'
981
EQUALITY objectIdentifierMatch
982
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
984
The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
985
(1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
987
The 'objectClass' attribute specifies the object classes of an entry,
988
which (among other things) are used in conjunction with the
989
controlling schema to determine the permitted attributes of an entry.
990
Values of this attribute can be modified by clients, but the
991
'objectClass' attribute cannot be removed.
993
Servers that follow X.500(93) models SHALL restrict modifications of
994
this attribute to prevent the basic structural class of the entry
995
from being changed. That is, one cannot change a 'person' into a
998
When creating an entry or adding an 'objectClass' value to an entry,
999
all superclasses of the named classes SHALL be implicitly added as
1000
well if not already present. That is, if the auxiliary class 'x-a'
1001
is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
1002
causes 'x-b' to be implicitly added (if is not already present).
1004
Servers SHALL restrict modifications of this attribute to prevent
1005
superclasses of remaining 'objectClass' values from being deleted.
1006
That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
1010
Zeilenga Standards Track [Page 18]
1012
RFC 4512 LDAP Models June 2006
1015
class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
1016
an attempt to delete only 'x-b' from the 'objectClass' attribute is
1019
3.4. Operational Attributes
1021
Some attributes, termed operational attributes, are used or
1022
maintained by servers for administrative and operational purposes.
1023
As stated in [X.501]: "There are three varieties of operational
1024
attributes: Directory operational attributes, DSA-shared operational
1025
attributes, and DSA-specific operational attributes".
1027
A directory operational attribute is used to represent operational
1028
and/or administrative information in the Directory Information Model.
1029
This includes operational attributes maintained by the server (e.g.,
1030
'createTimestamp') as well as operational attributes that hold values
1031
administrated by the user (e.g., 'ditContentRules').
1033
A DSA-shared operational attribute is used to represent information
1034
of the DSA Information Model that is shared between DSAs.
1036
A DSA-specific operational attribute is used to represent information
1037
of the DSA Information Model that is specific to the DSA (though, in
1038
some cases, may be derived from information shared between DSAs;
1039
e.g., 'namingContexts').
1041
The DSA Information Model operational attributes are detailed in
1044
Operational attributes are not normally visible. They are not
1045
returned in search results unless explicitly requested by name.
1047
Not all operational attributes are user modifiable.
1049
Entries may contain, among others, the following operational
1052
- creatorsName: the Distinguished Name of the user who added this
1053
entry to the directory,
1055
- createTimestamp: the time this entry was added to the directory,
1057
- modifiersName: the Distinguished Name of the user who last
1058
modified this entry, and
1060
- modifyTimestamp: the time this entry was last modified.
1066
Zeilenga Standards Track [Page 19]
1068
RFC 4512 LDAP Models June 2006
1071
Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
1072
'modifiersName', and 'modifyTimestamp' attributes for all entries of
1075
3.4.1. 'creatorsName'
1077
This attribute appears in entries that were added using the protocol
1078
(e.g., using the Add operation). The value is the distinguished name
1081
( 2.5.18.3 NAME 'creatorsName'
1082
EQUALITY distinguishedNameMatch
1083
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1084
SINGLE-VALUE NO-USER-MODIFICATION
1085
USAGE directoryOperation )
1087
The 'distinguishedNameMatch' matching rule and the DistinguishedName
1088
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
1090
3.4.2. 'createTimestamp'
1092
This attribute appears in entries that were added using the protocol
1093
(e.g., using the Add operation). The value is the time the entry was
1096
( 2.5.18.1 NAME 'createTimestamp'
1097
EQUALITY generalizedTimeMatch
1098
ORDERING generalizedTimeOrderingMatch
1099
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1100
SINGLE-VALUE NO-USER-MODIFICATION
1101
USAGE directoryOperation )
1103
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
1104
matching rules and the GeneralizedTime
1105
(1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
1107
3.4.3. 'modifiersName'
1109
This attribute appears in entries that have been modified using the
1110
protocol (e.g., using the Modify operation). The value is the
1111
distinguished name of the last modifier.
1113
( 2.5.18.4 NAME 'modifiersName'
1114
EQUALITY distinguishedNameMatch
1115
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1116
SINGLE-VALUE NO-USER-MODIFICATION
1117
USAGE directoryOperation )
1122
Zeilenga Standards Track [Page 20]
1124
RFC 4512 LDAP Models June 2006
1127
The 'distinguishedNameMatch' matching rule and the DistinguishedName
1128
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
1130
3.4.4. 'modifyTimestamp'
1132
This attribute appears in entries that have been modified using the
1133
protocol (e.g., using the Modify operation). The value is the time
1134
the entry was last modified.
1136
( 2.5.18.2 NAME 'modifyTimestamp'
1137
EQUALITY generalizedTimeMatch
1138
ORDERING generalizedTimeOrderingMatch
1139
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
1140
SINGLE-VALUE NO-USER-MODIFICATION
1141
USAGE directoryOperation )
1143
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
1144
matching rules and the GeneralizedTime
1145
(1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
1147
3.4.5. 'structuralObjectClass'
1149
This attribute indicates the structural object class of the entry.
1151
( 2.5.21.9 NAME 'structuralObjectClass'
1152
EQUALITY objectIdentifierMatch
1153
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
1154
SINGLE-VALUE NO-USER-MODIFICATION
1155
USAGE directoryOperation )
1157
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
1158
(1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
1160
3.4.6. 'governingStructureRule'
1162
This attribute indicates the structure rule governing the entry.
1164
( 2.5.21.10 NAME 'governingStructureRule'
1165
EQUALITY integerMatch
1166
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
1167
SINGLE-VALUE NO-USER-MODIFICATION
1168
USAGE directoryOperation )
1170
The 'integerMatch' matching rule and INTEGER
1171
(1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
1178
Zeilenga Standards Track [Page 21]
1180
RFC 4512 LDAP Models June 2006
1185
As defined in [X.501]:
1187
The Directory Schema is a set of definitions and constraints
1188
concerning the structure of the DIT, the possible ways entries are
1189
named, the information that can be held in an entry, the
1190
attributes used to represent that information and their
1191
organization into hierarchies to facilitate search and retrieval
1192
of the information and the ways in which values of attributes may
1193
be matched in attribute value and matching rule assertions.
1195
NOTE 1 - The schema enables the Directory system to, for example:
1197
- prevent the creation of subordinate entries of the wrong
1198
object-class (e.g., a country as a subordinate of a person);
1200
- prevent the addition of attribute-types to an entry
1201
inappropriate to the object-class (e.g., a serial number to a
1204
- prevent the addition of an attribute value of a syntax not
1205
matching that defined for the attribute-type (e.g., a printable
1206
string to a bit string).
1208
Formally, the Directory Schema comprises a set of:
1210
a) Name Form definitions that define primitive naming relations
1211
for structural object classes;
1213
b) DIT Structure Rule definitions that define the names that
1214
entries may have and the ways in which the entries may be
1215
related to one another in the DIT;
1217
c) DIT Content Rule definitions that extend the specification of
1218
allowable attributes for entries beyond those indicated by the
1219
structural object classes of the entries;
1221
d) Object Class definitions that define the basic set of mandatory
1222
and optional attributes that shall be present, and may be
1223
present, respectively, in an entry of a given class, and which
1224
indicate the kind of object class that is being defined;
1234
Zeilenga Standards Track [Page 22]
1236
RFC 4512 LDAP Models June 2006
1239
e) Attribute Type definitions that identify the object identifier
1240
by which an attribute is known, its syntax, associated matching
1241
rules, whether it is an operational attribute and if so its
1242
type, whether it is a collective attribute, whether it is
1243
permitted to have multiple values and whether or not it is
1244
derived from another attribute type;
1246
f) Matching Rule definitions that define matching rules.
1250
g) LDAP Syntax definitions that define encodings used in LDAP.
1252
4.1. Schema Definitions
1254
Schema definitions in this section are described using ABNF and rely
1255
on the common productions specified in Section 1.2 as well as these:
1257
noidlen = numericoid [ LCURLY len RCURLY ]
1260
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
1261
oidlist = oid *( WSP DOLLAR WSP oid )
1263
extensions = *( SP xstring SP qdstrings )
1264
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
1266
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
1267
qdescrlist = [ qdescr *( SP qdescr ) ]
1268
qdescr = SQUOTE descr SQUOTE
1270
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
1271
qdstringlist = [ qdstring *( SP qdstring ) ]
1272
qdstring = SQUOTE dstring SQUOTE
1273
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
1275
QQ = ESC %x32 %x37 ; "\27"
1276
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
1278
; Any UTF-8 encoded Unicode character
1279
; except %x27 ("\'") and %x5C ("\")
1280
QUTF8 = QUTF1 / UTFMB
1282
; Any ASCII character except %x27 ("\'") and %x5C ("\")
1283
QUTF1 = %x00-26 / %x28-5B / %x5D-7F
1285
Schema definitions in this section also share a number of common
1290
Zeilenga Standards Track [Page 23]
1292
RFC 4512 LDAP Models June 2006
1295
The NAME field provides a set of short names (descriptors) that are
1296
to be used as aliases for the OID.
1298
The DESC field optionally allows a descriptive string to be provided
1299
by the directory administrator and/or implementor. While
1300
specifications may suggest a descriptive string, there is no
1301
requirement that the suggested (or any) descriptive string be used.
1303
The OBSOLETE field, if present, indicates the element is not active.
1305
Implementors should note that future versions of this document may
1306
expand these definitions to include additional terms. Terms whose
1307
identifier begins with "X-" are reserved for private experiments and
1308
are followed by <SP> and <qdstrings> tokens.
1310
4.1.1. Object Class Definitions
1312
Object Class definitions are written according to the ABNF:
1314
ObjectClassDescription = LPAREN WSP
1315
numericoid ; object identifier
1316
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
1317
[ SP "DESC" SP qdstring ] ; description
1318
[ SP "OBSOLETE" ] ; not active
1319
[ SP "SUP" SP oids ] ; superior object classes
1320
[ SP kind ] ; kind of class
1321
[ SP "MUST" SP oids ] ; attribute types
1322
[ SP "MAY" SP oids ] ; attribute types
1323
extensions WSP RPAREN
1325
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
1328
<numericoid> is object identifier assigned to this object class;
1329
NAME <qdescrs> are short names (descriptors) identifying this
1331
DESC <qdstring> is a short descriptive string;
1332
OBSOLETE indicates this object class is not active;
1333
SUP <oids> specifies the direct superclasses of this object class;
1334
the kind of object class is indicated by one of ABSTRACT,
1335
STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
1336
MUST and MAY specify the sets of required and allowed attribute
1337
types, respectively; and
1338
<extensions> describe extensions.
1346
Zeilenga Standards Track [Page 24]
1348
RFC 4512 LDAP Models June 2006
1351
4.1.2. Attribute Types
1353
Attribute Type definitions are written according to the ABNF:
1355
AttributeTypeDescription = LPAREN WSP
1356
numericoid ; object identifier
1357
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
1358
[ SP "DESC" SP qdstring ] ; description
1359
[ SP "OBSOLETE" ] ; not active
1360
[ SP "SUP" SP oid ] ; supertype
1361
[ SP "EQUALITY" SP oid ] ; equality matching rule
1362
[ SP "ORDERING" SP oid ] ; ordering matching rule
1363
[ SP "SUBSTR" SP oid ] ; substrings matching rule
1364
[ SP "SYNTAX" SP noidlen ] ; value syntax
1365
[ SP "SINGLE-VALUE" ] ; single-value
1366
[ SP "COLLECTIVE" ] ; collective
1367
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
1368
[ SP "USAGE" SP usage ] ; usage
1369
extensions WSP RPAREN ; extensions
1371
usage = "userApplications" / ; user
1372
"directoryOperation" / ; directory operational
1373
"distributedOperation" / ; DSA-shared operational
1374
"dSAOperation" ; DSA-specific operational
1377
<numericoid> is object identifier assigned to this attribute type;
1378
NAME <qdescrs> are short names (descriptors) identifying this
1380
DESC <qdstring> is a short descriptive string;
1381
OBSOLETE indicates this attribute type is not active;
1382
SUP oid specifies the direct supertype of this type;
1383
EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
1384
ordering, and substrings matching rules, respectively;
1385
SYNTAX identifies value syntax by object identifier and may suggest
1386
a minimum upper bound;
1387
SINGLE-VALUE indicates attributes of this type are restricted to a
1389
COLLECTIVE indicates this attribute type is collective
1391
NO-USER-MODIFICATION indicates this attribute type is not user
1393
USAGE indicates the application of this attribute type; and
1394
<extensions> describe extensions.
1396
Each attribute type description must contain at least one of the SUP
1397
or SYNTAX fields. If no SYNTAX field is provided, the attribute type
1398
description takes its value from the supertype.
1402
Zeilenga Standards Track [Page 25]
1404
RFC 4512 LDAP Models June 2006
1407
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
1408
fields, if not specified, take their value from the supertype.
1410
Usage of userApplications, the default, indicates that attributes of
1411
this type represent user information. That is, they are user
1414
A usage of directoryOperation, distributedOperation, or dSAOperation
1415
indicates that attributes of this type represent operational and/or
1416
administrative information. That is, they are operational
1419
directoryOperation usage indicates that the attribute of this type is
1420
a directory operational attribute. distributedOperation usage
1421
indicates that the attribute of this type is a DSA-shared usage
1422
operational attribute. dSAOperation usage indicates that the
1423
attribute of this type is a DSA-specific operational attribute.
1425
COLLECTIVE requires usage userApplications. Use of collective
1426
attribute types in LDAP is discussed in [RFC3671].
1428
NO-USER-MODIFICATION requires an operational usage.
1430
Note that the <AttributeTypeDescription> does not list the matching
1431
rules that can be used with that attribute type in an extensibleMatch
1432
search filter [RFC4511]. This is done using the 'matchingRuleUse'
1433
attribute described in Section 4.1.4.
1435
This document refines the schema description of X.501 by requiring
1436
that the SYNTAX field in an <AttributeTypeDescription> be a string
1437
representation of an object identifier for the LDAP string syntax
1438
definition, with an optional indication of the suggested minimum
1439
bound of a value of this attribute.
1441
A suggested minimum upper bound on the number of characters in a
1442
value with a string-based syntax, or the number of bytes in a value
1443
for all other syntaxes, may be indicated by appending this bound
1444
count inside of curly braces following the syntax's OBJECT IDENTIFIER
1445
in an Attribute Type Description. This bound is not part of the
1446
syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests
1447
that server implementations should allow a string to be 64 characters
1448
long, although they may allow longer strings. Note that a single
1449
character of the Directory String syntax may be encoded in more than
1450
one octet since UTF-8 [RFC3629] is a variable-length encoding.
1458
Zeilenga Standards Track [Page 26]
1460
RFC 4512 LDAP Models June 2006
1463
4.1.3. Matching Rules
1465
Matching rules are used in performance of attribute value assertions,
1466
such as in performance of a Compare operation. They are also used in
1467
evaluating search filters, determining which individual values are to
1468
be added or deleted during performance of a Modify operation, and in
1469
comparing distinguished names.
1471
Each matching rule is identified by an object identifier (OID) and,
1472
optionally, one or more short names (descriptors).
1474
Matching rule definitions are written according to the ABNF:
1476
MatchingRuleDescription = LPAREN WSP
1477
numericoid ; object identifier
1478
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
1479
[ SP "DESC" SP qdstring ] ; description
1480
[ SP "OBSOLETE" ] ; not active
1481
SP "SYNTAX" SP numericoid ; assertion syntax
1482
extensions WSP RPAREN ; extensions
1485
<numericoid> is object identifier assigned to this matching rule;
1486
NAME <qdescrs> are short names (descriptors) identifying this
1488
DESC <qdstring> is a short descriptive string;
1489
OBSOLETE indicates this matching rule is not active;
1490
SYNTAX identifies the assertion syntax (the syntax of the assertion
1491
value) by object identifier; and
1492
<extensions> describe extensions.
1494
4.1.4. Matching Rule Uses
1496
A matching rule use lists the attribute types that are suitable for
1497
use with an extensibleMatch search filter.
1499
Matching rule use descriptions are written according to the following
1502
MatchingRuleUseDescription = LPAREN WSP
1503
numericoid ; object identifier
1504
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
1505
[ SP "DESC" SP qdstring ] ; description
1506
[ SP "OBSOLETE" ] ; not active
1507
SP "APPLIES" SP oids ; attribute types
1508
extensions WSP RPAREN ; extensions
1514
Zeilenga Standards Track [Page 27]
1516
RFC 4512 LDAP Models June 2006
1520
<numericoid> is the object identifier of the matching rule
1521
associated with this matching rule use description;
1522
NAME <qdescrs> are short names (descriptors) identifying this
1524
DESC <qdstring> is a short descriptive string;
1525
OBSOLETE indicates this matching rule use is not active;
1526
APPLIES provides a list of attribute types the matching rule
1528
<extensions> describe extensions.
1530
4.1.5. LDAP Syntaxes
1532
LDAP Syntaxes of (attribute and assertion) values are described in
1533
terms of ASN.1 [X.680] and, optionally, have an octet string encoding
1534
known as the LDAP-specific encoding. Commonly, the LDAP-specific
1535
encoding is constrained to a string of Unicode [Unicode] characters
1536
in UTF-8 [RFC3629] form.
1538
Each LDAP syntax is identified by an object identifier (OID).
1540
LDAP syntax definitions are written according to the ABNF:
1542
SyntaxDescription = LPAREN WSP
1543
numericoid ; object identifier
1544
[ SP "DESC" SP qdstring ] ; description
1545
extensions WSP RPAREN ; extensions
1548
<numericoid> is the object identifier assigned to this LDAP syntax;
1549
DESC <qdstring> is a short descriptive string; and
1550
<extensions> describe extensions.
1552
4.1.6. DIT Content Rules
1554
A DIT content rule is a "rule governing the content of entries of a
1555
particular structural object class" [X.501].
1557
For DIT entries of a particular structural object class, a DIT
1558
content rule specifies which auxiliary object classes the entries are
1559
allowed to belong to and which additional attributes (by type) are
1560
required, allowed, or not allowed to appear in the entries.
1562
The list of precluded attributes cannot include any attribute listed
1563
as mandatory in the rule, the structural object class, or any of the
1564
allowed auxiliary object classes.
1570
Zeilenga Standards Track [Page 28]
1572
RFC 4512 LDAP Models June 2006
1575
Each content rule is identified by the object identifier, as well as
1576
any short names (descriptors), of the structural object class it
1579
An entry may only belong to auxiliary object classes listed in the
1580
governing content rule.
1582
An entry must contain all attributes required by the object classes
1583
the entry belongs to as well as all attributes required by the
1584
governing content rule.
1586
An entry may contain any non-precluded attributes allowed by the
1587
object classes the entry belongs to as well as all attributes allowed
1588
by the governing content rule.
1590
An entry cannot include any attribute precluded by the governing
1593
An entry is governed by (if present and active in the subschema) the
1594
DIT content rule that applies to the structural object class of the
1595
entry (see Section 2.4.2). If no active rule is present for the
1596
entry's structural object class, the entry's content is governed by
1597
the structural object class (and possibly other aspects of user and
1598
system schema). DIT content rules for superclasses of the structural
1599
object class of an entry are not applicable to that entry.
1601
DIT content rule descriptions are written according to the ABNF:
1603
DITContentRuleDescription = LPAREN WSP
1604
numericoid ; object identifier
1605
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
1606
[ SP "DESC" SP qdstring ] ; description
1607
[ SP "OBSOLETE" ] ; not active
1608
[ SP "AUX" SP oids ] ; auxiliary object classes
1609
[ SP "MUST" SP oids ] ; attribute types
1610
[ SP "MAY" SP oids ] ; attribute types
1611
[ SP "NOT" SP oids ] ; attribute types
1612
extensions WSP RPAREN ; extensions
1615
<numericoid> is the object identifier of the structural object
1616
class associated with this DIT content rule;
1617
NAME <qdescrs> are short names (descriptors) identifying this DIT
1619
DESC <qdstring> is a short descriptive string;
1620
OBSOLETE indicates this DIT content rule use is not active;
1621
AUX specifies a list of auxiliary object classes that entries
1622
subject to this DIT content rule may belong to;
1626
Zeilenga Standards Track [Page 29]
1628
RFC 4512 LDAP Models June 2006
1631
MUST, MAY, and NOT specify lists of attribute types that are
1632
required, allowed, or precluded, respectively, from appearing
1633
in entries subject to this DIT content rule; and
1634
<extensions> describe extensions.
1636
4.1.7. DIT Structure Rules and Name Forms
1638
It is sometimes desirable to regulate where object and alias entries
1639
can be placed in the DIT and how they can be named based upon their
1640
structural object class.
1642
4.1.7.1. DIT Structure Rules
1644
A DIT structure rule is a "rule governing the structure of the DIT by
1645
specifying a permitted superior to subordinate entry relationship. A
1646
structure rule relates a name form, and therefore a structural object
1647
class, to superior structure rules. This permits entries of the
1648
structural object class identified by the name form to exist in the
1649
DIT as subordinates to entries governed by the indicated superior
1650
structure rules" [X.501].
1652
DIT structure rule descriptions are written according to the ABNF:
1654
DITStructureRuleDescription = LPAREN WSP
1655
ruleid ; rule identifier
1656
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
1657
[ SP "DESC" SP qdstring ] ; description
1658
[ SP "OBSOLETE" ] ; not active
1659
SP "FORM" SP oid ; NameForm
1660
[ SP "SUP" ruleids ] ; superior rules
1661
extensions WSP RPAREN ; extensions
1663
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
1664
ruleidlist = ruleid *( SP ruleid )
1668
<ruleid> is the rule identifier of this DIT structure rule;
1669
NAME <qdescrs> are short names (descriptors) identifying this DIT
1671
DESC <qdstring> is a short descriptive string;
1672
OBSOLETE indicates this DIT structure rule use is not active;
1673
FORM is specifies the name form associated with this DIT structure
1675
SUP identifies superior rules (by rule id); and
1676
<extensions> describe extensions.
1682
Zeilenga Standards Track [Page 30]
1684
RFC 4512 LDAP Models June 2006
1687
If no superior rules are identified, the DIT structure rule applies
1688
to an autonomous administrative point (e.g., the root vertex of the
1689
subtree controlled by the subschema) [X.501].
1693
A name form "specifies a permissible RDN for entries of a particular
1694
structural object class. A name form identifies a named object class
1695
and one or more attribute types to be used for naming (i.e., for the
1696
RDN). Name forms are primitive pieces of specification used in the
1697
definition of DIT structure rules" [X.501].
1699
Each name form indicates the structural object class to be named, a
1700
set of required attribute types, and a set of allowed attribute
1701
types. A particular attribute type cannot be in both sets.
1703
Entries governed by the form must be named using a value from each
1704
required attribute type and zero or more values from the allowed
1707
Each name form is identified by an object identifier (OID) and,
1708
optionally, one or more short names (descriptors).
1710
Name form descriptions are written according to the ABNF:
1712
NameFormDescription = LPAREN WSP
1713
numericoid ; object identifier
1714
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
1715
[ SP "DESC" SP qdstring ] ; description
1716
[ SP "OBSOLETE" ] ; not active
1717
SP "OC" SP oid ; structural object class
1718
SP "MUST" SP oids ; attribute types
1719
[ SP "MAY" SP oids ] ; attribute types
1720
extensions WSP RPAREN ; extensions
1723
<numericoid> is object identifier that identifies this name form;
1724
NAME <qdescrs> are short names (descriptors) identifying this name
1726
DESC <qdstring> is a short descriptive string;
1727
OBSOLETE indicates this name form is not active;
1728
OC identifies the structural object class this rule applies to,
1729
MUST and MAY specify the sets of required and allowed,
1730
respectively, naming attributes for this name form; and
1731
<extensions> describe extensions.
1733
All attribute types in the required ("MUST") and allowed ("MAY")
1734
lists shall be different.
1738
Zeilenga Standards Track [Page 31]
1740
RFC 4512 LDAP Models June 2006
1743
4.2. Subschema Subentries
1745
Subschema (sub)entries are used for administering information about
1746
the directory schema. A single subschema (sub)entry contains all
1747
schema definitions (see Section 4.1) used by entries in a particular
1748
part of the directory tree.
1750
Servers that follow X.500(93) models SHOULD implement subschema using
1751
the X.500 subschema mechanisms (as detailed in Section 12 of
1752
[X.501]), so these are not ordinary object entries but subentries
1753
(see Section 3.2). LDAP clients SHOULD NOT assume that servers
1754
implement any of the other aspects of X.500 subschema.
1756
Servers MAY allow subschema modification. Procedures for subschema
1757
modification are discussed in Section 14.5 of [X.501].
1759
A server that masters entries and permits clients to modify these
1760
entries SHALL implement and provide access to these subschema
1761
(sub)entries including providing a 'subschemaSubentry' attribute in
1762
each modifiable entry. This is so clients may discover the
1763
attributes and object classes that are permitted to be present. It
1764
is strongly RECOMMENDED that all other servers implement this as
1767
The value of the 'subschemaSubentry' attribute is the name of the
1768
subschema (sub)entry holding the subschema controlling the entry.
1770
( 2.5.18.10 NAME 'subschemaSubentry'
1771
EQUALITY distinguishedNameMatch
1772
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
1773
SINGLE-VALUE NO-USER-MODIFICATION
1774
USAGE directoryOperation )
1776
The 'distinguishedNameMatch' matching rule and the DistinguishedName
1777
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
1779
Subschema is held in (sub)entries belonging to the subschema
1780
auxiliary object class.
1782
( 2.5.20.1 NAME 'subschema' AUXILIARY
1783
MAY ( dITStructureRules $ nameForms $ ditContentRules $
1784
objectClasses $ attributeTypes $ matchingRules $
1787
The 'ldapSyntaxes' operational attribute may also be present in
1794
Zeilenga Standards Track [Page 32]
1796
RFC 4512 LDAP Models June 2006
1799
Servers MAY provide additional attributes (described in other
1800
documents) in subschema (sub)entries.
1802
Servers SHOULD provide the attributes 'createTimestamp' and
1803
'modifyTimestamp' in subschema (sub)entries, in order to allow
1804
clients to maintain their caches of schema information.
1806
The following subsections provide attribute type definitions for each
1807
of schema definition attribute types.
1809
4.2.1. 'objectClasses'
1811
This attribute holds definitions of object classes.
1813
( 2.5.21.6 NAME 'objectClasses'
1814
EQUALITY objectIdentifierFirstComponentMatch
1815
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
1816
USAGE directoryOperation )
1818
The 'objectIdentifierFirstComponentMatch' matching rule and the
1819
ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
1820
defined in [RFC4517].
1822
4.2.2. 'attributeTypes'
1824
This attribute holds definitions of attribute types.
1826
( 2.5.21.5 NAME 'attributeTypes'
1827
EQUALITY objectIdentifierFirstComponentMatch
1828
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
1829
USAGE directoryOperation )
1831
The 'objectIdentifierFirstComponentMatch' matching rule and the
1832
AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
1833
defined in [RFC4517].
1835
4.2.3. 'matchingRules'
1837
This attribute holds definitions of matching rules.
1839
( 2.5.21.4 NAME 'matchingRules'
1840
EQUALITY objectIdentifierFirstComponentMatch
1841
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
1842
USAGE directoryOperation )
1844
The 'objectIdentifierFirstComponentMatch' matching rule and the
1845
MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
1846
defined in [RFC4517].
1850
Zeilenga Standards Track [Page 33]
1852
RFC 4512 LDAP Models June 2006
1855
4.2.4 'matchingRuleUse'
1857
This attribute holds definitions of matching rule uses.
1859
( 2.5.21.8 NAME 'matchingRuleUse'
1860
EQUALITY objectIdentifierFirstComponentMatch
1861
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
1862
USAGE directoryOperation )
1864
The 'objectIdentifierFirstComponentMatch' matching rule and the
1865
MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
1866
defined in [RFC4517].
1868
4.2.5. 'ldapSyntaxes'
1870
This attribute holds definitions of LDAP syntaxes.
1872
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
1873
EQUALITY objectIdentifierFirstComponentMatch
1874
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
1875
USAGE directoryOperation )
1877
The 'objectIdentifierFirstComponentMatch' matching rule and the
1878
SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
1881
4.2.6. 'dITContentRules'
1883
This attribute lists DIT Content Rules that are present in the
1886
( 2.5.21.2 NAME 'dITContentRules'
1887
EQUALITY objectIdentifierFirstComponentMatch
1888
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
1889
USAGE directoryOperation )
1891
The 'objectIdentifierFirstComponentMatch' matching rule and the
1892
DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
1893
defined in [RFC4517].
1906
Zeilenga Standards Track [Page 34]
1908
RFC 4512 LDAP Models June 2006
1911
4.2.7. 'dITStructureRules'
1913
This attribute lists DIT Structure Rules that are present in the
1916
( 2.5.21.1 NAME 'dITStructureRules'
1917
EQUALITY integerFirstComponentMatch
1918
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
1919
USAGE directoryOperation )
1921
The 'integerFirstComponentMatch' matching rule and the
1922
DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax
1923
are defined in [RFC4517].
1927
This attribute lists Name Forms that are in force.
1929
( 2.5.21.7 NAME 'nameForms'
1930
EQUALITY objectIdentifierFirstComponentMatch
1931
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
1932
USAGE directoryOperation )
1934
The 'objectIdentifierFirstComponentMatch' matching rule and the
1935
NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are
1936
defined in [RFC4517].
1938
4.3. 'extensibleObject' object class
1940
The 'extensibleObject' auxiliary object class allows entries that
1941
belong to it to hold any user attribute. The set of allowed
1942
attribute types of this object class is implicitly the set of all
1943
attribute types of userApplications usage.
1945
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
1948
The mandatory attributes of the other object classes of this entry
1949
are still required to be present, and any precluded attributes are
1950
still not allowed to be present.
1952
4.4. Subschema Discovery
1954
To discover the DN of the subschema (sub)entry holding the subschema
1955
controlling a particular entry, a client reads that entry's
1956
'subschemaSubentry' operational attribute. To read schema attributes
1957
from the subschema (sub)entry, clients MUST issue a Search operation
1958
[RFC4511] where baseObject is the DN of the subschema (sub)entry,
1962
Zeilenga Standards Track [Page 35]
1964
RFC 4512 LDAP Models June 2006
1967
scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
1968
and the attributes field lists the names of the desired schema
1969
attributes (as they are operational). Note: the
1970
"(objectClass=subschema)" filter allows LDAP servers that gateway to
1971
X.500 to detect that subentry information is being requested.
1973
Clients SHOULD NOT assume that a published subschema is complete,
1974
that the server supports all of the schema elements it publishes, or
1975
that the server does not support an unpublished element.
1977
5. DSA (Server) Informational Model
1979
The LDAP protocol assumes there are one or more servers that jointly
1980
provide access to a Directory Information Tree (DIT). The server
1981
holding the original information is called the "master" (for that
1982
information). Servers that hold copies of the original information
1983
are referred to as "shadowing" or "caching" servers.
1986
As defined in [X.501]:
1988
context prefix: The sequence of RDNs leading from the Root of the
1989
DIT to the initial vertex of a naming context; corresponds to
1990
the distinguished name of that vertex.
1992
naming context: A subtree of entries held in a single master DSA.
1994
That is, a naming context is the largest collection of entries,
1995
starting at an entry that is mastered by a particular server, and
1996
including all its subordinates and their subordinates, down to the
1997
entries that are mastered by different servers. The context prefix
1998
is the name of the initial entry.
2000
The root of the DIT is a DSA-specific Entry (DSE) and not part of any
2001
naming context (or any subtree); each server has different attribute
2002
values in the root DSE.
2004
5.1. Server-Specific Data Requirements
2006
An LDAP server SHALL provide information about itself and other
2007
information that is specific to each server. This is represented as
2008
a group of attributes located in the root DSE, which is named with
2009
the DN with zero RDNs (whose [RFC4514] representation is as the
2010
zero-length string).
2012
These attributes are retrievable, subject to access control and other
2013
restrictions, if a client performs a Search operation [RFC4511] with
2014
an empty baseObject, scope of baseObject, the filter
2018
Zeilenga Standards Track [Page 36]
2020
RFC 4512 LDAP Models June 2006
2023
"(objectClass=*)" [RFC4515], and the attributes field listing the
2024
names of the desired attributes. It is noted that root DSE
2025
attributes are operational and, like other operational attributes,
2026
are not returned in search requests unless requested by name.
2028
The root DSE SHALL NOT be included if the client performs a subtree
2029
search starting from the root.
2031
Servers may allow clients to modify attributes of the root DSE, where
2034
The following attributes of the root DSE are defined below.
2035
Additional attributes may be defined in other documents.
2037
- altServer: alternative servers;
2039
- namingContexts: naming contexts;
2041
- supportedControl: recognized LDAP controls;
2043
- supportedExtension: recognized LDAP extended operations;
2045
- supportedFeatures: recognized LDAP features;
2047
- supportedLDAPVersion: LDAP versions supported; and
2049
- supportedSASLMechanisms: recognized Simple Authentication and
2050
Security Layers (SASL) [RFC4422] mechanisms.
2052
The values provided for these attributes may depend on session-
2053
specific and other factors. For example, a server supporting the
2054
SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
2055
identity has been established by a lower level. See [RFC4513].
2057
The root DSE may also include a 'subschemaSubentry' attribute. If it
2058
does, the attribute refers to the subschema (sub)entry holding the
2059
schema controlling the root DSE. Clients SHOULD NOT assume that this
2060
subschema (sub)entry controls other entries held by the server.
2061
General subschema discovery procedures are provided in Section 4.4.
2074
Zeilenga Standards Track [Page 37]
2076
RFC 4512 LDAP Models June 2006
2081
The 'altServer' attribute lists URIs referring to alternative servers
2082
that may be contacted when this server becomes unavailable. URIs for
2083
servers implementing the LDAP are written according to [RFC4516].
2084
Other kinds of URIs may be provided. If the server does not know of
2085
any other servers that could be used, this attribute will be absent.
2086
Clients may cache this information in case their preferred server
2087
later becomes unavailable.
2089
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
2090
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
2091
USAGE dSAOperation )
2093
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
2096
5.1.2. 'namingContexts'
2098
The 'namingContexts' attribute lists the context prefixes of the
2099
naming contexts the server masters or shadows (in part or in whole).
2100
If the server is a first-level DSA [X.501], it should list (in
2101
addition) an empty string (indicating the root of the DIT). If the
2102
server does not master or shadow any information (e.g., it is an LDAP
2103
gateway to a public X.500 directory) this attribute will be absent.
2104
If the server believes it masters or shadows the entire directory,
2105
the attribute will have a single value, and that value will be the
2106
empty string (indicating the root of the DIT).
2108
This attribute may be used, for example, to select a suitable entry
2109
name for subsequent operations with this server.
2111
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
2112
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
2113
USAGE dSAOperation )
2115
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
2116
defined in [RFC4517].
2118
5.1.3. 'supportedControl'
2120
The 'supportedControl' attribute lists object identifiers identifying
2121
the request controls [RFC4511] the server supports. If the server
2122
does not support any request controls, this attribute will be absent.
2123
Object identifiers identifying response controls need not be listed.
2125
Procedures for registering object identifiers used to discovery of
2126
protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
2130
Zeilenga Standards Track [Page 38]
2132
RFC 4512 LDAP Models June 2006
2135
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
2136
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2137
USAGE dSAOperation )
2139
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2140
defined in [RFC4517].
2142
5.1.4. 'supportedExtension'
2144
The 'supportedExtension' attribute lists object identifiers
2145
identifying the extended operations [RFC4511] that the server
2146
supports. If the server does not support any extended operations,
2147
this attribute will be absent.
2149
An extended operation generally consists of an extended request and
2150
an extended response but may also include other protocol data units
2151
(such as intermediate responses). The object identifier assigned to
2152
the extended request is used to identify the extended operation.
2153
Other object identifiers used in the extended operation need not be
2154
listed as values of this attribute.
2156
Procedures for registering object identifiers used to discovery of
2157
protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
2159
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
2160
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2161
USAGE dSAOperation )
2163
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
2164
defined in [RFC4517].
2166
5.1.5. 'supportedFeatures'
2168
The 'supportedFeatures' attribute lists object identifiers
2169
identifying elective features that the server supports. If the
2170
server does not support any discoverable elective features, this
2171
attribute will be absent.
2173
( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
2174
EQUALITY objectIdentifierMatch
2175
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
2176
USAGE dSAOperation )
2178
Procedures for registering object identifiers used to discovery of
2179
protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
2181
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
2182
objectIdentifierMatch matching rule are defined in [RFC4517].
2186
Zeilenga Standards Track [Page 39]
2188
RFC 4512 LDAP Models June 2006
2191
5.1.6. 'supportedLDAPVersion'
2193
The 'supportedLDAPVersion' attribute lists the versions of LDAP that
2194
the server supports.
2196
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
2197
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
2198
USAGE dSAOperation )
2200
The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in
2203
5.1.7. 'supportedSASLMechanisms'
2205
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
2206
[RFC4422] that the server recognizes and/or supports [RFC4513]. The
2207
contents of this attribute may depend on the current session state.
2208
If the server does not support any SASL mechanisms, this attribute
2209
will not be present.
2211
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
2212
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
2213
USAGE dSAOperation )
2215
The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
2216
defined in [RFC4517].
2218
6. Other Considerations
2220
6.1. Preservation of User Information
2222
Syntaxes may be defined that have specific value and/or value form
2223
(representation) preservation requirements. For example, a syntax
2224
containing digitally signed data can mandate that the server preserve
2225
both the value and form of value presented to ensure that the
2226
signature is not invalidated.
2228
Where such requirements have not been explicitly stated, servers
2229
SHOULD preserve the value of user information but MAY return the
2230
value in a different form. And where a server is unable (or
2231
unwilling) to preserve the value of user information, the server
2232
SHALL ensure that an equivalent value (per Section 2.3) is returned.
2242
Zeilenga Standards Track [Page 40]
2244
RFC 4512 LDAP Models June 2006
2249
Short names, also known as descriptors, are used as more readable
2250
aliases for object identifiers and are used to identify various
2251
schema elements. However, it is not expected that LDAP
2252
implementations with human user interface would display these short
2253
names (or the object identifiers they refer to) to the user.
2254
Instead, they would most likely be performing translations (such as
2255
expressing the short name in one of the local national languages).
2256
For example, the short name "st" (stateOrProvinceName) might be
2257
displayed to a German-speaking user as "Land".
2259
The same short name might have different meaning in different
2260
subschemas, and, within a particular subschema, the same short name
2261
might refer to different object identifiers each identifying a
2262
different kind of schema element.
2264
Implementations MUST be prepared that the same short name might be
2265
used in a subschema to refer to the different kinds of schema
2266
elements. That is, there might be an object class 'x-fubar' and an
2267
attribute type 'x-fubar' in a subschema.
2269
Implementations MUST be prepared that the same short name might be
2270
used in the different subschemas to refer to the different schema
2271
elements. That is, there might be two matching rules 'x-fubar', each
2272
in different subschemas.
2274
Procedures for registering short names (descriptors) are detailed in
2275
BCP 64, RFC 4520 [RFC4520].
2277
6.3. Cache and Shadowing
2279
Some servers may hold cache or shadow copies of entries, which can be
2280
used to answer search and comparison queries, but will return
2281
referrals or contact other servers if modification operations are
2282
requested. Servers that perform shadowing or caching MUST ensure
2283
that they do not violate any access control constraints placed on the
2284
data by the originating server.
2298
Zeilenga Standards Track [Page 41]
2300
RFC 4512 LDAP Models June 2006
2303
7. Implementation Guidelines
2305
7.1. Server Guidelines
2307
Servers MUST recognize all names of attribute types and object
2308
classes defined in this document but, unless stated otherwise, need
2309
not support the associated functionality. Servers SHOULD recognize
2310
all the names of attribute types and object classes defined in
2311
Section 3 and 4, respectively, of [RFC4519].
2313
Servers MUST ensure that entries conform to user and system schema
2314
rules or other data model constraints.
2316
Servers MAY support DIT Content Rules. Servers MAY support DIT
2317
Structure Rules and Name Forms.
2319
Servers MAY support alias entries.
2321
Servers MAY support the 'extensibleObject' object class.
2323
Servers MAY support subentries. If so, they MUST do so in accordance
2324
with [RFC3672]. Servers that do not support subentries SHOULD use
2325
object entries to mimic subentries as detailed in Section 3.2.
2327
Servers MAY implement additional schema elements. Servers SHOULD
2328
provide definitions of all schema elements they support in subschema
2331
7.2. Client Guidelines
2333
In the absence of prior agreements with servers, clients SHOULD NOT
2334
assume that servers support any particular schema elements beyond
2335
those referenced in Section 7.1. The client can retrieve subschema
2336
information as described in Section 4.4.
2338
Clients MUST NOT display or attempt to decode a value as ASN.1 if the
2339
value's syntax is not known. Clients MUST NOT assume the LDAP-
2340
specific string encoding is restricted to a UTF-8 encoded string of
2341
Unicode characters or any particular subset of Unicode (such as a
2342
printable subset) unless such restriction is explicitly stated.
2343
Clients SHOULD NOT send attribute values in a request that are not
2344
valid according to the syntax defined for the attributes.
2354
Zeilenga Standards Track [Page 42]
2356
RFC 4512 LDAP Models June 2006
2359
8. Security Considerations
2361
Attributes of directory entries are used to provide descriptive
2362
information about the real-world objects they represent, which can be
2363
people, organizations, or devices. Most countries have privacy laws
2364
regarding the publication of information about people.
2366
General security considerations for accessing directory information
2367
with LDAP are discussed in [RFC4511] and [RFC4513].
2369
9. IANA Considerations
2371
The Internet Assigned Numbers Authority (IANA) has updated the LDAP
2372
descriptors registry as indicated in the following template:
2374
Subject: Request for LDAP Descriptor Registration Update
2375
Descriptor (short name): see comment
2376
Object Identifier: see comment
2377
Person & email address to contact for further information:
2378
Kurt Zeilenga <kurt@OpenLDAP.org>
2380
Specification: RFC 4512
2381
Author/Change Controller: IESG
2384
The following descriptors (short names) has been added to
2388
------------------------ ---- -----------------
2389
governingStructureRule A 2.5.21.10
2390
structuralObjectClass A 2.5.21.9
2392
The following descriptors (short names) have been updated to
2396
------------------------ ---- -----------------
2398
aliasedObjectName A 2.5.4.1
2399
altServer A 1.3.6.1.4.1.1466.101.120.6
2400
attributeTypes A 2.5.21.5
2401
createTimestamp A 2.5.18.1
2402
creatorsName A 2.5.18.3
2403
dITContentRules A 2.5.21.2
2404
dITStructureRules A 2.5.21.1
2405
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
2406
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
2410
Zeilenga Standards Track [Page 43]
2412
RFC 4512 LDAP Models June 2006
2415
matchingRuleUse A 2.5.21.8
2416
matchingRules A 2.5.21.4
2417
modifiersName A 2.5.18.4
2418
modifyTimestamp A 2.5.18.2
2419
nameForms A 2.5.21.7
2420
namingContexts A 1.3.6.1.4.1.1466.101.120.5
2421
objectClass A 2.5.4.0
2422
objectClasses A 2.5.21.6
2423
subschema O 2.5.20.1
2424
subschemaSubentry A 2.5.18.10
2425
supportedControl A 1.3.6.1.4.1.1466.101.120.13
2426
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
2427
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
2428
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
2429
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
2432
10. Acknowledgements
2434
This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
2435
S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
2436
RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
2437
Indexing of Directories (ASID) Working Group. This document is also
2438
based in part on "The Directory: Models" [X.501], a product of the
2439
International Telephone Union (ITU). Additional text was borrowed
2440
from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
2442
This document is a product of the IETF LDAP Revision (LDAPBIS)
2466
Zeilenga Standards Track [Page 44]
2468
RFC 4512 LDAP Models June 2006
2471
11. Normative References
2473
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2474
Requirement Levels", BCP 14, RFC 2119, March 1997.
2476
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
2477
10646", STD 63, RFC 3629, November 2003.
2479
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
2480
Directory Access Protocol (LDAP)", RFC 3671, December
2483
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
2484
Access Protocol (LDAP)", RFC 3672, December 2003.
2486
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2487
Specifications: ABNF", RFC 4234, October 2005.
2489
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
2490
Authentication and Security Layer (SASL)", RFC 4422,
2493
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
2494
Protocol (LDAP): Technical Specification Road Map", RFC
2497
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
2498
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
2500
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access
2501
Protocol (LDAP): Authentication Methods and Security
2502
Mechanisms", RFC 4513, June 2006.
2504
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
2505
Protocol (LDAP): String Representation of Distinguished
2506
Names", RFC 4514, June 2006.
2508
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
2509
Access Protocol (LDAP): String Representation of Search
2510
Filters", RFC 4515, June 2006.
2512
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
2513
Access Protocol (LDAP): Uniform Resource Locator", RFC
2516
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
2517
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
2522
Zeilenga Standards Track [Page 45]
2524
RFC 4512 LDAP Models June 2006
2527
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
2528
Protocol (LDAP): Schema for User Applications", RFC
2531
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
2532
(IANA) Considerations for the Lightweight Directory
2533
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
2535
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
2536
3.2.0" is defined by "The Unicode Standard, Version
2537
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
2538
61633-5), as amended by the "Unicode Standard Annex
2540
(http://www.unicode.org/reports/tr27/) and by the
2541
"Unicode Standard Annex #28: Unicode 3.2"
2542
(http://www.unicode.org/reports/tr28/).
2544
[X.500] International Telecommunication Union -
2545
Telecommunication Standardization Sector, "The
2546
Directory -- Overview of concepts, models and
2547
services," X.500(1993) (also ISO/IEC 9594-1:1994).
2549
[X.501] International Telecommunication Union -
2550
Telecommunication Standardization Sector, "The
2551
Directory -- Models," X.501(1993) (also ISO/IEC 9594-
2554
[X.680] International Telecommunication Union -
2555
Telecommunication Standardization Sector, "Abstract
2556
Syntax Notation One (ASN.1) - Specification of Basic
2557
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
2578
Zeilenga Standards Track [Page 46]
2580
RFC 4512 LDAP Models June 2006
2585
This appendix is non-normative.
2587
This document amounts to nearly a complete rewrite of portions of RFC
2588
2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
2589
overall clarity of technical specification. This appendix provides a
2590
summary of substantive changes made to the portions of these
2591
documents incorporated into this document. Readers should consult
2592
[RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of
2593
remaining portions of these documents.
2595
A.1. Changes to RFC 2251
2597
This document incorporates from RFC 2251, Sections 3.2 and 3.4, and
2598
portions of Sections 4 and 6 as summarized below.
2600
A.1.1. Section 3.2 of RFC 2251
2602
Section 3.2 of RFC 2251 provided a brief introduction to the X.500
2603
data model, as used by LDAP. The previous specification relied on
2604
[X.501] but lacked clarity in how X.500 models are adapted for use by
2605
LDAP. This document describes the X.500 data models, as used by
2606
LDAP, in greater detail, especially in areas where adaptation is
2609
Section 3.2.1 of RFC 2251 described an attribute as "a type with one
2610
or more associated values". In LDAP, an attribute is better
2611
described as an attribute description, a type with zero or more
2612
options, and one or more associated values.
2614
Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
2615
objectClasses and attributeTypes attributes, yet X.500(93) treats
2616
these attributes as optional. While generally all implementations
2617
that support X.500(93) subschema mechanisms will provide both of
2618
these attributes, it is not absolutely required for interoperability
2619
that all servers do. The mandate was removed for consistency with
2620
X.500(93). The subschema discovery mechanism was also clarified to
2621
indicate that subschema controlling an entry is obtained by reading
2622
the (sub)entry referred to by that entry's 'subschemaSubentry'
2634
Zeilenga Standards Track [Page 47]
2636
RFC 4512 LDAP Models June 2006
2639
A.1.2. Section 3.4 of RFC 2251
2641
Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
2642
This material, with changes, was incorporated in Section 5.1 of this
2647
- Clarify that attributes of the root DSE are subject to "other
2648
restrictions" in addition to access controls.
2650
- Clarify that only recognized extended requests need to be
2651
enumerated 'supportedExtension'.
2653
- Clarify that only recognized request controls need to be enumerated
2656
- Clarify that root DSE attributes are operational and, like other
2657
operational attributes, will not be returned in search requests
2658
unless requested by name.
2660
- Clarify that not all root DSE attributes are user modifiable.
2662
- Remove inconsistent text regarding handling of the
2663
'subschemaSubentry' attribute within the root DSE. The previous
2664
specification stated that the 'subschemaSubentry' attribute held in
2665
the root DSE referred to "subschema entries (or subentries) known
2666
by this server". This is inconsistent with the attribute's
2667
intended use as well as its formal definition as a single valued
2668
attribute [X.501]. It is also noted that a simple (possibly
2669
incomplete) list of subschema (sub)entries is not terribly useful.
2670
This document (in Section 5.1) specifies that the
2671
'subschemaSubentry' attribute of the root DSE refers to the
2672
subschema controlling the root DSE. It is noted that the general
2673
subschema discovery mechanism remains available (see Section 4.4 of
2676
A.1.3. Section 4 of RFC 2251
2678
Portions of Section 4 of RFC 2251 detailing aspects of the
2679
information model used by LDAP were incorporated in this document,
2682
- Restriction of distinguished values to attributes whose
2683
descriptions have no options (from Section 4.1.3);
2690
Zeilenga Standards Track [Page 48]
2692
RFC 4512 LDAP Models June 2006
2695
- Data model aspects of Attribute Types (from Section 4.1.4),
2696
Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
2697
Matching Rule Identifier (from 4.1.9); and
2699
- User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
2701
Clarifications to these portions include:
2703
- Subtyping and AttributeDescriptions with options.
2705
A.1.4. Section 6 of RFC 2251
2707
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
2708
where incorporated into this document.
2710
A.2. Changes to RFC 2252
2712
This document incorporates Sections 4, 5, and 7 from RFC 2252.
2714
A.2.1. Section 4 of RFC 2252
2716
The specification was updated to use Augmented BNF [RFC4234]. The
2717
string representation of an OBJECT IDENTIFIER was tightened to
2718
disallow leading zeros as described in RFC 2252.
2720
The <descr> syntax was changed to disallow semicolon (U+003B)
2721
characters in order to appear to be consistent its natural language
2722
specification "descr is the syntactic representation of an object
2723
descriptor, which consists of letters and digits, starting with a
2724
letter". In a related change, the statement "an AttributeDescription
2725
can be used as the value in a NAME part of an
2726
AttributeTypeDescription" was deleted. RFC 2252 provided no
2727
specification of the semantics of attribute options appearing in NAME
2730
RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
2731
over the <numericoid> form. However, <descr> form can be ambiguous.
2732
To address this issue, the imperative was replaced with a statement
2733
(in Section 1.4) that while the <descr> form is generally preferred,
2734
<numericoid> should be used where an unambiguous <descr> is not
2735
available. Additionally, an expanded discussion of descriptor issues
2736
is in Section 6.2 ("Short Names").
2738
The ABNF for a quoted string (qdstring) was updated to reflect
2739
support for the escaping mechanism described in Section 4.3 of RFC
2746
Zeilenga Standards Track [Page 49]
2748
RFC 4512 LDAP Models June 2006
2751
A.2.2. Section 5 of RFC 2252
2753
Definitions of operational attributes provided in Section 5 of RFC
2754
2252 where incorporated into this document.
2756
The 'namingContexts' description was clarified. A first-level DSA
2757
should publish, in addition to other values, "" indicating the root
2760
The 'altServer' description was clarified. It may hold any URI.
2762
The 'supportedExtension' description was clarified. A server need
2763
only list the OBJECT IDENTIFIERs associated with the extended
2764
requests of the extended operations it recognizes.
2766
The 'supportedControl' description was clarified. A server need only
2767
list the OBJECT IDENTIFIERs associated with the request controls it
2770
Descriptions for the 'structuralObjectClass' and
2771
'governingStructureRule' operational attribute types were added.
2773
The attribute definition of 'subschemaSubentry' was corrected to list
2774
the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
2776
A.2.3. Section 7 of RFC 2252
2778
Section 7 of RFC 2252 provides definitions of the 'subschema' and
2779
'extensibleObject' object classes. These definitions where
2780
integrated into Section 4.2 and Section 4.3 of this document,
2781
respectively. Section 7 of RFC 2252 also contained the object class
2782
implementation requirement. This was incorporated into Section 7 of
2785
The specification of 'extensibleObject' was clarified regarding how
2786
it interacts with precluded attributes.
2788
A.3. Changes to RFC 2256
2790
This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2793
Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
2794
attribute type. This was integrated into Section 2.4.1 of this
2795
document. The statement "One of the values is either 'top' or
2796
'alias'" was replaced with statement that one of the values is 'top'
2797
as entries belonging to 'alias' also belong to 'top'.
2802
Zeilenga Standards Track [Page 50]
2804
RFC 4512 LDAP Models June 2006
2807
Section 5.2 of RFC 2256 provided the definition of the
2808
'aliasedObjectName' attribute type. This was integrated into Section
2809
2.6.2 of this document.
2811
Section 7.1 of RFC 2256 provided the definition of the 'top' object
2812
class. This was integrated into Section 2.4.1 of this document.
2814
Section 7.2 of RFC 2256 provided the definition of the 'alias' object
2815
class. This was integrated into Section 2.6.1 of this document.
2817
A.4. Changes to RFC 3674
2819
This document made no substantive change to the 'supportedFeatures'
2820
technical specification provided in RFC 3674.
2827
EMail: Kurt@OpenLDAP.org
2858
Zeilenga Standards Track [Page 51]
2860
RFC 4512 LDAP Models June 2006
2863
Full Copyright Statement
2865
Copyright (C) The Internet Society (2006).
2867
This document is subject to the rights, licenses and restrictions
2868
contained in BCP 78, and except as set forth therein, the authors
2869
retain all their rights.
2871
This document and the information contained herein are provided on an
2872
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2873
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2874
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2875
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2876
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2877
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2879
Intellectual Property
2881
The IETF takes no position regarding the validity or scope of any
2882
Intellectual Property Rights or other rights that might be claimed to
2883
pertain to the implementation or use of the technology described in
2884
this document or the extent to which any license under such rights
2885
might or might not be available; nor does it represent that it has
2886
made any independent effort to identify any such rights. Information
2887
on the procedures with respect to rights in RFC documents can be
2888
found in BCP 78 and BCP 79.
2890
Copies of IPR disclosures made to the IETF Secretariat and any
2891
assurances of licenses to be made available, or the result of an
2892
attempt made to obtain a general license or permission for the use of
2893
such proprietary rights by implementers or users of this
2894
specification can be obtained from the IETF on-line IPR repository at
2895
http://www.ietf.org/ipr.
2897
The IETF invites any interested party to bring to its attention any
2898
copyrights, patents or patent applications, or other proprietary
2899
rights that may cover technology that may be required to implement
2900
this standard. Please address the information to the IETF at
2905
Funding for the RFC Editor function is provided by the IETF
2906
Administrative Support Activity (IASA).
2914
Zeilenga Standards Track [Page 52]
added
removed
source4/ldap_server/devdocs/rfc4512.txt
