Alignment with Microsoft Guidance

Domain and forest recovery in Cygna Forest Recovery is built on Microsoft's Active Directory Forest Recovery Guide. Each step of a recovery plan carries out a step of that guide, in the guide's order. This topic was checked against the guide as published on Microsoft Learn on October 13, 2026; its overview and initial recovery pages were last revised on February 16, 2026.

Microsoft guidance and how it is applied

Microsoft guidance	How it is applied
Recover in isolation from the production network.	Every restore target is isolated before anything is restored, and you attest to it. The targets keep firewalled paths to the Manager and the storage machine only.
Restore one writable domain controller per domain, forest root first and each parent before its child: non-authoritative AD DS, authoritative SYSVOL. Verify the data before going on.	A plan restores exactly one writable domain controller per domain, in that order: by full system recovery followed by an authoritative SYSVOL synchronization, or by DC state recovery, a system state restore with authoritative SYSVOL onto the same Windows installation. You then check the restored data, or reject it and re-plan with an older restore point.
Seize the operations master roles: all five in the root, the domain-wide roles in each child.	Seized on the restored domain controller, as a point of no return.
On a restored role holder, set `Repl Perform Initial Synchronizations` to 0, and back to 1 once the forest is recovered.	Set to 0 with the role seizure and back to 1 during cleanup.
Clean up the metadata of every other writable domain controller.	Removed for every domain controller in the domain that is not restored, including those without a DC agent.
Make DNS work on the restored domain controller and remove stale name server and service records.	The root points at itself, each child at the root, and stale records are removed.
Raise the available RID pool by 100,000, then invalidate the current RID pool.	Raised by 100,000 by default; you can change the amount in the plan. The current pool is always invalidated.
Reset the domain controller's computer account password twice.	Reset twice, and each reset is verified.
Reset the `krbtgt` password twice.	Reset twice; read-only domain controllers' `krbtgt` accounts are left alone. See the differences below.
After a security breach, reset trust passwords, one side at a time, with the same password on both sides.	In a forest recovery, trusts are reset only when the security breach flag is set. Each side is reset by the agent on its own domain's restored domain controller, one side at a time, to one password per trust that the Manager generates. For an external trust, only this forest's side is reset, and you carry out and attest that step.
In a forest with more than one domain, remove the global catalog from the restored domain controller; later add one in the forest root.	Removed from every domain's restored domain controller after the restore, and added back on a restored root domain controller once the forest health check passes. The step waits until that domain controller has completed its first full synchronization and serves as a global catalog.
Set the root PDC emulator to an external time source.	The plan requires at least one external time source.
Join the restored domain controllers on a common isolated network, check replication health, and take a new backup of each.	A health gate on each restored domain controller, then a backup checkpoint, both before the forest is reconnected. Each gate pulls replication from the domain controller's partners, checks that its inbound replication converges and that its domain lists exactly its restored domain controller, and runs `dcdiag`. Nothing is promoted before every gate passes.
Redeploy the remaining domain controllers by installing AD DS.	Each is rebuilt by promotion, with the roles and features its last backup recorded reinstalled first.
Clean up: revert DNS, delete records of unrecovered domain controllers, move operations master roles, re-create missing objects, and restore external trusts.	The recovery report lists these as follow-ups. See After a Recovery.

What Cygna Forest Recovery adds

Microsoft's guide is a template you adapt and run by hand. Cygna Forest Recovery adds:

Preflight checks—Hard checks block approval until cleared, for example a second restored domain controller in one domain or a restore point past the tombstone lifetime. See Preflight Check Reference.
Isolation attestation—A named operator attests that the targets are isolated before anything is restored.
Points of no return—Steps that cannot be undone wait for a typed acknowledgment.
Audit trail—Every decision, check result, and state change is recorded.
Breach resets—The security breach flag adds the resets Microsoft describes for a compromise, before any domain controller is rebuilt.
Unattended execution—A plan can accept its pauses in the executing operator's name. A trust reset carried out by hand, such as this forest's side of an external trust, still stops for a person.
Recovery report—What happened to each domain controller, and the follow-ups left to you.

Where Cygna Forest Recovery differs, and why

krbtgt resets back to back—Microsoft's reset procedure says to wait 10 hours, the default maximum ticket lifetime, between the two resets, so that tickets issued under the first new key can expire. By default, Cygna Forest Recovery runs the second reset as soon as the first is acknowledged. Both resets run while the forest is still isolated, and reconnecting waits for the second, so no client holds a ticket issued between them. If your policy requires the 10-hour wait, contact Cygna Labs support before you plan the recovery, so that the plan is created with that gap.
RID pool always invalidated—Microsoft notes that a system state restore invalidates the pool by itself. A full system recovery does not, so the pool is invalidated explicitly every time. Invalidating twice does no harm.
Trust resets in every domain recovery—Microsoft describes trust resets for a security breach. A forest recovery follows this: it resets trusts only when the security breach flag is set. Without the flag, each side of a trust keeps the trust password its own restore point holds, and the plan warns when the two sides' restore points are 30 days or more apart, because Windows rotates the trust password every 30 days and the two may no longer match. A domain recovery, which brings one domain back into a forest that kept running, resets every trust of the domain whether or not the flag is set.
Isolation keeps two paths open—For a physical domain controller, Microsoft's guide disconnects the network cable. The agents run every step, so the targets keep firewalled paths to the Manager and the storage machine. See Isolating Recovery Targets.
Redeployment by promotion only—Microsoft also describes virtualized domain controller cloning and install from media. Rebuilds promote each domain controller and replicate the directory over the network.

DC state recovery and authoritative restore

A DC state recovery of a single domain controller follows the authoritative restore procedure in Microsoft's Restore user accounts and groups in AD (checked as published on Microsoft Learn on October 21, 2026; last revised February 12, 2026):

System state restore in DSRM, then marking—The domain controller is restarted into Directory Services Restore Mode, system state is restored, and each subtree or object is marked with ntdsutil authoritative restore before the normal restart.
Back-links with ldifde—After the restart, the back-link files ntdsutil writes are imported with ldifde on the restored domain controller, so the marked objects' group memberships come back.
Subtrees and objects, never the whole database—The recovery marks only what you name. It refuses a whole partition, the schema, the domain controllers, and CN=System, so trust and domain controller passwords are not rolled back. Microsoft advises against restoring the whole database authoritatively for the same reason.

Where it differs:

Inbound replication stays on—Microsoft's procedure turns off inbound replication on the recovery domain controller while the restored objects replicate out. A DC state recovery does not; the marked objects carry raised version numbers, and the agent reads them back from replication metadata before the run counts as restored.
Marks are verified—The run records the evidence of each mark and the hash of each back-link file, imports only those files, and reports the recovery as restored only when the marks are read back.
krbtgt after rolling back CN=Users—When a DC state recovery puts krbtgt back to the backup and you choose the reset, krbtgt is reset twice once the recovery validates. The second reset waits until the first has reached every writable domain controller, not for the 10-hour ticket lifetime, so tickets issued under the backup's keys stop working and users and services sign in again.

Note: Microsoft revises its guidance from time to time. The mapping on this page is Cygna Labs Corp.'s own reading of it; it does not imply review or endorsement by Microsoft.