Keeping some form of a deleted object is necessary in multimaster systems such as Active Directory (AD), which must replicate deletions among domain controllers (DCs). When you delete an object in AD, that object doesn't disappear completely. Instead, the object becomes a deleted object, aka a tombstone. Before the release of Windows Server 2003, no method existed for bringing tombstones back to life. With Windows 2003, however, this type of resurrection is possible—though the process isn't necessarily simple. Still, the ability can be beneficial in certain situations, such as when someone accidentally deletes a user object. Let me show you the basics of AD's deletion and tombstone cleanup processes as well as how to search for, recover, and restore deleted objects.
Death of an Object
When an object is deleted, AD performs a variety of housekeeping tasks behind the scenes to turn the object into a tombstone. AD sets the object's isDeleted attribute to TRUE, which simplifies the distinction between tombstone objects and normal objects during a search. AD also moves the deleted object to the Deleted Objects container in the partition that contained the object before the deletion. (Each directory partition, including Windows 2003's new application partitions, holds a Deleted Objects container. The only exception is the Schema partition, which doesn't contain a Deleted Objects container because you can't delete objects from the schema.) AD hides these Deleted Objects containers by default, so to view them you must enable the Return Deleted Objects Lightweight Directory Access Protocol (LDAP) control as part of a search operation. (For more information about such operations, see the sidebar "Searching for Tombstones.")
AD renames the object, using an odd format. Generically, this format is OriginalName\0ADEL:ObjectGUID, where OriginalName is the object's original relative distinguished name (RDN), \0A is a null terminated character, and ObjectGUID is the object's original globally unique identifier (GUID). If I delete the object cn=rallen,ou=employees,dc=rallencorp,dc=com, for example, the resulting tombstone will have a distinguished name (DN) similar to CN=rallen\0ADEL:efc1ca9e-a5ec-4a29-97e1-c8013e538d2c,CN=Deleted Objects,DC=rallencorp,DC=com. One reason for using this format is that it guarantees uniqueness, even when multiple objects with the same RDN are deleted.
As if getting moved and renamed weren't bad enough for the lowly tombstone, AD also removes most of the original object's stored attributes. Because the object has been deleted, AD doesn't need to retain all the information originally stored with the object. Therefore, AD clears all but the essential attributes. You can identify a tombstone's retained attributes by using the Ldp tool (one of the Windows Support Tools) to query the schema for attributeSchema objects that have the eighth bit in the searchFlags attribute enabled.
For deleted objects on Windows 2003 DCs, AD populates the lastKnownParent attribute with the DN of the original object's container. AD stores tombstone objects directly under the Deleted Objects container, without maintaining the original objects' directory hierarchy, but you can use a tombstone's lastKnownParent attribute to identify the object's original location in the directory tree. This feature is available only in Windows 2003.
Life of a Tombstone
Tombstones are useful for replicating object deletions, but AD doesn't keep these objects around forever. After a period of time known as the tombstone lifetime, each DC automatically removes the tombstones it contains. (DCs can't replicate operations in which the target object is removed completely, so the Garbage Collection process on each DC cleans out any tombstone objects older than the tombstone lifetime.)
The default tombstone lifetime is 60 days. This setting is defined in the tombstoneLifetime attribute of each domain's cn=Directory Services,cn=WindowsNT,cn=Services,cn=Configuration, DomainDN object, where DomainDN is the domain's DN (e.g., dc=rallencorp,dc=com). You can customize the tombstone lifetime, but be aware that the setting affects how long you can keep a DC offline and how long you can keep backups of the DC. Suppose a DC is offline (or doesn't replicate) within the defined tombstone lifetime. During this time, an object on another DC is deleted, then completely removed after the tombstone lifetime. When the offline DC wakes up, it still contains a copy of the deleted object. Because no corresponding tombstone object exists to replicate to the awakened DC, the DC replicates the object out as a new object. This action results in a zombie object, aka a lingering object.