AD Recycle Bin: test recovery with evidence

09 November 2026 · Active Directory · AD-Hardening · Recovery · Permissions · Operations

The OU is visible again, but the application denies access

AD Recycle Bin is enabled, an accidental deletion is detected and the affected OU is restored. The structure initially looks correct in the management console. Yet users are missing, a permission group is empty or the business application still denies access. Completing a directory restore and recovering the service are two separate acceptance milestones.

This article assumes AD Recycle Bin is already enabled. It focuses on a controlled recovery test for deleted OUs, users and groups. The initial deployment is extended with concrete evidence: which identities and relationships have returned, which dependencies remain missing and when can the service actually be used again?

Define identity and access as acceptance criteria

The objective is to restore the original objects. Creating a new user with the same name produces a different identity and is not an equivalent replacement. Compare objectGUID, the SID for security principals, the intended parent path and relevant attributes against a protected baseline.

Add business acceptance tests: the test account must access an approved resource while remaining unable to access an explicitly excluded resource. Define the maximum recovery time, responsible people and conditions for stopping the procedure. A command returning successfully does not, by itself, satisfy those criteria.

Prepare a bounded test scope and a baseline

Prefer an isolated test environment. A production pilot requires an explicitly approved scope containing synthetic accounts without production service dependencies. Useful cases include a single user, a group with members and a small nested OU structure. Controlled test deletion belongs in a separately approved procedure; broad deletion scripts are inappropriate.

Record GUIDs, SIDs, original paths, direct group memberships, nested groups, relevant ACLs and OU links to GPOs beforehand. Also record account state and expected access. The baseline needs access protection and an owner; passwords belong in neither this export nor support tickets.

Check replication, DC connectivity and administrative access before testing. Keep restore permissions limited and test them in advance. Permanent Domain Admin membership for the entire help desk is not an appropriate substitute for a defined role model.

Verify the recovery window actually available

Recycle Bin helps with objects deleted after it was enabled that remain in a recoverable state. Check the configured msDS-deletedObjectLifetime and its fallback relationship to tombstoneLifetime; do not assume a universal 180 days based on another environment. Document the effective value, along with detection and escalation for accidental deletion.

While an object is in the deleted state, the attributes and relationships needed for recovery are retained. After it transitions to the recycled state, Recycle Bin can no longer restore it. Appearing in a search for deleted objects is therefore insufficient evidence of recoverability. isRecycled can be absent on an object that is still recoverable; do not require an explicit False value.

Identify the object by its recorded GUID instead of a broad name filter. The following example only reads metadata. Replace the example DC and GUID with the approved test values and use an administrative workstation with the ActiveDirectory module.

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'
Import-Module ActiveDirectory

$dc = 'dc01.example.com'
$objectGuid = [guid]'f6830908-5dbc-4b4c-9bbd-fc683073c60a'

Get-ADObject -Identity $objectGuid -Server $dc `
    -IncludeDeletedObjects `
    -Properties isDeleted,isRecycled,lastKnownParent,'msDS-LastKnownRDN' |
    Select-Object ObjectGUID,ObjectClass,isDeleted,isRecycled,
        lastKnownParent,'msDS-LastKnownRDN'

Restore parent OUs first and select objects precisely

When a hierarchy has been deleted, the required parent containers must exist before their children can be restored. Recover the highest missing OU, followed by its subordinate OUs and then their objects. In Active Directory Administrative Center, restoring an OU does not recursively restore its children. Refresh the view and explicitly work through each level.

Check the original path, object class and naming conflicts for each object. Use a writable DC for the controlled procedure and specify it consistently. An RODC is not a restore target. Preview the intended action for one selected object:

Restore-ADObject `
    -Identity ([guid]'f6830908-5dbc-4b4c-9bbd-fc683073c60a') `
    -Server 'dc01.example.com' `
    -WhatIf

-WhatIf performs no restore and cannot replace a functional test. Only after verifying the object, the existing parent container and potential conflicts should you execute the same approved single-object operation without -WhatIf and with -Confirm. Avoid unchecked pipelines that restore every object returned by a search.

A different -TargetPath or -NewName can resolve a conflict, but it changes the result. A different parent path can introduce different permissions and policies. These deviations require a separate decision and renewed acceptance testing.

Verify group relationships and fresh sign-in sessions

After restoring all participating objects, compare relationships against the baseline. Check direct membership, nested groups and the primary group separately. A single memberOf query does not prove effective authorization. If both users and groups were deleted, assess the outcome only after both endpoints have been restored and the changes have replicated.

Then compare ACLs, account state and actual access. Recovery can also return permissions that existed previously but are no longer wanted. Reconcile the original state with the currently approved target before returning the identity to production use.

Use a fresh sign-in session for application testing. Old access tokens, existing Kerberos tickets or an application session that remains open can distort the results. Test successful sign-in and permitted access alongside the required access denial. Record results and timestamps, without recording secrets.

Accept replication, policies and downstream systems separately

Check the restored objects on another relevant DC after replication completes. In distributed environments, acceptance must include the DCs actually used at the affected sites. A successful restore on one DC does not establish consistent availability.

Compare GPO links on the OU and the policies actually applied to the test device. A GPO contains both AD components and files in SYSVOL. Restoring an OU or an AD object does not recover deleted SYSVOL files. Missing GPOs require their own protected recovery procedure.

Microsoft Entra synchronization, provisioning and applications need separate acceptance checks. An AD restore does not guarantee recovery of resources deleted in the cloud. Coordinate the procedure with their owners. Event 5138 can support the audit trail, provided Audit Directory Service Changes and the appropriate create SACL on the destination container are configured. Validate the event and its forwarding in practice.

Benefits of a rehearsed recovery procedure

Identity, relationships and access are verified instead of checking object visibility alone.
Problems involving sequence, delegation and naming conflicts are discovered before a real outage.
Measured recovery times make emergency planning more credible.
Repeatable tests reveal whether changes to OUs, groups or applications affect the procedure.

Disadvantages and limits of the procedure

Maintaining the baseline, test accounts and application acceptance cases requires ongoing work.
Recycle Bin depends on a usable AD environment and an open recovery window. It replaces neither protected backups nor a rehearsed forest recovery process.
It restores deleted objects; it does not roll back unwanted changes to objects that still exist.
Restored attributes and permissions are not automatically safe. A security incident requires a separate assessment of possible compromise.

Common pitfalls and project checklist

Frequent mistakes include treating a new identity with the same name as a successful restore, overlooking an OU's children and testing applications through old sessions. Also verify protection against accidental deletion after the test. It reduces operator error, but does not replace restricted change permissions or reliably prevent an attacker with sufficient privileges from deleting objects.

[ ] Test scope, owners and approval documented.
[ ] GUIDs, SIDs, hierarchy, relationships and access recorded beforehand.
[ ] Effective recovery window and object state checked.
[ ] Parent containers restored before children; conflicts assessed individually.
[ ] Identities, group relationships and ACLs compared with baseline and target state.
[ ] Replication and fresh positive and negative access tests passed.
[ ] GPO/SYSVOL, synchronization and application dependencies checked separately.
[ ] Audit evidence, deletion protection, measured duration and next exercise documented.