This repository has been archived by the owner on Dec 1, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrfc4512.txt
2915 lines (1881 loc) · 106 KB
/
rfc4512.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group K. Zeilenga
Request for Comments: 4512 OpenLDAP Foundation
Obsoletes: 2251, 2252, 2256, 3674 June 2006
Category: Standards Track
Lightweight Directory Access Protocol (LDAP):
Directory Information Models
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Lightweight Directory Access Protocol (LDAP) is an Internet
protocol for accessing distributed directory services that act in
accordance with X.500 data and service models. This document
describes the X.500 Directory Information Models, as used in LDAP.
Zeilenga Standards Track [Page 1]
RFC 4512 LDAP Models June 2006
Table of Contents
1. Introduction ....................................................3
1.1. Relationship to Other LDAP Specifications ..................3
1.2. Relationship to X.501 ......................................4
1.3. Conventions ................................................4
1.4. Common ABNF Productions ....................................4
2. Model of Directory User Information .............................6
2.1. The Directory Information Tree .............................7
2.2. Structure of an Entry ......................................7
2.3. Naming of Entries ..........................................8
2.4. Object Classes .............................................9
2.5. Attribute Descriptions ....................................12
2.6. Alias Entries .............................................16
3. Directory Administrative and Operational Information ...........17
3.1. Subtrees ..................................................17
3.2. Subentries ................................................18
3.3. The 'objectClass' attribute ...............................18
3.4. Operational Attributes ....................................19
4. Directory Schema ...............................................22
4.1. Schema Definitions ........................................23
4.2. Subschema Subentries ......................................32
4.3. 'extensibleObject' object class ...........................35
4.4. Subschema Discovery .......................................35
5. DSA (Server) Informational Model ...............................36
5.1. Server-Specific Data Requirements .........................36
6. Other Considerations ...........................................40
6.1. Preservation of User Information ..........................40
6.2. Short Names ...............................................41
6.3. Cache and Shadowing .......................................41
7. Implementation Guidelines ......................................42
7.1. Server Guidelines .........................................42
7.2. Client Guidelines .........................................42
8. Security Considerations ........................................43
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................44
11. Normative References ..........................................45
Appendix A. Changes ...............................................47
A.1. Changes to RFC 2251 .......................................47
A.2. Changes to RFC 2252 .......................................49
A.3. Changes to RFC 2256 .......................................50
A.4. Changes to RFC 3674 .......................................51
Zeilenga Standards Track [Page 2]
RFC 4512 LDAP Models June 2006
1. Introduction
This document discusses the X.500 Directory Information Models
[X.501], as used by the Lightweight Directory Access Protocol (LDAP)
[RFC4510].
The Directory is "a collection of open systems cooperating to provide
directory services" [X.500]. The information held in the Directory
is collectively known as the Directory Information Base (DIB). A
Directory user, which may be a human or other entity, accesses the
Directory through a client (or Directory User Agent (DUA)). The
client, on behalf of the directory user, interacts with one or more
servers (or Directory System Agents (DSA)). A server holds a
fragment of the DIB.
The DIB contains two classes of information:
1) user information (e.g., information provided and administrated
by users). Section 2 describes the Model of User Information.
2) administrative and operational information (e.g., information
used to administer and/or operate the directory). Section 3
describes the model of Directory Administrative and Operational
Information.
These two models, referred to as the generic Directory Information
Models, describe how information is represented in the Directory.
These generic models provide a framework for other information
models. Section 4 discusses the subschema information model and
subschema discovery. Section 5 discusses the DSA (Server)
Informational Model.
Other X.500 information models (such as access control distribution
knowledge and replication knowledge information models) may be
adapted for use in LDAP. Specification of how these models apply to
LDAP is left to future documents.
1.1. Relationship to Other LDAP Specifications
This document is a integral part of the LDAP technical specification
[RFC4510], which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety.
This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
portions of Sections 4 and 6. Appendix A.1 summarizes changes to
these sections. The remainder of RFC 2251 is obsoleted by the
[RFC4511], [RFC4513], and [RFC4510] documents.
Zeilenga Standards Track [Page 3]
RFC 4512 LDAP Models June 2006
This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2
summarizes changes to these sections. The remainder of RFC 2252 is
obsoleted by [RFC4517].
This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
Appendix A.3 summarizes changes to these sections. The remainder of
RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
This document obsoletes RFC 3674 in its entirety. Appendix A.4
summarizes changes since RFC 3674.
1.2. Relationship to X.501
This document includes material, with and without adaptation, from
[X.501] as necessary to describe this protocol. These adaptations
(and any other differences herein) apply to this protocol, and only
this protocol.
1.3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
Schema definitions are provided using LDAP description formats (as
defined in Section 4.1). Definitions provided here are formatted
(line wrapped) for readability. Matching rules and LDAP syntaxes
referenced in these definitions are specified in [RFC4517].
1.4. Common ABNF Productions
A number of syntaxes in this document are described using Augmented
Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a
number of syntaxes defined in other documents) rely on the following
common productions:
keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
Zeilenga Standards Track [Page 4]
RFC 4512 LDAP Models June 2006
NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""")
SHARP = %x23 ; octothorpe (or sharp sign) ("#")
DOLLAR = %x24 ; dollar sign ("$")
SQUOTE = %x27 ; single quote ("'")
LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",")
HYPHEN = %x2D ; hyphen ("-")
DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (";")
LANGLE = %x3C ; left angle bracket ("<")
EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket (">")
ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}"
; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
OCTET = %x00-FF ; Any octet (8-bit data unit)
Object identifiers (OIDs) [X.680] are represented in LDAP using a
dot-decimal format conforming to the ABNF:
numericoid = number 1*( DOT number )
Short names, also known as descriptors, are used as more readable
aliases for object identifiers. Short names are case insensitive and
conform to the ABNF:
descr = keystring
Zeilenga Standards Track [Page 5]
RFC 4512 LDAP Models June 2006
Where either an object identifier or a short name may be specified,
the following production is used:
oid = descr / numericoid
While the <descr> form is generally preferred when the usage is
restricted to short names referring to object identifiers that
identify like kinds of objects (e.g., attribute type descriptions,
matching rule descriptions, object class descriptions), the
<numericoid> form should be used when the object identifiers may
identify multiple kinds of objects or when an unambiguous short name
(descriptor) is not available.
Implementations SHOULD treat short names (descriptors) used in an
ambiguous manner (as discussed above) as unrecognized.
Short Names (descriptors) are discussed further in Section 6.2.
2. Model of Directory User Information
As [X.501] states:
The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'.
An object can be anything which is identifiable (can be named).
An object class is an identified family of objects, or conceivable
objects, which share certain characteristics. Every object
belongs to at least one class. An object class may be a subclass
of other object classes, in which case the members of the former
class, the subclass, are also considered to be members of the
latter classes, the superclasses. There may be subclasses of
subclasses, etc., to an arbitrary depth.
A directory entry, a named collection of information, is the basic
unit of information held in the Directory. There are multiple kinds
of directory entries.
An object entry represents a particular object. An alias entry
provides alternative naming. A subentry holds administrative and/or
operational information.
The set of entries representing the DIB are organized hierarchically
in a tree structure known as the Directory Information Tree (DIT).
Section 2.1 describes the Directory Information Tree.
Section 2.2 discusses the structure of entries.
Section 2.3 discusses naming of entries.
Zeilenga Standards Track [Page 6]
RFC 4512 LDAP Models June 2006
Section 2.4 discusses object classes.
Section 2.5 discusses attribute descriptions.
Section 2.6 discusses alias entries.
2.1. The Directory Information Tree
As noted above, the DIB is composed of a set of entries organized
hierarchically in a tree structure known as the Directory Information
Tree (DIT); specifically, a tree where vertices are the entries.
The arcs between vertices define relations between entries. If an
arc exists from X to Y, then the entry at X is the immediate superior
of Y, and Y is the immediate subordinate of X. An entry's superiors
are the entry's immediate superior and its superiors. An entry's
subordinates are all of its immediate subordinates and their
subordinates.
Similarly, the superior/subordinate relationship between object
entries can be used to derive a relation between the objects they
represent. DIT structure rules can be used to govern relationships
between objects.
Note: An entry's immediate superior is also known as the entry's
parent, and an entry's immediate subordinate is also known as
the entry's child. Entries that have the same parent are known
as siblings.
2.2. Structure of an Entry
An entry consists of a set of attributes that hold information about
the object that the entry represents. Some attributes represent user
information and are called user attributes. Other attributes
represent operational and/or administrative information and are
called operational attributes.
An attribute is an attribute description (a type and zero or more
options) with one or more associated values. An attribute is often
referred to by its attribute description. For example, the
'givenName' attribute is the attribute that consists of the attribute
description 'givenName' (the 'givenName' attribute type [RFC4519] and
zero options) and one or more associated values.
The attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions. Options indicate
subtypes and other functions.
Attribute values conform to the defined syntax of the attribute type.
Zeilenga Standards Track [Page 7]
RFC 4512 LDAP Models June 2006
No two values of an attribute may be equivalent. Two values are
considered equivalent if and only if they would match according to
the equality matching rule of the attribute type. Or, if the
attribute type is defined with no equality matching rule, two values
are equivalent if and only if they are identical. (See 2.5.1 for
other restrictions.)
For example, a 'givenName' attribute can have more than one value,
they must be Directory Strings, and they are case insensitive. A
'givenName' attribute cannot hold both "John" and "JOHN", as these
are equivalent values per the equality matching rule of the attribute
type.
Additionally, no attribute is to have a value that is not equivalent
to itself. For example, the 'givenName' attribute cannot have as a
value a directory string that includes the REPLACEMENT CHARACTER
(U+FFFD) code point, as matching involving that directory string is
Undefined per this attribute's equality matching rule.
When an attribute is used for naming of the entry, one and only one
value of the attribute is used in forming the Relative Distinguished
Name. This value is known as a distinguished value.
2.3. Naming of Entries
2.3.1. Relative Distinguished Names
Each entry is named relative to its immediate superior. This
relative name, known as its Relative Distinguished Name (RDN)
[X.501], is composed of an unordered set of one or more attribute
value assertions (AVA) consisting of an attribute description with
zero options and an attribute value. These AVAs are chosen to match
attribute values (each a distinguished value) of the entry.
An entry's relative distinguished name must be unique among all
immediate subordinates of the entry's immediate superior (i.e., all
siblings).
The following are examples of string representations of RDNs
[RFC4514]:
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
The last is an example of a multi-valued RDN; that is, an RDN
composed of multiple AVAs.
Zeilenga Standards Track [Page 8]
RFC 4512 LDAP Models June 2006
2.3.2. Distinguished Names
An entry's fully qualified name, known as its Distinguished Name (DN)
[X.501], is the concatenation of its RDN and its immediate superior's
DN. A Distinguished Name unambiguously refers to an entry in the
tree. The following are examples of string representations of DNs
[RFC4514]:
UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
2.3.3. Alias Names
An alias, or alias name, is "an name for an object, provided by the
use of alias entries" [X.501]. Alias entries are described in
Section 2.6.
2.4. Object Classes
An object class is "an identified family of objects (or conceivable
objects) that share certain characteristics" [X.501].
As defined in [X.501]:
Object classes are used in the Directory for a number of purposes:
- describing and categorizing objects and the entries that
correspond to these objects;
- where appropriate, controlling the operation of the Directory;
- regulating, in conjunction with DIT structure rule
specifications, the position of entries in the DIT;
- regulating, in conjunction with DIT content rule
specifications, the attributes that are contained in entries;
- identifying classes of entry that are to be associated with a
particular policy by the appropriate administrative authority.
An object class (a subclass) may be derived from an object class
(its direct superclass) which is itself derived from an even more
generic object class. For structural object classes, this process
stops at the most generic object class, 'top' (defined in Section
2.4.1). An ordered set of superclasses up to the most superior
object class of an object class is its superclass chain.
Zeilenga Standards Track [Page 9]
RFC 4512 LDAP Models June 2006
An object class may be derived from two or more direct
superclasses (superclasses not part of the same superclass chain).
This feature of subclassing is termed multiple inheritance.
Each object class identifies the set of attributes required to be
present in entries belonging to the class and the set of attributes
allowed to be present in entries belonging to the class. As an entry
of a class must meet the requirements of each class it belongs to, it
can be said that an object class inherits the sets of allowed and
required attributes from its superclasses. A subclass can identify
an attribute allowed by its superclass as being required. If an
attribute is a member of both sets, it is required to be present.
Each object class is defined to be one of three kinds of object
classes: Abstract, Structural, or Auxiliary.
Each object class is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
2.4.1. Abstract Object Classes
An abstract object class, as the name implies, provides a base of
characteristics from which other object classes can be defined to
inherit from. An entry cannot belong to an abstract object class
unless it belongs to a structural or auxiliary class that inherits
from that abstract class.
Abstract object classes cannot derive from structural or auxiliary
object classes.
All structural object classes derive (directly or indirectly) from
the 'top' abstract object class. Auxiliary object classes do not
necessarily derive from 'top'.
The following is the object class definition (see Section 4.1.1) for
the 'top' object class:
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
All entries belong to the 'top' abstract object class.
Zeilenga Standards Track [Page 10]
RFC 4512 LDAP Models June 2006
2.4.2. Structural Object Classes
As stated in [X.501]:
An object class defined for use in the structural specification of
the DIT is termed a structural object class. Structural object
classes are used in the definition of the structure of the names
of the objects for compliant entries.
An object or alias entry is characterized by precisely one
structural object class superclass chain which has a single
structural object class as the most subordinate object class.
This structural object class is referred to as the structural
object class of the entry.
Structural object classes are related to associated entries:
- an entry conforming to a structural object class shall
represent the real-world object constrained by the object
class;
- DIT structure rules only refer to structural object classes;
the structural object class of an entry is used to specify the
position of the entry in the DIT;
- the structural object class of an entry is used, along with an
associated DIT content rule, to control the content of an
entry.
The structural object class of an entry shall not be changed.
Each structural object class is a (direct or indirect) subclass of
the 'top' abstract object class.
Structural object classes cannot subclass auxiliary object classes.
Each entry is said to belong to its structural object class as well
as all classes in its structural object class's superclass chain.
2.4.3. Auxiliary Object Classes
Auxiliary object classes are used to augment the characteristics of
entries. They are commonly used to augment the sets of attributes
required and allowed to be present in an entry. They can be used to
describe entries or classes of entries.
Auxiliary object classes cannot subclass structural object classes.
Zeilenga Standards Track [Page 11]
RFC 4512 LDAP Models June 2006
An entry can belong to any subset of the set of auxiliary object
classes allowed by the DIT content rule associated with the
structural object class of the entry. If no DIT content rule is
associated with the structural object class of the entry, the entry
cannot belong to any auxiliary object class.
The set of auxiliary object classes that an entry belongs to can
change over time.
2.5. Attribute Descriptions
An attribute description is composed of an attribute type (see
Section 2.5.1) and a set of zero or more attribute options (see
Section 2.5.2).
An attribute description is represented by the ABNF:
attributedescription = attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar
where <attributetype> identifies the attribute type and each <option>
identifies an attribute option. Both <attributetype> and <option>
productions are case insensitive. The order in which <option>s
appear is irrelevant. That is, any two <attributedescription>s that
consist of the same <attributetype> and same set of <option>s are
equivalent.
Examples of valid attribute descriptions:
2.5.4.0
cn;lang-de;lang-en
owner
An attribute description with an unrecognized attribute type is to be
treated as unrecognized. Servers SHALL treat an attribute
description with an unrecognized attribute option as unrecognized.
Clients MAY treat an unrecognized attribute option as a tagging
option (see Section 2.5.2.1).
All attributes of an entry must have distinct attribute descriptions.
2.5.1. Attribute Types
An attribute type governs whether the attribute can have multiple
values, the syntax and matching rules used to construct and compare
values of that attribute, and other functions.
Zeilenga Standards Track [Page 12]
RFC 4512 LDAP Models June 2006
If no equality matching is specified for the attribute type:
- the attribute (of the type) cannot be used for naming;
- when adding the attribute (or replacing all values), no two
values may be equivalent (see 2.2);
- individual values of a multi-valued attribute are not to be
independently added or deleted;
- attribute value assertions (such as matching in search filters
and comparisons) using values of such a type cannot be
performed.
Otherwise, the specified equality matching rule is to be used to
evaluate attribute value assertions concerning the attribute type.
The specified equality rule is to be transitive and commutative.
The attribute type indicates whether the attribute is a user
attribute or an operational attribute. If operational, the attribute
type indicates the operational usage and whether or not the attribute
is modifiable by users. Operational attributes are discussed in
Section 3.4.
An attribute type (a subtype) may derive from a more generic
attribute type (a direct supertype). The following restrictions
apply to subtyping:
- a subtype must have the same usage as its direct supertype,
- a subtype's syntax must be the same, or a refinement of, its
supertype's syntax, and
- a subtype must be collective [RFC3671] if its supertype is
collective.
An attribute description consisting of a subtype and no options is
said to be the direct description subtype of the attribute
description consisting of the subtype's direct supertype and no
options.
Each attribute type is identified by an object identifier (OID) and,
optionally, one or more short names (descriptors).
2.5.2. Attribute Options
There are multiple kinds of attribute description options. The LDAP
technical specification details one kind: tagging options.
Not all options can be associated with attributes held in the
directory. Tagging options can be.
Zeilenga Standards Track [Page 13]
RFC 4512 LDAP Models June 2006
Not all options can be used in conjunction with all attribute types.
In such cases, the attribute description is to be treated as
unrecognized.
An attribute description that contains mutually exclusive options
shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
"x-foo" and "x-bar" are mutually exclusive, is to be treated as
unrecognized.
Other kinds of options may be specified in future documents. These
documents must detail how new kinds of options they define relate to
tagging options. In particular, these documents must detail whether
or not new kinds of options can be associated with attributes held in
the directory, how new kinds of options affect transfer of attribute
values, and how new kinds of options are treated in attribute
description hierarchies.
Options are represented as short, case-insensitive textual strings
conforming to the <option> production defined in Section 2.5 of this
document.
Procedures for registering options are detailed in BCP 64, RFC 4520
[RFC4520].
2.5.2.1. Tagging Options
Attributes held in the directory can have attribute descriptions with
any number of tagging options. Tagging options are never mutually
exclusive.
An attribute description with N tagging options is a direct
(description) subtype of all attribute descriptions of the same
attribute type and all but one of the N options. If the attribute
type has a supertype, then the attribute description is also a direct
(description) subtype of the attribute description of the supertype
and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
(description) subtype of 'cn;lang-de', 'cn;lang-en', and
'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
in [RFC4519]).
2.5.3. Attribute Description Hierarchies
An attribute description can be the direct subtype of zero or more
other attribute descriptions as indicated by attribute type subtyping
(as described in Section 2.5.1) or attribute tagging option subtyping
(as described in Section 2.5.2.1). These subtyping relationships are
used to form hierarchies of attribute descriptions and attributes.
Zeilenga Standards Track [Page 14]
RFC 4512 LDAP Models June 2006
As adapted from [X.501]:
Attribute hierarchies allow access to the DIB with varying degrees
of granularity. This is achieved by allowing the value components
of attributes to be accessed by using either their specific
attribute description (a direct reference to the attribute) or a
more generic attribute description (an indirect reference).
Semantically related attributes may be placed in a hierarchical
relationship, the more specialized being placed subordinate to the
more generalized. Searching for or retrieving attributes and
their values is made easier by quoting the more generalized
attribute description; a filter item so specified is evaluated for
the more specialized descriptions as well as for the quoted
description.
Where subordinate specialized descriptions are selected to be
returned as part of a search result these descriptions shall be
returned if available. Where the more general descriptions are
selected to be returned as part of a search result both the
general and the specialized descriptions shall be returned, if
available. An attribute value shall always be returned as a value
of its own attribute description.
All of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions for user
modification of entry content.
An attribute value stored in an object or alias entry is of
precisely one attribute description. The description is indicated
when the value is originally added to the entry.
For the purpose of subschema administration of the entry, a
specification that an attribute is required is fulfilled if the entry
contains a value of an attribute description belonging to an
attribute hierarchy where the attribute type of that description is
the same as the required attribute's type. That is, a "MUST name"
specification is fulfilled by 'name' or 'name;x-tag-option', but is
not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
subtype of 'name'). Likewise, an entry may contain a value of an
attribute description belonging to an attribute hierarchy where the
attribute type of that description is either explicitly included in
the definition of an object class to which the entry belongs or
allowed by the DIT content rule applicable to that entry. That is,
'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
(or by "MUST name").
Zeilenga Standards Track [Page 15]
RFC 4512 LDAP Models June 2006
For the purposes of other policy administration, unless stated
otherwise in the specification of the particular administrative
model, all of the attribute descriptions in an attribute hierarchy
are treated as distinct and unrelated descriptions.
2.6. Alias Entries
As adapted from [X.501]:
An alias, or an alias name, for an object is an alternative name
for an object or object entry which is provided by the use of
alias entries.
Each alias entry contains, within the 'aliasedObjectName'
attribute (known as the 'aliasedEntryName' attribute in X.500), a
name of some object. The distinguished name of the alias entry is
thus also a name for this object.
NOTE - The name within the 'aliasedObjectName' is said to be
pointed to by the alias. It does not have to be the
distinguished name of any entry.
The conversion of an alias name to an object name is termed
(alias) dereferencing and comprises the systematic replacement of
alias names, where found within a purported name, by the value of
the corresponding 'aliasedObjectName' attribute. The process may
require the examination of more than one alias entry.
Any particular entry in the DIT may have zero or more alias names.
It therefore follows that several alias entries may point to the
same entry. An alias entry may point to an entry that is not a
leaf entry and may point to another alias entry.
An alias entry shall have no subordinates, so that an alias entry
is always a leaf entry.
Every alias entry shall belong to the 'alias' object class.
An entry with the 'alias' object class must also belong to an object
class (or classes), or be governed by a DIT content rule, which
allows suitable naming attributes to be present.
Example:
dn: cn=bar,dc=example,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
Zeilenga Standards Track [Page 16]
RFC 4512 LDAP Models June 2006
cn: bar
aliasedObjectName: cn=foo,dc=example,dc=com
2.6.1. 'alias' Object Class
Alias entries belong to the 'alias' object class.
( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL
MUST aliasedObjectName )
2.6.2. 'aliasedObjectName' Attribute Type
The 'aliasedObjectName' attribute holds the name of the entry an
alias points to. The 'aliasedObjectName' attribute is known as the
'aliasedEntryName' attribute in X.500.
( 2.5.4.1 NAME 'aliasedObjectName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
3. Directory Administrative and Operational Information
This section discusses select aspects of the X.500 Directory
Administrative and Operational Information model [X.501]. LDAP
implementations MAY support other aspects of this model.
3.1. Subtrees
As defined in [X.501]:
A subtree is a collection of object and alias entries situated at
the vertices of a tree. Subtrees do not contain subentries. The
prefix sub, in subtree, emphasizes that the base (or root) vertex
of this tree is usually subordinate to the root of the DIT.
A subtree begins at some vertex and extends to some identifiable
lower boundary, possibly extending to leaves. A subtree is always
defined within a context which implicitly bounds the subtree. For
example, the vertex and lower boundaries of a subtree defining a
replicated area are bounded by a naming context.
Zeilenga Standards Track [Page 17]
RFC 4512 LDAP Models June 2006
3.2. Subentries
A subentry is a "special sort of entry, known by the Directory, used
to hold information associated with a subtree or subtree refinement"
[X.501]. Subentries are used in Directory to hold for administrative
and operational purposes as defined in [X.501]. Their use in LDAP is
detailed in [RFC3672].
The term "(sub)entry" in this specification indicates that servers
implementing X.500(93) models are, in accordance with X.500(93) as
described in [RFC3672], to use a subentry and that other servers are
to use an object entry belonging to the appropriate auxiliary class
normally used with the subentry (e.g., 'subschema' for subschema
subentries) to mimic the subentry. This object entry's RDN SHALL be
formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
all subentries are named with 'cn').
3.3. The 'objectClass' attribute
Each entry in the DIT has an 'objectClass' attribute.
( 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
(1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
The 'objectClass' attribute specifies the object classes of an entry,
which (among other things) are used in conjunction with the
controlling schema to determine the permitted attributes of an entry.
Values of this attribute can be modified by clients, but the
'objectClass' attribute cannot be removed.
Servers that follow X.500(93) models SHALL restrict modifications of
this attribute to prevent the basic structural class of the entry
from being changed. That is, one cannot change a 'person' into a
'country'.
When creating an entry or adding an 'objectClass' value to an entry,
all superclasses of the named classes SHALL be implicitly added as
well if not already present. That is, if the auxiliary class 'x-a'