Lightweight Directory Access Protocol (LDAP): Directory Information Models
obsoletes
Extracted elements (28)
Attribute description hierarchies allow access to the DIB with varying degrees of granularity: searching with a general attribute description (e.g., 'name') evaluates specialized subtypes (e.g., 'cn') as well. However, for user modification purposes, all descriptions in a hierarchy are treated as distinct and unrelated.
Short names (descriptors) are defined as more readable aliases for OIDs but are explicitly not expected to be displayed to end users; implementations are expected to translate them into local natural-language representations. The same short name can legitimately refer to different schema elements in different subschemas.
The 'extensibleObject' auxiliary object class (OID 1.3.6.1.4.1.1466.101.120.111) allows entries to hold any userApplications attribute, providing an escape hatch from strict schema enforcement while still requiring mandatory attributes and respecting precluded attributes from DIT content rules.
Clients SHOULD NOT assume that a published subschema is complete, that the server supports all published schema elements, or that the server does not support unpublished elements. Schema discovery (Section 4.4) is advisory, not exhaustive.
LDAP clients SHOULD NOT assume that servers implement any aspects of X.500 subschema beyond those described in RFC 4512. Servers following X.500(93) models SHOULD use X.500 subentry mechanisms, but other servers may use ordinary object entries belonging to the 'subschema' auxiliary class.
A server that masters entries and permits clients to modify those entries SHALL implement subschema (sub)entries and provide a 'subschemaSubentry' operational attribute in each modifiable entry, so clients can discover permitted attributes and object classes.
An alias entry SHALL have no subordinates, so alias entries are always leaf entries in the DIT. Every alias entry shall belong to the 'alias' object class.
An LDAP server SHALL provide root DSE information when a client performs a Search with empty baseObject, scope baseObject, and filter '(objectClass=*)'. The root DSE SHALL NOT be included if the client performs a subtree search starting from the root.
Clients MUST NOT display or attempt to decode a value as ASN.1 if the value's syntax is not known. Clients MUST NOT assume the LDAP-specific string encoding is restricted to a UTF-8 encoded string of Unicode characters unless such restriction is explicitly stated.
Implementations MUST be prepared that the same short name (descriptor) might be used in a subschema to refer to different kinds of schema elements (e.g., both an object class 'x-fubar' and an attribute type 'x-fubar') and across different subschemas.
Servers MUST recognize all attribute type and object class names defined in RFC 4512, and MUST ensure entries conform to user and system schema rules or other data model constraints.
Servers SHOULD maintain the 'creatorsName', 'createTimestamp', 'modifiersName', and 'modifyTimestamp' operational attributes for all entries of the DIT.
Servers that follow X.500(93) models SHALL restrict modifications of the 'objectClass' attribute to prevent the basic structural class of the entry from being changed (e.g., one cannot change a 'person' into a 'country').
Servers that perform shadowing or caching MUST ensure that they do not violate any access control constraints placed on the data by the originating server.
The structural object class of an entry shall not be changed. This means an entry's primary structural classification is fixed at creation and cannot be altered through modify operations.
To read schema from a subschema subentry, clients MUST issue a Search operation with baseObject set to the subschema DN, scope baseObject, filter '(objectClass=subschema)', and the desired schema attribute names listed explicitly (as they are operational).
When creating an entry or adding an 'objectClass' value, all superclasses of the named classes SHALL be implicitly added if not already present. Servers SHALL also restrict modifications that would delete superclasses of remaining objectClass values.
A subschema subentry holds all schema definitions (objectClasses, attributeTypes, matchingRules, matchingRuleUse, ldapSyntaxes, dITContentRules, dITStructureRules, nameForms) for a particular part of the DIT. It belongs to the 'subschema' auxiliary object class (OID 2.5.20.1).
Each entry consists of a set of attributes. An attribute is an attribute description (type plus zero or more options) with one or more values; no two values of an attribute may be equivalent per the attribute type's equality matching rule.
Object classes are one of three kinds: Abstract (base for inheritance, entries cannot belong directly unless a subclass is present), Structural (defines the primary structure of an entry; exactly one structural chain per entry), or Auxiliary (augments entries; governed by DIT content rules).
Operational attributes (creatorsName, createTimestamp, modifiersName, modifyTimestamp, structuralObjectClass, governingStructureRule) are defined with USAGE directoryOperation, SINGLE-VALUE, and NO-USER-MODIFICATION. They are not returned in search results unless explicitly requested by name.
The Directory Information Base (DIB) is organized as a tree of entries called the Directory Information Tree (DIT). Arcs between vertices define superior/subordinate relationships; an entry's Distinguished Name is the concatenation of its RDN and its immediate superior's DN.
The root DSE (named by the zero-length DN) exposes server-specific attributes: altServer, namingContexts, supportedControl, supportedExtension, supportedFeatures, supportedLDAPVersion, and supportedSASLMechanisms. These attributes have USAGE dSAOperation and are not returned unless explicitly requested.
The IANA LDAP Descriptors registry is updated by RFC 4512 to register short names (descriptors) for the attribute types and object classes defined herein (including 'objectClass', 'aliasedObjectName', 'creatorsName', 'createTimestamp', 'modifiersName', 'modifyTimestamp', 'subschemaSubentry', 'subschema', 'extensibleObject', and root DSE attributes). Registration procedures are specified in BCP 64, RFC 4520.
Attributes of directory entries provide descriptive information about real-world objects including people. Most countries have privacy laws regarding publication of information about people; general security considerations for LDAP are deferred to RFC 4511 and RFC 4513.
An attribute description is encoded as 'attributetype options' where attributetype is an OID or descriptor and each option is a semicolon-separated case-insensitive keychar string: 'attributedescription = attributetype options; options = *( SEMI option )'.
AttributeTypeDescription ABNF includes EQUALITY, ORDERING, and SUBSTR matching rule OIDs, a SYNTAX noidlen field with optional suggested upper bound in curly braces (e.g., '1.3.6.4.1.1466.0{64}'), SINGLE-VALUE, COLLECTIVE, NO-USER-MODIFICATION, and USAGE flags. NO-USER-MODIFICATION requires an operational usage.
ObjectClassDescription is encoded as ABNF: 'LPAREN WSP numericoid [SP "NAME" SP qdescrs] [SP "DESC" SP qdstring] [SP "OBSOLETE"] [SP "SUP" SP oids] [SP kind] [SP "MUST" SP oids] [SP "MAY" SP oids] extensions WSP RPAREN' where kind is ABSTRACT, STRUCTURAL, or AUXILIARY (default STRUCTURAL).