Active Directory Object Recovery (Recycle Bin)

Active Directory Object Recovery (Recycle Bin)

Editors note: This is the 3rd in a series of blog around Active Directory (AD) backup and recovery using STEALTHbits, StealthRECOVER. Read the 1st blog, An Introduction to Active Directory Backup and Recovery and the 2nd blog, Active Directory Object Recovery.

The previous post in this series discussed the joys of Active Directory object recovery in an environment without the AD Recycle Bin. If you missed that post, I strongly encourage you to go back and read it as it is arguably the single greatest blog post I have ever written about Active Directory object recovery in an environment without the AD Recycle Bin. To summarize, when an Active Directory object is deleted in a domain without the AD Recycle Bin it becomes a “tombstone”. This object, stripped of the majority of its attributes, then hangs out in the partition’s Deleted Objects container for the duration of the domain’s tombstoneLifetime. During this period the object is technically recoverable, but its lost attributes can be generally considered to be irrecoverable. After the tombstone exceeds the tombstoneLifetime value, the object is garbage-collected into non-existence. This summary is further simplified in the following illustration:

The Active Directory Recycle Bin was introduced in the Windows Server 2008 R2 release. The goal of this feature was to facilitate the recovery of deleted Active Directory objects without requiring restoration of backups, restarting Active Directory Domain Services, or rebooting domain controllers. To accomplish these goals, the AD Recycle Bin introduced changes to the behavior of the Active Directory object deletion lifecycle.

The fundamental change introduced by the Active Directory Recycle Bin relates to the management of a deleted object’s attributes. After enabling the AD Recycle Bin, the majority of a deleted object’s attributes, including its link-valued attributes, are preserved for a period of time. This change greatly simplifies the process of fully-restoring deleted objects to the state they were in immediately prior to their deletion.

Objects in this new recoverable state are referred to as a “deleted object” and the period of time which they retain their attributes is defined in a new attribute, msDS-DeletedObjectLifetime. When the AD Recycle Bin is enabled, the value of the msDS-DeletedObjectLifetime attribute defaults to the value of the tombstoneLifetime attribute. If the value of the msDS-deletedObjectLifetime attribute is null or the attribute itself simply doesn’t exist, its value is interpreted to be equivalent to the value of the tombstoneLifetime attribute. If there’s also no tombstoneLifetime value, both values default to 60 days.

After the object’s time as in a deleted object state exceeds the period of time specified in msDS-DeletedObjectLifetime, the object is recycled. A “recycled object” looks suspiciously like a tombstone with an isRecycled attribute slapped on and set to TRUE. Like a tombstone, the majority of its attributes are removed and it persists in Active Directory for the duration of the tombstoneLifetime before being cleaned up by Active Directory’s garbage collection.

A simplification of the Recycle Bin deleted object lifecycle looks like this:

Now that everyone has a basic understanding of the AD Recycle Bin’s deleted object behavior, let’s fire up the LDP utility and take a closer look with the help of my sacrificial user account.

As you can see, thanks to the wonders of the PowerShell script that both creates and resuscitates him, we have plenty of attributes populated.

After deleting the object, we can see that the behavior has definitely changed as the majority of its attributes persisted into the deleted object state.

Here is a summary of the changes which occurred as a result of the object’s deletion:

  1. The object has been moved.
    Like our previous experiment without the Recycle Bin, the object has been moved into the partition’s Deleted Objects container.
  2. The object has been renamed.
    The object’s name has also been updated using the same Common-Name\0ADEL:Object-Guid pattern as before.
  3. The object possesses some new attributes.
    The isDeleted attribute again makes an appearance with a value of TRUE and the lastKnownParent attribute is populated (though in this case, it had already been populated as a result of the object’s deletion and recovery as part of the last post). A new attribute, msDS-LastKnownRDN, is also populated with the object’s last known relative distinguished name. This attribute allows the Recycle Bin to properly reset an object’s RDN during its restoration, even if the object’s renaming resulted in the truncation of the original RDN.
  4. Two attributes have been removed.
    Thanks to the Recycle Bin, the only attributes that have been removed are objectCategory and sAMAccountType. These two attributes are actually always removed from an object when it is deleted, regardless of the Recycle Bin state or the presence of the 0x8 ( PRESERVE_ON_DELETE ) search flag. When a deleted object is recovered, the objectCategory value is automatically set to the most specific value in the object’s objectClass attribute and the sAMAccountType value is calculated from the value of either the userAccountControl (for user objects) or the groupType attribute (for group objects).
    Keen-eyed observers might also notice that the manager and memberOf attributes are also missing from my screenshot. They’re actually just hiding. Both the manager and memberOf attributes are link-valued (i.e., they contain references to other objects) and LDP doesn’t return deactivated links unless the cleverly-named Return Deactivated Links control has been set. If I had enabled that control the attributes and their values would have been visible in my screenshot, but I would have missed out on this teachable moment.

On to the AD Recycle Bin object recovery process. While providing considerably more value, the AD Recycle Bin was initially hampered by the fact that it was relatively difficult to use. Prior to Windows Server 2012, viewing the contents of the Recycle Bin required the use of an LDAP tool or PowerShell. For example, this PowerShell query will return all of the deleted objects within a domain:

Get-ADObject -filter 'isDeleted -eq $true -and name -ne "Deleted Objects"' -includeDeletedObjects

In my lab, which is has a limited amount of Active Directory churn, the output looks like this:

You can employ additional filters to reduce the scope of the query and, consequently, the volume of deleted objects being returned, but I’m sure you can imagine what the results of this query might look like in a real production environment.

Assuming you can find the object you want to restore, you can use a query like this to restore it:

Restore-ADObject -Identity '562f229c-e03a-4005-a098-10046e9b8942'

I’m passing the ObjectGUID to the Identity parameter to specify the object I’m trying to restore, but I could also have passed the results of a Get-ADObject query through the pipeline to the Restore-ADObject cmdlet.

What I’m getting at is that it was a good thing the AD Recycle Bin was so useful because it was not exactly fun to use. Thankfully, after receiving what I can only assume was some aggressively constructive feedback from the user community, Microsoft made things easier to use by adding the Recycle Bin functionality to the Active Directory Administrative Center beginning with Windows Server 2012.

Let’s take a look at the Deleted Objects container using ADAC:

I’m passing the ObjectGUID to the Identity parameter to specify the object I’m trying to restore, but I could also have passed the results of a Get-ADObject query through the pipeline to the Restore-ADObject cmdlet.

What I’m getting at is that it was a good thing the AD Recycle Bin was so useful because it was not exactly fun to use. Thankfully, after receiving what I can only assume was some aggressively constructive feedback from the user community, Microsoft made things easier to use by adding the Recycle Bin functionality to the Active Directory Administrative Center beginning with Windows Server 2012.

Let’s take a look at the Deleted Objects container using ADAC:

As you can see, the four objects returned by my PowerShell query are visible in a much more user-friendly interface. There’s also the ability to easily generate filters to constrain the volume number of objects being returned to the UI and a Restore action in the Tasks available on the right side of the window. I’ll click the Restore action and pop back over to LDP to look at my newly -restored object.

Pretty cool, right?

Before anyone goes running off to enable the Active Directory Recycle Bin, there are immediate and potentially detrimental impact to doing so:

  1. Enabling the Active Directory Recycle Bin involves a schema change.
    As a result of this schema change is that it will not be possible to disable the Recycle Bin without resorting to a full-forest recovery. That is to say, once you turn the Recycle Bin on you can’t turn it off.
  2. Active Directory is going to be a little bigger.
    After enabling the AD Recycle Bin, deleted objects will retain all of their attributes until the deleted object lifetime is exceeded. They will also persist for twice the duration of the tombstone lifetime. Both of these facts are likely to result in Active Directory using a little more disc space than it did before.
  3. The Recycle Bin does not work retroactively.
    This consequence, which is decidedly the most consequential consequence, is that the moment the Recycle Bin is enabled all tombstone objects within the forest will cease to exist. If you’ve been looking for an opportunity to laugh at the misfortune of others, search the internet for “deleted objects gone after enabling recycle bin”. A not-inconsequential number of people have learned about this particular consequence the hard way.

All this having been said, none of these issues is severe enough to overcome the benefit of enabling the AD Recycle Bin. In fact, StealthRECOVER works with or without the Active Directory Recycle Bin and provides additional security with its capability to restore backed-up objects that have exceeded their forest’s mdDS-DeletedObjectLifetime and are no longer recoverable using the AD Recycle Bin.

In the next post in this series, we’ll move away from object deletion and discuss the restoration of modified objects.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free StealthAUDIT® Trial!

No risk. No obligation.