When you delete an AD object, a number of things happen behind the scenes. Most important, deleting an object doesn’t directly correlate to a record being removed from the AD database. To maintain consistency in AD’s replication model, objects first transition through a state known as being tombstoned. Rather than implementing a distributed mechanism to replicate physical deletions from the database, AD replicates a change to an attribute that indicates the object has been deleted.
When you delete an object from AD, the isDeleted attribute is set to True, which means nearly all the object’s attributes are removed. The object is moved to the Deleted Objects container, and its lastKnownParent attribute is stamped with the distinguished name (DN) of the parent object before the object is deleted. After an object has been marked as deleted, it won’t be visible to any tools that query AD, unless you add a special LDAP control to indicate that you want AD to return deleted objects in the search results. Various free LDAP query tools (such as AdFind) will include this LDAP control for you and allow you to easily search for deleted objects.
At this point, the object will remain as a tombstone for a period of time. The default tombstone lifetime for forests is based on the OS of the first DC in the forest. Table 1 shows the default tombstone lifetimes. Upgrading AD doesn’t change the tombstone lifetime for the forest.
Up until the point when a tombstone is purged by the garbage collector, you can recover the object using a process known as tombstone reanimation. When you reanimate a tombstone, you only get back a handful of attributes that are kept during the tombstoning process. For example, the attributes saved for a user object include the user’s SID, SID history, and username (sAMAccountName). Notice that this list doesn’t include attributes such as the user’s password, group membership, or demographic information (e.g., name, department). You can control the list of attributes that are preserved when an object is tombstoned by modifying the searchFlags attribute of an individual attribute’s definition in the schema. You can add as many attributes as you like. However, you can’t add linked attributes, such as group membership or the mailbox database containing a user’s mailbox. For information about how to modify the searchFlags attribute, see the MSDN web page “Search-Flags Attribute”.
In AD forests operating at the Server 2008 R2 forest functional level (FFL), you can enable a new feature known as the Active Directory Recycle Bin. The Active Directory Recycle Bin adds an intermediate state between when an object is deleted and when it is tombstoned. When an object is in this new deleted state, it’s hidden from search results but all its attributes (including linked attributes such as group membership) are preserved.
An object in the deleted object phase can be recovered to the exact state it was in at the time of deletion using the same process that’s used to reanimate a tombstone. By default, an object stays in the deleted object phase for the same amount of time as the forest’s tombstone lifetime, as outlined in Table 1. You can change this time period by modifying the forest’s msDS-deletedObjectLifetime attribute.
After the deleted object lifetime expires, the garbage collector moves the object into the recycled object phase. A recycled object is the functional equivalent of a tombstone, with one important difference: You can’t reanimate a recycled object or restore it from a backup.
