AD Tombstone Objects

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.

Reviving the Dead
As I mentioned, Windows 2003 provides the ability to recover tombstone objects—a useful capability. If, for example, you accidentally delete a user object, you can't just create a new object and expect everything to work for the user as it did before, partially because the new user object will have a new SID. When you grant a user permission to a file or AD object, that user's SID resides in the file's or AD object's ACL. If you create a new user account, the user's previously set ACLs need to be modified to include the user's new account SID. One attribute that a tombstoned user object maintains is the objectSID attribute, which contains the user's SID, so in this situation you can restore a deleted user object to retain the original SID, thus reducing some of the work necessary to get the user running again.

But don't get too excited yet. Tombstone objects are shells of their former selves, so restoring a tombstone doesn't restore the object to all of its former glory. Let's walk through the steps to restore a tombstone by using the Windows 2003 version of Ldp. (A Win2K version of Ldp is also available, but it lacks some of the functionality I describe in the following steps.)

1. Open Ldp, connect and bind to a DC, and enable Ldp's Return Deleted Objects LDAP control, as the sidebar "Searching for Tombstones" explains.
2. Select View, Tree from the Ldp menu bar. Enter the DN of the DC's Deleted Objects container (e.g., cn=Deleted Objects,dc=rallencorp,dc=com) and click OK. The Deleted Objects container appears in the tool's left pane, as Figure 1 shows. Expand the container to view all the tombstone objects in the container. Right-click the object you want to restore and select Modify from the context menu. Remove the object's isDeleted attribute by typing

isDeleted

in the Modify dialog box's Attribute field. Leave the Values field blank. Under Operation, select Delete, then click Enter.

3. Still in the Modify dialog box, enter

distinguishedName

in the Attribute field. In the Values field, enter the restored object's new DN. Under Operation, select Replace, then click Enter.

4. Repeat the modification procedure to add any mandatory attributes for objects you're restoring. In some cases (e.g., user objects), the tombstone maintains all mandatory attributes, so you won't need to add any.
5. After you've finished modifying the tombstone, confirm that the Extended check box (on the Modify dialog box) is selected and click Run. In Ldp's right pane, you'll see a message similar to the one that Figure 2 shows, telling you whether the restoration operation was successful. After you've restored the object, you can modify it further to populate any applicable optional attributes.

By default, only members of the Domain Admins group can restore tombstones in a domain. However, you can use ADSI Edit (available in the Windows Support Tools) to grant the Reanimate Tombstones extended right at the root of a partition to a user or group, thereby delegating the permission to restore tombstones. Open ADSI Edit, right-click the target partition's root DN, and select Properties. Go to the Security tab, click Advanced, then click Add. Locate the user or group to which you want to delegate the permission. After you've selected the user or group, select the Allow check box beside Reanimate Tombstones, then click OK. Be extremely cautious about granting this right, though, because a malicious user could, for example, restore a deleted user object, set the password for that object, and use that account to log on. The user or group to which you delegate the permission must have Write privileges on the organizational unit (OU) or container to which the deleted object will be restored.

New Life
I hope that restoring or even searching for tombstone objects isn't something you'll need to do on a regular basis. However, understanding how AD handles deleted objects and what you can do with them is a useful capability. Third-party vendors such as Aelita software and Sysinternals are even providing search-and-restore capabilities for deleted objects. You might want to try the search and restore procedures in a test forest to get comfortable with them—just in case.