Before Microsoft brought the recycle bin to Active Directory (AD), accidental deletion of AD objects--users, computers, groups, or even entire organizational units (OUs)--was a common annoyance for administrators, and recovering from such a mistake was a complex and time-consuming task. After the AD recycle bin came along in Windows Server 2008 R2, administrators saved a significant amount of time compared to the legacy built-in AD object recovery methods. Let's examine how to enable the AD recycle bin, how you can use it for easy object recovery, and what’s good (and not so good) about it.
One reminder before we continue on to AD object recovery: To reduce the chances that you ever need to recover deleted AD objects, you can lock down the default permissions of AD objects. For example, you can take away the Delete and/or Delete Subtree permissions for the Everyone group by adding an ACL entry that specifically denies the Everyone group from deleting. Or, you can leverage the new feature in Server 2008 Active Directory Users and Computers (ADUC)--the check box labeled Protect object from accidental deletion. You enable this feature on the Object tab of an AD object, which Figure 1 shows.
Object Recovery, Before: Authoritative Restore
Microsoft provides two mechanisms to recover deleted AD objects. In all AD versions, administrators can recover deleted objects by using an authoritative restore. Starting with Windows Server 2003, they can also use tombstone reanimation.
An authoritative restore means that you recreate the deleted AD objects by replicating them back into your AD infrastructure from a Global Catalog (GC) Domain Controller (DC) that still has a live copy of the deleted objects--this is a GC DC in the deleted object’s domain that hasn't received or applied the object deletions in its AD database. If you don’t have such a DC available, you must perform--before the authoritative restore--a non-authoritative restore (also referred to as a system state restore) of the AD database on one of your DCs. In this case it is critical to have a recent system state backup of a GC DC in the deleted object’s domain.
To initiate an authoritative restore and to mark the objects that must be restored, you use ntdsutil.exe. An important drawback is that you must do this in Directory Services Restore Mode (DSRM). In other words, the DC you use for the authoritative restore must be offline.
An even more important shortcoming is that an authoritative store doesn't restore all of the deleted object’s attributes. Without going into the details, I'll give you an example: Not all user group memberships are automatically and fully regenerated during an authoritative restore. To work around this, after the authoritative restore you must use a script or third-party tool that restores the missing attributes.
Because of that drawback in the authoritative restore process, Microsoft included a new version of ntdsutil.exe in Windows Server 2003 SP1. During the authoritative restore process, the new ntdsutil tool generates an .ldf file that is used with the Ldifde.exe utility for restoring the missing object attributes in the different domains of your forest. After the authoritative restore, administrators can then import these files in the domains using the ldifde utility to bring back the complete attribute set of the restored objects.
The problem of missing object attributes is partially handled in AD domains that support link-value replication (LVR). LVR is available if your forest has at least a functional level of Windows 2003 interim mode. But even then you'll have some extra work after the authoritative restore. For example, you'll need scripts or tools that can fully restore the object group memberships in remote domains (i.e., groups that aren't located in the domain that holds the restored object).
For more information, refer to the Microsoft TechNet article "Performing an Authoritative Restore of Active Directory Objects," http://technet.microsoft.com/en-us/library/cc779573(WS.10).aspx and the Microsoft article "How to restore deleted user accounts and their group memberships in Active Directory" at http://support.microsoft.com/kb/840001.
Object Recovery, Before: Tombstone Reanimation
Tombstone reanimation is an AD object recovery method that Microsoft introduced in Server 2003. Tombstone reanimation takes advantage of the fact that AD keeps deleted objects in the database for a period of time--this is 180 days in the latest AD version--before it physically removes them. When an AD object is deleted, AD creates what Microsoft refers to as a tombstone of the object. Tombstones ensure that an object deletion is actually replicated throughout all DCs in the AD environment. When AD creates a tombstone of a deleted AD object, it marks the object as deleted, strips most of its attributes, renames the object, and moves the object to a special AD container called CN=Deleted Objects.
As opposed to an authoritative restore, tombstone reanimation allows you to recover deleted objects without taking a DC offline. Similar to an authoritative restore, tombstone reanimation doesn't recover all a reanimated object's attributes. Once more you will need a recovery mechanism to get the lost attributes back. And again also in this scenario a backup is the only solution that will bring the attributes back. Remember that the tombstoning process strips most of the object attributes.
Starting with Server 2008 AD, administrators can also leverage snapshots and Volume Shadow Copy Services (VSS) to create AD database backups and reanimate objects. Snapshots are “pictures” of the AD data at a given point-in-time that you create using ntdsutil.exe (You must use the new ntdsutil Snapshot submenu and its Create option) and that you can leverage for object reanimation. Under the hood, ntdsutil calls on VSS to create the snapshot. Note that you can also create VSS backups of AD database using the new Windows Server Backup (WSB) utility that is bundled with Server 2008. See http://blogs.dirteam.com/blogs/jorge/archive/2008/03/20/windows-server-2008-reanimating-objects-and-restoring-additional-information.aspx for more details on how to leverage tombstone reanimation and snapshots for AD object recovery. For more general details on tombstone reanimation, I refer to http://technet.microsoft.com/en-us/magazine/2007.09.tombstones.aspx.
None of the above AD object recovery techniques is perfect, and all are complex and time-consuming. If you want to ease your admin life, I advise you to look at a third-party AD backup and recovery tool and also at the Server 2008 AD recycle bin.
Object Recovery After: AD Recycle Bin
Compared with the object recovery techniques that were outlined in the previous section, the Server 2008 R2 AD recycle bin significantly enhances and eases an administrator’s ability to recover accidentally deleted AD objects. This is primarily because AD recycle bin can restore objects in their entirety with all their attributes preserved. This is possible thanks to a new “deleted” AD object state that replaces the “tombstone” object state that exists in previous AD versions. As opposed to an object that is in the tombstone state, AD leaves the attributes (including linked object attributes such as group memberships) of an object that's in a deleted state intact.
The AD recycle bin also introduces a second object state: when a deleted object expires (the default lifetime is 180 days) the object goes in a “recycled” state meaning that some of the object’s attributes are stripped. In fact, the recycled state is a new name for the “tombstone” state. When a recycled object expires (the default lifetime is also 180 days) the object it is physically deleted from the AD database using garbage collection. At the next online defragmentation of the AD database, the free space left by the recycled object will be recovered from the AD database.
Figure 2 summarizes the different states a deleted object goes through when the AD recycle bin is enabled. The figure also shows how the different states affect the content of the isDeleted and isRecycled AD object attributes, how you can switch between the deleted and the live state and between the recycled and live state, and what AD attributes control the lifetime of a given state. Only two of the four AD attributes shown in Figure 2 are new attributes: isRecycled and msDS-deletedObjectLifetime. Microsoft continues to use the isDeleted and tomstoneLifetime attributes because these are leveraged by many third-party backup and recovery applications.
Because a deleted AD object now goes through two different states before it actually disappears from the database, the deleted object hangs around for twice as long in the AD database. By default, this is 360 days (two times 180). Microsoft says this increases the size of the AD database an average of 10 to 15 percent.
The time an administrator gets to recover an object remains at 180 days, by default. In Microsoft documentation this timeframe is referred to as the Deleted Object Lifetime (DOL). You can change the DOL by modifying the value of the msDS-deletedObjectLifetime attribute of the Directory Service AD container (CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<your forest root domain>).
When the AD recycle bin is enabled, you can use it to undelete an object, this is to move the object from the deleted state back to the live state. As an extra safety net, Microsoft still supports authoritative restores to revive deleted objects. You could still use them to move the object from the recycled to the live state. But Microsoft strongly advises against the use of authoritative restores because of their complexity and because they create opportunities for introducing inconsistencies in the AD database. To illustrate this have a look at the following Microsoft statement that you can find at: http://technet.microsoft.com/en-us/library/dd379542(WS.10).aspx: “Do not attempt to recover a recycled object through an authoritative restore from a backup of AD DS. Instead, we recommend that you recover deleted objects with Active Directory Recycle Bin during the deleted object lifetime.” This statement probably explains why authoritative restores aren't enabled by default; you must set a specific flag using ntdsutil before you can do so: this flag is called the “Toggle recycled objects flag”. And by the way, you should also not use tombstone reanimation anymore, so no more nightmares about that one--AD recycle bin is the way to go!
Contrary to its Windows desktop peer, the AD recycle bin is not represented in the Microsoft Management Console (MMC) ADUC snap-in in the form of an icon or container that you can use to easily access deleted objects. Deleted objects are inaccessible from the classic AD management tools, and you must use directory editors like Windows’ proper LDP or Joeware’s AdMod (http://www.joeware.net/freetools/). As I explain in the next section Microsoft’s preferred way of dealing with the AD recycle bin is to use PowerShell cmdlets. At the time of writing, there were also third-party tools available that provide a GUI to interact with AD recycle bin. Examples are Overallsolutions’ ADrecyclebin (http://www.overall.ca/ADRecycleBin) and PowerGUI’s AD Recycle Bin PowerPack (https://www.quest.com/).
Although the recycle bin preserves all deleted object information, it won’t tell you who deleted your users, groups, or computers. To get that information you must use the built-in Windows event viewer and make sure that you have turned on auditing for the “Directory Service Changes” auditing policy subcategory.
Using AD Recycle Bin
The AD recycle bin is not enabled by default on a Server 2008 R2 AD installation: You must explicitly enable it. Before you can do so, you must also make sure that your AD schema is up-to-date, and that your AD domains and forest are at the Server 2008 R2 functional level.
The AD recycle bin uses a specific set of AD schema attributes to support, for example, the new recycled object state. The new attributes are present in AD when you do a clean Server 2008 R2 AD installation. If you are upgrading an existing AD infrastructure, you can make the required changes using the adprep command. For more information, see the Microsoft TechNet article "Requirements for Active Directory Recycle Bin" at "http://technet.microsoft.com/en-us/library/dd379484(WS.10).aspx.
To enable the AD Recycle Bin functionality in AD you can use the following PowerShell cmdlets. If not already loaded, you must first load the AD PowerShell module. To do so, type the following at the PowerShell prompt:
Import-module ActiveDirectory
Then enable the bin using the Enable-ADOptionalFeature PS cmdlet as follows (ensure that you replace <your forest root domain name> with your actual forest root domain name):
Enable-ADOptionalFeature –Identity “CN='Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DN=<your forest root domain name>” -Scope ForestOrConfigurationSet -Target “<your forest root domain name>”
Figure 3 shows the PowerShell output of running the above command. Note that the output warns you that the process of enabling AD recycle bin is irreversible. Once the AD recycle bin is turned on, you cannot turn it off. Before you enable it, you must make sure that AD recycle bin won’t be in violation of any company security rules or legislative or industry security requirements. For example, the AD recycle bin may unacceptably retain personally identifiable information because object attributes aren’t deleted.
After AD recycle bin is enabled, to get a list of all objects that are in the deleted state and all their attributes, run the following cmdlet:
Get-ADObject -filter 'isdeleted -eq $true -and name -ne "Deleted Objects"' -includeDeletedObjects -property *
If you want a formatted list that shows only the deleted object’s distinguished name, account name, parent container, and GUID, use the following, (as illustrated in Figure 4):
Get-ADObject -filter 'isdeleted -eq $true -and name -ne "Deleted Objects"' -includeDeletedObjects -property * | Format-List Deleted,DistinguishedName,samAccountName,lastknownParent,objectGUID
To undelete an account, if you know the object’s distinguished name or GUID, you can run the Restore-ADObject cmdlet from the PowerShell prompt as follows (Don’t forget to replace with the actual DN or GUID of the object you want to restore):
Restore-ADObject -identity
If you do not know the object’s distinguished name or GUID, you can use the Get-ADObject cmdlet to filter out the deleted object based on its samaccountname, and then pipeline this into the Restore-ADObject cmdlet, as follows (Replace <yoursamaccountname> with the account name of the actual object you want to undelete):
Get-ADObject -Filter 'samaccountname -eq "<yoursamaccountname>"' -IncludeDeletedObjects | Restore-ADObject
If you want to learn how to restore multiple deleted objects or how to restore an entire organizational unit hierarchy and its objects, have a look at the following Microsoft TechNet article: http://technet.microsoft.com/en-us/library/dd379509(WS.10).aspx.
The AD recycle bin is a nice add-on that will save administrators a significant amount of time compared with the legacy built-in AD object recovery methods. But the AD recycle bin cannot replace the functionality of more advanced backup and recovery tools. You still need a backup and recovery tool to cope with the restoration of AD changes (the bin just covers object deletions), to properly handle problems with AD schema updates and most importantly to deal with AD database corruptions. Also the AD recycle bin cannot cover the recovery of user-related data that are not stored in AD (e.g., GPO or Exchange-specific information). Finally, remember that AD recycle bin is available only if all your DCs are running Server 2008 R2.