This case study is real, the entities are not. Details have been changed to protect the innocent.

When ACME Corporation, a major South African life insurer, architected its environment around Active Directory (AD), they did what most mature enterprises do: invested in redundancy, backup, and a belt-and-braces approach to critical systems. With close to 100,000 user and application objects distributed across multiple datacentres and several cloud services, ACME had every reason to believe their identity backbone was resilient.

Then came the day the process misfired.

In a matter of hours, more than 1,000 applications ground to a halt, victims of unauthorised changes cascading through their AD. The initial root-cause analysis was academic—the business reality was immediate.

What ACME Thought They Had: The Illusion of Backup

Like many, ACME assumed their AD backup—folded into their standard backup set—would save the day. Marketing materials had promised attribute-level recovery, minimising downtime and business disruption.

But as the team discovered, that promise had an asterisk the size of Johannesburg:

• Attribute-level restore was contingent on the AD Recycle Bin being enabled.

• Even then, the Recycle Bin could only rehydrate a subset of attributes—no Group Policy Objects (GPO), no symbolic links, and certainly no authoritative full-object restore.

• Microsoft’s official advice? An authoritative restore from backup—a process, as it turned out, completely untested in ACME’s live environment.

 

This was not a “click next” restore scenario…

How Recovery Actually Worked

 

The only viable backup in ACME’s arsenal: a raw NTDS.DIT file (the AD database), extracted from their existing backup tool. But here’s where things turned in their favour—Quest Recovery Manager for Active Directory (RMAD) became the savior needed to rescue their metaphorical bacon.

Steps taken:

1. Mount the NTDS.DIT Securely:

   The backup was mounted within ACME’s own environment—no third-party exposure, no loss of control. This is critical to maintain audibility of the process and to reduce further risk of exposure.

2. Analyse the Blast Radius:

   Using RMAD, we compared the “before and after” state for the affected accounts, identifying which attributes had been lost or changed.

3. Prove Restoration on a Subset:

   Before touching production, we performed a controlled restore on a subset of accounts, validating the process with ACME’s own internal stakeholders.

4. Bulk Recovery:

   With proof in hand, the full-scale recovery proceeded—returning hundreds of critical applications to life, with no risk of collateral damage.

 

 

Like many, ACME assumed their AD backup—folded into their standard backup set—would save the day. Marketing materials had promised attribute-level recovery, minimising downtime and business disruption.

But as the team discovered, that promise had an asterisk the size of Johannesburg:

• Attribute-level restore was contingent on the AD Recycle Bin being enabled.

• Even then, the Recycle Bin could only rehydrate a subset of attributes—no Group Policy Objects (GPO), no symbolic links, and certainly no authoritative full-object restore.

• Microsoft’s official advice? An authoritative restore from backup—a process, as it turned out, completely untested in ACME’s live environment.

 

Again, This was not a “click next” restore scenario.

 

 

What Should Have Happened:

 

AD Backups should be auditable, repeatable, and fully under the Active Directory Services team’s control.

Our ideal scenario:

• Regular, Purpose-Built AD Backups:

  Use Quest RMAD to schedule secure, appliance-based AD backups—automatically, with tested recovery procedures.

• No Dependency on the Backup Team:

  Restore operations should not require waiting for a generalist backup admin to locate and copy a NTDS.DIT file, nor should they expose critical assets on uncontrolled filesystems.

• Zero Trust Aligned:

  Recovery operations are logged, auditable, and defensible—fitting a Zero Trust, “Assume Breach” security model. Moreover, since the backup can be tested – a backup is only a backup if you can restore it – it also functions as the last line of defense in our Zero Trust mindset.

 

Why AD Specific Backup Isn’t “Belt and Braces”

It’s tempting to believe that all backup vendors offer attribute-level restore. Here’s some truth:

• Microsoft Can’t—So Why Can Others?

  Even Microsoft’s Recycle Bin is limited. Authoritative restores are fraught with risk and rarely tested outside disaster scenarios.  Don’t test your restore scenario in the middle of a disaster.

• Vendors Overpromise, Under-Deliver:

  “Attribute restore” often hinges on additional technologies, hidden prerequisites, or amounts to little more than a marketing tick-box.

• AD is a 26-Year-Old Attack Platform:

  Its value to attackers—and the business—demands backup and recovery fit for purpose. We must be able to recover from anything: including full DC (Domain Controller) loss or ransomware encryption.

Takeaways

 

• Test Your Backups—Don’t Assume.

• Use purpose-built tools like Quest RMAD, not generic file-level backup, for Active Directory.

• Control, audit, and document your recovery path—before you need it.

 

How to audit your own AD backup: Start with these three questions:

1. Can we restore all critical attributes, including GPOs and linked attributes on objects?

2. Is our recovery path tested—by the same team who’ll execute it?

3. If ransomware encrypted every Domain Controller tonight, what would tomorrow look like?