Compartilhar via

3.1.1.5.5 Delete Operation

  • Artigo

References

LDAP attributes: distinguishedName, isDeleted, isRecycled, entryTTL, msDS-Entry-Time-To-Die, nTSecurityDescriptor, attributeID, attributeSyntax, dNReferenceUpdate, dNSHostName, flatName, governsID, groupType, instanceType, lDAPDisplayName, legacyExchangeDN, mS-DS-CreatorSID, msDS-LastKnownRDN, mSMQOwnerID, nCName, objectClass, objectGUID, objectSid, oMSyntax, proxiedObjectName, name, replPropertyMetaData, sAMAccountName, securityIdentifier, sIDHistory, subClassOf, systemFlags, trustPartner, trustDirection, trustType, trustAttributes, userAccountControl, uSNChanged, uSNCreated, whenCreated, searchFlags, isCriticalSystemObject, objectCategory, sAMAccountType, isDeleted, lastKnownParent.

State model attributes: rdnType

LDAP classes: dynamicObject, crossRef.

Constants

  • Win32/status error codes: ERROR_DS_REFERRAL, ERROR_DS_ILLEGAL_MOD_OPERATION, ERROR_DS_CHILDREN_EXIST, ERROR_DS_TREE_DELETE_NOT_FINISHED

  • Access mask bits, control access rights: SECURITY_PRIVATE_OBJECT, RIGHT_DELETE, RIGHT_DS_DELETE_CHILD, RIGHT_DS_DELETE_TREE

  • systemFlags bits: FLAG_DISALLOW_DELETE, FLAG_DISALLOW_MOVE_ON_DELETE

  • Schema bits: fPRESERVEONDELETE

The delete operation results in the transformation of an existing-object in the directory tree into some form of deleted object. There are several modes of transformation, depending on whether the Recycle Bin optional feature is enabled or not. In all modes of transformation, the requester supplies the DN of the object to be transformed.

If the Recycle Bin optional feature is not enabled, the delete operation results in the transformation of an existing-object in the directory tree into a tombstone. If the Recycle Bin optional feature is enabled and the requester has specified an existing-object as the object to be transformed, the deletion operation results in transformation of the existing-object in the directory tree into a deleted-object.

If the Recycle Bin optional feature is enabled and the requester has specified a deleted-object as the object to be transformed, the operation results in transformation of a deleted-object in the directory tree into a recycled-object. Recycled-objects are created only by the transformation of a deleted-object, never directly from a normal object.

Tombstones, deleted-objects, and recycled-objects (collectively referred to in this section as deleted objects) are special placeholder objects that replicate around, signaling replica partners that the original object was deleted. Tombstones, deleted-objects, and recycled-objects are invisible to LDAP searches by default, so for an LDAP application, it appears that the object was physically removed from the directory after a delete operation has taken place.

Tombstones are a type of deleted object distinguished from existing-objects by the presence of the isDeleted attribute with the value TRUE. The value of the isRecycled attribute can be TRUE, or the isRecycled attribute can be absent. Tombstones exist only when the Recycle Bin optional feature is not enabled. After a time period at least as large as a tombstone lifetime, the tombstone is removed from the directory.

Deleted-objects are a type of deleted object distinguished from existing-objects by the presence of the isDeleted attribute with the value TRUE and the absence of the isRecycled attribute. Deleted-objects exist only when the Recycle Bin optional feature is enabled. After a time period at least as large as a deleted-object lifetime, the deleted-object is transformed into a recycled-object.

Recycled-objects are a type of deleted object distinguished from existing-objects by the presence of the isRecycled attribute with the value TRUE. Recycled-objects exist only when the Recycle Bin optional feature is enabled. After a time period at least as large as a tombstone lifetime, the recycled-object is removed from the directory.

Normally, only leaf objects (objects without descendants in the directory tree) can be deleted. There is also a special tree-delete operation, with which whole trees of objects are removed (see Tree-delete operation in section 3.1.1.5.5.7).

In most cases, upon deletion, a tombstone, deleted-object, or recycled-object is moved into the Deleted Objects container of its NC; for exceptions see section 3.1.1.5.5.6. The RDN of the object is changed to a "delete-mangled RDN"-an RDN that is guaranteed to be unique within the Deleted Objects container. If O is the object that is deleted, the delete-mangled RDN is the concatenation of O!name, the character with value 0x0A, the string "DEL:", and the dashed string representation ([RFC4122] section 3) of O!objectGUID. During this concatenation, if required, the O!name part is truncated to ensure that the length of the delete-mangled RDN does not violate the RDN size constraint in section 3.1.1.5.1.2. The RDN attribute of this object is also set to this delete-mangled RDN value. The illegal character constraint regarding a character with the value 0xA, as specified in section 3.1.1.5.1.2, is not enforced for this delete-mangled RDN. Also, the rangeUpper constraint for the RDN attribute of this object is not enforced. A "delete-mangled DN" is a DN such that the leaf RDN is a delete-mangled RDN.

An object whose class is defunct, or whose class is active but some of whose attributes are defunct, can still be deleted.

Linked attributes store references to other objects in the forest (see referential integrity in section 3.1.1.1.6). They are pairs of attributes for which the system calculates the values of one attribute (the back link) based on the values set on the other attribute (the forward link) throughout the forest. A back-link value on any object instance consists of the DNs of all the objects that have that object's DN set in the corresponding forward link. In addition to storing object references using linked attributes, objects can also store references to other objects in attributes that have an object reference syntax (see referential integrity in section 3.1.1.1.6). Such attributes are not considered to be linked attributes.

The direction of a linked attribute is determined by the directional flow of a forward link and the object from which this link is viewed. If this object has a forward link attribute containing a reference to another object, then its linked attribute is called an outgoing linked attribute. The link, as viewed from the referenced object, is called an incoming link. For example, if Object A has a forward link storing a reference to Object B (this implies that Object B has a backward link storing a reference to Object A), then the linked attribute on Object A is an outgoing linked attribute and accordingly, an incoming linked attribute on Object B.