Active Directory and Entra ID Recovery Guide

When Active Directory or Entra ID is destroyed, corrupted or controlled by an attacker, nothing else can be recovered safely until the identity plane is trusted again. Domain controllers hold every password hash, Entra ID gates every cloud application, and the sync and federation servers between them carry compromise from one to the other. This guide covers the recovery mechanics: choosing the right recovery path, the backups that make it possible, Microsoft's forest recovery sequence, Entra ID soft delete and configuration recovery, rebuilding Entra Connect, and the credential resets that evict an attacker. It is written for identity engineers, incident responders and infrastructure teams who will run or rehearse the recovery.

Key takeaways

• Match the recovery to the failure. A deleted user, a dead DC, a corrupted forest and a compromised forest need different procedures; forest recovery is the last resort.
• Restore one writable DC per domain, in isolation. Microsoft's sequence is a nonauthoritative restore of AD DS with an authoritative SYSVOL restore, seizing all FSMO roles, metadata cleanup, a RID pool increase of 100,000 and two krbtgt resets.
• Entra ID only keeps some objects. Users, groups, applications and service principals sit in the recycle bin for 30 days; most other objects are hard deleted immediately, and misconfigurations are not deleted at all, so configuration needs its own backup.
• Sequence hybrid recovery deliberately. Decide whether cloud or on-premises is the trusted source, keep Entra Connect in staging or rebuilt from a clean configuration, and only let one sync server export.
• Eviction is a credential event. krbtgt, trust passwords, DC computer accounts, gMSAs and their KDS root key, AD FS signing certificates and service principal secrets all need resetting, or the attacker returns with keys you restored for them.

Choose the recovery path before you restore anything

A forest recovery for a deleted OU wastes days; an object restore after a tier 0 compromise leaves the attacker in place. Classify the event first.

Backups that make identity recovery possible

Microsoft's forest recovery guide sets backup requirements that are easy to miss until the day they matter.

• Coverage: back up at least two writable DCs in every domain. Name a preferred restore DC per domain: writable, running DNS, ideally a virtual machine on a hypervisor supporting VM-GenerationID so it can be the cloning source.
• Type: keep both a full server (bare metal) backup and a system state backup. The wbadmin start systemstaterecovery -authsysvol path that restores AD DS and marks SYSVOL authoritative in one step needs a backup that explicitly includes system state.
• Useful life: with the AD Recycle Bin enabled, a backup's useful life is the shorter of deletedObjectLifetime and tombstoneLifetime. Older backups cannot be restored safely.
• Secrets for the restore: archive the Directory Services Restore Mode (DSRM) password and the built-in Administrator password history for as long as the backups are valid. A system state backup restores the DSRM password that was current when it was taken, so a password rotated last month will not open a backup from last quarter.
• Restore target: restoring system state to a new Windows installation on new hardware is not supported. Plan a full server restore first, then the system state restore.
• Inspection: Dsamain.exe exposes a backup or ntdsutil snapshot as an LDAP server, so you can find the last good state without booting a DC into DSRM.
• Protection: a system state backup contains NTDS.dit, so whoever can read it holds every hash in the domain. Keep identity backups immutable, encrypted and administered from a separate identity. See the Backup Security and Immutable Backup Guide and the Credential Dumping Guide.

ATT&CK Inhibit System Recovery (T1490) covers deleting shadow copies, the Windows Backup Catalog and online backups, and the NCSC tells responders to "Assume backups may have been targeted by attackers".

Active Directory forest recovery, step by step

Microsoft's AD Forest Recovery guide covers DCs running Windows Server 2012 to 2022 and is meant to be turned into your own plan. The core sequence for the first writable DC in each domain, starting with the forest root and working parent before child, is:

1. Shut down every writable DC, especially FSMO holders, so bad data cannot replicate back. Read-only DCs can keep running; rebuild them all afterwards.
2. Isolate the restore target: unplug the physical NIC or move the virtual NIC to an isolated network.
3. Restore: a nonauthoritative restore of AD DS and an authoritative restore of SYSVOL, by full server recovery plus authoritative DFSR sync, or by system state recovery with -authsysvol. Do the authoritative SYSVOL restore only on the first DC in each domain.
4. Verify the data; if damaged, restore a different backup. If the DC held a FSMO role, set HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations (REG_DWORD) to 0.
5. Seize all FSMO roles on the first forest root DC (domain roles only in child domains).
6. Clean up metadata of every writable DC you are not restoring. Until that is done a former RID master will not resume the role: watch for event ID 16648 (success) or 16650 (failure) in the System log.
7. Fix DNS: point the forest root DC at itself, delete NS and SRV records for removed DCs (nltest /dsderegdns:server.domain.tld speeds this up).
8. Raise the RID pool by 100,000 and invalidate the current pool, so the DC cannot reissue RIDs handed out after the backup. The next object creation fails once by design.
9. Reset credentials: the DC's computer account password twice, krbtgt twice, and trust passwords on one side of each trust if the recovery follows a breach.
10. Remove the global catalog in a multi-domain forest to avoid lingering objects, then add it back later and confirm with event ID 1119.
11. Set the PDC emulator in the forest root to an external time source.
12. Validate on an isolated common network with repadmin /replsum, repadmin /viewlist *, nltest /dclist:<domain> and dcdiag /v, then reconnect and promote or clone the remaining DCs.

Rollback point: until step 13 nothing touches production. If validation fails, discard the DC and restore an earlier backup.

Recovering from compromise, not just failure

Forest recovery after a fire and after an intrusion share the same mechanics, but compromise adds a security pass that Microsoft says should finish before additional DCs are installed: reset every account in Enterprise Admins, Domain Admins, Schema Admins, Server Operators and Account Operators, reset krbtgt, and replace gMSA passwords. Where a writable DC database was exposed, create a new KDS root key and recreate gMSAs, because the attacker can derive their passwords.

One krbtgt reset leaves the old password in history, so forged tickets still validate; ATT&CK's Golden Ticket mitigation also says to reset twice. Do not delete the krbtgt_<number> accounts of read-only DCs you intend to recover. For AD FS, Microsoft warns that "rotating the Token Signing certificate a single time would still allow the previous Token Signing certificate to work". The SolarWinds compromise is the reference case for forged SAML tokens surviving password resets.

Restore or rebuild: restore when you can name a backup taken before initial access and show it holds no attacker accounts, ACL changes, GPOs or SID history. Build a new forest when the intrusion date is unknown or persistence predates every backup; it takes weeks to months and touches every application.

Recovering Entra ID objects and configuration

Entra ID has no forest to restore, and less to restore from than most teams assume.

• Entra Backup and Recovery: daily backups that Microsoft says no user or application, "even with the highest admin privileges", can turn off, delete or modify. It needs Entra ID P1 or P2 and a workforce tenant. Grant Microsoft Entra Backup Administrator through PIM (Backup Reader is enough for review) and read the difference report before every recovery.
• Synced objects: for objects whose source of authority is AD DS, Microsoft says to use an alternative solution, which in practice means your AD backup and Entra Connect.
• Longer-term configuration backup: export with Microsoft Graph or the open-source Microsoft Entra Exporter into a version-controlled repository with restricted access. Keep TCM snapshots and Graph exports separate, as Microsoft advises, because they cover different scopes.
• Dependencies: a Conditional Access policy depends on the users, groups and service principals it targets. Restoring the policy without its exclusion group can lock out administrators, which is why recovery starts with break-glass access. See the Break-Glass Account Guide and the Conditional Access Guide.
• Prevention that helps recovery: apply protected actions to hard deletion and Conditional Access changes, and stream the audit log to a SIEM. It does not record a deleted group's type, so document it.

Hybrid sequencing and rebuilding Entra Connect

In a hybrid estate the order of recovery decides whether a bad state on one side overwrites a good state on the other.

1. Decide which side is trusted. If the cloud tenant is intact and on-premises is compromised, Microsoft's highest-assurance option is to remove federation trust and switch to cloud-mastered authentication while on-premises is remediated.
2. Stop exports. Put the active Entra Connect server into staging mode (it then exports nothing and runs no password hash sync or writeback), or shut it down so it cannot "regain access unexpectedly".
3. Recover AD as above, inside the isolated environment.
4. Rebuild Entra Connect from clean media. The sync engine stores no object state and rejoins objects on sourceAnchor. Reapply custom filtering and sync rules from an exported configuration before the first sync, and reset the AD DS connector account.
5. Preview before export. Enable prevent accidental deletes, run a full import and sync in staging, and verify pending exports. Microsoft warns that switching a server to active without doing so "can have a severe impact".
6. Go active-passive only. Confirm Get-ADSyncScheduler shows StagingModeEnabled True on every other server. Password hash sync catch-up can take hours; do not restart the sync services meanwhile.

Treat the sync server as tier 0: it holds credentials that write to both directories. See the Active Directory and Entra ID Hardening Guide.

Clean-room recovery and validating trust

The NCSC calls trusted identity "a critical dependency for recovery" and warns that recovering before eviction "carries a risk of the incident restarting". Recover identity in an isolated environment with its own admin accounts and MFA, from a trusted device such as a privileged access workstation. The Ransomware Response and Recovery Guide covers the clean room itself; validate these before reconnecting:

• Directory health: clean dcdiag /v, and no rogue or unexpected DCs in nltest /dclist.
• Persistence sweep: privileged group membership matches the documented baseline; AdminSDHolder ACL, DCSync rights, GPOs linked to the Domain Controllers OU, SID history and unconstrained delegation reviewed against known-good.
• Cloud side: no new federated domains ("Set domain authentication" events), no unexpected credentials on service principals, no new high-privilege consent grants, Conditional Access matching the export.
• Credentials: every reset in the next section completed and logged.
• Outside parties: the NCSC notes partners "may require independent assurance or evidence of compromise remediation before restoring connectivity", so build the evidence pack as you validate.

Where identity fits: rotating non-human credentials

A domain admin can read most machine credentials, and a restored backup brings them all back. Human password resets alone do not evict an attacker holding these:

• Directory secrets: krbtgt (twice), trust passwords, DC computer accounts (twice), the KDS root key and gMSAs, DSRM passwords on every DC.
• Service accounts: reset passwords of every account that runs a service or scheduled task, and move what you can to gMSAs once the new KDS root key exists. See the Service Account Security Guide.
• Cloud workload credentials: client secrets and certificates on app registrations and service principals, including ones the attacker added. The Microsoft Midnight Blizzard breach shows how an overlooked test tenant and an OAuth application kept a path open.
• Federation and sync: AD FS token-signing and decryption certificates, the Entra Connect AD DS connector account, and any account with replication rights.
• Secrets held elsewhere: vault, pipeline and script credentials readable from compromised servers. See the Secrets Management Guide.

Preparing the capability: a phased approach

1. Inventory (weeks 1 to 2): forests, domains, trusts, FSMO holders, DCs, Entra tenants including test tenants, sync and federation servers, DSRM password storage.
2. Backups (weeks 2 to 6): system state and full server backups of two writable DCs per domain, immutable and under a separate identity; daily Entra configuration export to a repository; Entra Backup and Recovery enabled where licensed; Entra Connect configuration exported after every change.
3. Runbook (weeks 4 to 8): adapt Microsoft's guide with real server names, commands and decision owners; pre-stage an isolated network.
4. Test in a lab (quarterly): restore the forest root DC into an isolated lab through to dcdiag, then destroy it; restore a test user and Conditional Access policy in a test tenant.
5. Rehearse compromise (annually): run the double krbtgt reset and gMSA recreation in the lab, and a tabletop of the hybrid sequence with the business.

Small vs large organisations: a single-domain forest can recover in hours from one well-tested virtual DC backup, with Entra Backup and Recovery plus a Graph export covering the cloud. Multi-domain, multi-site forests need a restore DC per domain, parent-before-child sequencing and scripted metadata cleanup; plan for days.

Detection and measurement

Monitor continuously during recovery, as Microsoft's responder guidance stresses: events 16648, 16650 and 1119, privileged group changes, Entra "Delete" events, Conditional Access changes and new service principal credentials, sent to a SIEM workspace the attacker cannot reach. See the ITDR Guide.

• Time to first healthy DC in the last lab test, against your recovery time objective.
• Backup coverage: domains with two verified, in-life writable DC backups.
• Restore success rate for quarterly DC and Entra object restore tests.
• Configuration drift: Conditional Access and tenant settings differing from the export without a change record.
• Credential reset completeness: share of the NHI rotation list done within the eviction window in rehearsals.

Common failure patterns

• DSRM password unknown: the backup restores an old DSRM password nobody archived.
• Single krbtgt reset, or two in quick succession: forged tickets keep working, or legitimate ones break before the old password has aged out.
• Old sync server left running: a forgotten Entra Connect server reconnects and exports stale objects over the recovered tenant.
• Restoring the attacker's backup: the newest backup is chosen without checking the intrusion timeline.
• Cloud configuration assumed recoverable: a hard-deleted object or a policy changed more than seven days ago has no native restore, and no export exists.
• Recovering production only: test tenants, secondary forests and trusted partner domains keep the attacker's access, as in the Midnight Blizzard case.

Framework mapping

Practitioner checklist

• Classify every identity incident against the recovery path table before restoring anything.
• Keep system state and full server backups of two writable DCs per domain, immutable and inside the useful backup life.
• Archive DSRM and built-in Administrator passwords for the life of each backup.
• Maintain a forest-specific runbook covering FSMO seizure, metadata cleanup, the RID pool increase and DNS cleanup.
• Reset krbtgt twice, 10 hours or more apart, plus trust passwords and DC computer accounts after any compromise.
• Create a new KDS root key and recreate gMSAs where a writable DC database was exposed.
• Export Entra configuration and Conditional Access policies daily to a restricted, version-controlled repository; enable Entra Backup and Recovery where licensed.
• Keep Entra Connect recoverable: exported configuration, a staging server or rebuild runbook, prevent accidental deletes enabled.
• Rotate every non-human credential readable from compromised tier 0 systems, including in test tenants.
• Restore a DC and an Entra object in a lab every quarter and record the time taken.

Standards and references

• Microsoft Learn: AD Forest Recovery, Perform initial recovery
• Microsoft Learn: AD Forest Recovery, Determine how to recover
• Microsoft Learn: AD Forest Recovery, Reset the krbtgt password
• Microsoft Learn: Recoverability best practices in Microsoft Entra ID
• Microsoft Learn: Microsoft Entra Backup and Recovery overview
• Microsoft Learn: Microsoft Entra Connect Sync, staging server and disaster recovery
• NCSC: Recovering from a highly disruptive cyber attack, Recovery and ongoing investigations
• Microsoft Security: Advice for incident responders on recovery from systemic identity compromises

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Ransomware Response and Recovery Guide · Break-Glass Account Guide · Backup Security and Immutable Backup Guide · Business Continuity and Disaster Recovery Guide