Recovering an Active Directory forest after ransomware is a long, manual, error-prone process, and most organisations discover how long only when they need it. Microsoft's forest recovery guidance requires restoring one writeable domain controller per domain in isolation, seizing operations master roles, cleaning metadata, raising the RID pool and resetting the krbtgt password twice, before any other domain controller is rebuilt. Dedicated AD and Entra ID recovery tools automate parts of this, add clean restore options and back up cloud directory objects that native features do not keep for long. This vendor-neutral buyer's guide is for identity, infrastructure and resilience leads choosing such a tool. It does not repeat the recovery procedure itself, which is covered in the Identity Recovery Guide, or general backup platform selection, covered in the Backup and Cyber Recovery Buyer's Guide.
Key takeaways
- Buy for the compromise case, not the hardware failure case: the hard part is restoring a forest you can trust, without the attacker's persistence.
- Measure time to a working forest in a test, end to end, including isolation, role seizure, password resets and rebuilding the remaining domain controllers.
- Close the Entra ID gap: native soft delete covers some object types for 30 days, and native Entra Backup and Recovery keeps up to seven days of history for supported objects.
- Protect the recovery tool as tier 0: it holds domain controller backups and privileged credentials, so its own identity, storage and administration must be isolated.
- Insist on a regular full recovery test in an isolated environment, with a report you can show auditors and the board.
Define requirements
- Directory estate: number of forests, domains and domain controllers, sites, trusts, Windows Server versions, and whether domain controllers are physical, virtual or in a cloud IaaS service.
- Hybrid scope: Entra ID tenants, synchronisation with Entra Connect or Cloud Sync, objects mastered in the cloud, and dependencies such as AD FS or AD CS. See the Microsoft Entra Connect and Cloud Sync Hardening Guide.
- Recovery objectives: target recovery time for a full forest and for a single object or attribute, and the acceptable data loss. Microsoft notes that each restored domain returns to the state of its last trusted backup, losing later objects, updates and configuration changes.
- Scenarios to cover: accidental deletion, bulk malicious changes, a compromised domain, a destroyed forest (wiper or ransomware on all domain controllers) and loss of the Entra tenant configuration.
- Recovery location: on premises, an isolated recovery environment, or a cloud clean room. See the Cloud Recovery and Clean Room Guide.
- Constraints: regulatory resilience obligations, data residency for backup copies, staff skills and the teams who will run recovery out of hours.
Capability areas
| Area | What to look for |
|---|---|
| AD backup | Full server and system state backups of at least two writeable domain controllers per domain, matching Microsoft's advice; schedule and retention within the tombstone or deleted object lifetime; integrity checks on each backup |
| Automated forest recovery | Orchestration of the Microsoft sequence: isolated restore of the first writeable DC per domain, FSMO seizure, metadata cleanup, DNS clean-up, RID pool raise, computer account and krbtgt resets, global catalog handling and promotion of the remaining DCs |
| Clean restore | Restore to new hardware or virtual machines (Microsoft does not support restoring a system state backup to a different server), option to rebuild the operating system rather than restore it, and scanning of backups for known persistence before use |
| Granular AD recovery | Object, attribute, group membership, GPO and DNS record restore with comparison against a backup point, without restoring a domain controller |
| Change tracking and rollback | Audit of directory changes with who, what and when, and the ability to roll back a set of malicious changes |
| Entra ID backup | Backup of users, groups, applications, service principals, Conditional Access policies, named locations and authentication method policies, with retention longer than the native seven days and restore of hard-deleted object types |
| Hybrid sequencing | Guidance or automation for the order of AD restore, sync server rebuild and Entra recovery so sync does not overwrite good cloud data |
| Post-recovery hardening | Built-in steps or reports for resetting privileged and service account passwords, new KDS root key and gMSA recreation where the database was compromised, and trust password resets |
| Testing | Scheduled recovery rehearsals in an isolated network with timing reports and evidence |
| Tool security | Separate administration identities, MFA, immutable or air-gapped backup storage, encryption, and no dependence on the production domain for sign-in |
Evaluation criteria
| Criterion | Illustrative weight | Good evidence |
|---|---|---|
| Measured full forest recovery time | 20% | Timed recovery of your test forest in the proof of concept, all domains, to working authentication |
| Compromise recovery features | 20% | Clean OS rebuild, backup scanning, krbtgt and privileged resets, choice of backup point by integrity rather than recency |
| Entra ID coverage | 15% | Object type list, attribute coverage, retention, restore of hard-deleted configuration |
| Security of the tool itself | 15% | Independent sign-in, immutable storage, tier 0 deployment guidance, vendor penetration test summary |
| Granular restore and rollback | 10% | Demonstrated restore of a deleted OU with linked GPOs and group memberships |
| Operability | 10% | Runbooks, role-based access, how many people it needs, out-of-hours support |
| Commercials | 10% | Licence metric (users, DCs or objects), recovery environment costs, renewal terms |
Weights are illustrative; adjust them to your recovery objectives. A single-domain organisation with a small Entra tenant may weight cost and operability higher; a multi-forest regulated estate should weight recovery time and compromise features higher. In framework terms the tool supports NIST CSF 2.0 PR.DS-11 (backups created, protected and tested), RC.RP-03 (backup integrity verified before restoration) and RC.RP-05 (restored assets verified), and NIST SP 800-53 Rev. 5 CP-4, CP-9 and CP-10.
Questions to ask vendors
- Show us a timed recovery of a multi-domain forest from backup to working Kerberos authentication. What did you automate, and what did an engineer do by hand?
- Which Microsoft forest recovery steps does the product perform, and in what order? How does it handle the RID pool raise, krbtgt double reset and global catalog clean-up?
- How do you help us choose a backup point that predates the compromise, and what do you check in a backup before restoring it?
- Can we restore to new virtual machines or a cloud clean room when the original hardware or hypervisor is untrusted?
- Which Entra ID object types and attributes do you back up, how long do you keep them, and can you restore objects that Entra hard deletes, such as Conditional Access policies?
- How does recovery avoid Entra Connect or Cloud Sync overwriting cloud objects with stale on-premises data?
- How is the product administered if the production domain is down or compromised? Does sign-in depend on it?
- Where are backups stored, can an administrator with full rights in the tool delete them, and how is that prevented?
- What evidence does a recovery test produce, and can we schedule tests without touching production?
- What support do you give during a live incident, and what response times are contractual?
Red flags
- "Forest recovery" that is only a system state restore with no orchestration of the steps after it.
- No way to restore to clean, new infrastructure.
- Tool administration joined to, or authenticating against, the production domain it protects.
- Backup storage that a compromised tool administrator can delete or encrypt.
- Entra ID "backup" limited to users and groups, with no Conditional Access, application or service principal coverage.
- No timed proof of concept, or a demonstration only on a single-DC lab.
- Post-recovery credential resets left entirely to the customer with no guidance.
- Licence terms that charge extra to run recovery tests.
Proof of concept
- Build an isolated test forest that mirrors production: at least two domains, several sites, a trust, AD CS if you run it, and a synchronised Entra test tenant.
- Deploy the tool as you would in production, with its own administration identities and isolated backup storage, then take backups.
- Simulate scenarios: delete an OU with linked GPOs, make bulk malicious group changes, delete Conditional Access policies and an application registration, and finally make all domain controllers unavailable.
- Time each recovery from declaration to working sign-in, and record every manual step.
- Verify the result: replication health, krbtgt and computer account resets, RID pool, DNS records, Kerberos tickets, and Entra objects and policies matching the backup.
- Try to delete or alter backups with a tool administrator account to test immutability.
- Review the evidence report, runbooks and the vendor's incident support process, and compare commercial quotes including the recovery environment.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support across identity resilience, IAM, PAM and NHI, including recovery planning for the service accounts and machine credentials that must be reset after a forest restore. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Identity Recovery Guide · Active Directory Forest Recovery Runbook Template · krbtgt account · Backup and Cyber Recovery RFP Template · Active Directory Domain Compromise Response Playbook