Active Directory recovery: Planning for worst-case scenarios

Only 36% of organizations have run an Active Directory (AD) security assessment in the past 12 months, according to The Netwrix 2026 Data and Identity Security Report. The same survey found 73% are not fully confident that their AD is free of misconfigurations that enable privilege escalation.

Microsoft Threat Intelligence reports that threat actors breach a domain controller in more than 78% of human-operated cyberattacks, exploiting the very gaps that unassessed environments leave open.

That makes AD disaster recovery an identity resilience problem, and the worst-case scenario is a forest-wide event in which every domain controller (DC) is down, replication is corrupted, or the backups themselves are encrypted.

A backup schedule and a recovery plan also prove different things. The schedule proves data exists somewhere. The plan proves the business can rebuild a working directory from that data under pressure, so a usable one defines the worst-case failures it must survive, the recovery sequence, and the test cadence that proves it works.

What is Active Directory disaster recovery?

Active Directory disaster recovery is the documented, sequenced process for restoring an entire AD forest after a failure that individual object recovery can't fix, such as a forest-wide outage, corruption, or compromise.

Forest recovery follows a strict, dependency-based sequence. The plan defines which domain controller comes back first, the order in which the team reassigns Flexible Single Master Operations (FSMO roles), and how it re-establishes replication without propagating corrupted data.

The term is applied loosely to anything from restoring a single deleted user account to rebuilding an entire forest, and the two require completely different plans. Restoring a single object from the AD Recycle Bin assumes the surrounding forest is healthy; full forest recovery starts from the premise that the forest itself is broken.

What do worst-case AD failure scenarios look like?

These AD failure scenarios compel organizations to pursue full forest recovery rather than routine troubleshooting.

Ransomware encrypting or wiping every domain controller at once

Ransomware operators now target domain controllers directly, and gaining highly privileged accounts lets attackers delete backups as part of the same operation. If backup DCs sit on the same network segment as production, the same attack that takes down AD can take down the backups meant to restore it. Microsoft's criterion for forest recovery is that all DCs are logically corrupted or physically damaged to the point that business continuity is impossible.

Maersk's 2017 NotPetya incident is the textbook version of this scenario. The malware wiped nearly every domain controller across Maersk's global network within an hour, and the company avoided a total loss only because one DC in its Accra, Ghana office happened to be powered off during a local blackout when the attack hit. That single surviving copy is what let Maersk rebuild the rest of its Active Directory forest, though Maersk's CISO later said the nine days it took to recover "isn't good enough." The broader rebuild eventually covered roughly 4,000 servers and 45,000 PCs, and Maersk estimated the total cost at up to $300 million.

A compromised admin account deleting OUs, GPOs, or entire subtrees

A rogue administrator with Domain Admin or Schema Admin privileges can make changes indistinguishable from legitimate operations in the replication stream. Without a known-good baseline from backup, no individual object restore can establish which changes were malicious.

The deletion of organizational units (OUs), Group Policy Objects (GPOs), or subtrees often goes unnoticed because it appears to be a normal administrative action. Persistence techniques that alter Kerberos tickets, SIDHistory, AdminSDHolder, or GPOs can remain inside the directory database unless the team restores from a trusted backup and validates the result.

Corrupted replication or a bad schema change propagating across every DC

An attacker or an administrator can run a script that spreads data corruption across the forest, or extend the schema with conflicting changes that replicate everywhere. By the time the error becomes visible, it may already exist on every domain controller in the forest, including those the recovery plan assumes are clean. The schema partition is forest-wide and shared by every domain, so a corrupted schema breaks operations across all domains at once.

A site-wide hardware failure or natural disaster with no geographically redundant DC

Microsoft's forest-recovery criteria focus on logical corruption and physical damage, and a single-site physical event produces the same outcome. Organizations that run every domain controller from a single site or data center risk losing the entire forest to a single fire, flood, or power outage, taking down production and any co-located backup DCs. Geographic redundancy is the primary structural defense against this class of failure.

A failed AD upgrade or migration that corrupts the schema mid-process

Beyond attack-driven failures, a schema modification can also leave the forest in an inconsistent state. Schema modifications replicate to all DCs and are largely irreversible under normal operations, so rolling back isn't always straightforward, and a corrupted or conflicting schema can break forest-wide operations for every domain simultaneously.

Why AD disaster recovery planning matters

Without a plan, every scenario above ends the same way, in improvisation, under pressure, with every dependent system already down.

Ransomware groups now target domain controllers and backups directly

Documented tactics show how far this has moved past endpoint encryption. Attackers now power down domain controller virtual machines to extract credential databases directly, and they transfer FSMO roles to rogue domain controllers they control.

The exposure shows up in survey data too. In the survey behind The Netwrix 2026 Data and Identity Security Report, 25% of organizations reported experiencing an incident in the past 12 months in which unauthorized identities accessed sensitive data.

A recovery strategy that assumes backups are automatically safe no longer matches how these attacks unfold.

Every dependent system goes down the moment AD does

Email, file access, VPN, and most business applications authenticate against AD, so downtime cost compounds by the hour across every dependent system. If identity, DNS, network, secrets, or databases aren't available, an application may restore but stay unusable, extending downtime beyond the stated recovery time objective.

First National Bank Minnesota felt that math directly and completed an Active Directory rebuild in three weeks with support from Netwrix Auditor, against an original estimate of six months.

Microsoft's forest recovery process is long, sequence-dependent, and unforgiving

The official Microsoft AD forest recovery guide covers the mechanical rebuild steps in depth and explicitly excludes security recovery after compromise, planning and governance, and reporting to leadership or insurers. One step performed out of order, such as skipping metadata cleanup or restoring domain controllers out of dependency order, can invalidate the rebuild and force a restart.

Boards and cyber insurers ask for a tested recovery time objective

A tested AD recovery time objective provides leadership, boards, and insurers with a specific metric to review. It reflects an actual restore performed under realistic conditions. A general statement that a disaster recovery plan exists provides less operational evidence than a dated restore test with measured phase times and completion criteria.

Untested plans fail during the actual incident

Gaps in a recovery plan surface fastest under real pressure, which is the most expensive possible time to discover them. Confidence and capability measure different things, and only testing reconciles them.

What an AD disaster recovery plan should include

Each component below states what it covers and why leaving it out breaks the plan when it matters most.

• Immutable, offline backups of system state on every domain controller: If backups reside on the same network as production, ransomware that took down AD can reach the copies intended to restore it. Air-gapped or immutable storage keeps recovery media outside the same failure path, and an AD-aware backup application avoids update sequence number (USN) rollback on restore.
• A documented, ordered rebuild sequence: Forest recovery has strict sequencing dependencies, and restoring DCs or reassigning FSMO roles out of order can further corrupt the forest rather than fix it. Microsoft notes there's no end-to-end automation native to the process, which puts the burden on an environment-specific plan.
• A tested recovery time objective (RTO) specific to AD: A backup schedule tells you data exists; an RTO tells you how long the business is down, which is the number leadership and insurers can review. Recovery Point Objective (RPO) sits alongside it, defining how much directory change you can tolerate losing.
• A defined communication and escalation plan for an AD outage: During a real AD outage, the tools teams normally use to coordinate, including email, Teams, and ticketing systems, are often down as well. The plan needs to specify how the team communicates without them, using contact trees stored offline and distributed in advance.
• Scheduled recovery drills or tabletop exercises: A plan the team has never rehearsed reveals its gaps during a live incident rather than during a controlled test. Periodic exercises build organizational muscle memory before the recovery team works under incident pressure.

Directory recovery software should support both operating modes, granular object repair and full forest rebuild, so one class of failure doesn't force the team onto a second tool mid-incident.

Directory recovery also depends on adjacent identity controls: zero standing privilege reduces persistent admin exposure before an incident, ephemeral admin accounts limit the lifetime of privileged credentials, and access certification keeps evidence of privileged access up to date.

How to build an AD disaster recovery plan that survives a worst-case scenario

Building the plan in the right order matters as much as what's in it. Each step below depends on the one before it, and skipping ahead produces a plan that looks complete but hasn't been stress-tested against dependencies.

1. Inventory your forest structure and every dependency first

Map every domain controller, FSMO role holder, trust relationship, and DNS dependency before writing a single recovery step. A plan built without this inventory will miss a dependency the moment it's actually needed. Microsoft's guidance treats the forest root domain DC list as the most important item because that domain gets recovered first.

Include global catalog servers, site links, and the replication topology, since these determine the order in which DCs come back online. Capture baseline repadmin /showrepl and dcdiag output alongside the inventory so the recovery team knows what healthy looked like.

Record the Domain Admin password and the Directory Services Restore Mode (DSRM) passwords for each domain now, because a system state restore requires them, and you can't retrieve them from a dead forest.

2. Set a dedicated AD recovery time objective outside the general DR plan

AD's RTO needs to be shorter than the RTO of every system that depends on it, since nothing else can fully recover until AD does. Microsoft's rule that you always recover a parent domain before a child means the forest root RTO gates everything downstream. Treating AD recovery as a line item in a broader disaster recovery plan usually understates how urgent it actually is.

Measure the AD RTO from failure declaration to the moment a functional forest root DC is restored and replication is confirmed. Every dependent application RTO should exceed that figure.

3. Write the rebuild sequence in order, and store it where AD can't lock you out

The sequence needs to specify which DC restores first, in what order FSMO roles get reassigned, and how replication gets re-verified. For the first writable DC in a domain, the runbook needs to cover each recovery action in this order:

1. Perform a nonauthoritative restore of Active Directory Domain Services (AD DS).
2. Complete an authoritative restore of SYSVOL, the shared system volume that stores domain scripts and Group Policy files.
3. Run metadata cleanup for DCs you aren't restoring.
4. Seize FSMO roles.
5. Invalidate the Relative Identifier (RID) pool and raise the available RID pool value by 100,000 to prevent reissuing RIDs consumed after the backup.
6. Reset the DC computer account password twice.
7. Reset the krbtgt password twice to protect the Kerberos Ticket Granting Ticket account, with a 10-hour wait between resets.

Write these steps clearly enough for the recovery team to follow them without normal AD-dependent tools. The plan itself has to live outside AD-dependent systems. A runbook stored on a SharePoint site that requires AD to authenticate is useless when AD is down.

4. Build immutable, air-gapped backups of system state

Backups need isolation from the production network so that whatever took down AD, whether ransomware or a compromised admin account, can't also reach the copies meant to restore it. Critical backups belong in separate storage protected from unauthorized modification.

Backup age also has to stay inside the forest's tombstone lifetime (180 days by default), because AD rejects restores from older media.

A backup made after a compromise can restore malware and attacker persistence alongside AD, since SIDHistory manipulation, AdminSDHolder changes, and malicious GPOs live inside the directory database. Isolation and clean-restore validation prevent the attacker from reintroducing themselves to the directory.

5. Assign clear ownership and a named escalation path

Name who executes each phase of recovery and who they escalate to if a step fails, so the plan doesn't stall waiting for someone to volunteer during the actual incident.

Without pre-built dependency inventories and named owners, recovery teams discover interdependencies reactively, under pressure, and without every original system architect available.

Assign a primary and a backup for each phase, and confirm that both know how to reach each other via the offline communication channels defined in the plan.

How to test an AD recovery plan before you need it

A recovery plan that has only ever existed on paper remains a hypothesis until testing proves it works.

1. Run a tabletop exercise before attempting a live failover test

Walk the team through the written plan step by step without touching production. Use a discussion-based exercise where personnel talk through their roles and responses to a specific emergency, with no equipment deployed. This surfaces gaps in ownership and sequencing before any system is at risk, and its findings sharpen the scope of the subsequent live drill.

2. Restore a forest in an isolated test environment on a set cadence

A tabletop checks the plan's logic. Only a real restore in an isolated environment checks whether the backups and rebuild sequence actually work.

Microsoft recommends moving virtualized DCs to a virtual network isolated from production and using production backups in the lab, so the test proves the real recovery data restores. Microsoft recommends this drill at least annually and again whenever Enterprise Admins or Domain Admins group membership changes.

3. Measure the actual recovery timeline

The RTO in the plan is only valid once measured against a real test restore. An unverified number is a guess. Record the actual time per phase, covering isolation, restore, FSMO seizure, and replication verification, so the plan reflects what the team can genuinely execute.

Help Net Security reported in 2024 that only 6% of enterprises can recover AD in under an hour, which means most stated RTOs are well above what teams assume. Gate completion on dcdiag, running clean; SYSVOL and NETLOGON shares exist, and DNS is running healthy.

4. Update the plan every time the forest topology changes

A new domain controller, a schema change, or a new trust relationship can invalidate parts of the rebuild sequence, so the plan needs a trigger-based review cadence in addition to any annual review. Changes to FSMO role holders, site topology, or replication links are the most common sources of plan drift.

Add migrations, upgrades, and new application deployments to the trigger list, since each can introduce a dependency that the existing sequence doesn't account for. Every triggered review should end with an updated inventory and, where the change touches topology, trusts, or the schema, a fresh restore test.

How Netwrix supports Active Directory recovery

Netwrix Identity Recovery covers both recovery modes, which this plan distinguishes. For object-level incidents, it keeps a timeline of directory changes and rolls back deleted or modified users, groups, GPOs, and DNS records to a known-good state without touching the rest of the forest.

For the worst-case scenarios above, it automates the full AD forest recovery sequence. Coverage extends to Entra ID and Okta, so hybrid identity recovers under the same runbook.

Recovery decisions also depend on evidence, because the first question in a compromise is which backup predates the attacker.

Netwrix Auditor supplies that context through continuous AD change auditing, showing who changed what and when, with before-and-after values that separate malicious changes from legitimate ones. Its state-in-time reports compare the directory's configuration between two points in time, which is how a team pins down when the compromise began and which backup predates it.

Cheshire County Government used Netwrix Auditor to investigate a 27,000-file change incident in 15 minutes, the evidence speed a recovery team needs while the directory is down.

Running drills and real incidents on the same tooling keeps every phase comparable, so the RTO measured in the isolated lab is the same number the team defends to leadership.

Turn your AD recovery plan into a tested, working process

Real readiness comes down to evidence that leadership can review. That means a dated restore test, a measured AD RTO, a known-good backup set inside the tombstone lifetime, and a runbook that names owners for every recovery phase.

The package answers the questions boards, auditors, and cyber insurers now ask, and it holds up because each item comes from a rehearsal rather than an assertion.

The first isolated restore surfaces the missing DSRM password, the dependency nobody inventoried, and the phase that blows the assumed RTO. The second drill runs cleaner and produces a number the business can plan around. From there, trigger-based reviews keep the plan aligned with the forest as domain controllers, trusts, and schema evolve, so the gap between the documented plan and the real environment never widens back into risk.

Request a demo to see how Netwrix Identity Recovery handles forest rebuilds, granular rollbacks, and recovery drills on your own topology.