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:

tobstone_lifetime

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  http://msdn.microsoft.com/en-us/library/windows/desktop/ms680022%28v=vs.85%29.aspx

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:

Object-Sid:

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

objectSid_searchFlags

Surname:

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.

surname_searchFlags

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 > domain1.com

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:

ldp_view_del_items

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

ldp_tree_view

or using the search option

Browse > Search

ldp_search

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

tobstoned_object

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!

delete_isDeleted

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:

modify_DN

Hit RUN

The object is restored!

Leave a comment