What Active Directory Forest Recovery Backup Validation Means
Active Directory forest recovery backup validation asks two questions: can the backup be restored, and can the organization justify trusting the forest recovered from it? A successful restore answers the first. The second needs an investigated recovery point, a rehearsed procedure and evidence that the restored directory meets the recovery criteria.
Microsoft's Active Directory Forest Recovery Guide provides a template to customize for the environment. Its incident assessment guidance explicitly excludes complete security recommendations for recovering a hacked or compromised forest. Use the recovery procedure alongside the incident response work required to establish trust.
Here, validated recovery means a documented exercise or recovery with recorded acceptance checks and explicitly stated limits. It is an editorial definition, not a Microsoft certification. “The DC started” and “replication works” are useful observations, but neither establishes that the selected directory state is safe.
| Question | Evidence to request | What it leaves open |
|---|---|---|
| Is the backup restorable? | An actual restore result for the selected backup and recovery path | Whether the restored state is trustworthy |
| Is the recovery repeatable? | A current runbook and a dated rehearsal record | Whether the next incident has the same scope |
| Is the recovery point defensible? | An incident timeline and reasons for accepting that backup | Malicious changes not covered by the investigation |
| Is the recovered forest ready? | Recorded operational checks and security review decisions | Dependencies or persistence outside those checks |
Treat elapsed recovery time as another recorded result. A fast exercise with unknown credentials, unreviewed data or unresolved validation failures should not be described as a validated recovery.
Choose a Trusted State Before Restoring
Microsoft's backup selection guidance warns that a newer backup can reintroduce dangerous data. If the failure time is unknown, investigate the last safe state. Recovery loses subsequent objects, updates and configuration or schema changes.
The same page recommends regularly backing up at least two writable DCs per domain. It requires Domain Admin credentials for each domain and the DSRM password. An RODC backup cannot restore a writable DC; a system state restore onto a new Windows installation is unsupported. Plan the appropriate full server recovery path. Dsamain and an LDAP browser such as Ldp can help inspect backed-up directory data.
With Recycle Bin enabled, backup validity is bounded by the smaller of deletedObjectLifetime and tombstoneLifetime. These conditions make “we have a recent file” an incomplete recovery argument.
For the recovery decision, record which backup was chosen, which domain it represents, why its state is acceptable and which changes will be lost. If the investigation cannot support a trusted point, record that uncertainty rather than relabeling the newest backup as clean.
Persistence claims must remain conditional
The recovery-side inference is conditional: if a malicious directory change is present in the selected backup and falls within the restored state, restoring that state may reintroduce the change. This is a deduction from the documented rollback behavior, not a Microsoft assertion that every backdoor necessarily returns intact.
That distinction matters for ACLs and AdminSDHolder. Our AdminSDHolder and SDProp article explains persistence through a modified ACL template and why correcting only a protected object's ACL can leave the template problem unresolved. For recovery, ask whether the saved template and relevant permissions match an accepted baseline. The Forest Recovery pages cited here do not explicitly describe restoring an AdminSDHolder backdoor.
Microsoft's certificate template documentation states that enterprise CA templates reside in AD DS. It distinguishes changing a template, enabling issuance on a CA and publishing an issued certificate. A modified template contained in restored directory state could therefore reappear: that is a conditional inference. It does not establish the restored condition of every CA, issued certificate or PKI secret. Define the complementary PKI review separately.
Our Golden Ticket article describes the persistence concern associated with a compromised krbtgt secret. The recovery instructions and reset timing below come from Microsoft Learn. The link explains why the secret matters; it is not the authority for this recovery procedure.
Follow the Recovery Sequence with Validation Gates
The Microsoft prerequisites assume that the cause and possible remedies have been evaluated with Microsoft Support and that forest restoration is the chosen remedy, often as a last option. They also call for a documented plan tested in a lab using production backups.
Prepare that decision before beginning destructive recovery steps. Record the incident scope, recovery credentials, emergency access information and chosen backups. A runbook should make the next decision clear even when normal directory services are unavailable.
The following is an overview of Microsoft's initial recovery sequence, not an executable replacement for the full procedure:
- Restore in isolation. Start with a writable DC in the forest root domain, then recover other domains, parent before child.
- Use the correct restoration mode for the first restored DC in each domain. Restore AD DS nonauthoritatively and SYSVOL authoritatively, following the documented method. Later DCs in that domain must resynchronize SYSVOL from the authoritative copy.
- Verify the restored data before production connection. Complete the documented FSMO, metadata, DNS, RID, account-password and time steps. Suspected intrusion requires administrative password resets and work to replace all gMSA passwords. Suspected user-account compromise also requires planning password resets for all users in the domain.
- Validate the recovered DCs together. Use a common isolated network before the production transition.
- Back up the restored DCs before redeploying the remaining DCs.
The page also documents these operational checks in its forest-replication-health section, after the production-network transition:
repadmin /replsum
DCDiag /v
They assess replication and DC/DNS health. Successful output does not certify the absence of persistence. Keep operational evidence and security review conclusions distinguishable in the recovery record.
Reset krbtgt twice with the documented interval
Microsoft's krbtgt reset procedure applies to writable DCs, not RODCs. In Active Directory Users and Computers, enable Advanced Features, open the domain's Users container and use Reset Password on krbtgt.
Perform the operation twice. The account retains the two most recent passwords; two resets remove the old password from that history. Learn requires 10 hours between resets with the default maximum user-ticket and service-ticket lifetimes. If the maximum lifetime is changed, the waiting period must be greater than the configured value. Do not assume that the first reset universally invalidates every forged ticket.
For a recovery involving RODCs, Learn says not to delete their krbtgt_number accounts. Do not apply the writable-DC procedure to them.
Detection: Measure Backup Age and Missing Evidence
A backup job's success, a directory timestamp and a restore exercise describe different evidence. Review each on its own terms.
Microsoft's backup latency guidance documents:
Repadmin.exe /showbackup
Collect the reported backup dates for the targeted DCs and naming contexts, and record the actual command scope. Repadmin needs administrative credentials on each targeted DC. Microsoft explains that the backup timestamp is written by backups using the standard backup APIs; a file-level copy of the AD database does not provide that protection.
Investigate when backups are older than half the forest's tombstone lifetime. Learn states that backups older than the tombstone lifetime are invalid and recommends at least daily backups in almost all scenarios. Read the forest's actual lifetime settings. Do not substitute a universal 180-day value or the collector's independent 60-day threshold.
A recent timestamp still does not demonstrate media integrity or a successful restoration.
| Signal to investigate | Evidence to collect | Next decision |
|---|---|---|
| Missing or aging backup information | Scoped /showbackup results, job history and available backup inventory | Correct missing coverage or failed jobs |
| No recorded restore exercise | The latest rehearsal date, backup identifiers and check outputs | Schedule an exercise with production backups |
| Uncertain recovery point | Incident timeline and review of candidate backed-up state | Establish the last trusted point or retain the uncertainty |
| Recycle Bin unavailable or unknown | Actual feature state and prerequisite review | Plan enablement before future deletions |
| Recovery checks fail | Saved diagnostic output and runbook deviations | Resolve the failure before accepting recovery |
These are investigation prompts, not observations of a customer environment. Ask for the artifacts behind “tested” or “recoverable”: which backup, which domain, which procedure revision and which checks passed?
Remediation: Document, Rehearse and Prepare Object Recovery
1. Make the runbook specific to the forest
Microsoft's planning guidance calls for a topology map covering DCs, roles, backup status and trust relationships. It recommends practicing forest recovery at least annually and also suggests drills when Domain Admins or Enterprise Admins membership changes.
Turn the map into a usable decision record: identify the recovery DC for each domain, the backup selection criteria, required access and validation checkpoints. Assign ownership for keeping those entries current. An unexplained gap should remain visible rather than being hidden by a completed checklist.
2. Repeat the restore and preserve the results
The prerequisites call for regular lab backup and restoration of AD DS and SYSVOL, routine procedure review and updates after OS or architecture changes. Rehearse the actual recovery path with production backups.
A useful rehearsal record identifies the runbook revision, selected backups, operators, checks performed, outputs and deviations. Include the elapsed time, but also state what the exercise did and did not validate. If a backup starts successfully but the data review fails, retain both results. If required access was unavailable, record that as a recovery dependency to fix.
Separate “the procedure was performed” from “the acceptance criteria passed.” Repeating a procedure without examining its results does not close the trust question.
3. Enable Recycle Bin before it is needed
Microsoft's Recycle Bin guidance says the feature is disabled by default and activation is irreversible. It preserves deleted objects' attributes and links, including group memberships. It can recover only objects deleted after enablement.
Check the documented prerequisites: forest and domain functional levels of Windows Server 2008 R2 or higher, the stated administrative permissions, and ADAC or the Active Directory PowerShell module.
For the documented ADAC path, select the appropriate target domain, choose Enable Recycle Bin in the Tasks pane, acknowledge the messages and refresh ADAC. After a controlled test deletion, use the Deleted Objects container to restore the selected object and verify its location.
Record the enablement decision and a controlled object restoration test. Recycle Bin addresses object recovery; it does not validate a compromised forest. Keep that test separate from the forest restoration exercise.
4. Close the evidence gaps before declaring recovery validated
Use a short acceptance record that connects every conclusion to evidence. “Backup available” should name the backup. “Recovery rehearsed” should identify the exercise. “Trusted state” should identify the investigation and baseline review. “Operational checks passed” should identify the recorded outputs.
Where the incident requires additional security or PKI work, name the unresolved task and its owner. Do not let a successful replication check silently become the approval for everything outside its scope.
How EtcSec Detects This
The collector provides three active checks relevant to this topic. They identify configuration or review signals; they do not prove forest recoverability.
| Active check | Actual predicate | Limit |
|---|---|---|
HDS_5_8_DR_PLAN_MISSING | Fewer than 2 inventoried DCs produces Count 1 | A DC-count heuristic. It reads no runbook, backup or rehearsal. Two colocated DCs without a plan can pass; a well-planned single-DC deployment can fail. |
DC_BACKUP_OLD | Missing DomainInfo or LastADBackupDate produces Count 1; otherwise more than 60 whole days produces Count 1 | The provider populates the field with the maximum whenChanged across nTDSDSA objects. This is a collection-level NTDS metadata proxy, not backup age per DC. Topology changes can make it look recent. Exactly 60 whole days does not trigger. |
RECYCLE_BIN_DISABLED | RecycleBinEnabled=false produces Count 1; true produces Count 0 | With missing DomainInfo, the result is unknown with Count 0. That is not proof that the feature is enabled. |
The HDS identifier does not establish a specific numbered HDS requirement or prove that a recovery plan is missing. Use it to prompt a human review of topology and recovery planning.
BACKUP_AD_NOT_VERIFIED is not measured by the collector. Its retired detector returns no findings and is not registered. It is excluded from this article's vulnerability tags. Restore verification needs operational evidence outside these directory checks.
Explore the identity security pages that support this topic