Recovering deleted Active Directory Objects – Tombstone reanimation

To start off, sorry to disappoint, no zombie jokes here just routine AD stuff 😉

When deleting an object, Active Directory will not actually delete that object immediately (in most cases) but rather it will keep it for a period of time as a tombstone object. This means it will remove some of its attributes, add the isDeleted=True attribute, and place the object in the Deleted Object container.

The tombstone objects do have a limited life however; they will be removed after a certain amount of time by the AD garbage collection process.

The life of the tombstone objects is determined here (nr. of days):

Configuration namespace > Services > Windows NT > Directory Service > tombstoneLifetime:


To start we need to play attention to the object’s systemFlags attribute (This is an optional attribute of the TOP class). The systemFlags will determine what we can “tell” AD to do with an object.

Let’s take two of its possible values for example:

33554432 (0x02000000) The object is not moved to the Deleted Objects container when it is deleted. It will be deleted immediately.
2147483648 (0x80000000) The object cannot be deleted.

If the object’s systemFlags attribute is NOT 0, verify here what its constraints are applied to the object

Next we need to focus on what attributes will be kept (and therefore recoverable) when the object is tombstoned. This is controlled by the attribute’s searchFlags.

If the searchFlags’ bit 3 is 0 then the attribute is will be discarded, if it’s 1 the the attribute is kept (00001000 = keep; 00000000 = delete)

Let’s take a look at two attributes in the schema partition:


The searchFlags’ decimal value is 9, if we translate this in binary 00001001 so the attribute will be kept when the object is tombstoned.



The searchFlags’ decimal value is 5, if we translate this in binary 00000101 so the attribute will not be kept when the object is tombstoned.


Note. I will cover in a future article how to change the searchFlags attribute in order to keep it in the tombstone



Let’s recover an object (of course use your own domain naming convention)

Start Ldp.exe

Connect >

Bind > enter your credentials

Before we do anything else we must enable ldp.exe to show the deleted objects:

Options > Controls > Load Predefined > Return deleted objects > OK

Should look like this:


The deleted objects can be found either using tree view

View > Tree > BaseDN “DC=domain1, DC=com”

Navigate to “CN=Deleted Objects,DC=domain1, DC=com” and expand


or using the search option

Browse > Search


Earlier I deleted user4.test. Let’s take a closer look at the tombstone:


First of all we see that the object’s DN now incorporates its GUID. The Deleted Objects is a flat container so this is done in order to prevent overlap in case another object with the same name gets deleted.

Of particular interest is the lastKnownParent attribute. Its value tells us the object’s previous location so it’s very useful if we want to restore it in the same OU.

We right-click the object we want to restore and select Modify.

Select Operation Delete.

Write in the Attribute field: isDeleted

Hit enter

Do not hit RUN yet!


Select Operation Replace

Write in the Attribute field: distinguishedName

Write in the Value field: the future DN of the object

(I often just combine the object’s previous CN with value of lastKnownParent if you want to restore in the object’s previous location)

Hit Enter

Final result should look like this:



The object is restored!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s