RFC 4512
Lightweight Directory Access Protocol (LDAP): Directory Information Models
Lightweight Directory Access Protocol (LDAP): Directory Information Models ✨
Okay bestie, let's get into it 🎀. This is RFC 4512, called "Lightweight Directory Access Protocol (LDAP): Directory Information Models." It came out of the Network Working Group in June 2006, written by K. Zeilenga of the OpenLDAP Foundation. It's on the Standards Track 🦋, and it obsoletes RFC 2251, RFC 2252, RFC 2256, and RFC 3674. Main character energy, no cap 👑.
Status of This Memo
This is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💌. If you want the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
LDAP is an Internet protocol for accessing distributed directory services, and those services act in line with X.500 data and service models 🧚. This document describes the X.500 Directory Information Models as they're used in LDAP, so it's the blueprint for how the directory stores its info 💖.
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 .......................................511. Introduction ✨
This document talks about the X.500 Directory Information Models [X.501], which the Lightweight Directory Access Protocol (LDAP) [RFC4510] uses 💅.
The Directory is "a collection of open systems cooperating to provide directory services" [X.500]. All the information in the Directory is collectively called the Directory Information Base (DIB). A Directory user can be a human or some other entity, and they reach the Directory through a client (or Directory User Agent (DUA)). The client works for the user and talks to one or more servers (or Directory System Agents (DSA)). Each server holds a fragment of the DIB 🫶.
The DIB holds two kinds of information:
- User information, which is stuff provided and managed by users. Section 2 covers the Model of User Information.
- Administrative and operational information, which is the stuff used to run and administer the directory. Section 3 covers the model of Directory Administrative and Operational Information.
These two models are the generic Directory Information Models, and they describe how information gets represented in the Directory. They give you a framework that other information models can plug into ✨. Section 4 is about the subschema information model and subschema discovery, and Section 5 is about the DSA (Server) Informational Model 🧠.
Other X.500 information models, like the access control distribution knowledge and replication knowledge models, could be adapted for LDAP too. Spelling out how those apply to LDAP is left to future documents 🔮.
1.1. Relationship to Other LDAP Specifications
This document is an integral part of the LDAP technical specification [RFC4510], which obsoletes the previous LDAP technical specification, RFC 3377, in its entirety 💖.
This document obsoletes RFC 2251, Sections 3.2 and 3.4, plus parts of Sections 4 and 6. Appendix A.1 summarizes the changes to these sections. The rest of RFC 2251 is obsoleted by the [RFC4511], [RFC4513], and [RFC4510] documents 🎀.
This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2 summarizes changes to these sections. The rest 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 rest 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 from [X.501], sometimes adapted and sometimes not, as needed to describe this protocol. Those adaptations, and any other differences in this document, 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]. These are the rules-of-the-game words, so please don't freestyle them 🙈.
Schema definitions are written using LDAP description formats (as defined in Section 4.1). The definitions here are line wrapped so they're easier to read 💜. The matching rules and LDAP syntaxes referenced in these definitions are specified in [RFC4517] 📖.
1.4. Common ABNF Productions
A bunch of the syntaxes in this document are written in Augmented Backus-Naur Form (ABNF) [RFC4234] 🧚. These syntaxes, plus a number of syntaxes defined in other documents, all 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 " "
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 that follows this ABNF 🌸:
numericoid = number 1*( DOT number )Short names, also called descriptors, are used as more readable aliases for object identifiers. Short names are case insensitive and follow this ABNF 💅:
descr = keystringWhere either an object identifier or a short name can be specified, this production is used 🍓:
oid = descr / numericoidThe <descr> form is generally the go-to when you're only using short names for object identifiers that identify the same kind of thing, like attribute type descriptions, matching rule descriptions, or object class descriptions. The <numericoid> form should be used when the object identifiers could identify multiple kinds of objects, or when there isn't an unambiguous short name (descriptor) 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 ✨
okay so this section is the big picture, bestie 🌸 It's basically the "here's how the directory thinks about its data" chapter, and it starts by borrowing the official X.501 definition. 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).
So the big idea is that entries are the basic unit, there are a few different flavours of entry, and they all sit in one giant tree 🌳 Here's the roadmap for the rest of the section:
- Section 2.1 describes the Directory Information Tree.
- Section 2.2 discusses the structure of entries.
- Section 2.3 discusses naming of entries.
- 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.
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 ShoresThe last is an example of a multi-valued RDN; that is, an RDN composed of multiple AVAs. 💅
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=US2.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.
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.
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.
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 💅✨
okay so an attribute description is basically a combo of two things: an attribute type (see Section 2.5.1) and a set of zero or more attribute options (see Section 2.5.2) 🎀
It's written in ABNF like this:
attributedescription = attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keycharSo <attributetype> tells you which attribute type you've got, and each <option> is one attribute option 🦋 Both of those productions are case insensitive, so CN and cn are the same vibe. The order of the options doesn't matter either! Two attribute descriptions with the same attribute type and the same set of options are equivalent, period 💖
Some valid examples:
2.5.4.0
cn;lang-de;lang-en
ownerNow, what happens when things get weird? If an attribute description has an attribute type nobody recognizes, it gets treated as unrecognized 🙈 Servers SHALL treat an attribute description with an unrecognized attribute option as unrecognized too. Clients MAY be more chill about it and treat an unrecognized attribute option as a tagging option (see Section 2.5.2.1) 🫶
And one last rule: all the attributes of an entry have to have distinct attribute descriptions. No duplicates, bestie 💅
2.5.1. Attribute Types 🌸
An attribute type is the boss of an attribute. It decides whether the attribute can hold multiple values, which syntax and matching rules are used to build and compare its values, and a bunch of other stuff too ✨
If there's no equality matching specified for the attribute type, then:
- the attribute (of that type) can't be used for naming;
- when you add the attribute (or replace all of its values), no two values may be equivalent (see 2.2);
- individual values of a multi-valued attribute are not to be added or deleted on their own;
- attribute value assertions (like matching in search filters, and comparisons) using values of that type can't be performed.
Otherwise, the specified equality matching rule is what gets used to evaluate attribute value assertions for that attribute type. That rule is supposed to be transitive and commutative 🧠
The attribute type also tells you whether the attribute is a user attribute or an operational attribute. If it's operational, the attribute type shows what it's used for operationally and whether users are allowed to modify it. Operational attributes get their own deep dive in Section 3.4 🔥
Attribute types can have subtypes, which are more specific versions of a more generic attribute type (the direct supertype). Subtyping has a few rules, though:
- a subtype must have the same usage as its direct supertype,
- a subtype's syntax must be the same as its supertype's syntax, or a refinement of it, and
- a subtype must be collective [RFC3671] if its supertype is collective.
An attribute description that has a subtype and no options is called the direct description subtype of the attribute description made of that subtype's direct supertype and no options 💜
Each attribute type gets 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, but the LDAP technical specification only details one kind: tagging options 💅
Not every option can be attached to attributes held in the directory. Tagging options can be, though 🌈
Also, not every option works with every attribute type. When that happens, the attribute description is treated as unrecognized 💀
If an attribute description contains mutually exclusive options, it shall be treated as unrecognized. For example, cn;x-bar;x-foo, where x-foo and x-bar are mutually exclusive, gets treated as unrecognized 🙅
Other kinds of options might show up in future documents. Those documents must detail how their new option kinds relate to tagging options. Specifically, they must say whether the new kinds can be attached to attributes held in the directory, how they affect the transfer of attribute values, and how they're treated in attribute description hierarchies 📜
Options are written as short, case-insensitive textual strings that follow the <option> production from Section 2.5 of this document ✨
If you want to register options, the procedures are 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, so they can all hang out together 🥰
An attribute description with N tagging options is a direct (description) subtype of all the attribute descriptions that share its attribute type and all but one of those N options. If the attribute type has a supertype, the attribute description is also a direct (description) subtype of the supertype's attribute description combined with those N tagging options.
Here's an example: 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, and 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. That happens through attribute type subtyping (see Section 2.5.1) or attribute tagging option subtyping (see Section 2.5.2.1). These subtyping relationships build hierarchies of attribute descriptions and attributes 🫧
Here's the X.501 take on it, adapted for us:
Attribute hierarchies let you access the DIB at different levels of granularity 🔍 You can reach an attribute's value components either through their specific attribute description (a direct reference to the attribute) or through a more generic one (an indirect reference).
Semantically related attributes can be put into a hierarchy, with the more specialized ones placed under the more generalized ones. Searching for or retrieving attributes and their values gets easier when you quote the more generalized attribute description. A filter item written that way is evaluated against the more specialized descriptions too, as well as the one you quoted 🙌
When a search result is supposed to return a specialized subordinate description, that description shall be returned if it's available. When a search result is supposed to return a more general description, both the general and the specialized descriptions shall be returned, if they're available. An attribute value always comes back as a value of its own attribute description ✨
Every attribute description in an attribute hierarchy is treated as a distinct, unrelated description when it comes to users modifying entry content 🚧
An attribute value stored in an object or alias entry belongs to exactly one attribute description. That description gets recorded when the value is first added to the entry 📝
Now, for subschema administration of an entry: a requirement that an attribute is required gets satisfied if the entry has a value of an attribute description in an attribute hierarchy where that description's attribute type matches the required attribute's type. So a "MUST name" specification is satisfied by name or name;x-tag-option, but NOT by CN or CN;x-tag-option, even though CN is a subtype of name 🙈
Similarly, an entry can have a value of an attribute description in an attribute hierarchy if that description's attribute type is either explicitly included in the definition of an object class the entry belongs to, or allowed by the DIT content rule that governs that entry. So 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") 💅
For other policy administration, unless the specification of a particular administrative model says otherwise, every attribute description in an attribute hierarchy is treated as distinct and unrelated 🎀
2.6. Alias Entries 🎭
Here's the X.501 vibe, adapted for us: an alias (or alias name) is an alternative name for an object or object entry, provided by using alias entries 🪞
Each alias entry holds, inside the 'aliasedObjectName' attribute (called the 'aliasedEntryName' attribute in X.500), a name of some object. That means the alias entry's distinguished name is also a name for that object 💖
NOTE - The name inside the 'aliasedObjectName' is said to be pointed to by the alias. It does not have to be the distinguished name of any entry.
Turning an alias name back into an object name is called (alias) dereferencing. It works by systematically swapping out alias names, wherever they show up in a purported name, for the value of the matching 'aliasedObjectName' attribute. Sometimes this means checking more than one alias entry 🔁
Any particular entry in the DIT can have zero or more alias names. So it follows that several alias entries can point to the same entry. An alias entry can point to an entry that isn't a leaf entry, and it can also point to another alias entry 🌀
An alias entry shall have no subordinates, which means 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 also has to belong to an object class (or classes), or be governed by a DIT content rule, that allows suitable naming attributes to be present 🧚
Example time! 🌸
dn: cn=bar,dc=example,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
cn: bar
aliasedObjectName: cn=foo,dc=example,dc=com2.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 that an alias points to. In X.500, this attribute is known as the 'aliasedEntryName' attribute 💅
( 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 both defined in [RFC4517] ✨
3. Directory Administrative and Operational Information 🏛️
This section talks about select parts of the X.500 Directory Administrative and Operational Information model [X.501]. LDAP implementations MAY support other aspects of this model too 🌈
3.1. Subtrees
okay so [X.501] says a subtree is a collection of object and alias entries sitting at the vertices of a tree 🌳 subtrees do NOT contain subentries (ngl that's a big one). the "sub" in subtree is there because the base, or root, vertex is usually tucked underneath the root of the DIT 🦋
a subtree starts at some vertex and runs down to some identifiable lower boundary, and it might go all the way to the leaves 🍃 a subtree is always defined inside a context that bounds it. like, a subtree that defines a replicated area has its top and bottom edges set by a naming context. the boundaries are literally bounded, bestie 💅
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] 🧚 it's used in the Directory to hold stuff for administrative and operational purposes, as defined in [X.501]. how LDAP uses them is detailed in [RFC3672] 💜
the term "(sub)entry" in this spec means that servers following X.500(93) models, as described in [RFC3672], use a subentry. other servers use an object entry from the right auxiliary class that's normally paired with the subentry (like 'subschema' for subschema subentries) to mimic it 🎀 this is the important bit: that object entry's RDN SHALL be formed from a value of the 'cn' (commonName) attribute [RFC4519], because every subentry gets named with 'cn' anyway ✨
3.3. The 'objectClass' attribute
every entry in the DIT has an 'objectClass' attribute 🌸 here's its definition:
( 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 tells you the object classes of an entry. those classes, along with the controlling schema, decide which attributes an entry is allowed to have 🔥 clients can change its values, but the 'objectClass' attribute can never be removed. it's giving permanent 🔒
servers following X.500(93) models SHALL restrict changes to this attribute so the entry's basic structural class can't be changed. basically you can't turn a 'person' into a 'country' 💀
when you create an entry, or add an'objectClass'value to one, all the superclasses of the named classes SHALL be added implicitly too, if they aren't already there. so if the auxiliary class'x-a'is a subclass of'x-b', adding'x-a'makes'x-b'get added implicitly (unless it's already present). no skipping the parents, periodt 👑
servers SHALL restrict changes to this attribute so that superclasses of the remaining 'objectClass' values can't be deleted. so if 'x-a' is a subclass of the auxiliary class 'x-b' and the attribute holds both, trying to delete only 'x-b' is an error 🙈
3.4. Operational Attributes
some attributes, called operational attributes, are used or maintained by servers for administrative and operational purposes ⭐ as [X.501] puts it: "There are three varieties of operational attributes: Directory operational attributes, DSA-shared operational attributes, and DSA-specific operational attributes" 🌈
a directory operational attribute holds operational and/or administrative information in the Directory Information Model. that covers stuff the server maintains (like 'createTimestamp') and stuff users administer (like 'ditContentRules') 💖
a DSA-shared operational attribute holds information from the DSA Information Model that's shared between DSAs 🦋
a DSA-specific operational attribute holds information from the DSA Information Model that's specific to one DSA. it can sometimes be derived from info shared between DSAs, like 'namingContexts' 🧚
the DSA Information Model operational attributes are detailed in [X.501] 🌸
operational attributes aren't normally visible. they don't come back in search results unless somebody explicitly asks for them by name 🙈 and not all of them are user modifiable, so don't get your hopes up 😭
entries may contain, among others, these operational attributes:
- creatorsName: the Distinguished Name of the user who added this entry to the directory,
- createTimestamp: the time this entry was added to the directory,
- modifiersName: the Distinguished Name of the user who last modified this entry, and
- modifyTimestamp: the time this entry was last modified.
servers SHOULD maintain the 'creatorsName', 'createTimestamp', 'modifiersName', and 'modifyTimestamp' attributes for all entries of the DIT 🫶
3.4.1. 'creatorsName'
this attribute shows up in entries that were added using the protocol (like with the Add operation) 💅 the value is the distinguished name of the creator.
( 2.5.18.3 NAME 'creatorsName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )the 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517] ✨
3.4.2. 'createTimestamp'
this attribute shows up in entries that were added using the protocol (like with the Add operation) ⏰ the value is the time the entry was added.
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )the 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517] 🦋
3.4.3. 'modifiersName'
this attribute shows up in entries that have been modified using the protocol (like with the Modify operation) 🎀 the value is the distinguished name of the last modifier.
( 2.5.18.4 NAME 'modifiersName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )the 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517] 💜
3.4.4. 'modifyTimestamp'
this attribute shows up in entries that have been modified using the protocol (like with the Modify operation) 🌈 the value is the time the entry was last modified.
( 2.5.18.2 NAME 'modifyTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )the 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517] 🍓
3.4.5. 'structuralObjectClass'
this attribute tells you the structural object class of the entry 🔥
( 2.5.21.9 NAME 'structuralObjectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )the 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517] ✨
3.4.6. 'governingStructureRule'
this attribute tells you the structure rule that governs the entry 👑
( 2.5.21.10 NAME 'governingStructureRule'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )the 'integerMatch' matching rule and INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in [RFC4517] 🫶
4. Directory Schema 🎀
okay the schema is the big one, bestie 📚 as [X.501] defines it:
"The Directory Schema is a set of definitions and constraints concerning the structure of the DIT, the possible ways entries are named, the information that can be held in an entry, the attributes used to represent that information and their organization into hierarchies to facilitate search and retrieval of the information and the ways in which values of attributes may be matched in attribute value and matching rule assertions."
NOTE 1 - the schema lets the Directory system do stuff like:
- prevent the creation of subordinate entries of the wrong object-class (e.g., a country as a subordinate of a person);
- prevent the addition of attribute-types to an entry inappropriate to the object-class (e.g., a serial number to a person's entry);
- prevent the addition of an attribute value of a syntax not matching that defined for the attribute-type (e.g., a printable string to a bit string).
formally, the Directory Schema is a set of:
- a) Name Form definitions that define primitive naming relations for structural object classes;
- b) DIT Structure Rule definitions that define the names that entries may have and the ways in which the entries may be related to one another in the DIT;
- c) DIT Content Rule definitions that extend the specification of allowable attributes for entries beyond those indicated by the structural object classes of the entries;
- d) Object Class definitions that define the basic set of mandatory and optional attributes that shall be present, and may be present, respectively, in an entry of a given class, and which indicate the kind of object class that is being defined;
- e) Attribute Type definitions that identify the object identifier by which an attribute is known, its syntax, associated matching rules, whether it is an operational attribute and if so its type, whether it is a collective attribute, whether it is permitted to have multiple values and whether or not it is derived from another attribute type;
- f) Matching Rule definitions that define matching rules.
and in LDAP:
- g) LDAP Syntax definitions that define encodings used in LDAP. ✨ that's the schema, all wrapped up 💖
4.1. Schema Definitions ✨
Okay bestie, schema definitions in this section are described using ABNF 💅 and they lean on the common productions from Section 1.2, plus these:
noidlen = numericoid [ LCURLY len RCURLY ]
len = number
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )
extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
; Any UTF-8 encoded Unicode character
; except %x27 ("\'") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB
; Any ASCII character except %x27 ("\'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7FSchema definitions in this section also share a few common terms, and these are the big ones:
The NAME field gives you a set of short names (descriptors) that work as aliases for the OID. Think of them as nicknames, periodt 🎀
The DESC field can optionally hold a descriptive string from the directory administrator and/or implementor 🌸 Specs might suggest a description, but there's no requirement that the suggested (or any) descriptive string actually gets used. No pressure! 🫶
The OBSOLETE field, if it's there, tells you the element is not active 💀
Implementors should note that future versions of this document may expand these definitions to include more terms 🦋 Anything whose identifier starts with "X-" is reserved for private experiments, and those are followed by <SP> and <qdstrings> tokens. Hands off the X- prefix, it's giving "private diary" 🙈
4.1.1. Object Class Definitions 🧚
Object Class definitions are written according to this ABNF:
ObjectClassDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"Here's the breakdown, bestie 👑
<numericoid> is the object identifier assigned to this object class 🔢
NAME <qdescrs> are the short names (descriptors) that identify this object class ✨
DESC <qdstring> is a short descriptive string 🌈
OBSOLETE means this object class is not active anymore 💀
SUP <oids> names the direct superclasses of this object class 🍓
The kind of object class is one of ABSTRACT, STRUCTURAL, or AUXILIARY, and if you don't pick one, it defaults to STRUCTURAL 💅
MUST and MAY are the fields that specify the sets of required and allowed attribute types, respectively 🫶
And <extensions> describe the extensions 🦋
4.1.2. Attribute Types 💖
Attribute Type definitions are written according to this ABNF:
AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; supertype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions
usage = "userApplications" / ; user
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operationalHere's what each piece does 🍓
<numericoid> is the object identifier assigned to this attribute type 🔢
NAME <qdescrs> are the short names (descriptors) that identify this attribute type ✨
DESC <qdstring> is a short descriptive string 🌈
OBSOLETE means this attribute type is not active 💀
SUP oid names the direct supertype of this type 👑
EQUALITY, ORDERING, and SUBSTR give you the oid of the equality, ordering, and substrings matching rules, respectively 💅
SYNTAX identifies the value syntax by object identifier, and it may suggest a minimum upper bound 🎀
SINGLE-VALUE means attributes of this type are restricted to a single value 🙈
COLLECTIVE says this attribute type is collective [X.501][RFC3671] 🧚
NO-USER-MODIFICATION says this attribute type is not user modifiable 🔒
USAGE tells you the application of this attribute type 🦋
And <extensions> describe the extensions 🌸
Each attribute type description must contain at least one of the SUP or SYNTAX fields. If there's no SYNTAX field, the attribute type description takes its value from the supertype. Lowkey the supertype is doing all the work here 🫶
If the SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING fields take their value from the supertype when they're not specified. Iykyk 💖
A usage of userApplications is the default, and it means that attributes of this type represent user information. In other words, they are user attributes 🌈
A usage of directoryOperation, distributedOperation, or dSAOperation means that attributes of this type represent operational and/or administrative information. In other words, they are operational attributes ⭐
More specifically, directoryOperation usage means the attribute of this type is a directory operational attribute. distributedOperation usage means the attribute of this type is a DSA-shared usage operational attribute. And dSAOperation usage means the attribute of this type is a DSA-specific operational attribute 🍓
COLLECTIVE requires usage userApplications. Use of collective attribute types in LDAP is discussed in [RFC3671] 👑
NO-USER-MODIFICATION requires an operational usage 💅
Heads up: the <AttributeTypeDescription> does not list the matching rules that can be used with that attribute type in an extensibleMatch search filter [RFC4511]. That info lives in the 'matchingRuleUse' attribute, which is described in Section 4.1.4. Don't go looking for it in the wrong place, bestie 💀
This document refines the schema description of X.501 by requiring that the SYNTAX field in an <AttributeTypeDescription> be a string representation of an object identifier for the LDAP string syntax definition. It can also come with an optional indication of the suggested minimum bound of a value of this attribute 🎀
A suggested minimum upper bound on the number of characters in a value with a string-based syntax (or the number of bytes in a value for every other syntax) can be shown by appending the bound count inside curly braces, right after the syntax's OBJECT IDENTIFIER in an Attribute Type Description. That bound isn't part of the syntax name itself. For example, "1.3.6.4.1.1466.0{64}" suggests that server implementations should allow a string to be 64 characters long, although they may allow longer strings 🧚 Also, a single character of the Directory String syntax can be encoded in more than one octet, since UTF-8 [RFC3629] is a variable-length encoding. Wild, right? 🌈
4.1.3. Matching Rules 🔥
Matching rules are used when performing attribute value assertions, like during a Compare operation. They're also used when evaluating search filters, when figuring out which individual values get added or deleted during a Modify operation, and when comparing distinguished names 💅
Each matching rule is identified by an object identifier (OID) and, optionally, one or more short names (descriptors) ✨
Matching rule definitions are written according to this ABNF:
MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; assertion syntax
extensions WSP RPAREN ; extensionsHere's the rundown 🫶
<numericoid> is the object identifier assigned to this matching rule 🔢
NAME <qdescrs> are the short names (descriptors) that identify this matching rule 🌸
DESC <qdstring> is a short descriptive string 🌈
OBSOLETE means this matching rule is not active 💀
SYNTAX identifies the assertion syntax (the syntax of the assertion value) by object identifier 🎀
And <extensions> describe the extensions 🦋
4.1.4. Matching Rule Uses 💖
A matching rule use lists the attribute types that are suitable for use with an extensibleMatch search filter. Very organized of it 👑
Matching rule use descriptions are written according to the following ABNF:
MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "APPLIES" SP oids ; attribute types
extensions WSP RPAREN ; extensionsAnd the breakdown 🍓
<numericoid> is the object identifier of the matching rule associated with this matching rule use description 🔢
NAME <qdescrs> are the short names (descriptors) that identify this matching rule use ✨
DESC <qdstring> is a short descriptive string 🌈
OBSOLETE means this matching rule use is not active 💀
APPLIES gives you a list of the attribute types the matching rule applies to 🧚
And <extensions> describe the extensions 🌸
4.1.5. LDAP Syntaxes 🌈
LDAP Syntaxes of (attribute and assertion) values are described in terms of ASN.1 [X.680] and, optionally, they have an octet string encoding known as the LDAP-specific encoding. Usually, the LDAP-specific encoding is limited to a string of Unicode [Unicode] characters in UTF-8 [RFC3629] form 🫶
Each LDAP syntax is identified by an object identifier (OID) ✨
LDAP syntax definitions are written according to this ABNF:
SyntaxDescription = LPAREN WSP
numericoid ; object identifier
[ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensionsAnd here's what's what 💅
<numericoid> is the object identifier assigned to this LDAP syntax 🔢
DESC <qdstring> is a short descriptive string 🌈
And <extensions> describe the extensions 🦋
4.1.6. DIT Content Rules 🎀
okay so a DIT content rule is a "rule governing the content of entries of a particular structural object class" [X.501] 💅 basically it's the guest list for entries in the directory ✨
for DIT entries of one particular structural object class, a DIT content rule decides which auxiliary object classes those entries are allowed to belong to, plus which extra attributes (by type) are required, allowed, or not allowed to show up in them 🦋
the list of precluded attributes cannot include any attribute that's listed as mandatory in the rule, the structural object class, or any of the allowed auxiliary object classes 🙈
each content rule is identified by the object identifier, plus any short names (descriptors), of the structural object class it applies to 🌸
an entry may only belong to auxiliary object classes that are listed in the governing content rule 💜
an entry must contain all attributes required by the object classes it belongs to, AND all attributes required by the governing content rule 🫶
an entry may contain any non-precluded attributes allowed by the object classes it belongs to, as well as all attributes allowed by the governing content rule ✨
an entry cannot include any attribute precluded by the governing content rule 💀
an entry is governed by the DIT content rule that applies to its structural object class (if one is present and active in the subschema) 👑 see Section 2.4.2. if there's no active rule for the entry's structural object class, the entry's content is governed by the structural object class itself (and possibly other aspects of user and system schema) 🧚 DIT content rules for superclasses of an entry's structural object class are not applicable to that entry, so don't go looking up there 🙅♀️
DIT content rule descriptions are written according to this ABNF:
DITContentRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "AUX" SP oids ] ; auxiliary object classes
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types
extensions WSP RPAREN ; extensionswhere, in tea form:
<numericoid>is the object identifier of the structural object class associated with this DIT content rule;- NAME
<qdescrs>are short names (descriptors) identifying this DIT content rule; - DESC
<qdstring>is a short descriptive string; - OBSOLETE indicates this DIT content rule use is not active;
- AUX specifies a list of auxiliary object classes that entries subject to this DIT content rule may belong to;
- MUST, MAY, and NOT specify lists of attribute types that are required, allowed, or precluded, respectively, from appearing in entries subject to this DIT content rule; and
<extensions>describe extensions.
4.1.7. DIT Structure Rules and Name Forms 🌈
sometimes it's really useful to control where object and alias entries can be placed in the DIT, and how they get named, based on their structural object class 👑
4.1.7.1. DIT Structure Rules
a DIT structure rule is a "rule governing the structure of the DIT by specifying a permitted superior to subordinate entry relationship. A structure rule relates a name form, and therefore a structural object class, to superior structure rules. This permits entries of the structural object class identified by the name form to exist in the DIT as subordinates to entries governed by the indicated superior structure rules" [X.501] 🦋
DIT structure rule descriptions are written according to this ABNF:
DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules
extensions WSP RPAREN ; extensions
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = numberwhere:
<ruleid>is the rule identifier of this DIT structure rule;- NAME
<qdescrs>are short names (descriptors) identifying this DIT structure rule; - DESC
<qdstring>is a short descriptive string; - OBSOLETE indicates this DIT structure rule use is not active;
- FORM is specifies the name form associated with this DIT structure rule;
- SUP identifies superior rules (by rule id); and
<extensions>describe extensions.
if no superior rules are identified, the DIT structure rule applies to an autonomous administrative point (for example, the root vertex of the subtree controlled by the subschema) [X.501] 🌸
4.1.7.2. Name Forms 🎀
a name form "specifies a permissible RDN for entries of a particular structural object class. A name form identifies a named object class and one or more attribute types to be used for naming (i.e., for the RDN). Name forms are primitive pieces of specification used in the definition of DIT structure rules" [X.501] 💖
each name form indicates the structural object class to be named, a set of required attribute types, and a set of allowed attribute types. a particular attribute type cannot be in both sets 🙅♀️
entries governed by the form must be named using a value from each required attribute type, plus zero or more values from the allowed attribute types ✨
each name form is identified by an object identifier (OID) and, optionally, one or more short names (descriptors) 🫶
name form descriptions are written according to this ABNF:
NameFormDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "OC" SP oid ; structural object class
SP "MUST" SP oids ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN ; extensionswhere:
<numericoid>is object identifier that identifies this name form;- NAME
<qdescrs>are short names (descriptors) identifying this name form; - DESC
<qdstring>is a short descriptive string; - OBSOLETE indicates this name form is not active;
- OC identifies the structural object class this rule applies to,
- MUST and MAY specify the sets of required and allowed, respectively, naming attributes for this name form; and
<extensions>describe extensions.
all attribute types in the required ("MUST") and allowed ("MAY") lists shall be different 💅
4.2. Subschema Subentries 🧚
subschema (sub)entries are used for administering information about the directory schema 📚 a single subschema (sub)entry contains all schema definitions (see Section 4.1) used by entries in a particular part of the directory tree 🌳
servers that follow X.500(93) models SHOULD implement subschema using the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]), so these are not ordinary object entries but subentries (see Section 3.2). LDAP clients SHOULD NOT assume that servers implement any of the other aspects of X.500 subschema 🙈
servers MAY allow subschema modification. Procedures for subschema modification are discussed in Section 14.5 of [X.501] 🍓
a server that masters entries and permits clients to modify these entries SHALL implement and provide access to these subschema (sub)entries, including providing a 'subschemaSubentry' attribute in each modifiable entry 🔥 this is so clients can discover the attributes and object classes that are permitted to be present. It is strongly RECOMMENDED that all other servers implement this as well 💜
the value of the 'subschemaSubentry' attribute is the name of the subschema (sub)entry holding the subschema controlling the entry 🦋
( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )the 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517] ✨
subschema is held in (sub)entries belonging to the subschema auxiliary object class 🌈
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )the 'ldapSyntaxes' operational attribute may also be present in subschema entries 🌸
servers MAY provide additional attributes (described in other documents) in subschema (sub)entries 🎀
servers SHOULD provide the attributes 'createTimestamp' and 'modifyTimestamp' in subschema (sub)entries, so clients can maintain their caches of schema information 🫶
the following subsections provide attribute type definitions for each of the schema definition attribute types 💅
4.2.1. 'objectClasses' 🎀
this attribute holds definitions of object classes 📚
( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )the 'objectIdentifierFirstComponentMatch' matching rule and the ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are defined in [RFC4517] 💖
4.2.2. 'attributeTypes' 🦋
this attribute holds definitions of attribute types 🧚
( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )the 'objectIdentifierFirstComponentMatch' matching rule and the AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are defined in [RFC4517] ✨
4.2.3. 'matchingRules' 🌈
this attribute holds definitions of matching rules 🔥
( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation )the 'objectIdentifierFirstComponentMatch' matching rule and the MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are defined in [RFC4517] 💜
4.2.4 'matchingRuleUse' 🌸
this attribute holds definitions of matching rule uses 🍓
( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )the 'objectIdentifierFirstComponentMatch' matching rule and the MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are defined in [RFC4517] 🎀
4.2.5. 'ldapSyntaxes' 👑
this attribute holds definitions of LDAP syntaxes 💅
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation )the 'objectIdentifierFirstComponentMatch' matching rule and the SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined in [RFC4517] 🫶
4.2.6. 'dITContentRules' 💅
Okay so this attribute lists the DIT Content Rules that are present in the subschema 🌸
( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )The 'objectIdentifierFirstComponentMatch' matching rule and the DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are defined in [RFC4517]. ✨
4.2.7. 'dITStructureRules' 🦋
This attribute lists the DIT Structure Rules that are present in the subschema. It's giving organization 🎀
( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation )The 'integerFirstComponentMatch' matching rule and the DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are defined in [RFC4517]. 💜
4.2.8 'nameForms' 🧚
This attribute lists the Name Forms that are in force. Main character energy 👑
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )The 'objectIdentifierFirstComponentMatch' matching rule and the NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined in [RFC4517]. 🫶
4.3. 'extensibleObject' object class 🌈
Okay this one is so fun. The 'extensibleObject' auxiliary object class lets entries that belong to it hold any user attribute 🙈 The set of allowed attribute types for this object class is implicitly the set of all attribute types of userApplications usage. Literally anything goes 💅
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )Now the catch: the mandatory attributes of the other object classes on this entry are still required to be present, and any precluded attributes are still not allowed to be present. So it's not a free-for-all, bestie 💀
4.4. Subschema Discovery 🔥
Okay so how do you find the subschema? To discover the DN of the subschema (sub)entry holding the subschema controlling a particular entry, a client reads that entry's subschemaSubentry operational attribute 🍓
To read schema attributes from the subschema (sub)entry, clients MUST issue a Search operation [RFC4511] where baseObject is the DN of the subschema (sub)entry, scope is baseObject, filter is (objectClass=subschema) [RFC4515], and the attributes field lists the names of the desired schema attributes (as they are operational). Note: the (objectClass=subschema) filter lets LDAP servers that gateway to X.500 detect that subentry information is being requested. Lowkey clever 🧠✨
Clients SHOULD NOT assume that a published subschema is complete, that the server supports all of the schema elements it publishes, or that the server does not support an unpublished element. Trust, but verify 🫶
5. DSA (Server) Informational Model 🌸
The LDAP protocol assumes there are one or more servers that jointly provide access to a Directory Information Tree (DIT). The server holding the original information is called the "master" (for that information). Servers that hold copies of the original information are referred to as "shadowing" or "caching" servers. The group chat has a lot of copies, okay 💖
As defined in [X.501]:
- context prefix: The sequence of RDNs leading from the Root of the DIT to the initial vertex of a naming context; corresponds to the distinguished name of that vertex.
- naming context: A subtree of entries held in a single master DSA.
So, that is, a naming context is the largest collection of entries, starting at an entry that is mastered by a particular server, and including all its subordinates and their subordinates, down to the entries that are mastered by different servers. The context prefix is the name of the initial entry. Iconic 👑
The root of the DIT is a DSA-specific Entry (DSE) and not part of any naming context (or any subtree). Each server has different attribute values in the root DSE. Everyone's root is unique, no cap 🦋
5.1. Server-Specific Data Requirements 🎀
An LDAP server SHALL provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE, which is named with the DN with zero RDNs (whose [RFC4514] representation is as the zero-length string). 💜
These attributes are retrievable, subject to access control and other restrictions, if a client performs a Search operation [RFC4511] with an empty baseObject, scope of baseObject, the filter (objectClass=*) [RFC4515], and the attributes field listing the names of the desired attributes. It is noted that root DSE attributes are operational and, like other operational attributes, are not returned in search requests unless requested by name. Be specific or get nothing 🙈
The root DSE SHALL NOT be included if the client performs a subtree search starting from the root. No root DSE in the subtree party, sorry 💅
Servers may allow clients to modify attributes of the root DSE, where appropriate. 🧚
The following attributes of the root DSE are defined below. Additional attributes may be defined in other documents. ✨
- altServer: alternative servers;
- namingContexts: naming contexts;
- supportedControl: recognized LDAP controls;
- supportedExtension: recognized LDAP extended operations;
- supportedFeatures: recognized LDAP features;
- supportedLDAPVersion: LDAP versions supported; and
- supportedSASLMechanisms: recognized Simple Authentication and Security Layers (SASL) [RFC4422] mechanisms.
The values provided for these attributes may depend on session-specific and other factors. For example, a server supporting the SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's identity has been established by a lower level. See [RFC4513]. It depends on the vibe of the session 🌈
The root DSE may also include a 'subschemaSubentry' attribute. If it does, the attribute refers to the subschema (sub)entry holding the schema controlling the root DSE. Clients SHOULD NOT assume that this subschema (sub)entry controls other entries held by the server. General subschema discovery procedures are provided in Section 4.4. Don't assume, bestie 🫶
5.1.1. 'altServer' 🦋
The 'altServer' attribute lists URIs referring to alternative servers that may be contacted when this server becomes unavailable. URIs for servers implementing the LDAP are written according to [RFC4516]. Other kinds of URIs may be provided. If the server does not know of any other servers that could be used, this attribute will be absent. Clients may cache this information in case their preferred server later becomes unavailable. A backup plan, obsessed 💖
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation )The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in [RFC4517]. 🌸
5.1.2. 'namingContexts' 🍓
The 'namingContexts' attribute lists the context prefixes of the naming contexts the server masters or shadows (in part or in whole). If the server is a first-level DSA [X.501], it should list (in addition) an empty string (indicating the root of the DIT). If the server does not master or shadow any information (e.g., it is an LDAP gateway to a public X.500 directory), this attribute will be absent. If the server believes it masters or shadows the entire directory, the attribute will have a single value, and that value will be the empty string (indicating the root of the DIT). 🧠
This attribute may be used, for example, to select a suitable entry name for subsequent operations with this server. ✨
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation )The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is defined in [RFC4517]. 💅
5.1.3. 'supportedControl' 🔥
The 'supportedControl' attribute lists object identifiers identifying the request controls [RFC4511] the server supports. If the server does not support any request controls, this attribute will be absent. Object identifiers identifying response controls need not be listed. 🎀
Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. 🦋
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517]. 💜
5.1.4. 'supportedExtension' 🧚
The 'supportedExtension' attribute lists object identifiers identifying the extended operations [RFC4511] that the server supports. If the server does not support any extended operations, this attribute will be absent. 👑
An extended operation generally consists of an extended request and an extended response, but may also include other protocol data units (such as intermediate responses). The object identifier assigned to the extended request is used to identify the extended operation. Other object identifiers used in the extended operation need not be listed as values of this attribute. 🌈
Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. 🫶
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517]. ✨
5.1.5. 'supportedFeatures' 💖
The 'supportedFeatures' attribute lists object identifiers identifying elective features that the server supports. If the server does not support any discoverable elective features, this attribute will be absent. 🌸
( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. 🍓
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and objectIdentifierMatch matching rule are defined in [RFC4517]. 🧠
5.1.6. 'supportedLDAPVersion' 🎀
The 'supportedLDAPVersion' attribute lists the versions of LDAP that the server supports. 🦋
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation )The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517]. 💜
5.1.7. 'supportedSASLMechanisms' 👑
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms [RFC4422] that the server recognizes and/or supports [RFC4513]. The contents of this attribute may depend on the current session state. If the server does not support any SASL mechanisms, this attribute will not be present. 🔥
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined in [RFC4517]. 🌈
6. Other Considerations 🧚
6.1. Preservation of User Information 💅
Syntaxes may be defined that have specific value and/or value form (representation) preservation requirements. For example, a syntax containing digitally signed data can mandate that the server preserve both the value and form of value presented, so that the signature is not invalidated. Signatures are serious bestie 😭
Where such requirements have not been explicitly stated, servers SHOULD preserve the value of user information but MAY return the value in a different form. And where a server is unable (or unwilling) to preserve the value of user information, the server SHALL ensure that an equivalent value (per Section 2.3) is returned. Equivalent values only, periodt 🫶
6.2. Short Names 🎀
okay so short names (aka descriptors) are basically the nicknames for object identifiers 🦋 they make schema elements way easier to read. BUT implementations with a human UI usually won't just show those short names (or the OIDs) to users 💅 they'll translate them instead, like into a local national language. example: the short name "st" (stateOrProvinceName) could show up as "Land" for a German-speaking user 🇩🇪
same short name, different meaning in different subschemas, and even inside ONE subschema it can point to different OIDs for totally different kinds of schema elements 🙈
Implementations MUST be prepared for the same short name to be used in a subschema for different kinds of schema elements. like, there could be an object class 'x-fubar' AND an attribute type 'x-fubar' in the same subschema 💀
Implementations MUST also be prepared for the same short name to show up in different subschemas referring to different schema elements. so there might be two matching rules 'x-fubar', each living in its own subschema 🫶
registering short names (descriptors) is covered in BCP 64, RFC 4520 [RFC4520] ✨
6.3. Cache and Shadowing 🧚
some servers keep cache or shadow copies of entries 💜 they can use those to answer search and comparison queries, but if someone asks for a modification, they'll return referrals or go contact other servers instead.
servers doing shadowing or caching MUST make sure they don't violate any access control constraints the originating server put on the data 🔒 no sneaky workarounds, bestie!
7. Implementation Guidelines ✨
7.1. Server Guidelines 👑
servers MUST recognize all the names of attribute types and object classes defined in this document 📖 but unless it says otherwise, they don't need to support the functionality tied to them. servers SHOULD also recognize all the names of attribute types and object classes defined in Section 3 and 4, respectively, of [RFC4519] 🌸
servers MUST make sure entries conform to user and system schema rules or other data model constraints 💅
servers MAY support DIT Content Rules 🌈 and servers MAY support DIT Structure Rules and Name Forms too 🧚
servers MAY support alias entries 🦋
servers MAY support the 'extensibleObject' object class 💖
servers MAY support subentries. if they do, they MUST do it in accordance with [RFC3672] 📜 and servers that don't support subentries SHOULD use object entries to mimic subentries, as detailed in Section 3.2 🎀
servers MAY implement additional schema elements ✨ and servers SHOULD provide definitions of ALL the schema elements they support in subschema (sub)entries 💜
7.2. Client Guidelines 🫶
unless clients have prior agreements with servers, clients SHOULD NOT assume that servers support any particular schema elements beyond the ones referenced in Section 7.1 🙈 clients can grab subschema info like it's described in Section 4.4 🔍
clients MUST NOT display or try to decode a value as ASN.1 if the value's syntax isn't known 💀 clients MUST NOT assume the LDAP-specific string encoding is restricted to a UTF-8 encoded string of Unicode characters, or to any particular subset of Unicode (like a printable subset), unless that restriction is explicitly stated 🌈 and clients SHOULD NOT send attribute values in a request that aren't valid according to the syntax defined for the attributes 🍓
8. Security Considerations 🔥
the attributes of directory entries give descriptive info about real-world objects, and those objects can be people, organizations, or devices 😭 most countries have privacy laws about publishing info about people, so this is a serious one, bestie. handle it with care 💜
general security considerations for accessing directory info with LDAP are discussed in [RFC4511] and [RFC4513] 🔐
9. IANA Considerations 📋
the Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry 🦋 here's the template it used:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment
Specification: RFC 4512
Author/Change Controller: IESG
Comments:
The following descriptors (short names) has been added to
the registry.
NAME Type OID
------------------------ ---- -----------------
governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.9
The following descriptors (short names) have been updated to
refer to this RFC.
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.010. Acknowledgements 🫶
this document is based in part on RFC 2251 by M. Wahl, T. Howes, and S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and RFC 2556 by M. Wahl, all products of the IETF Access, Searching and Indexing of Directories (ASID) Working Group 🌟 it's also based in part on "The Directory: Models" [X.501], a product of the International Telephone Union (ITU) 🌍 and extra text was borrowed from RFC 2253 by M. Wahl, T. Howes, and S. Kille 📚
this document is a product of the IETF LDAP Revision (LDAPBIS) Working Group 💖
11. Normative References 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, December 2003.
- [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, December 2003.
- [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
- [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
- [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
- [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
- [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
- [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
- [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
- [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
- [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
- [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
- [X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
- [X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
- [X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
Appendix A. Changes 🦋
This appendix is non-normative. 🌸
this document is basically a near-complete rewrite of parts of RFC 2251, RFC 2252, and RFC 2256 ✨ the rewrite was done to make the technical spec clearer 💅 this appendix sums up the substantive changes made to the parts of those documents that got folded in here. for summaries of the remaining parts, readers should check out [RFC4510], [RFC4511], [RFC4517], and [RFC4519] 📖
A.1. Changes to RFC 2251 🎀
this document incorporates Sections 3.2 and 3.4 from RFC 2251, plus portions of Sections 4 and 6, as summarized below 👑
A.1.1. Section 3.2 of RFC 2251
Okay, bestie, this section is about the X.500 data model and how LDAP uses it 💅🌸. Section 3.2 of RFC 2251 gave a quick intro to X.500, but it leaned on [X.501] without really explaining how LDAP adapts it. This document goes deeper, especially where adaptation is needed 🔍.
Section 3.2.1 of RFC 2251 called an attribute "a type with one or more associated values." In LDAP, an attribute is better described as an attribute description: a type with zero or more options, and one or more associated values 🎀.
Section 3.2.2 of RFC 2251 required subschema subentries to contain objectClasses and attributeTypes attributes. But X.500(93) treats those attributes as optional 🤔. Sure, pretty much every implementation that supports X.500(93) subschema mechanisms will provide both, but interoperability doesn't strictly require every server to do it. So the requirement got removed to match X.500(93) ✨. The subschema discovery mechanism was also clarified: the subschema controlling an entry is found by reading the (sub)entry referred to by that entry's subschemaSubentry attribute 🦋.
A.1.2. Section 3.4 of RFC 2251
Section 3.4 of RFC 2251 covered "Server-specific Data Requirements." That material was updated and folded into Section 5.1 of this document 🧚.
Changes:
- Clarify that attributes of the root DSE are subject to "other restrictions" in addition to access controls.
- Clarify that only recognized extended requests need to be enumerated
supportedExtension. - Clarify that only recognized request controls need to be enumerated
supportedControl. - Clarify that root DSE attributes are operational and, like other operational attributes, will not be returned in search requests unless requested by name.
- Clarify that not all root DSE attributes are user modifiable.
- Remove inconsistent text about handling the
subschemaSubentryattribute within the root DSE 💀. The old spec said thesubschemaSubentryattribute in the root DSE referred to "subschema entries (or subentries) known by this server." That clashes with how the attribute is meant to be used, and with its formal definition as a single valued attribute [X.501]. Also, a simple (possibly incomplete) list of subschema (sub)entries isn't terribly useful 🙄. This document (in Section 5.1) says thesubschemaSubentryattribute of the root DSE refers to the subschema controlling the root DSE 👑. The general subschema discovery mechanism is still available, see Section 4.4 of this document 🫶.
A.1.3. Section 4 of RFC 2251
Parts of Section 4 of RFC 2251 that describe the information model LDAP uses were brought into this document 📚, including:
- Restriction of distinguished values to attributes whose descriptions have no options (from Section 4.1.3);
- Data model aspects of Attribute Types (from Section 4.1.4), Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8), Matching Rule Identifier (from 4.1.9); and
- User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
The clarifications to these parts include:
- Subtyping and AttributeDescriptions with options.
A.1.4. Section 6 of RFC 2251
Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 were incorporated into this document 🌈.
A.2. Changes to RFC 2252
This document brings in Sections 4, 5, and 7 from RFC 2252 🍓.
A.2.1. Section 4 of RFC 2252
The specification now uses Augmented BNF [RFC4234] ✨. The string form of an OBJECT IDENTIFIER got tightened so leading zeros are disallowed, as described in RFC 2252 🔥.
The <descr> syntax now disallows semicolon (U+003B) characters, so it lines up with its natural language spec: "descr is the syntactic representation of an object descriptor, which consists of letters and digits, starting with a letter" 💜. Related to that, the statement "an AttributeDescription can be used as the value in a NAME part of an AttributeTypeDescription" got deleted 🗑️. RFC 2252 never specified what attribute options in NAME fields actually mean semantically, so yeah, that was a mess 😭.
RFC 2252 said the <descr> form of <oid> SHOULD be preferred over the <numericoid> form. But <descr> can be ambiguous 👀. To fix that, the SHOULD got swapped for a statement (in Section 1.4) saying that while <descr> is generally preferred, <numericoid> should be used when an unambiguous <descr> isn't available 🎯. There's also a deeper dive on descriptor issues in Section 6.2 ("Short Names") 🧠.
The ABNF for a quoted string (qdstring) was updated to support the escaping mechanism from Section 4.3 of RFC 2252 🎀.
A.2.2. Section 5 of RFC 2252
The operational attribute definitions from Section 5 of RFC 2252 were moved into this document 🏠.
The namingContexts description got clarified. A first-level DSA should publish, along with its other values, "" to indicate the root of the DIT 🌳.
The altServer description got clarified too. It may hold any URI 🌐.
The supportedExtension description got clarified. A server only needs to list the OBJECT IDENTIFIERs for the extended requests of the extended operations it recognizes 🦋.
The supportedControl description got clarified. A server only needs to list the OBJECT IDENTIFIERs for the request controls it recognizes ⭐.
Descriptions for the structuralObjectClass and governingStructureRule operational attribute types were added 💖.
The attribute definition of subschemaSubentry got corrected so the terms SINGLE-VALUE and NO-USER-MODIFICATION are in the right order 🙈.
A.2.3. Section 7 of RFC 2252
Section 7 of RFC 2252 defines the subschema and extensibleObject object classes. Those definitions were merged into Section 4.2 and Section 4.3 of this document, respectively 🧚♀️. Section 7 of RFC 2252 also held the object class implementation requirement, which now lives in Section 7 of this document 📜.
The spec for extensibleObject got clarified about how it interacts with precluded attributes 💅.
A.3. Changes to RFC 2256
This document brings in Sections 5.1, 5.2, 7.1, and 7.2 of RFC 2256 🫶.
Section 5.1 of RFC 2256 defined the objectClass attribute type. That got folded into Section 2.4.1 of this document. The statement "One of the values is either 'top' or 'alias'" was replaced with a statement that one of the values is 'top', since entries belonging to 'alias' also belong to 'top' 🔥.
Section 5.2 of RFC 2256 defined the aliasedObjectName attribute type. That got integrated into Section 2.6.2 of this document 🌸.
Section 7.1 of RFC 2256 defined the 'top' object class. That got integrated into Section 2.4.1 of this document ✨.
Section 7.2 of RFC 2256 defined the 'alias' object class. That got integrated into Section 2.6.1 of this document 🦋.
A.4. Changes to RFC 3674
This document made no substantive change to the supportedFeatures technical specification from RFC 3674 🌈. Nothing to see here, it's giving consistency 💜.
Editor's Address
Kurt D. Zeilenga OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79 ⚖️.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 📎.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org 💌.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🙏✨.
📦 where this page comes from
- ietf: rfc4512 2006-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms