Active Directory Recycle Bin Operations: Recover Objects Without Guessing

Active Directory Recycle Bin can restore deleted directory objects with far more attribute state than older tombstone recovery methods, but restoration is still a security-sensitive directory write. A restored user or group may regain memberships, access rights, service references, and application behavior that existed before deletion. The right recovery target must be identified by immutable evidence, not by display name alone. A mistaken restore can reintroduce a privileged identity or collide with a replacement object created after the deletion.

This runbook covers an environment where Active Directory Recycle Bin was already enabled before the object was deleted. It is not a method for restoring objects deleted before enablement, objects that have passed their recoverable lifecycle, or an entire domain controller. Recycle Bin does not replace system-state backups, authoritative restore procedures, or forest recovery plans. Start by preserving incident evidence and determining which domain and domain controller recorded the deletion.

Check feature state and recoverability

Recycle Bin is not enabled by default. Enabling it requires supported forest/domain functional levels and administrative rights, and the enablement is irreversible. Because this is a forest-wide capability, make the decision through forest-level change control and verify backup and recovery procedures before enabling it. Do not enable it in the middle of an incident simply to recover an older deletion; Microsoft documents that only objects deleted after the feature is enabled can be restored through Recycle Bin.

Query the feature state before attempting a restore. The following is read-only and displays the configured optional feature object:

Import-Module ActiveDirectory -ErrorAction Stop

$recycleBin = Get-ADOptionalFeature `
    -Identity 'Recycle Bin Feature' `
    -Properties EnabledScopes

[pscustomobject]@{
    Name = $recycleBin.Name
    EnabledScopes = $recycleBin.EnabledScopes -join '; '
}

Confirm the feature’s scope is populated for the intended forest and that the deleted object remains within the recoverable lifetime. Retention depends on directory lifecycle configuration. Do not assume a fixed number of days based on a previous forest or server version; inspect the relevant directory settings and use the deletion timestamp from authoritative evidence. If the object is no longer recoverable, stop and move to the approved backup/restore path instead of running undocumented attribute edits.

Record the affected domain, deletion time, requestor, object type, distinguished name, object GUID, SID if present, sAMAccountName or computer name, last known parent, and known group memberships or service dependencies. Capture the incident or change ID. Ask the object owner and security team to confirm that restoration is desired, particularly for administrators, service accounts, computer accounts, security groups, and policy objects.

Identify the exact deleted object

Use Get-ADObject -IncludeDeletedObjects to search the Deleted Objects container. Narrow the query with a reliable identifier and inspect the full result before restore. Names may include deletion metadata; lastKnownParent and object class help distinguish a stale object from a recent replacement. Search the domain that held the original object and specify a known domain controller when you need a consistent view.

$server = 'DC01.contoso.com'
$searchText = 'svc-app01'

$candidates = Get-ADObject `
    -Server $server `
    -IncludeDeletedObjects `
    -Filter "Name -like '*$searchText*'" `
    -Properties isDeleted, lastKnownParent, objectGUID, objectSid,
        sAMAccountName, objectClass, whenChanged

$candidates |
    Select-Object Name, ObjectClass, ObjectGUID, ObjectSid,
        sAMAccountName, lastKnownParent, whenChanged, DistinguishedName |
    Format-List

Treat $searchText as an exact controlled input and review escaping rules if identifiers can contain filter metacharacters. Broad wildcard queries can return many objects. Do not pipe an unreviewed Get-ADObject result directly into Restore-ADObject. Confirm object GUID, account identity, prior OU, owner, and deletion timestamp against the incident record. If more than one candidate matches, collect additional metadata and consult the object’s owner before choosing.

If the target is a group or privileged account, separately record the expected memberships, delegation, SPNs, logon restrictions, and application ACLs. If the deleted object has a replacement with the same name, do not assume the replacement and deleted object are interchangeable. Their SIDs and GUIDs can differ, and applications may still reference the prior identity. Plan whether the replacement should be retained, renamed, or removed as a distinct approved change.

Preview and restore deliberately

Restore-ADObject can return an object to its original parent or a specified target path. The default location may not be the intended OU after a reorganization or parent deletion. Choose a target that exists and has the correct policy, delegation, and administrative protections. Preview with -WhatIf, then restore one object at a time with an explicit identity and confirmation.

$server = 'DC01.contoso.com'
$objectGuid = [guid]'11111111-2222-3333-4444-555555555555'
$targetPath = 'OU=Service Accounts,DC=contoso,DC=com'

# Preview the exact target before writing to Active Directory.
Restore-ADObject -Server $server `
    -Identity $objectGuid `
    -TargetPath $targetPath `
    -WhatIf

# After owner approval and review of the preview:
Restore-ADObject -Server $server `
    -Identity $objectGuid `
    -TargetPath $targetPath `
    -Confirm

Replace the sample GUID and path with values from the verified candidate and recovery plan. If restoring to the original location, omit -TargetPath only after confirming that the original parent exists and is the correct security boundary. Restore deleted parent containers before children when required, or select an approved existing target OU. Do not restore many related objects through a broad filter without understanding their dependency and group-membership order.

Validate identity, membership, and security state

After the restore, query the object by GUID and verify it is no longer marked deleted, its distinguished name is correct, and key attributes match the approved pre-deletion state. For a user, check enabled state, UPN, account expiration, logon restrictions, group memberships, and any delegation settings. For a group, validate scope, type, members, nesting, and owner. For a computer, verify DNS, SPNs, secure-channel behavior, and whether a corresponding computer account has been recreated since deletion. Do not assume a restored computer account automatically repairs a broken machine secure channel.

Active Directory Recycle Bin preserves link-valued and non-link-valued attributes for restoration, including group membership relationships when the relevant objects and links are recoverable. Still verify membership explicitly, especially when groups or parent containers were separately deleted, modified, or recreated. Compare against a trusted backup, identity governance record, or pre-deletion audit log. A user regaining historical group memberships can regain access the incident team had intentionally removed.

Check replication to other domain controllers with repadmin /showrepl and query the restored object on a second DC after convergence. Verify the object appears in the intended OU and that group policy, authentication, application access, and name resolution behave as expected. For computer accounts, validate the machine’s domain secure channel and DNS registrations. For service identities, check service dependencies and SPN uniqueness before restarting applications.

The recovery is not complete merely because the object appears in Active Directory Users and Computers. Record the object GUID and SID, target path, restoration timestamp, performing account, change ticket, group membership comparison, replication evidence, and application validation. Monitor for duplicate names, stale DNS registrations, failed service logons, and unexpected access after the change.

Understand the boundary with backups and authoritative restore

Recycle Bin restores a deleted object within the directory’s supported lifecycle. It is not an authoritative restore of an entire OU or domain controller, and it does not restore files, policy content in SYSVOL, a certificate private key, application data, or a separate service dependency. A GPO, for example, has directory metadata and SYSVOL files; restoring only one side may leave the policy inconsistent. Use a coordinated backup restore procedure for multi-part objects and large-scale directory corruption.

If the feature was not enabled before deletion, or the object has expired from the recoverable lifecycle, stop before attempting ADSI edits or manual attribute changes. Use the supported system-state or forest-recovery procedure for the affected version and scope. Authoritative restore can have broad replication consequences and requires an AD DS recovery plan. Preserve current backups and involve the directory recovery owner; do not improvise ntdsutil steps from an unrelated version or recovery scenario.

Improve readiness and reduce recurrence

Enable and audit directory deletion monitoring according to the organization’s security policy. Alert on deletion of protected users, groups, OUs, GPOs, service identities, and domain controller objects. Maintain an object owner and recovery priority for critical identities. Keep system-state backups and forest recovery documentation current, and periodically rehearse a restore in an isolated lab with a representative object type.

Do not use Recycle Bin as a reason to relax least privilege or approval checks on object deletion. Use delegated OU administration, protected groups, change management, and service-owner validation. Document the recovery path in the identity incident response plan, including who may authorize privileged group restoration and how recovered access will be reviewed.

For sensitive restores, separate the authority to approve the identity recovery from the operator who performs the directory write. Require a second reviewer to confirm the GUID, prior parent, and requested target path. After replication, inspect not only direct group membership but also nested group paths and resource ACLs that may grant indirect access. Ask the service owner whether the restored object should remain enabled immediately; recovery of data and authorization to authenticate are separate decisions. Record any intentional difference from the pre-deletion state and schedule a post-incident access review.

Related:

Sources: