Active Directory Recycle Bin

Overview

This page covers the Active Directory Recycle Bin (AD Recycle Bin), not the Recycle Bin for local Windows files.

AD Recycle Bin is a forest-wide optional feature that restores accidentally deleted AD objects while retaining their objectSid, many attributes, and group memberships. According to Microsoft, the link-valued and non-link-valued attributes of objects deleted after the feature is enabled are preserved, allowing restoration to a logical state close to the one before deletion.

Even in ordinary AD environments, the SID (Security Identifier) of a deleted account may remain in ACLs (Access Control Lists) on file servers, application objects, certificate templates, OUs, and other resources. The key point is that AD access control uses SIDs rather than names.

Before deletion:
legacy_admin -> SID S-1-5-21-...-1111

After deletion:
resource ACL -> SID S-1-5-21-...-1111 remains

After restoration:
legacy_admin -> same SID S-1-5-21-...-1111

In this case, the restored legacy_admin is again associated with the existing ACE (Access Control Entry) in the ACL. Creating a new user with the same sAMAccountName assigns a new SID, which does not match the old ACL.

Key information restored

For a user object, information important to restoration includes:

objectGUID
objectSid
sAMAccountName
Many user attributes
lastKnownParent, identifying the original parent OU
msDS-LastKnownRDN, identifying the original RDN (Relative Distinguished Name)
Linked attributes, including group memberships
Its relationship to ACLs that reference its SID

objectSid is especially important in permissions audits and incident response. Restoring a deleted object brings back its original SID as a security principal, so rights attached to an orphaned SID in a resource ACL or OU become effective again.

States after deletion

Deleting an AD object does not immediately remove it physically from the database. With AD Recycle Bin enabled, it roughly passes through these states:

Normal object
    ↓ deletion
Deleted Object
    ↓ msDS-deletedObjectLifetime expires
Recycled Object
    ↓ garbage collection after tombstoneLifetime expires
Physically removed

Deleted Object state

A Deleted Object is a deleted object that AD Recycle Bin can still restore.

It can typically be identified by these attributes:

isDeleted          : TRUE
isRecycled         : FALSE or unset
lastKnownParent    : Original OU / container
msDS-LastKnownRDN  : Original name

At this stage, Restore-ADObject can restore the object with relatively good consistency. Deleted objects do not appear in ordinary LDAP searches or Get-ADUser -Filter *; the search must include -IncludeDeletedObjects.

Recycled Object state

After msDS-deletedObjectLifetime expires, many attributes needed for restoration are removed and the object becomes a Recycled Object.

isDeleted   : TRUE
isRecycled  : TRUE

Normal, complete restoration through AD Recycle Bin is no longer possible at this stage. Microsoft’s ADAC (Active Directory Administrative Center) documentation says deleted objects are retained according to msDS-deletedObjectLifetime, which by default equals the forest’s tombstoneLifetime. A typical default for forests created with Windows Server 2003 SP1 or later is 180 days, but always check the attribute value in the actual environment.

Difference from a tombstone

A tombstone is primarily a deletion marker used to replicate the fact that an object was deleted to other DCs (Domain Controllers).

In the older recovery model without AD Recycle Bin, a deleted object became a tombstone that lost many attributes, leaving too little information to restore its previous state. With AD Recycle Bin enabled, it is first retained as a restorable Deleted Object. After the retention period, it becomes a Recycled Object with attributes removed.

State	Main purpose	Normal restoration
Deleted Object	Retain a state close to the pre-deletion state	Possible
Recycled Object	Retain deletion information for replication and garbage collection	Generally not possible
Tombstone	Replicate the fact of deletion	Difficult because attributes are missing

Some documentation and tools treat Recycled Objects as equivalent to tombstones, so terminology can overlap. In practice, inspect isDeleted, isRecycled, lastKnownParent, and msDS-LastKnownRDN to determine whether an object is still at a restorable stage.

Characteristics of enabling the feature

AD Recycle Bin is not enabled by default. Its main characteristics are:

It is enabled for the entire forest.
The forest functional level must be Windows Server 2008 R2 or later.
Once enabled, it cannot be disabled.
Only objects deleted after it is enabled can be restored with AD Recycle Bin.
Objects deleted before it was enabled cannot be recovered with AD Recycle Bin.
Retaining attributes on Deleted Objects increases NTDS.DIT usage on each DC.

Enabling it improves availability, but privileged objects and old group memberships remain restorable for a period. Rather than avoiding the feature, design audits of restoration rights and orphaned SIDs.

Check whether it is enabled

Use Get-ADOptionalFeature to check whether Recycle Bin Feature is enabled.

Get-ADOptionalFeature `
    -Filter 'Name -like "Recycle Bin Feature"' |
    Format-List Name,EnabledScopes

For a more direct check:

Get-ADOptionalFeature `
    -Identity "Recycle Bin Feature" |
    Select-Object Name,EnabledScopes

If EnabledScopes lists the forest’s Configuration Partition or similar scope, it is enabled. If the property is empty, it is not enabled.

Inspect deleted objects

To inspect all deleted objects:

Get-ADObject `
    -IncludeDeletedObjects `
    -Filter 'isDeleted -eq $true' `
    -Properties lastKnownParent,
                msDS-LastKnownRDN,
                isDeleted,
                isRecycled,
                objectSid |
    Select-Object Name,
                  ObjectGUID,
                  objectSid,
                  lastKnownParent,
                  msDS-LastKnownRDN,
                  isRecycled

To find objects deleted from a specific OU:

Get-ADObject `
    -IncludeDeletedObjects `
    -LDAPFilter '(&(isDeleted=TRUE)(lastKnownParent=OU=Operations,DC=example,DC=com))' `
    -Properties lastKnownParent,
                msDS-LastKnownRDN,
                isRecycled,
                objectSid

If you know the name or sAMAccountName, narrow the restoration candidates:

Get-ADObject `
    -IncludeDeletedObjects `
    -Filter 'sAMAccountName -eq "legacy_admin"' `
    -Properties sAMAccountName,
                objectSid,
                lastKnownParent,
                msDS-LastKnownRDN,
                isRecycled

A likely restoration candidate is an object with isDeleted=True and isRecycled either False or unset.

How to restore

The reliable approach is to retrieve the deleted object with Get-ADObject -IncludeDeletedObjects and pass it to Restore-ADObject.

Get-ADObject `
    -Identity "938182c3-bf0b-410a-9aaa-45c8e1a02ebf" `
    -IncludeDeletedObjects |
    Restore-ADObject

If the original name or location is unavailable, specify -NewName and -TargetPath.

Get-ADObject `
    -Identity "938182c3-bf0b-410a-9aaa-45c8e1a02ebf" `
    -IncludeDeletedObjects |
    Restore-ADObject `
        -NewName "legacy_admin" `
        -TargetPath "OU=Operations,DC=example,DC=com"

With Restore-ADObject, omitting -NewName uses msDS-LastKnownRDN, while omitting -TargetPath uses lastKnownParent.

If a parent object such as an OU was also deleted, restore the parent before restoring child objects. ADAC’s bulk restoration is best effort and may not always restore a complex subtree correctly in one pass.

Restoration permissions

Even with AD Recycle Bin enabled, ordinary users cannot freely enumerate and restore deleted objects. Depending on the environment and delegation design, restoration broadly involves these rights:

Permission to enumerate the Deleted Objects container.
Permission to read deleted objects.
Permission to create child objects in the destination container or OU.
The Reanimate Tombstones extended right.
Delegated ACLs on the target object or parent OU.

If restoration rights are delegated too broadly to operators or application administrators, restoring deleted objects can revive more privilege than expected. For example, GenericAll on an OU may combine with rights to create in the destination, modify ACLs, or reset passwords to form a privilege chain through a deleted account’s restoration.

What to look for in an audit or investigation

When investigating AD Recycle Bin, look for these signs:

An OU or group appears empty, but there are traces of objects that existed earlier.
Orphaned SIDs such as Account Unknown(S-1-5-21-...-RID) remain in ACLs.
ACEs on file shares, GPOs, certificate templates, or OUs contain SIDs that no longer resolve to names.
Ordinary LDAP enumeration results do not match the ACL state.
An object is absent from Get-ADUser -Filter * but appears with Get-ADObject -IncludeDeletedObjects.

The investigation can be organized as follows:

1. Find an unknown SID in an ACL
2. Search Deleted Objects for an object with the same SID
3. Confirm that isRecycled is not True
4. Check lastKnownParent / msDS-LastKnownRDN
5. Restore it with Restore-ADObject
6. Check whether ACLs and group memberships are effective again

The essence of AD is that access control uses SIDs, not names. AD Recycle Bin also makes that premise easy to verify in practice.

Defense and operational considerations

AD Recycle Bin is a feature for defense and availability. However, restoring an object may also restore its old rights and group memberships, so deletion and restoration should not be treated as simple account operations.

Pay particular attention to:

Whether a deleted user’s SID remains in ACLs.
Whether orphaned SIDs remain on certificate templates.
Whether restoration brings back group memberships, including past membership in privileged groups.
Whether past delegated rights become effective again after restoration.
Whether a privileged account remains as a restorable Deleted Object.
Whether enumeration and restoration rights on the Deleted Objects container are delegated too broadly.

When deleting an account, review more than just the object itself:

Where does its SID remain in ACLs / groups / certificate templates / delegation?

This revival of rights is a natural result of AD behavior, not an exceptional case. Think of AD Recycle Bin as a feature that restores deleted AD objects while preserving their SIDs and related information.