Compartir a través de

3.1.1.1.6 Attribute Syntaxes, Object References, Referential Integrity, and Well-Known Objects

  • Artículo

The complete set of attribute syntaxes supported by Active Directory are specified in section 3.1.1.2. The representation used by the abstract data model for values of each attribute syntax is specified in [MS-DRSR] section 5.16.2. These representations of each syntax can be returned in an LDAP response without conversion, that is, the values are represented in the abstract data model in the same format as used by the LDAP protocol.

The following five attribute syntaxes are called object reference syntaxes:

  • Object(DS-DN)

  • Object(DN-String)

  • Object(DN-Binary)

  • Object(Access-Point)

  • Object(OR-Name)

The values of an attribute with Object(DS-DN) syntax are DNs, which represent references to objects. The values of attributes with the other object reference syntaxes have two portions; one portion is a DN, which represents a reference to an object, and the other has information specific to each syntax. The five object reference syntaxes have a special behavior called "referential integrity"; no other attribute syntax have special behavior intrinsic to the syntax. The referential integrity behavior applies only to the DN portion of the syntax (the portion that represents a reference to an object), leaving the remaining portion unchanged. For this reason, and because the referential integrity is the same for the DN portion of all five object reference syntaxes, it suffices to specify the referential integrity behavior of syntax (the portion that represents a reference to an object), leaving the remaining portion unchanged. For this reason, and because the referential integrity is the same for the DN portion of all five object reference syntaxes, it suffices to specify the referential integrity behavior only for the Object(DS-DN) syntax (the simplest of the object reference syntaxes).

To specify referential integrity, some background on object deletion is required; object deletion is specified fully in section 3.1.1.5.

When the Recycle Bin optional feature is not enabled, object deletion is performed in two stages.

  1. In the first stage, the object to be deleted is transformed into a tombstone. A tombstone is a special object, part of a replica's state. The state of a deleted object's tombstone resembles the state of the object before deletion; it has the same objectGUID but a different DN. Specifically, its RDN is changed to a "delete-mangled RDN" and, in most cases, it is moved into the Deleted Objects container of its NC, as described in section 3.1.1.5.5. A tombstone is generally not an object from the LDAP perspective: a tombstone is not returned by a normal LDAP Search request, only by a Search request with extended control LDAP_SERVER_SHOW_DELETED_OID or LDAP_SERVER_SHOW_RECYCLED_OID, as described in section 3.1.1.3.

  2. In the second stage, after a significant delay (the tombstone lifetime), a tombstone is garbage collected, which removes it from the replica's state.

When the Recycle Bin optional feature is enabled, object deletion is performed in three stages.

  1. In the first stage, the object being deleted is transformed into a deleted-object. A deleted-object is a special object, part of a replica's state. The deleted-object also resembles the state of the object before deletion; it has the same objectGUID but a different DN. Specifically, its RDN is changed to a "delete-mangled RDN" and, in most cases, it is moved into the Deleted Objects container of its NC, as described in section 3.1.1.5.5. A deleted-object is generally not an object from the LDAP perspective: a deleted-object is not returned by a normal LDAP Search request, only by a Search request with extended control LDAP_SERVER_SHOW_DELETED_OID OID or LDAP_SERVER_SHOW_RECYCLED_OID, as described in section 3.1.1.3.

  2. In the second stage, after a significant delay (the deleted-object lifetime), a deleted-object is transformed into a recycled-object. A recycled-object is a special object, part of a replica's state. The recycled-object also resembles the state of the object before deletion; it has the same objectGUID but a different DN. Specifically, its RDN has been changed and, in most cases, the object moved, as described in the first stage. A recycled-object is also generally not an object from the LDAP perspective: a recycled-object is not returned by a normal LDAP Search request, only by a Search request with extended control LDAP_SERVER_SHOW_RECYCLED_OID, as described in section 3.1.1.3.

    Note that this transformation from deleted-object to recycled-object is only initiated on DCs where the deleted-object is in a writable naming context (NC) replica. On DCs where the deleted-object is not in a writable NC replica, the transformation from deleted-object to recycled-object occurs as the result of replication in this state change from a DC that holds a writable copy of the object.

  3. In the third and final stage, after a significant delay (the tombstone lifetime), a recycled-object is garbage collected, which removes it from the replica's state.

In situations where a deletion does not need to be replicated, an object is expunged (that is, removed in a single step from the replica's state) instead. A deletion does not need to be replicated in the following cases: removal of a lingering object (section 3.1.1.3.3.15), removal of an object being moved during a cross-domain move (section 3.1.1.5.4.2), and removal of a dynamic object (section 6.1.7).

An application is not limited to specifying a DN when creating an object reference; using the syntax specified in section 3.1.1.2, it can specify any combination of DN, SID, or GUID as the reference as long as it specifies at least one. A DSName is created using the specified references and is resolved to an object using DSName equality as defined in [MS-DRSR] section 5.50, DSNAME.

The state kept with an attribute to represent an object reference is a DSName.

When reading an object reference, an application can request the full DSName in the representation specified in [MS-DRSR] section 5.16.2.1 instead of a DN by passing the LDAP_SERVER_EXTENDED_DN_OID extended control as described in section 3.1.1.3.

A single-valued Object(DS-DN) attribute a on object src behaves as follows:

  • When an LDAP Add or Modify creates an object reference within attribute src.a, the server uses the DN (or SID or GUID) specified in the Add or Modify to locate an existing object dst. If no such object exists, including the case where the object has been deleted and exists as a tombstone, deleted-object, or recycled-object, the request fails with error noSuchObject / ERROR_DS_OBJ_NOT_FOUND. The values dst!distinguishedName, dst!objectGUID and dst!objectSid are used to populate the DSName representing the object reference within attribute src.a. If the object dst has no objectSid attribute, the "SID=" portion of the DSName representation is omitted.

  • If object dst has not been deleted, reading attribute a gives the DN (or extended format as described in section 3.1.1.3) of object dst, even if dst has been renamed since a was written.

  • If the object dst has been deleted or expunged, reading src.a gives a DN field that corresponds to no object. Either this DN is impossible to create via LDAP Add and LDAP Modify DN, or this DN changes (that is, the value of src.a changes) when an LDAP Add or Modify DN would give some other object this DN.

The multivalued case is similar; a multivalued attribute is capable of containing multiple object references that behave as described.

Each object reference syntax exists in two versions. The description just given is for the "nonlink" version. The other version is the "forward link". The Object(DS-DN) syntax also exists in a "back link" version.

A forward link Object(DS-DN) attribute supports the definition of a corresponding back link Object(DS-DN) attribute. The back link attribute is a read-only constructed attribute; clients MUST NOT write to the back link attribute, and servers MUST reject any such writes. If an object o contains a reference to object r in forward link attribute f, and there exists a back link attribute b corresponding to f, then a back link value referencing o exists in attribute b on object r. The correspondence between the forward and back link attributes is expressed in the schema; see section 3.1.1.2 for details. A forward link attribute can exist with no corresponding back link attribute, but not vice versa.

If the syntax of a forward link attribute is not Object(DS-DN), a corresponding back link attribute has syntax Object(DS-DN), not the syntax of the forward link. The non-reference portion of the forward link, if any, is ignored in computing the back link. If ignoring the non-reference portion of the forward link results in duplicate back references, the duplicates are present in the values of the back link attribute.

The referential integrity behavior of a forward link attribute differs from that of a nonlink attribute as follows:

  • When an object o is expunged or transformed into a tombstone or recycled-object, any forward link reference to o is removed from the attribute that contains it.

  • When an object o is transformed into a deleted-object, any forward link reference to o is maintained, but is made invisible to LDAP operations that do not specify the LDAP_SERVER_SHOW_DEACTIVATED_LINK_OID control.

  • When a deleted-object o is transformed into an object that is not a deleted-object, a tombstone, or a recycled-object, any forward link reference to o from object p where p is not a deleted-object is made visible to LDAP operations. Similarly, any forward link reference from o to p is made visible to LDAP operations.

Since a back link attribute is constructed, its referential integrity behavior follows from that of the corresponding forward link attribute.

The distinction between nonlink and forward link references is not visible in the part of the state model described in this section; it is a schema difference only. There is no difference in the state kept with an attribute to represent the object reference. There is a difference in the replication metadata accompanying the object reference, as will be described in section 3.1.1.1.9.

The behavior described in this section is for object references within a single NC replica. Additional behaviors, specified in section 3.1.1.1.12, are possible when an object reference crosses an NC replica boundary.

Extend the running example by adding a group object named "DSYS" as a child of "ou=NTDEV,dc=microsoft,dc=com". The object class group includes the attribute member with Object(DS-DN) syntax. In this example, the "DSYS" group has the user object "Peter Houston" as its only member.

 (
   "<GUID=5>;<SID=0x0105...00000000>;dc=microsoft,dc=com"
   ( (objectGUID 5) (parent 0) (dc "microsoft")
     (objectClass top ... domainDNS)
     (name "microsoft") (rdnType dc)
     (objectSid 0x0105...94E1F2E6) )
   ( (objectGUID 2) (parent 5) (ou "NTDEV")
     (objectClass top ... organizationalUnit)
     (name "NTDEV") (rdnType ou) )
   ( (objectGUID 9) (parent 2) (cn "Peter Houston")
     (objectClass top ... user) 
     (name "Peter Houston") (rdnType cn)
     (objectSid 0x0105...94E1F2E607080000) )
   ( (objectGUID 6) (parent 2) (cn "DSYS")
     (objectClass top ... group) 
     (name "DSYS") (rdnType cn)
     (objectSid 0x0105...94E1F2E60B080000)
     (member
       "<GUID=9>;<SID=0x0105...07080000>;
       cn=Peter Houston,ou=NTDEV,dc=microsoft,dc=com" ) )
 )

Note that the group "DSYS" is a security principal object within the domain NC, with the distinct RID value 2059 (decimal).

The root object of each NC contains the attribute wellKnownObjects. The purpose of this attribute is to provide a location-independent way to access certain objects within the NC. For instance, the Deleted Objects container where most tombstones live can be found using wellKnownObjects.

The wellKnownObjects attribute has syntax Object(DN-Binary). Each value consists of an object reference ref and a byte string binary that is 16 bytes long. The byte string binary contains a GUID identifying a well-known object (WKO) within an NC; the object reference ref is a reference to the corresponding object. A table of the GUIDs that identify well-known objects is given in section 6.1.1.4.

The following procedure implements well-known object location using the wellKnownObjects attribute. This procedure will be used throughout the rest of this specification:

  • procedure GetWellknownObject(nc: NC, guid: GUID): DSName

    • If there is no replica of NC nc on the server executing this procedure, return null.

    • Let v be the value of nc!wellKnownObjects on the server's replica satisfying v.binary = guid; if no such v exists, return null.

    • Return v.ref.

Assignments to the wellKnownObjects attribute are specially checked as described in section 3.1.1.5.

LDAP supports access to well-known objects using an extended DSName syntax as described in section 3.1.1.3.