Skip to main content

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.

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

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.

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 )

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