## Why Active Directory Recovery Deserves Its Own Runbook
For many organizations, Active Directory is not just a directory. It is the control plane for identity, file access, line-of-business applications, VPN authentication, endpoint management, email access, privileged administration, and often cloud identity synchronization. When Active Directory is unavailable or untrusted, the business is usually down even if servers, storage, and internet connectivity are still running.
That is why ransomware recovery plans that say only, “restore domain controllers from backup,” are incomplete. A domain controller backup may exist, but that does not mean it is usable, clean, isolated from reinfection, or sufficient to recover the forest. In a real incident, IT teams must answer harder questions:
– Which domain controller backup predates the compromise?
– Can the backup be restored without contacting infected systems?
– Are Directory Services Restore Mode credentials known and protected?
– Are DNS, SYSVOL, Group Policy, and FSMO roles recoverable?
– Can privileged admin work be performed from a trusted workstation?
– Has anyone tested the process recently?
This article explains how to build and rehearse a practical Active Directory forest recovery process for ransomware scenarios. It is written for IT managers, MSPs, systems engineers, and technically inclined business owners who need more than a backup success email. The goal is not to replace Microsoft’s official forest recovery guidance, but to help you operationalize it before an emergency.
## The Real Problem: Restoring AD Is Not the Same as Recovering Trust
A normal server restore is usually about data availability. Active Directory recovery is about trust. If an attacker obtained domain admin privileges, changed Group Policy, created persistence, modified ACLs, compromised AD-integrated DNS, or synchronized malicious changes across domain controllers, simply powering on another DC may reintroduce the problem.
In a ransomware event, there are usually three possible states:
1. **AD is available and trusted.** You may only need to recover member servers, endpoints, or application data.
2. **AD is available but untrusted.** Authentication still works, but privileged access, Group Policy, DNS, or account integrity may be compromised.
3. **AD is unavailable or must be rebuilt from known-good backup.** This is the forest recovery scenario.
The third case is where a rehearsed plan matters most. Forest recovery is high consequence work. Mistakes can cause lingering objects, replication failures, broken trusts, duplicate domain controllers, DNS conflicts, or accidental reintroduction of compromised systems.
## Build the Recovery Strategy Around Tier 0
Active Directory recovery starts with understanding Tier 0. Tier 0 assets are systems and accounts that control identity and privileged access. If an attacker controls Tier 0, they control the environment.
Common Tier 0 assets include:
– Domain controllers
– AD CS certificate authorities
– Entra Connect or other identity sync servers
– Privileged Access Workstations
– Backup servers and backup consoles
– Hypervisor management platforms hosting domain controllers
– Break-glass administrator accounts
– Password vaults containing domain admin credentials
– Systems that deploy Group Policy, scripts, agents, or endpoint security
A useful rule: if the system can change domain admins, issue authentication certificates, restore a domain controller, or access all backups, treat it as Tier 0.
This matters because ransomware operators often target backup infrastructure and identity infrastructure early. If your backup server is joined to the same domain it protects, administered by the same domain admins, and reachable from general server VLANs, it may not survive the incident.
## What a Recoverable AD Backup Must Include
A domain controller image backup is helpful, but the minimum recoverable set should be documented. At a practical level, you need:
– System State backups or image-level backups of domain controllers
– At least one usable backup per domain in the forest
– DNS data, especially if AD-integrated DNS is used
– SYSVOL and Group Policy contents
– FSMO role recovery plan
– Directory Services Restore Mode credentials
– Documentation of domain and forest functional levels
– IP addressing, site topology, and DNS forwarders
– Time source configuration
– Backup of AD CS, if certificate services are deployed
– Entra Connect configuration, if hybrid identity is deployed
Do not assume that backing up every domain controller is always better. In a forest-wide compromise, restoring many DCs from different points in time can complicate recovery. The usual forest recovery model is deliberate: restore selected domain controllers from known-good backups, isolate them, seize or transfer roles as required, clean metadata, and rebuild additional DCs after the restored forest is trusted.
## Immutable Backups Are Necessary but Not Sufficient
Immutable backup storage prevents backups from being deleted or modified for a defined retention period. That is important, but immutability alone does not prove recoverability.
A strong design includes multiple controls:
– **Immutability:** Backups cannot be altered during the retention window.
– **Separation of control:** Backup administrators are not the same accounts used for daily domain administration.
– **MFA on backup consoles:** Especially for deletion, export, retention, and repository changes.
– **Network isolation:** Backup repositories are not broadly reachable from server or workstation networks.
– **Offline or logically air-gapped copies:** At least one copy should survive domain compromise and storage compromise.
– **Restore testing:** Backups are regularly restored into an isolated environment.
For SMBs and nonprofits, this does not always require a large enterprise platform. It does require intentional design. A NAS snapshot, cloud object lock, removable media rotation, or managed backup vault can all be useful if permissions, retention, and recovery procedures are engineered correctly.
## Create an Isolated AD Recovery Network
An AD forest recovery rehearsal should happen in a lab or isolated recovery network. Never restore an old domain controller onto the production network to “see if it boots.” A restored DC may advertise stale DNS records, attempt replication, conflict with existing DCs, or expose old secrets.
A basic recovery lab can be created with:
– An isolated virtual switch with no route to production
– A clean management workstation
– Restored domain controller VM disks or backup images
– No internet access initially, unless updates or tools are intentionally staged
– A documented IP addressing plan
– A separate password vault or printed emergency credential envelope
On Hyper-V, for example, create an isolated switch:
“`powershell
New-VMSwitch -Name ‘AD-Recovery-Isolated’ -SwitchType Private
Connect-VMNetworkAdapter -VMName ‘RESTORED-DC01’ -SwitchName ‘AD-Recovery-Isolated’
Connect-VMNetworkAdapter -VMName ‘RECOVERY-ADMIN01’ -SwitchName ‘AD-Recovery-Isolated’
“`
On VMware or another hypervisor, the same concept applies: create a port group or network segment with no uplinks to production. The important control is not the product; it is isolation.
## Inventory the Current Forest Before You Need It
A recovery plan is much easier if you have current documentation. Export key AD information on a schedule and store it with your recovery documentation, preferably outside the domain.
Useful PowerShell examples:
“`powershell
# Domain and forest details
Get-ADForest | Select-Object * | Out-File C:\AD-Recovery\forest.txt
Get-ADDomain | Select-Object * | Out-File C:\AD-Recovery\domain.txt
# Domain controllers
Get-ADDomainController -Filter * |
Select-Object HostName,Site,IPv4Address,OperatingSystem,IsGlobalCatalog |
Export-Csv C:\AD-Recovery\domain-controllers.csv -NoTypeInformation
# FSMO role holders
netdom query fsmo | Out-File C:\AD-Recovery\fsmo-roles.txt
# AD sites and subnets
Get-ADReplicationSite -Filter * |
Select-Object Name |
Export-Csv C:\AD-Recovery\ad-sites.csv -NoTypeInformation
Get-ADReplicationSubnet -Filter * |
Select-Object Name,Site |
Export-Csv C:\AD-Recovery\ad-subnets.csv -NoTypeInformation
“`
Also export Group Policy information:
“`powershell
New-Item -ItemType Directory -Path C:\AD-Recovery\GPOReports -Force
Get-GPO -All | ForEach-Object {
Get-GPOReport -Guid $_.Id -ReportType Html `
-Path “C:\AD-Recovery\GPOReports\$($_.DisplayName).html”
}
“`
Store these outputs somewhere reachable during an incident: a secure documentation platform, encrypted offline media, or the managed service provider’s emergency vault. If the only copy is on a domain-joined file server encrypted by ransomware, it will not help.
## Validate System State Backups
Windows Server Backup can create a System State backup, though many organizations use third-party image-level tools. The exact tool matters less than whether the restore has been tested.
A simple System State backup command looks like this:
“`cmd
wbadmin start systemstatebackup -backuptarget:E: -quiet
“`
To list backups:
“`cmd
wbadmin get versions
“`
To inspect available recovery items:
“`cmd
wbadmin get items -version:MM/DD/YYYY-HH:MM
“`
In production, you will usually automate backups through a managed backup product. Still, knowing the native commands is helpful because they clarify what must exist: the AD database, SYSVOL, registry, boot files, COM+ registration database, and other System State components.
During a rehearsal, confirm:
– The backup can be mounted or restored.
– The restored server boots in the isolated network.
– DSRM credentials work.
– NTDS database services can be brought online.
– DNS zones are present.
– SYSVOL is present and shared.
– Event logs do not show critical AD database corruption.
## Know Your DSRM Credentials
Directory Services Restore Mode is a local recovery mode for domain controllers. It uses a local administrator password set when the DC is promoted. In many environments, no one knows whether that password is unique, vaulted, rotated, or recoverable.
You can reset the DSRM password on a domain controller with `ntdsutil`:
“`cmd
ntdsutil
set dsrm password
reset password on server null
quit
quit
“`
After resetting, store it in a privileged vault. Treat DSRM credentials as Tier 0 secrets. If an attacker can boot a DC into recovery mode and use DSRM credentials, they may gain access to the AD database.
## Rehearse the Recovery Sequence
A full forest recovery should follow vendor guidance and be adapted to your environment, but the rehearsal should prove the major steps. A simplified recovery sequence often looks like this:
1. Declare the production forest untrusted for recovery purposes.
2. Identify the approximate compromise window.
3. Select known-good backups for one DC in each domain.
4. Restore the first DC for the forest root domain into an isolated network.
5. Boot into DSRM if required and perform the appropriate restore procedure.
6. Bring AD DS online and verify database health.
7. Seize FSMO roles if original role holders will not return.
8. Clean up metadata for DCs that will not be restored.
9. Restore or rebuild one DC per additional domain.
10. Validate DNS, SYSVOL, replication, authentication, and Group Policy.
11. Rebuild additional domain controllers from clean operating system installations.
12. Reconnect recovered services in a controlled order.
The key principle is that old compromised domain controllers should not casually rejoin the recovered forest. In many cases, it is safer to rebuild DCs on clean OS installs after the core forest is restored.
## Health Checks After Restore
Once a domain controller is restored in isolation, run health checks before declaring success.
“`cmd
dcdiag /v /c /e /f:C:\AD-Recovery\dcdiag.txt
repadmin /replsummary
repadmin /showrepl * /csv > C:\AD-Recovery\showrepl.csv
net share
“`
Check SYSVOL and NETLOGON shares:
“`cmd
net share | findstr /i “SYSVOL NETLOGON”
“`
Check FSMO roles:
“`cmd
netdom query fsmo
“`
Check DNS zones with PowerShell:
“`powershell
Get-DnsServerZone | Select-Object ZoneName,ZoneType,IsDsIntegrated
“`
If SYSVOL is missing, Group Policy processing will fail even if logons work. If DNS is wrong, almost everything else will appear broken. If replication is unhealthy, do not scale the recovery by adding more domain controllers until you understand why.
## Decide What Not to Restore
A ransomware recovery is also an opportunity to avoid restoring the attacker’s persistence. Be cautious with:
– Old startup scripts and logon scripts
– Suspicious Group Policy changes
– Unused domain admin accounts
– Legacy service accounts with broad privileges
– Stale computer accounts
– Old AD CS templates
– Unconstrained delegation
– Weak Kerberos settings
– Excessive local admin rights deployed by GPO
Before reconnecting production workloads, review high-risk AD objects and policies. For example, list members of privileged groups:
“`powershell
$groups = ‘Domain Admins’,’Enterprise Admins’,’Schema Admins’,’Administrators’,’Account Operators’,’Backup Operators’,’Server Operators’
foreach ($group in $groups) {
Write-Host “`n=== $group ===”
Get-ADGroupMember $group -Recursive | Select-Object Name,SamAccountName,ObjectClass
}
“`
Review recently changed objects if you have a suspected compromise date:
“`powershell
$since = Get-Date ‘2026-01-01’
Get-ADObject -Filter ‘whenChanged -gt $since’ -Properties whenChanged |
Select-Object Name,ObjectClass,whenChanged,DistinguishedName |
Sort-Object whenChanged -Descending
“`
Use the correct date for your investigation. This is not a replacement for forensic analysis, but it helps identify changes that deserve scrutiny.
## Protect the Recovered Forest Before Reconnecting Systems
Do not bring the recovered forest back online with the same weaknesses that allowed the incident to spread. At minimum:
– Reset all privileged account passwords.
– Rotate Kerberos keys, including the `krbtgt` account, using a planned process.
– Disable or remove stale privileged accounts.
– Require MFA for remote access and administrative portals.
– Restrict domain admin logon to approved Tier 0 systems.
– Review Group Policy for local administrator rights.
– Rebuild domain controllers cleanly after the initial restore.
– Rejoin or rebuild member servers based on risk.
– Reconfigure endpoint security from trusted management infrastructure.
The `krbtgt` reset is especially important if Kerberos tickets may have been forged. It should be done carefully, usually twice with adequate replication time between resets. In a forest recovery scenario, coordinate this with your incident response team and Microsoft guidance.
## Test Business Services in Dependency Order
Once the recovered AD environment is healthy, restore services in dependency order. A typical sequence might be:
1. Core network services: DNS, DHCP, NTP
2. Identity dependencies: certificate services, identity sync, MFA connectors
3. Backup and monitoring platforms
4. File services and print services
5. Database platforms
6. Application servers
7. Remote access and VPN
8. Endpoint management
9. User workstations
Avoid reconnecting everything at once. Use firewall rules and VLAN segmentation to control exposure. Monitor authentication logs, DNS queries, endpoint alerts, and privileged group membership as systems return.
## How Often Should You Rehearse?
For most organizations, a tabletop exercise is not enough. You should perform a technical AD recovery rehearsal at least annually, and more often after major changes such as:
– Domain controller operating system upgrades
– Backup platform migration
– AD CS deployment or redesign
– Entra Connect changes
– New privileged access model
– Merger or acquisition
– Major network segmentation project
– Cyber insurance control changes
A good rehearsal produces evidence:
– Date and scope of the test
– Backup versions restored
– Recovery time achieved
– Issues encountered
– Screenshots or logs of validation checks
– Updated runbook
– Assigned remediation tasks
This evidence is useful for executives, auditors, insurers, and internal IT leadership. More importantly, it gives the recovery team confidence under pressure.
## A Practical AD Recovery Runbook Template
Your runbook should be concise enough to use during an incident. Include these sections:
### 1. Emergency Contacts
List internal IT, MSP contacts, cyber insurance breach coach, incident response firm, legal counsel, backup vendor, and key executives. Store offline copies.
### 2. Authority to Declare Forest Recovery
Define who can decide that the production forest is untrusted and recovery should begin. This avoids delay during a crisis.
### 3. Backup Selection Criteria
Document how to identify known-good backups, who approves the selected restore point, and where backup immutability settings are verified.
### 4. Isolation Procedure
Include exact hypervisor, firewall, VLAN, and switch steps needed to create an isolated recovery environment.
### 5. Restore Procedure
Document the restore steps for your backup product, including screenshots where useful. Include DSRM credential retrieval instructions.
### 6. Validation Commands
Include `dcdiag`, `repadmin`, DNS checks, SYSVOL checks, FSMO role checks, and privileged group review.
### 7. Reconnection Plan
Define which systems reconnect first, what firewall changes are required, and who approves each phase.
### 8. Security Hardening Checklist
Include privileged password resets, Tier 0 access restrictions, MFA requirements, endpoint security redeployment, and logging validation.
## Common Mistakes to Avoid
The most common AD recovery failures are not exotic. They are operational:
– Backups exist but were never restored in a test.
– DSRM passwords are unknown.
– Backup consoles rely entirely on compromised domain authentication.
– Restored DCs are accidentally connected to production.
– DNS is overlooked.
– AD CS is forgotten until authentication certificates fail.
– Entra Connect is re-enabled too early.
– Old domain controllers are allowed to replicate back into the environment.
– Executives assume cloud applications will work without on-prem identity.
Each mistake is preventable with planning and rehearsal.
## Why This Matters for SMBs and Nonprofits
Smaller organizations often have lean IT teams and limited tolerance for extended outages. They may also rely heavily on one or two domain controllers, a single backup appliance, and a small number of administrators. That simplicity can be an advantage if documented well, but a liability if everything depends on tribal knowledge.
For nonprofits, healthcare clinics, professional services firms, manufacturers, and local governments, AD downtime can stop payroll, case management, production, billing, file access, and communications. A tested recovery plan is not just an IT artifact. It is a business continuity control.
## Summary and Key Takeaways
Active Directory forest recovery is one of the most important disaster recovery capabilities an organization can develop. Ransomware has made this more urgent because attackers often target identity and backup systems before encryption becomes visible.
Key takeaways:
– Treat Active Directory as a Tier 0 business-critical control plane.
– Immutable backups help, but only tested restores prove recoverability.
– Rehearse AD recovery in an isolated network, never on production.
– Maintain offline documentation of FSMO roles, domain controllers, DNS, sites, and Group Policy.
– Vault and periodically verify DSRM credentials.
– Validate restored DCs with `dcdiag`, `repadmin`, DNS checks, SYSVOL checks, and privileged group reviews.
– Rebuild additional domain controllers cleanly after the core forest is trusted.
– Protect the recovered forest before reconnecting business systems.
– Run a technical rehearsal at least annually and after major infrastructure changes.
The best time to discover an Active Directory recovery gap is during a planned exercise, not during a ransomware incident. A well-rehearsed process turns a high-stress outage into an executable plan, and that can be the difference between a difficult recovery and a business-ending event.
