Accidentally deleting an important Active Directory object is a special kind of stomach drop. The good news is that modern Active Directory recovery is much better than the old tombstone-reanimation days, provided Active Directory Recycle Bin was enabled before the deletion occurred.
Microsoft’s current guidance is clear on that point: Recycle Bin preserves deleted objects so they can be restored with their attributes and links, such as group memberships, intact. It is not enabled by default, and enabling it is irreversible.
Enable and use Active Directory Recycle Bin
This post is the quick runbook I want nearby when someone says, “I deleted the wrong thing.”
Before the incident
Do this before you need it:
- Confirm Active Directory Recycle Bin is enabled.
- Know who can restore deleted objects.
- Know the deleted object lifetime and tombstone lifetime for the forest.
- Test restoring a user, group, computer, and OU in a lab.
- Document where restored objects should go if their original parent was also deleted.
The middle of an incident is a bad time to learn that Recycle Bin was never enabled.
Find the deleted object
First, search for the object with -IncludeDeletedObjects.
Get-ADObject `
-Filter 'ObjectClass -eq "user" -and IsDeleted -eq $true -and Name -like "*chad*"' `
-IncludeDeletedObjects `
-Properties IsDeleted, LastKnownParent |
Format-List Name, IsDeleted, LastKnownParent, DistinguishedName
This example searches for deleted user objects where the Name attribute contains chad.
That distinction matters under pressure. If you search Name for a login value such as cduff, you may not get a result because the login name is usually in sAMAccountName or userPrincipalName, not necessarily Name.
The distinguished name is important because deleted objects have mangled names. You need the deleted object’s current distinguished name to restore it.
Restore the object
Once you have the deleted object’s distinguished name, restore it:
Restore-ADObject `
-Identity "CN=chadduffey\0ADEL:549111ab-f6f0-4239a-8915-9231323eaaf8,CN=Deleted Objects,DC=DropbearSec,DC=com" `
-NewName "Chad Duffey" `
-TargetPath "CN=Users,DC=DropbearSec,DC=com"
-NewName controls the restored object’s name. -TargetPath controls where the object is restored.
If the original parent container still exists, you may not need to specify a new target. If the original OU was also deleted, restore the parent first or choose a known-good target path.
Verify the restore
After restoring the object, check the important attributes rather than assuming the job is done:
Get-ADUser chadduffey -Properties Enabled, MemberOf, LastLogonDate |
Select-Object Name, Enabled, DistinguishedName, MemberOf, LastLogonDate
For users and computers, confirm:
- The object is in the expected OU.
- Group memberships are correct.
- The account state is correct.
- Dependent systems can see the restored object after replication.
- Any automation that reacted to deletion did not also need rollback.
For groups, confirm membership and access impact. For OUs, check linked Group Policy objects and delegated permissions.
Common pressure mistakes
The mistakes are predictable:
- Searching the wrong attribute.
- Restoring to the wrong OU.
- Forgetting that the parent object may also be deleted.
- Assuming replication has completed immediately.
- Forgetting downstream systems that cached the deletion.
- Discovering too late that Recycle Bin was never enabled.
Take the extra minute to copy the deleted object’s DN, LastKnownParent, object class, and deletion time into the incident notes before restoring it. That small paper trail helps if the first restore attempt is not the final state you want.
Example
The short version: enable Recycle Bin before you need it, search with -IncludeDeletedObjects, restore by distinguished name, and verify the attributes that matter for the object’s role.
