Restoring an Active Directory object is not the same as recovering the person’s or service’s identity. The object may return while group access, cloud linkage, mailbox, certificates or application references remain broken.
Preserve evidence first
Record who reported the deletion, time window, affected object type/path and suspected cause. Preserve AD auditing, replication and sync logs. If deletion may be malicious, contain privileged access and treat restoration as part of an identity incident.
Do not immediately recreate a user with the same name. A new object gets a new SID/GUID and can complicate recovery of the original relationships.
Check the recovery capability
Determine whether Active Directory Recycle Bin was enabled before the deletion and whether the object remains inside the deleted-object lifetime. Recycle Bin is not enabled by default; enabling it is forest-wide and irreversible, and it only improves recovery for objects deleted after enablement.
If the object is already recycled/purged or Recycle Bin was not enabled, move to a tested system-state/authoritative-restore or application-specific recovery plan. Do not promise that a name search can recover it.
Identify the exact object
Use immutable identity and deletion metadata: object GUID, SID, last known distinguished name, deletion time and parent. Confirm the object has not been intentionally replaced or renamed elsewhere.
For users, also capture cloud immutable/anchor identity, mailbox/device relationships and HR status. For groups, capture scope/type, owners and access purpose. For computers/services, capture machine/service account consequences.
Restore in dependency order
For a single object with an existing parent, restore through AD Administrative Center or an exact Restore-ADObject selection.
For a deleted OU/tree, restore parents before children. Microsoft notes that ADAC cannot reliably restore every subtree in one action when parents are missing or partial selections fail. Build a depth-ordered plan and verify each parent before proceeding.
Restore users and group objects before relying on membership links. Complex deleted security-principal/group combinations may require repeated relationship reconciliation under Microsoft’s procedure.
ADAC handles deleted objects in domain partitions; some Configuration or DNS partition objects require PowerShell and specialised recovery. Do not treat every deleted object as a user-container restore.
Verify directory identity
After normal replication, read the restored object from multiple DCs. Confirm GUID, SID, path, enabled state, UPN/account name, manager and only the required attributes. Check group memberships in both directions and access to a synthetic resource.
Do not enable an account or reset credentials until the owner and security state are confirmed. A malicious deletion/restoration incident may require password, token, key or certificate rotation.
Reconcile downstream systems
Check identity sync/export for a match rather than a duplicate. Verify mailbox, licence, Teams/SharePoint ownership, endpoint/device association, certificate mapping, file ACLs and line-of-business application records as applicable.
A cloud soft-deleted object can have its own restore lifecycle. Prevent the synchronisation engine from creating a second identity or hard-matching the wrong object.
Close the cause
Confirm how deletion occurred, correct excessive delegation or automation, enable/validate auditing and add deletion protection where appropriate. Test Recycle Bin and system-state recovery regularly.
Recovery is complete when the original security identity and intended relationships work again, every downstream exception is owned and the cause cannot silently repeat—not when the display name returns to a console.