Editor’s Note: This is the 2nd in a series of blogs around Active Directory (AD) backup and recovery using STEALTHbits, StealthRECOVER. Read the 1st blog, An Introduction to Active Directory Backup and Recovery.
NOTE: For the purposes of this post I’m going to assume that the Active Recovery Recycle Bin has not been enabled within the domain. The AD Recycle Bin and its impact on object recovery will be covered in this series’ next post.
When an object is deleted from Active Directory it is not actually deleted, at least not right away.
This is not really a feature as much as it was the consequence of the multi-master replication implementation employed by Active Directory. This replication approach allows any domain controller to create or update an object with the changes then replicating out to other domain controllers.
Let’s use the LDP utility to take a look at what actually happens when an object is deleted. Assisting me in this endeavor will be Delete Q. Me, my handy PowerShell-generated demo user account.
It looks like a happy, healthy user account ready to participate in a demonstrative adventure. Sadly, as mentioned in the previous paragraph, I’m going to delete my poor user account for science.
Sorry, buddy.
Now that it’s gone, you may have trouble finding our dead-but-not-gone user account. LDP needs a nudge before it will show deleted objects. Within LDP, click the Options menu and select Controls. Within the Controls dialog box, open the Load Predefined dropdown, select Return deleted objects, and click OK.
The partition’s Deleted Objects container should now be visible below the root. After expanding that, we can poke around for our recently-deceased user object.
Yikes. Here’s a summary of the changes which occurred as a result of the user object’s deletion:
- The object has been moved.
Those of you who have been paying attention will have noticed that we went to a different spot to find the user object after it had been deleted. Every directory partition has its own Deleted Objects container. OK, that’s not true. The Schema partition does not have its own Deleted Objects container because you can’t delete objects from the schema. Anyway, the purpose of the Deleted Objects container is to contain deleted objects. You probably already figured that out though. Active Directory hides these containers unless you specifically request them, which you also may have already figured out. - The object has been renamed.
The object’s name has been updated using a clever pattern: Common-Name ADEL:O bject- . This naming scheme method guarantees the uniqueness of object names even when multiple objects with the same relative distinguished name have been deleted.Guid - The object possesses some new attributes.
Our friendly neighborhood user account has three new attributes. The first new attribute is isDeleted. If the value of this attribute is “TRUE”, the object has been marked for deletion. The next new attribute is isRecycled. This attribute has only been added and provided value because this domain’s functional level is higher than in 2008. It’s otherwise superfluous because this domain’s Recycle Bin has not been enabled. The final new attribute islastKnownParent attribute, which contains the distinguished name of the last known parent of the user object (which is going to come in handy in a minute). - Lots and lots of attributes have been removed.
When an object is deleted, only essential attributes are preserved. Attributes that do not possess the 0x8 ( PRESERVE_ON_DELETE ) search flag are deleted, as it’s assumed they’re no longer necessary. Since I haven’t modified my domain’s schema to preserve more than the default attributes (because it’s not a great idea), my good friend and user objecthas lost most of its attributes along with their associated values.
This object is now referred to as a “tombstone” and the last step in this demonstration is to “reanimate” it. Seriously. Those are the technical terms.
Anyway, we can totally reanimate this tombstone within the LDP utility by making use of its Modify feature:
- Right-click the tombstone and select the Modify option.
- In the Edit Entry section, enter the value “isDeleted” in the Attribute field, select the Delete radio button under Operation, and click the Enter button to add the entry to the Entry List.
- In
the Edit Entry section, enter the value “distinguishedName” in the Attribute
field, enter distinguished name of object prior to its deletion in the Values
field, select the Replace radio button under Operation, and click the Enter
button to add the entry to the Entry List.
Remember when I mentioned that the lastKnownParent attribute might end up being useful? Well, if you don’t know what the object’s dn was prior its deletion, you can try this trick: Take the current dn and replace the NULL terminated character (“ A”) and everything to its right with the current value of the lastKnownParent attribute. - Select the Extended option at the bottom-left of the panel.
- Click the Run button.
After clicking the Run button, we can go find the reanimated object again and see what it looks like.
As you can see, we technically recovered the deleted user object. It’s just missing most of the information it possessed prior to its deletion.
You can get around the whole “losing most of the useful attributes” thing by taking regular VSS Snapshots of Active Directory. Using this method, if you need to recover a deleted object you can just find a backup that was taken prior to the object’s deletion, mount the snapshot using NTDSUTIL, connect to the mounted snapshot using an LDAP utility, locate the object, export it to… never mind.
But wait, it gets worse.
The Deleted Objects container isn’t a forever kind of thing. The aptly-named tombstoneLifetime property on the CN=Directory Service,CN=Windows NT,CN-Services,CN=Configuration,ForestDistinguishedName object defines the number of days before a deleted object will be permanently removed from Active Directory.
The value of tombstoneLifetime is based on the version of Windows Server that was involved in the creation of the domain’s forest. It is set to 180 days (Microsoft’s current recommended setting) by default in forests created using a version of Windows Server more recent than 2003. Older implementations default to 60 days. The behavior of the tombstoneLifetime property is actually worth paying attention to and is kinda’ cool. If the value exists, the tombstone lifetime is the value specified. Unless the value is less than 2. Then the tombstone lifetime defaults to 60 days (Windows 2000 Server through Windows Server 2008) or 2 days (Windows Server 2008 R2 or later). If no value is specified the is 60 days.
If you’re curious about what the value of tombstoneLifetime is in your environment, this PowerShell script will return it for you (requires AD DS and AD LDS Tools):
(Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties *).tombstoneLifetimeOnce an object has spent a tombstoneLifetime in the Deleted Objects container, it is logically deleted by Active Directory’s garbage collection. At that point, it’s gone and it’s never coming back.
If I could suggest an alternative, I’m involved in the development of a software solution that addresses this very problem. StealthRECOVER restores deleted objects to any backed-up state prior to their deletion. It can also restore objects that have exceeded their forest’s tombstoneLifetime.
Learn more about StealthRECOVER here.
In the next post in this series, we’ll take a look at the functionality introduced with the Active Directory Recycle Bin.
Apparently, in server 2019 the manual way doesn’t work. When the attribute of “isRecycled: True”. Supposedly you cant recover it. I keep getting the “…aspect of the modification is not permitted.”