Why this matters

Ransomware can encrypt, delete, or corrupt Active Directory (AD) objects and user data. Restoring AD correctly is central to re‑establishing authentication, group policy, DNS and replication across your network. Doing it in the wrong order risks replication problems, lingering corrupted objects, or further outages.

At-a-glance recovery path and safe sequencing:

  • 1) Triage and isolate compromised systems.
  • 2) Identify last-known-good system state backups and export points.
  • 3) Decide authoritative vs non‑authoritative restore.
  • 4) Restore system state and SYSVOL in a controlled order.
  • 5) Validate AD, DNS, Kerberos and user logons; recover user profiles and data.

Pre-recovery triage

  • Determine which DCs are healthy vs compromised: isolate suspected infected domain controllers and remove them from the network or place them in a contained VLAN. Maintain a list of their hostnames, IPs and last contact times.
  • Identify last-known-good backups: locate system state backups, bare‑metal images or exported NTDS.dit snapshots. Prefer backups taken before any signs of infection or before malicious changes were observed. Note retention and encryption details so you can decrypt if client-side keys apply.
  • Record topology and roles: capture current FSMO role holders (or last known holders), replication partners, and DNS server status. This information guides whether to rebuild a DC or attempt a restore.
  • Preserve logs and evidence: export event logs, replication and directory service logs to a safe location for later forensics. Avoid making irreversible changes until you have confirmed restore points.

Choosing authoritative vs non-authoritative restore

Choice checklist:

  • Were AD objects encrypted, deleted, or modified globally? If many objects were removed or tampered with and other DCs still hold clean copies, a non‑authoritative restore (allowing replication to overwrite) may suffice.
  • Is your replication topology small and contained, or wide and multi‑site? Authoritative restores have significant replication implications and are riskier on multi‑site setups.
  • Is there a chance of lingering objects (USN rollback) if you repoint or clone DCs? If so, plan carefully to avoid replication conflicts.
  • Do you have a secure, clean source backup that predates the attack? An authoritative restore uses a known-good backup as the source of truth.

Authoritative restore — conceptual step sequence and cautions:

  1. Work on isolated hardware or a recovery VM whenever possible—never apply unverified restores directly on production DCs.
  2. Boot the target DC into Directory Services Restore Mode (DSRM) and apply the verified system state backup or supported restore tool. Use only supported tools like Windows Server Backup when documented or your tested enterprise backup solution.
  3. Mark selected objects (or entire domain) authoritative so that after the DC comes online it advertises higher update sequence numbers (USNs) and other DCs accept its data. This operation is effectively irreversible for those objects until a newer clean source appears.
  4. Bring the restored DC online into an isolated network to observe replication behaviour before rejoining production. Watch for USN rollback and replication errors.
  5. Cautions: authoritative restores can reintroduce an old state across all DCs and propagate deleted/malicious data if your chosen backup isn't truly clean. USN rollback can permanently desynchronize replication if you restore a cloned system without proper preparation.

Restoring SYSVOL and Group Policy safely

SYSVOL contains scripts and GPOs; its integrity is essential for consistent policy application.

  1. Restore order: restore the system state first (which includes the AD database and SYSVOL metadata) and then verify SYSVOL contents. If your backup stores SYSVOL separately (DFSR or FRS), follow the documented supported restore path for your replication method.
  2. Verify SYSVOL: compare GPO counts, GUIDs and file hashes where possible against a known-good source. Verify GPO settings in the GPMC (or equivalent) and check that scripts and templates are intact.
  3. Replication verification: allow DFSR/FRS to initialize and confirm file and folder replication health before marking the DC as authoritative for SYSVOL. If DFSR is used, ensure the service can process its backlog without collisions.

Recovering local user profiles and SID mapping

User data restoration must preserve security identifiers (SIDs) so file ownership and ACLs remain valid.

  • Restore profile folders safely: restore user profile directories to their original locations from a verified backup. Preserve NTFS permissions and ownership metadata if your backup captures ACLs.
  • When user objects were rebuilt: if AD user accounts were deleted and recreated, the new accounts have new SIDs. Restored profile folders will still be owned by the old SIDs and users may not have access. Strategies include: map old SIDs to new accounts using authoritative migration tools, reassign file ownership to the new account while preserving ACLs, or use user data export/import workflows.
  • Minimize user disruption: where possible, deliver recovered data to users via a secure share and perform ownership reconciliation in a maintenance window. Keep a copy of original folders in case further adjustments are needed.

Post-restore verification and cleanup

  • Replication health checks: run your standard replication diagnostics and watch for lingering objects, lingering replication queues or persistent errors. Use directory service and DFS logs to validate progress.
  • DNS and Kerberos: verify DNS records for SRV and DC entries, and validate time synchronization and Kerberos ticketing by performing test authentications from representative clients.
  • User logon tests: log on with several account types (administrator, normal user, roaming profile user) on different network segments to confirm authentication and GPO application.
  • Decide to retire vs rebuild: if a DC shows inconsistent replication or repeated errors after attempts to clean it, plan a rebuild: demote (if possible), rebuild OS and restore from a verified system state only after joining cleanly to the domain, or create a new DC and replicate from healthy controllers.

Troubleshooting checklist

  • Symptom: Replication errors after restore. Likely causes: USN rollback, authoritative restore mismatch, network partitions. Next steps: isolate the DC, verify backup integrity, review DS and replication logs, and consider rebuilding the DC if errors persist.
  • Symptom: Users cannot access files after profile restore. Likely causes: SID mismatch or missing ACLs. Next steps: verify ownership metadata on restored folders, map SIDs, and restore ACLs from backup metadata.
  • Symptom: Missing GPO settings. Likely causes: incomplete SYSVOL restore or DFSR backlog. Next steps: validate GPO GUIDs, compare to a known-good source and allow DFSR to finish; if necessary, recover GPOs from backup and reimport carefully.

Limitations and safe verification steps

  • Authoritative restores change replica expectations and can propagate an old state across your domain. Treat them as high‑impact operations and avoid unnecessary use.
  • Always verify backups on separate hardware or an isolated VM before touching production DCs. AgooCloud supports Windows system and file backups with changed‑chunk uploads, local-first storage options, retention and optional client-side encryption—use these features to prepare test restores.
  • Disk images created with supported Windows backup facilities are useful for recovery, but copying live databases or application files does not guarantee application consistency. Test restored application servers in a sandbox before reintroducing them to production.
  • When in doubt, prefer building a clean DC and allowing replication to seed its AD database from clean partners rather than forcing an authoritative restore from suspect backups.
Practical tip: keep a written restore runbook and regularly test restores (including SYSVOL and user profile recovery) in an isolated recovery lab. Published AgooCloud topics like "Integrating VSS snapshots with changed-chunk transfers" and "Emergency restore triage from long incremental chains" provide complementary test and staging guidance for Windows backups.

Recovering AD and user profiles after ransomware is a careful balance between speed and safety. Triage methodically, choose the least‑disruptive restore type that solves the problem, verify restores in isolation, and validate replication and authentication broadly before returning systems to users.