Planning an Active Directory forest recovery before you need it

Most disaster recovery plans I have read contain a dependency they never state: that Active Directory is available. The application recovery runbook assumes someone can authenticate. The backup console assumes a directory to log into. The documentation itself is often on a file share that needs a domain account to reach.

Forest recovery is the plan that has to work when that assumption fails. It is rarely written, almost never rehearsed, and the reason both are true is that it is genuinely difficult to write and requires a lab to rehearse. That does not make it optional.

Requirements: know which disaster you are planning for

Three failure modes get confused, and they have different answers. Establishing which one you are in is the first decision in the incident, so make it a decision you have already thought about.

A single domain controller has failed. This is not a recovery. Demote it, clean up metadata if it will not demote, and build a new one. A domain controller is a replica. Restoring one from backup when healthy peers exist introduces risk — chiefly USN rollback — for no benefit.

Something was deleted or changed incorrectly and replicated. This is an object-level recovery. The Active Directory Recycle Bin handles deletions if it is enabled, and an authoritative restore handles cases it cannot. The forest is healthy; you are repairing contents.

The forest itself is untrustworthy. Every domain controller is compromised, unrecoverable, or holding corrupted data that has replicated everywhere. There is no healthy peer to replicate from. This is forest recovery, and it is the only one of the three where you deliberately isolate and rebuild rather than repair.

Ransomware is what makes the third case realistic for ordinary organisations. If an attacker reached Tier 0, the forest is not a victim of the incident — it is the mechanism of it, and restoring it as-is restores their access with it.

Design: the decisions to make now

Which domain controller is your restore source

Forest recovery starts from a single restored domain controller per domain, and everything else is rebuilt from it. Decide in advance which one, and write down why.

The choice should favour a domain controller that holds a full copy of the domain, is not a read-only domain controller, and ideally holds the forest root’s operations master roles — though you can seize roles afterwards. In a multi-domain forest, restore the forest root domain first.

What you are actually backing up

You need system state backup of at least one writable domain controller per domain, and it must be a real system state backup rather than a file copy or a virtual machine snapshot.

Two constraints bite here:

Backups older than the tombstone lifetime are useless. A system state backup cannot be restored once its age exceeds the tombstone lifetime, which defaults to 180 days in forests built on Windows Server 2003 SP1 or later. Your retention must comfortably exceed your detection time for a slow compromise, and for most organisations that means retaining considerably longer than a fortnight.

Snapshots are not backups for this purpose. Reverting a domain controller virtual machine outside of a supported restore path is what produces USN rollback and a directory service that correctly refuses to write. Virtualisation-safe restore exists on supported hypervisors via the generation identifier, but a plan that says “revert the snapshot” is a plan to create a second incident.

Store at least one copy offline or otherwise out of reach of a domain credential. A backup system that an enterprise administrator can delete is not a recovery position against an attacker who has become an enterprise administrator.

Where the recovery happens

Recovery must happen in an isolated network. Not “mostly isolated” — genuinely disconnected from the production network and from anything that might still be compromised. The restored domain controller will be running with no replication partners and with services you have deliberately disabled, and it must not meet a surviving compromised host during that window.

Decide now where that environment comes from. An isolated virtual network with enough capacity to stand up a domain controller, a DNS server and a management host is the usual answer. Obtaining it during the incident is not.

What the plan is written on

The forest recovery plan cannot live on a domain-joined file share, in a wiki behind directory authentication, or in a password manager that federates to the directory you are recovering. Neither can the credentials it needs.

You need, available offline: the plan itself, the Directory Services Restore Mode password for the chosen domain controller, local administrator credentials for the recovery hosts, the backup system’s credentials, and the details of your forest — domains, operations master role placement, trusts, sites, and the service accounts that will need attention. Print it or keep it in a sealed offline store, and review it on a schedule.

Deployment: the shape of the recovery

The full procedure is long, version-specific, and Microsoft maintains it properly in the Active Directory forest recovery guide. Follow that document during an incident rather than a summary. What is worth internalising beforehand is the shape, because the shape is what tells you whether your preparation is adequate:

Isolate. Disconnect the recovery environment. Nothing from production reaches it.
Restore one domain controller per domain from system state backup, into isolation. For the forest root first.
Bring it up in Directory Services Restore Mode, then perform a non-authoritative restore of the directory and an authoritative restore of SYSVOL.
Stop it replicating and stop it advertising. The restored controller must not replicate with anything that survived, and clients must not find it until you are ready.
Seize operations master roles, because the holders are gone.
Clean up metadata for every domain controller that no longer exists — which, in a forest recovery, is all of them.
Raise the RID pool to avoid reissuing identifiers that the lost controllers had already allocated. Skipping this produces duplicate security identifiers later, and it is the step most often missed.
Reset the krbtgt account password twice, and reset trust passwords. Two resets are required because the account keeps its previous password, and one reset leaves tickets issued with the old key still valid.
Reset privileged account credentials, and the passwords of service accounts.
Rebuild the remaining domain controllers by promotion, never by restoring more backups. Additional restores reintroduce the divergence you are recovering from.
Reconnect and validate before returning the forest to service.

Steps 7 and 8 are the two I would highlight to anyone writing this plan for the first time. They are easy to omit, they cause no immediate symptom, and both produce serious problems weeks later.

Validation: rehearsal is the whole point

An unrehearsed forest recovery plan is a document, not a capability. The rehearsal does not need production data — it needs your actual backup, your actual tooling and your actual people.

Rehearse in an isolated lab with a real system state backup from a real domain controller. Measure three things:

Elapsed time to a usable domain controller. This number belongs in your business continuity plan, and it is almost always longer than the plan currently assumes.
Which steps were ambiguous. The rehearsal’s main output is a corrected plan.
What you could not reach. Credentials, documentation and tooling that turned out to depend on the directory. This is the most valuable finding and the one that only appears during a rehearsal.

Repeat annually, and after any significant change to the forest, the backup product or the hypervisor.

Operations: what keeps the plan valid

Enable the Active Directory Recycle Bin if it is not already on. It is irreversible once enabled, it requires a Windows Server 2008 R2 or later forest functional level, and it turns the most common object-deletion incident into a routine restore rather than an authoritative restore from backup. There is no good reason to leave it off.

Keep the operations master role placement, trust inventory and site topology documented alongside the plan, and update them when they change. Recovery depends on knowing what you had.

Verify backups by restoring them, on a schedule. A backup job reporting success is a claim about a job, not about a restore.

Finally, keep the Tier 0 boundary real. Forest recovery is the consequence of a Tier 0 compromise, and the administrative tiering work is what makes it unlikely. Recovery planning and tiering are the same programme viewed from different ends.

Rollback and honest limits

There is no rollback from a forest recovery. Once you have seized roles, reset krbtgt twice and cleaned metadata, the pre-recovery forest is gone. That asymmetry is why establishing which of the three failure modes you are in is the first and most consequential decision.

This article is a planning framework. It is not the recovery procedure, and it should not be used as one — the detailed steps are version-specific and Microsoft’s guide is the authoritative source. It also does not address recovery of a compromised hybrid identity estate, where Microsoft Entra ID, Entra Connect and federation each need their own treatment, or the forensic question of how the compromise occurred, which usually needs to be answered before the forest returns to service.

Verification and limits

The recovery sequence, tombstone lifetime constraints, krbtgt double-reset requirement, RID pool handling and Recycle Bin prerequisites were checked against current Microsoft documentation on 20 September 2026.

No procedure here was executed in a lab for this article, and I would not want anyone to treat it as a tested runbook. Its purpose is to make you build and rehearse your own, using Microsoft’s guide and your own environment. Enabling the Recycle Bin cannot be undone; confirm your forest functional level and read the current documentation before you do it.