Active Directory Recycle Bin: enabling it, restoring objects and knowing its limits
One click too many in the console and an entire organisational unit disappears, with its users, groups and their memberships. Without the Recycle Bin, the only option is an authoritative restore from backup. With it, the job takes minutes. Yet it is still disabled in some of the forests we audit.
What the Recycle Bin changes
Without the Recycle Bin, a deleted object becomes a tombstone: Active Directory strips most of its attributes, including group memberships, and keeps only a skeleton. Reanimating it produces an incomplete object that must be rebuilt. With the Recycle Bin, a deleted object first moves to a deleted-object state while keeping all its attributes, including linked attributes such as group memberships. It can then be restored exactly as it was, with the same SID and GUID.
Enabling it
The Recycle Bin requires a forest functional level of at least Windows Server 2008 R2, which any maintained forest exceeds today. It is enabled for the whole forest, from Active Directory Administrative Center or with the Enable-ADOptionalFeature command and the "Recycle Bin Feature". Two things to know:
- enabling it is irreversible, which in practice causes no problem;
- it is not retroactive: objects deleted before it was enabled remain tombstones and cannot be fully restored.
The directory database grows slightly, since deleted objects keep their attributes for their lifetime. In the vast majority of environments the impact is negligible.
Lifetimes to know
| Attribute | Role |
|---|---|
msDS-deletedObjectLifetime | How long a deleted object stays restorable with all its attributes. If unset, the tombstoneLifetime value applies. |
tombstoneLifetime | How long a recycled object lives before permanent removal. It is 180 days for forests created with modern versions, but may be 60 days in very old forests. |
Both attributes sit on the Directory Service object in the configuration partition. Check their values: a legacy forest may still have a 60-day lifetime, which also governs the maximum age of a restorable backup.
Restoring objects and memberships
Restores are done from the Deleted Objects container, in Administrative Center or with Restore-ADObject. Order matters: an object can only be restored if its parent container exists. After deleting an entire OU, restore the OU first, then its child OUs, then the objects they contained. Group memberships come back with the object, provided the groups involved exist too, so restore deleted groups and users together. Passwords are preserved: the user gets their account back exactly as it was.
Prevention beats cure. The "Protect object from accidental deletion" option, ticked by default on OUs created in the console, blocks deletion until it is cleared. Make sure it is enabled on sensitive OUs, especially those holding privileged accounts and servers.
What the Recycle Bin does not replace
- Modifications: a changed attribute or a membership removed by mistake cannot be restored from the Recycle Bin; only object deletion is covered.
- Content outside the directory: Group Policy settings stored in SYSVOL are not restored with the GPO object, so back them up separately.
- Compromise and corruption: against ransomware or a compromised forest, the Recycle Bin is useless. Only isolated, tested system state backups of controllers and a rehearsed forest recovery plan let you start again.
What an audit checks
- whether the Recycle Bin is enabled, and since when;
- the values of
msDS-deletedObjectLifetimeandtombstoneLifetime; - protection against accidental deletion on sensitive OUs;
- isolated, recent and tested controller backups, along with a forest recovery plan.