How to Verify AD Backups and Run a Forest Recovery Rehearsal (Australian Recipe)

The answer in fifty-five words

Verifying AD backups for Essential Eight Maturity Level 2 means three things: a daily System State backup on at least one domain controller per domain, written to an immutable destination outside the production domain, and a real forest recovery rehearsal at least annually in a lab that mirrors production. Spot restoration of individual objects is not enough.

What ML2 actually requires for AD backups

The ASD Essential Eight Maturity Model (Australian Cyber Security Centre — Essential Eight maturity model, accessed 16 June 2026) (current 2025 revision) Control 8 requires daily, coordinated, resilient backups of important data, software, and configuration; retention of at least three months; offline or immutable copies; restricted access to the backup store; and full restoration testing at least annually or when a substantial change is made.

For Active Directory, important data means the System State on at least one domain controller per domain, the SYSVOL share, and the Group Policy objects. Coordinated means the backup captures consistent state across replicating DCs; resilient means the destination is not reachable from a compromised production domain administrator. ASD's Information Security Manual (Australian Signals Directorate — Information Security Manual (ISM), accessed 16 June 2026) (November 2025 release) ISM-1511 reinforces the restoration testing requirement at the broader programme level.

Step 1 — Confirm what is actually being backed up

Most Australian organisations have a backup. Few can answer the question "what would you restore from?" with confidence. Begin with a clear inventory:

• Which domain controllers have a System State backup configured?
• What is the backup frequency? What is the retention?
• Where are the backups stored? Is that store joined to the production domain?
• Who can delete or modify those backups?
• When was the last successful backup, and when was the last verified read-back?

If any of these answers is I'm not sure, the verification is the deliverable.

Step 2 — Verify the backup is readable

A backup that has not been read back is not yet a backup. Verification has three layers:

1. Job-level success — the backup job reports success in the backup tool's console. Necessary but not sufficient.
2. File-level integrity — the backup file passes a checksum or restore-test on the backup destination. Most enterprise backup tools (Veeam, Commvault, Azure Backup, Cohesity) support an integrity verification mode.
3. Restore-level read-back — the backup is restored to scratch storage and the AD database (ntds.dit) is mounted and queried. Only the third layer proves the backup is usable.

Microsoft's AD Forest Recovery Guide (Microsoft Learn, 2025 reviewed) describes the read-back pattern using a domain controller booted into Directory Services Restore Mode and ntdsutil to load and verify the database.

Step 3 — Move the backup destination outside the trust

A backup store joined to the production domain can be deleted by any account that has been promoted to Domain Admin during an incident. ACSC ransomware guidance (current revision) and the Restricting Administrative Privileges guidance both push backup destinations outside the protected trust.

Acceptable Australian patterns in 2026:

• Immutable object storage: Azure Blob with immutability policies, or AWS S3 Object Lock in compliance mode. The retention lock is enforced by the cloud provider; even a tenant administrator cannot remove the lock during its retention period.
• Backup tenant pattern: backup workloads run inside a dedicated Microsoft Entra tenant (or AWS account) with no trust to the production tenant. The backup service principal has no permissions in production beyond the read path required to source the data.
• Air-gapped offline copy: a weekly System State export written to media that is physically disconnected after write. Used as a last-resort fallback rather than the primary.

Veeam, Commvault, Cohesity, and Rubrik all publish reference architectures for the first two patterns. Whichever pattern is chosen, document it on the Tier 0 register so it inherits the Tier 0 administrative discipline.

Step 4 — Build the recovery lab

The lab must mirror enough of production for the rehearsal to be informative. Minimum lab build:

• The same number of domain controllers as production (within reason — pairs of DCs per site are usually enough).
• FSMO role placement matching production (PDC Emulator, RID Master, Infrastructure Master, Schema Master, Domain Naming Master).
• DNS topology matching production (forwarders, conditional forwarders, AD-integrated zones).
• Time source matching production (PDC Emulator configured against an authoritative external source).
• A representative sample of SYSVOL data — the GPOs, scripts, and folders that production uses.

The lab is not the production network. It runs on isolated virtual networking with no route into production AD or production DNS.

Step 5 — Run the rehearsal

The rehearsal follows the Microsoft AD Forest Recovery Guide phases. Treat each phase as a checkpoint with a timed observation:

1. Identify a writable DC backup to restore — usually the most recent verified System State backup on the PDC Emulator.
2. Restore the first DC — boot into DSRM, restore System State, transfer FSMO roles authoritatively if needed, reset trust passwords.
3. Clean metadata — remove the lingering objects for DCs that will not be brought back.
4. Re-promote remaining DCs — promote new DCs from clean media; replicate from the recovered authoritative DC.
5. Rebuild SYSVOL — authoritative restore of SYSVOL on the first DC, then replication out.
6. Reset trust relationships — domain trusts, external trusts, and any forest trust.
7. Reset krbtgt twice, twenty-four hours apart — the ASD and Microsoft recommendation to evict any latent golden-ticket attacker. MITRE ATT&CK T1558.001 (Steal or Forge Kerberos Tickets — Golden Ticket) describes the technique mitigated by this reset.
8. Reset privileged account passwords — Enterprise Admins, Domain Admins, Schema Admins, Account Operators.
9. Validate DNS — both AD-integrated zones and forwarders.
10. Validate time — PDC Emulator authoritative for the forest.
11. Re-enable replication and bring tier-1 and tier-2 services back online in the lab.

Record the wall-clock time for each phase. The first rehearsal is the slow one; the second runs substantially faster; by the third the team is operating from muscle memory.

Step 6 — Document the outcomes

The rehearsal output is a document, not a tick-box. Capture:

• Wall-clock time for each phase.
• The decisions made at each fork (which DC was the source of truth, which FSMO transfers were authoritative).
• Every gap discovered (the backup of the certificate authority that wasn't taken, the DNS forwarder that pointed at a production IP, the service account passwords that nobody had documented).
• The remediation owner and target date for each gap.

The document is the ML2 evidence pack for restoration testing. ASD assessors expect it; Australian Privacy Act 1988 breach-response readiness depends on it.

Step 7 — Set the krbtgt cadence

After the rehearsal, set a recurring six-to-twelve month krbtgt rotation cadence in the production environment. ASD's Restricting Administrative Privileges guidance (ACSC, 2025) reinforces this as a privileged hygiene practice. Microsoft publishes a krbtgt reset script on GitHub that performs the reset and waits the required replication interval before the second reset.

The Semperis Purple Knight Community Report 2025 observed that organisations with a regular krbtgt rotation cadence detect golden-ticket activity faster — the cadence itself is a detection control because forged tickets stop working at the rotation point.

What to avoid

• Skipping the read-back. A backup job that reports success has not been verified.
• Backing up only one domain controller. A site outage is more likely than a forest-wide event; pick a DC in each site.
• Storing backups inside the protected domain. A compromised domain admin can delete the backups before the ransomware encrypts production.
• Treating a single-object restore as restoration testing. ML2 expects a real recovery, not a spot test.

Where to go next

• The pillar guide for the full programme view: AD tier model and Essential Eight ML2 recovery.
• Baseline your full posture: the Active Directory Security and Resilience Assessment.
• Practitioner-led deep dive: the paid Active Directory Resilience Review.

Sources cited

• Microsoft. Active Directory Forest Recovery Guide. Microsoft Learn, 2025 reviewed.
• Microsoft. AD DS Backup and Recovery. Microsoft Learn, 2025.
• ASD. Essential Eight Maturity Model. Current 2025 revision.
• ASD. Information Security Manual (ISM-1511). November 2025 release.
• ACSC. Restricting Administrative Privileges. 2025 revision.
• MITRE ATT&CK. T1558.001 Steal or Forge Kerberos Tickets — Golden Ticket. 2025.
• Semperis. Purple Knight Community Report 2025.

Sources referenced in this article: ASD Essential Eight Maturity Model, ASD Information Security Manual (ISM-1511), Microsoft Active Directory Forest Recovery Guide, Microsoft AD DS Backup and Recovery, ACSC Restricting Administrative Privileges, ACSC ransomware guidance, MITRE ATT&CK T1558.001, Semperis Purple Knight Community Report 2025, and Veeam, Commvault, Cohesity and Rubrik reference architectures.