Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4512

Lightweight Directory Access Protocol (LDAP): Directory Information Models

Pages: 52
Proposed Standard
Errata
Obsoletes:  2251225222563674
Part 2 of 3 – Pages 17 to 40
First   Prev   Next

Top   ToC   RFC4512 - Page 17   prevText

3. Directory Administrative and Operational Information

This section discusses select aspects of the X.500 Directory Administrative and Operational Information model [X.501]. LDAP implementations MAY support other aspects of this model.

3.1. Subtrees

As defined in [X.501]: A subtree is a collection of object and alias entries situated at the vertices of a tree. Subtrees do not contain subentries. The prefix sub, in subtree, emphasizes that the base (or root) vertex of this tree is usually subordinate to the root of the DIT. A subtree begins at some vertex and extends to some identifiable lower boundary, possibly extending to leaves. A subtree is always defined within a context which implicitly bounds the subtree. For example, the vertex and lower boundaries of a subtree defining a replicated area are bounded by a naming context.
Top   ToC   RFC4512 - Page 18

3.2. Subentries

A subentry is a "special sort of entry, known by the Directory, used to hold information associated with a subtree or subtree refinement" [X.501]. Subentries are used in Directory to hold for administrative and operational purposes as defined in [X.501]. Their use in LDAP is detailed in [RFC3672]. The term "(sub)entry" in this specification indicates that servers implementing X.500(93) models are, in accordance with X.500(93) as described in [RFC3672], to use a subentry and that other servers are to use an object entry belonging to the appropriate auxiliary class normally used with the subentry (e.g., 'subschema' for subschema subentries) to mimic the subentry. This object entry's RDN SHALL be formed from a value of the 'cn' (commonName) attribute [RFC4519] (as all subentries are named with 'cn').

3.3. The 'objectClass' attribute

Each entry in the DIT has an 'objectClass' attribute. ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517]. The 'objectClass' attribute specifies the object classes of an entry, which (among other things) are used in conjunction with the controlling schema to determine the permitted attributes of an entry. Values of this attribute can be modified by clients, but the 'objectClass' attribute cannot be removed. Servers that follow X.500(93) models SHALL restrict modifications of this attribute to prevent the basic structural class of the entry from being changed. That is, one cannot change a 'person' into a 'country'. When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present. That is, if the auxiliary class 'x-a' is a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes 'x-b' to be implicitly added (if is not already present). Servers SHALL restrict modifications of this attribute to prevent superclasses of remaining 'objectClass' values from being deleted. That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
Top   ToC   RFC4512 - Page 19
   class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
   an attempt to delete only 'x-b' from the 'objectClass' attribute is
   an error.

3.4. Operational Attributes

Some attributes, termed operational attributes, are used or maintained by servers for administrative and operational purposes. As stated in [X.501]: "There are three varieties of operational attributes: Directory operational attributes, DSA-shared operational attributes, and DSA-specific operational attributes". A directory operational attribute is used to represent operational and/or administrative information in the Directory Information Model. This includes operational attributes maintained by the server (e.g., 'createTimestamp') as well as operational attributes that hold values administrated by the user (e.g., 'ditContentRules'). A DSA-shared operational attribute is used to represent information of the DSA Information Model that is shared between DSAs. A DSA-specific operational attribute is used to represent information of the DSA Information Model that is specific to the DSA (though, in some cases, may be derived from information shared between DSAs; e.g., 'namingContexts'). The DSA Information Model operational attributes are detailed in [X.501]. Operational attributes are not normally visible. They are not returned in search results unless explicitly requested by name. Not all operational attributes are user modifiable. Entries may contain, among others, the following operational attributes: - creatorsName: the Distinguished Name of the user who added this entry to the directory, - createTimestamp: the time this entry was added to the directory, - modifiersName: the Distinguished Name of the user who last modified this entry, and - modifyTimestamp: the time this entry was last modified.
Top   ToC   RFC4512 - Page 20
   Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
   'modifiersName', and 'modifyTimestamp' attributes for all entries of
   the DIT.

3.4.1. 'creatorsName'

This attribute appears in entries that were added using the protocol (e.g., using the Add operation). The value is the distinguished name of the creator. ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].

3.4.2. 'createTimestamp'

This attribute appears in entries that were added using the protocol (e.g., using the Add operation). The value is the time the entry was added. ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].

3.4.3. 'modifiersName'

This attribute appears in entries that have been modified using the protocol (e.g., using the Modify operation). The value is the distinguished name of the last modifier. ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
Top   ToC   RFC4512 - Page 21
   The 'distinguishedNameMatch' matching rule and the DistinguishedName
   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].

3.4.4. 'modifyTimestamp'

This attribute appears in entries that have been modified using the protocol (e.g., using the Modify operation). The value is the time the entry was last modified. ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].

3.4.5. 'structuralObjectClass'

This attribute indicates the structural object class of the entry. ( 2.5.21.9 NAME 'structuralObjectClass' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].

3.4.6. 'governingStructureRule'

This attribute indicates the structure rule governing the entry. ( 2.5.21.10 NAME 'governingStructureRule' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) The 'integerMatch' matching rule and INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
Top   ToC   RFC4512 - Page 22

4. Directory Schema

As defined in [X.501]: The Directory Schema is a set of definitions and constraints concerning the structure of the DIT, the possible ways entries are named, the information that can be held in an entry, the attributes used to represent that information and their organization into hierarchies to facilitate search and retrieval of the information and the ways in which values of attributes may be matched in attribute value and matching rule assertions. NOTE 1 - The schema enables the Directory system to, for example: - prevent the creation of subordinate entries of the wrong object-class (e.g., a country as a subordinate of a person); - prevent the addition of attribute-types to an entry inappropriate to the object-class (e.g., a serial number to a person's entry); - prevent the addition of an attribute value of a syntax not matching that defined for the attribute-type (e.g., a printable string to a bit string). Formally, the Directory Schema comprises a set of: a) Name Form definitions that define primitive naming relations for structural object classes; b) DIT Structure Rule definitions that define the names that entries may have and the ways in which the entries may be related to one another in the DIT; c) DIT Content Rule definitions that extend the specification of allowable attributes for entries beyond those indicated by the structural object classes of the entries; d) Object Class definitions that define the basic set of mandatory and optional attributes that shall be present, and may be present, respectively, in an entry of a given class, and which indicate the kind of object class that is being defined;
Top   ToC   RFC4512 - Page 23
      e) Attribute Type definitions that identify the object identifier
         by which an attribute is known, its syntax, associated matching
         rules, whether it is an operational attribute and if so its
         type, whether it is a collective attribute, whether it is
         permitted to have multiple values and whether or not it is
         derived from another attribute type;

      f) Matching Rule definitions that define matching rules.

      And in LDAP:

      g) LDAP Syntax definitions that define encodings used in LDAP.

4.1. Schema Definitions

Schema definitions in this section are described using ABNF and rely on the common productions specified in Section 1.2 as well as these: noidlen = numericoid [ LCURLY len RCURLY ] len = number oids = oid / ( LPAREN WSP oidlist WSP RPAREN ) oidlist = oid *( WSP DOLLAR WSP oid ) extensions = *( SP xstring SP qdstrings ) xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE ) qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN ) qdescrlist = [ qdescr *( SP qdescr ) ] qdescr = SQUOTE descr SQUOTE qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN ) qdstringlist = [ qdstring *( SP qdstring ) ] qdstring = SQUOTE dstring SQUOTE dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string QQ = ESC %x32 %x37 ; "\27" QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c" ; Any UTF-8 encoded Unicode character ; except %x27 ("\'") and %x5C ("\") QUTF8 = QUTF1 / UTFMB ; Any ASCII character except %x27 ("\'") and %x5C ("\") QUTF1 = %x00-26 / %x28-5B / %x5D-7F Schema definitions in this section also share a number of common terms.
Top   ToC   RFC4512 - Page 24
   The NAME field provides a set of short names (descriptors) that are
   to be used as aliases for the OID.

   The DESC field optionally allows a descriptive string to be provided
   by the directory administrator and/or implementor.  While
   specifications may suggest a descriptive string, there is no
   requirement that the suggested (or any) descriptive string be used.

   The OBSOLETE field, if present, indicates the element is not active.

   Implementors should note that future versions of this document may
   expand these definitions to include additional terms.  Terms whose
   identifier begins with "X-" are reserved for private experiments and
   are followed by <SP> and <qdstrings> tokens.

4.1.1. Object Class Definitions

Object Class definitions are written according to the ABNF: ObjectClassDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "SUP" SP oids ] ; superior object classes [ SP kind ] ; kind of class [ SP "MUST" SP oids ] ; attribute types [ SP "MAY" SP oids ] ; attribute types extensions WSP RPAREN kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" where: <numericoid> is object identifier assigned to this object class; NAME <qdescrs> are short names (descriptors) identifying this object class; DESC <qdstring> is a short descriptive string; OBSOLETE indicates this object class is not active; SUP <oids> specifies the direct superclasses of this object class; the kind of object class is indicated by one of ABSTRACT, STRUCTURAL, or AUXILIARY (the default is STRUCTURAL); MUST and MAY specify the sets of required and allowed attribute types, respectively; and <extensions> describe extensions.
Top   ToC   RFC4512 - Page 25

4.1.2. Attribute Types

Attribute Type definitions are written according to the ABNF: AttributeTypeDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active [ SP "SUP" SP oid ] ; supertype [ SP "EQUALITY" SP oid ] ; equality matching rule [ SP "ORDERING" SP oid ] ; ordering matching rule [ SP "SUBSTR" SP oid ] ; substrings matching rule [ SP "SYNTAX" SP noidlen ] ; value syntax [ SP "SINGLE-VALUE" ] ; single-value [ SP "COLLECTIVE" ] ; collective [ SP "NO-USER-MODIFICATION" ] ; not user modifiable [ SP "USAGE" SP usage ] ; usage extensions WSP RPAREN ; extensions usage = "userApplications" / ; user "directoryOperation" / ; directory operational "distributedOperation" / ; DSA-shared operational "dSAOperation" ; DSA-specific operational where: <numericoid> is object identifier assigned to this attribute type; NAME <qdescrs> are short names (descriptors) identifying this attribute type; DESC <qdstring> is a short descriptive string; OBSOLETE indicates this attribute type is not active; SUP oid specifies the direct supertype of this type; EQUALITY, ORDERING, and SUBSTR provide the oid of the equality, ordering, and substrings matching rules, respectively; SYNTAX identifies value syntax by object identifier and may suggest a minimum upper bound; SINGLE-VALUE indicates attributes of this type are restricted to a single value; COLLECTIVE indicates this attribute type is collective [X.501][RFC3671]; NO-USER-MODIFICATION indicates this attribute type is not user modifiable; USAGE indicates the application of this attribute type; and <extensions> describe extensions. Each attribute type description must contain at least one of the SUP or SYNTAX fields. If no SYNTAX field is provided, the attribute type description takes its value from the supertype.
Top   ToC   RFC4512 - Page 26
   If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
   fields, if not specified, take their value from the supertype.

   Usage of userApplications, the default, indicates that attributes of
   this type represent user information.  That is, they are user
   attributes.

   A usage of directoryOperation, distributedOperation, or dSAOperation
   indicates that attributes of this type represent operational and/or
   administrative information.  That is, they are operational
   attributes.

   directoryOperation usage indicates that the attribute of this type is
   a directory operational attribute.  distributedOperation usage
   indicates that the attribute of this type is a DSA-shared usage
   operational attribute.  dSAOperation usage indicates that the
   attribute of this type is a DSA-specific operational attribute.

   COLLECTIVE requires usage userApplications.  Use of collective
   attribute types in LDAP is discussed in [RFC3671].

   NO-USER-MODIFICATION requires an operational usage.

   Note that the <AttributeTypeDescription> does not list the matching
   rules that can be used with that attribute type in an extensibleMatch
   search filter [RFC4511].  This is done using the 'matchingRuleUse'
   attribute described in Section 4.1.4.

   This document refines the schema description of X.501 by requiring
   that the SYNTAX field in an <AttributeTypeDescription> be a string
   representation of an object identifier for the LDAP string syntax
   definition, with an optional indication of the suggested minimum
   bound of a value of this attribute.

   A suggested minimum upper bound on the number of characters in a
   value with a string-based syntax, or the number of bytes in a value
   for all other syntaxes, may be indicated by appending this bound
   count inside of curly braces following the syntax's OBJECT IDENTIFIER
   in an Attribute Type Description.  This bound is not part of the
   syntax name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests
   that server implementations should allow a string to be 64 characters
   long, although they may allow longer strings.  Note that a single
   character of the Directory String syntax may be encoded in more than
   one octet since UTF-8 [RFC3629] is a variable-length encoding.
Top   ToC   RFC4512 - Page 27

4.1.3. Matching Rules

Matching rules are used in performance of attribute value assertions, such as in performance of a Compare operation. They are also used in evaluating search filters, determining which individual values are to be added or deleted during performance of a Modify operation, and in comparing distinguished names. Each matching rule is identified by an object identifier (OID) and, optionally, one or more short names (descriptors). Matching rule definitions are written according to the ABNF: MatchingRuleDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "SYNTAX" SP numericoid ; assertion syntax extensions WSP RPAREN ; extensions where: <numericoid> is object identifier assigned to this matching rule; NAME <qdescrs> are short names (descriptors) identifying this matching rule; DESC <qdstring> is a short descriptive string; OBSOLETE indicates this matching rule is not active; SYNTAX identifies the assertion syntax (the syntax of the assertion value) by object identifier; and <extensions> describe extensions.

4.1.4. Matching Rule Uses

A matching rule use lists the attribute types that are suitable for use with an extensibleMatch search filter. Matching rule use descriptions are written according to the following ABNF: MatchingRuleUseDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "APPLIES" SP oids ; attribute types extensions WSP RPAREN ; extensions
Top   ToC   RFC4512 - Page 28
   where:
     <numericoid> is the object identifier of the matching rule
         associated with this matching rule use description;
     NAME <qdescrs> are short names (descriptors) identifying this
         matching rule use;
     DESC <qdstring> is a short descriptive string;
     OBSOLETE indicates this matching rule use is not active;
     APPLIES provides a list of attribute types the matching rule
         applies to; and
     <extensions> describe extensions.

4.1.5. LDAP Syntaxes

LDAP Syntaxes of (attribute and assertion) values are described in terms of ASN.1 [X.680] and, optionally, have an octet string encoding known as the LDAP-specific encoding. Commonly, the LDAP-specific encoding is constrained to a string of Unicode [Unicode] characters in UTF-8 [RFC3629] form. Each LDAP syntax is identified by an object identifier (OID). LDAP syntax definitions are written according to the ABNF: SyntaxDescription = LPAREN WSP numericoid ; object identifier [ SP "DESC" SP qdstring ] ; description extensions WSP RPAREN ; extensions where: <numericoid> is the object identifier assigned to this LDAP syntax; DESC <qdstring> is a short descriptive string; and <extensions> describe extensions.

4.1.6. DIT Content Rules

A DIT content rule is a "rule governing the content of entries of a particular structural object class" [X.501]. For DIT entries of a particular structural object class, a DIT content rule specifies which auxiliary object classes the entries are allowed to belong to and which additional attributes (by type) are required, allowed, or not allowed to appear in the entries. The list of precluded attributes cannot include any attribute listed as mandatory in the rule, the structural object class, or any of the allowed auxiliary object classes.
Top   ToC   RFC4512 - Page 29
   Each content rule is identified by the object identifier, as well as
   any short names (descriptors), of the structural object class it
   applies to.

   An entry may only belong to auxiliary object classes listed in the
   governing content rule.

   An entry must contain all attributes required by the object classes
   the entry belongs to as well as all attributes required by the
   governing content rule.

   An entry may contain any non-precluded attributes allowed by the
   object classes the entry belongs to as well as all attributes allowed
   by the governing content rule.

   An entry cannot include any attribute precluded by the governing
   content rule.

   An entry is governed by (if present and active in the subschema) the
   DIT content rule that applies to the structural object class of the
   entry (see Section 2.4.2).  If no active rule is present for the
   entry's structural object class, the entry's content is governed by
   the structural object class (and possibly other aspects of user and
   system schema).  DIT content rules for superclasses of the structural
   object class of an entry are not applicable to that entry.

   DIT content rule descriptions are written according to the ABNF:

     DITContentRuleDescription = LPAREN WSP
         numericoid                 ; object identifier
         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
         [ SP "DESC" SP qdstring ]  ; description
         [ SP "OBSOLETE" ]          ; not active
         [ SP "AUX" SP oids ]       ; auxiliary object classes
         [ SP "MUST" SP oids ]      ; attribute types
         [ SP "MAY" SP oids ]       ; attribute types
         [ SP "NOT" SP oids ]       ; attribute types
         extensions WSP RPAREN      ; extensions

   where:
     <numericoid> is the object identifier of the structural object
         class associated with this DIT content rule;
     NAME <qdescrs> are short names (descriptors) identifying this DIT
         content rule;
     DESC <qdstring> is a short descriptive string;
     OBSOLETE indicates this DIT content rule use is not active;
     AUX specifies a list of auxiliary object classes that entries
         subject to this DIT content rule may belong to;
Top   ToC   RFC4512 - Page 30
     MUST, MAY, and NOT specify lists of attribute types that are
         required, allowed, or precluded, respectively, from appearing
         in entries subject to this DIT content rule; and
     <extensions> describe extensions.

4.1.7. DIT Structure Rules and Name Forms

It is sometimes desirable to regulate where object and alias entries can be placed in the DIT and how they can be named based upon their structural object class.
4.1.7.1. DIT Structure Rules
A DIT structure rule is a "rule governing the structure of the DIT by specifying a permitted superior to subordinate entry relationship. A structure rule relates a name form, and therefore a structural object class, to superior structure rules. This permits entries of the structural object class identified by the name form to exist in the DIT as subordinates to entries governed by the indicated superior structure rules" [X.501]. DIT structure rule descriptions are written according to the ABNF: DITStructureRuleDescription = LPAREN WSP ruleid ; rule identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "FORM" SP oid ; NameForm [ SP "SUP" ruleids ] ; superior rules extensions WSP RPAREN ; extensions ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN ) ruleidlist = ruleid *( SP ruleid ) ruleid = number where: <ruleid> is the rule identifier of this DIT structure rule; NAME <qdescrs> are short names (descriptors) identifying this DIT structure rule; DESC <qdstring> is a short descriptive string; OBSOLETE indicates this DIT structure rule use is not active; FORM is specifies the name form associated with this DIT structure rule; SUP identifies superior rules (by rule id); and <extensions> describe extensions.
Top   ToC   RFC4512 - Page 31
   If no superior rules are identified, the DIT structure rule applies
   to an autonomous administrative point (e.g., the root vertex of the
   subtree controlled by the subschema) [X.501].

4.1.7.2. Name Forms
A name form "specifies a permissible RDN for entries of a particular structural object class. A name form identifies a named object class and one or more attribute types to be used for naming (i.e., for the RDN). Name forms are primitive pieces of specification used in the definition of DIT structure rules" [X.501]. Each name form indicates the structural object class to be named, a set of required attribute types, and a set of allowed attribute types. A particular attribute type cannot be in both sets. Entries governed by the form must be named using a value from each required attribute type and zero or more values from the allowed attribute types. Each name form is identified by an object identifier (OID) and, optionally, one or more short names (descriptors). Name form descriptions are written according to the ABNF: NameFormDescription = LPAREN WSP numericoid ; object identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "OC" SP oid ; structural object class SP "MUST" SP oids ; attribute types [ SP "MAY" SP oids ] ; attribute types extensions WSP RPAREN ; extensions where: <numericoid> is object identifier that identifies this name form; NAME <qdescrs> are short names (descriptors) identifying this name form; DESC <qdstring> is a short descriptive string; OBSOLETE indicates this name form is not active; OC identifies the structural object class this rule applies to, MUST and MAY specify the sets of required and allowed, respectively, naming attributes for this name form; and <extensions> describe extensions. All attribute types in the required ("MUST") and allowed ("MAY") lists shall be different.
Top   ToC   RFC4512 - Page 32

4.2. Subschema Subentries

Subschema (sub)entries are used for administering information about the directory schema. A single subschema (sub)entry contains all schema definitions (see Section 4.1) used by entries in a particular part of the directory tree. Servers that follow X.500(93) models SHOULD implement subschema using the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]), so these are not ordinary object entries but subentries (see Section 3.2). LDAP clients SHOULD NOT assume that servers implement any of the other aspects of X.500 subschema. Servers MAY allow subschema modification. Procedures for subschema modification are discussed in Section 14.5 of [X.501]. A server that masters entries and permits clients to modify these entries SHALL implement and provide access to these subschema (sub)entries including providing a 'subschemaSubentry' attribute in each modifiable entry. This is so clients may discover the attributes and object classes that are permitted to be present. It is strongly RECOMMENDED that all other servers implement this as well. The value of the 'subschemaSubentry' attribute is the name of the subschema (sub)entry holding the subschema controlling the entry. ( 2.5.18.10 NAME 'subschemaSubentry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. Subschema is held in (sub)entries belonging to the subschema auxiliary object class. ( 2.5.20.1 NAME 'subschema' AUXILIARY MAY ( dITStructureRules $ nameForms $ ditContentRules $ objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) ) The 'ldapSyntaxes' operational attribute may also be present in subschema entries.
Top   ToC   RFC4512 - Page 33
   Servers MAY provide additional attributes (described in other
   documents) in subschema (sub)entries.

   Servers SHOULD provide the attributes 'createTimestamp' and
   'modifyTimestamp' in subschema (sub)entries, in order to allow
   clients to maintain their caches of schema information.

   The following subsections provide attribute type definitions for each
   of schema definition attribute types.

4.2.1. 'objectClasses'

This attribute holds definitions of object classes. ( 2.5.21.6 NAME 'objectClasses' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) The 'objectIdentifierFirstComponentMatch' matching rule and the ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are defined in [RFC4517].

4.2.2. 'attributeTypes'

This attribute holds definitions of attribute types. ( 2.5.21.5 NAME 'attributeTypes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation ) The 'objectIdentifierFirstComponentMatch' matching rule and the AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are defined in [RFC4517].

4.2.3. 'matchingRules'

This attribute holds definitions of matching rules. ( 2.5.21.4 NAME 'matchingRules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation ) The 'objectIdentifierFirstComponentMatch' matching rule and the MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are defined in [RFC4517].
Top   ToC   RFC4512 - Page 34

4.2.4 'matchingRuleUse'

This attribute holds definitions of matching rule uses. ( 2.5.21.8 NAME 'matchingRuleUse' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation ) The 'objectIdentifierFirstComponentMatch' matching rule and the MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are defined in [RFC4517].

4.2.5. 'ldapSyntaxes'

This attribute holds definitions of LDAP syntaxes. ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation ) The 'objectIdentifierFirstComponentMatch' matching rule and the SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined in [RFC4517].

4.2.6. 'dITContentRules'

This attribute lists DIT Content Rules that are present in the subschema. ( 2.5.21.2 NAME 'dITContentRules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation ) The 'objectIdentifierFirstComponentMatch' matching rule and the DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are defined in [RFC4517].
Top   ToC   RFC4512 - Page 35

4.2.7. 'dITStructureRules'

This attribute lists DIT Structure Rules that are present in the subschema. ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation ) The 'integerFirstComponentMatch' matching rule and the DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are defined in [RFC4517].

4.2.8 'nameForms'

This attribute lists Name Forms that are in force. ( 2.5.21.7 NAME 'nameForms' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation ) The 'objectIdentifierFirstComponentMatch' matching rule and the NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined in [RFC4517].

4.3. 'extensibleObject' object class

The 'extensibleObject' auxiliary object class allows entries that belong to it to hold any user attribute. The set of allowed attribute types of this object class is implicitly the set of all attribute types of userApplications usage. ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' SUP top AUXILIARY ) The mandatory attributes of the other object classes of this entry are still required to be present, and any precluded attributes are still not allowed to be present.

4.4. Subschema Discovery

To discover the DN of the subschema (sub)entry holding the subschema controlling a particular entry, a client reads that entry's 'subschemaSubentry' operational attribute. To read schema attributes from the subschema (sub)entry, clients MUST issue a Search operation [RFC4511] where baseObject is the DN of the subschema (sub)entry,
Top   ToC   RFC4512 - Page 36
   scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
   and the attributes field lists the names of the desired schema
   attributes (as they are operational).  Note: the
   "(objectClass=subschema)" filter allows LDAP servers that gateway to
   X.500 to detect that subentry information is being requested.

   Clients SHOULD NOT assume that a published subschema is complete,
   that the server supports all of the schema elements it publishes, or
   that the server does not support an unpublished element.

5. DSA (Server) Informational Model

The LDAP protocol assumes there are one or more servers that jointly provide access to a Directory Information Tree (DIT). The server holding the original information is called the "master" (for that information). Servers that hold copies of the original information are referred to as "shadowing" or "caching" servers. As defined in [X.501]: context prefix: The sequence of RDNs leading from the Root of the DIT to the initial vertex of a naming context; corresponds to the distinguished name of that vertex. naming context: A subtree of entries held in a single master DSA. That is, a naming context is the largest collection of entries, starting at an entry that is mastered by a particular server, and including all its subordinates and their subordinates, down to the entries that are mastered by different servers. The context prefix is the name of the initial entry. The root of the DIT is a DSA-specific Entry (DSE) and not part of any naming context (or any subtree); each server has different attribute values in the root DSE.

5.1. Server-Specific Data Requirements

An LDAP server SHALL provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE, which is named with the DN with zero RDNs (whose [RFC4514] representation is as the zero-length string). These attributes are retrievable, subject to access control and other restrictions, if a client performs a Search operation [RFC4511] with an empty baseObject, scope of baseObject, the filter
Top   ToC   RFC4512 - Page 37
   "(objectClass=*)" [RFC4515], and the attributes field listing the
   names of the desired attributes.  It is noted that root DSE
   attributes are operational and, like other operational attributes,
   are not returned in search requests unless requested by name.

   The root DSE SHALL NOT be included if the client performs a subtree
   search starting from the root.

   Servers may allow clients to modify attributes of the root DSE, where
   appropriate.

   The following attributes of the root DSE are defined below.
   Additional attributes may be defined in other documents.

      - altServer: alternative servers;

      - namingContexts: naming contexts;

      - supportedControl: recognized LDAP controls;

      - supportedExtension: recognized LDAP extended operations;

      - supportedFeatures: recognized LDAP features;

      - supportedLDAPVersion: LDAP versions supported; and

      - supportedSASLMechanisms: recognized Simple Authentication and
        Security Layers (SASL) [RFC4422] mechanisms.

   The values provided for these attributes may depend on session-
   specific and other factors.  For example, a server supporting the
   SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
   identity has been established by a lower level.  See [RFC4513].

   The root DSE may also include a 'subschemaSubentry' attribute.  If it
   does, the attribute refers to the subschema (sub)entry holding the
   schema controlling the root DSE.  Clients SHOULD NOT assume that this
   subschema (sub)entry controls other entries held by the server.
   General subschema discovery procedures are provided in Section 4.4.
Top   ToC   RFC4512 - Page 38

5.1.1. 'altServer'

The 'altServer' attribute lists URIs referring to alternative servers that may be contacted when this server becomes unavailable. URIs for servers implementing the LDAP are written according to [RFC4516]. Other kinds of URIs may be provided. If the server does not know of any other servers that could be used, this attribute will be absent. Clients may cache this information in case their preferred server later becomes unavailable. ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation ) The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in [RFC4517].

5.1.2. 'namingContexts'

The 'namingContexts' attribute lists the context prefixes of the naming contexts the server masters or shadows (in part or in whole). If the server is a first-level DSA [X.501], it should list (in addition) an empty string (indicating the root of the DIT). If the server does not master or shadow any information (e.g., it is an LDAP gateway to a public X.500 directory) this attribute will be absent. If the server believes it masters or shadows the entire directory, the attribute will have a single value, and that value will be the empty string (indicating the root of the DIT). This attribute may be used, for example, to select a suitable entry name for subsequent operations with this server. ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation ) The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is defined in [RFC4517].

5.1.3. 'supportedControl'

The 'supportedControl' attribute lists object identifiers identifying the request controls [RFC4511] the server supports. If the server does not support any request controls, this attribute will be absent. Object identifiers identifying response controls need not be listed. Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
Top   ToC   RFC4512 - Page 39
      ( 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].
Top   ToC   RFC4512 - Page 40

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].


(page 40 continued on part 3)

Next Section