TL;DR
Identity disaster recovery should restore trusted access before dependent workloads return to service. Start by distinguishing an outage from a compromise, then establish an administrative path that does not depend on the failed environment. Recover Active Directory using a tested forest-specific plan, validate Microsoft Entra ID configuration before restarting hybrid synchronization, and treat certificate validation separately from certificate issuance. Restore privileged and workload access with explicit owners and release gates. The final test is not whether an administrator can sign in. It is whether the intended business transaction succeeds while unauthorized access remains blocked.
Introduction
A disaster recovery plan can be technically detailed and still begin at the wrong dependency. Virtual machines have recovery priorities, databases have restore procedures, and networks have failover configurations. The plan then assumes that administrators can reach those systems, applications can authenticate, and the certificates connecting everything remain trustworthy.
Consider a hybrid expense-management application. Users authenticate through Microsoft Entra ID, a backend service uses an Active Directory account to access a database, internal connections use enterprise-issued certificates, and administrators retrieve credentials through a privileged access platform. Restoring the application servers addresses only part of that design.
The recovery sequence must also answer who can operate the platform, which identity state is acceptable, and what evidence permits the application to reconnect. Those questions become more important when the incident involves compromised credentials rather than unavailable infrastructure.
This article develops an operational recovery model for that hybrid environment. The scope includes AD DS, an existing Entra tenant, enterprise certificate services, and privileged access dependencies. It is a framework for building and testing the runbook, not a replacement for Microsoft’s forest recovery procedures or an environment-specific incident response plan.
Define the Failure Before Choosing the Recovery Path
An identity service can be unavailable, incorrectly configured, or no longer trustworthy. Those conditions may produce similar symptoms, but they should not produce identical recovery actions.
Use the following decision model before approving a restore:
| Incident condition | Initial recovery direction | Decision that must be resolved |
|---|---|---|
| A server or site fails, but trusted identity services remain | Use healthy capacity and repair the affected components | Is the surviving service both reachable and trustworthy? |
| Objects, permissions, or policies change incorrectly | Recover the affected configuration at the smallest appropriate scope | Which changes must be reversed, and which legitimate changes must remain? |
| Directory integrity or privileged credentials are compromised | Contain the affected environment and establish a trusted recovery state | Which backups, keys, administrators, and systems can be accepted? |
Microsoft’s Active Directory Forest Recovery guidance is a forest recovery process, not the default response to every failed domain controller. Its backup-selection guidance also makes an important distinction: the newest backup is not necessarily the safest one.
For a security incident, the recovery point must be evaluated against the incident timeline. Restoring yesterday’s directory is not useful when yesterday’s directory already contained the unauthorized changes.
Choose the recovery mechanism after classifying the failure, not because a backup is available.
Map the Identity Recovery Dependencies
“Identity before workloads” is a dependency rule, not an instruction to restore every identity component before doing any infrastructure work.
You still need enough compute, storage, networking, name resolution, time, and key access to begin. The design objective is to make that minimum recovery environment operable without requiring the production identity services it is supposed to recover.
The following diagram shows the workstreams and their shared release boundary. It is not a universal server startup order.
Entra administration may be recoverable while AD remains isolated. An enterprise CA may depend on recovered AD configuration. A certificate distribution endpoint may need to return before the issuing CA does. Record those relationships explicitly rather than treating each box as an independent restoration job.
For each dependency, document its owner, administrative access path, recovery material, validation method, and release condition. Include the systems that recovery operators use, not just the systems listed in the application inventory.
Prepare the Recovery Prerequisites
The first useful exercise is simple: assume normal single sign-on is unavailable and attempt to retrieve the recovery instructions and credentials.
A runbook stored only behind the failed identity provider is not an effective starting point. Neither is a backup repository whose decryption material can be retrieved only from an unavailable vault.
Prepare a protected recovery package covering three areas:
- Administrative access: designated workstations, supported emergency management paths, authorized custodians, and an independent communication method.
- Recovery material: tested backups, required decryption keys, protected configuration baselines, relevant account recovery information, and vendor procedures.
- Decision authority: incident classification, recovery-point approval, technical owners, release authority, and evidence-retention requirements.
Keep secret values out of ordinary runbooks and change tickets. Document the protected retrieval process and test it with the people who would actually perform recovery.
Establish Independent Entra Emergency Access
Microsoft’s Manage emergency access accounts in Microsoft Entra ID guidance recommends at least two cloud-only accounts that are neither synchronized nor federated. It calls for permanently active Global Administrator assignments, phishing-resistant authentication, protected credentials, monitoring, and designated secure workstations.
The current guidance also excludes these accounts from Conditional Access policies that could block or restrict emergency sign-in. That is not a recommendation for password-only access. Microsoft identifies FIDO2 passkeys and appropriately configured certificate-based authentication as methods that satisfy mandatory MFA requirements.
For an exercise involving PKI failure, test whether the emergency account’s authentication method depends on that same PKI. A separate FIDO2 path can remove that particular dependency, although it still requires Entra authentication to be available.
The goal is not an account with fewer controls. It is an access path whose controls remain usable during the incident being tested.
Recover Active Directory Into a Trusted State
AD recovery needs a documented directory procedure, not a collection of independently restored virtual machines.
Microsoft recommends regularly backing up at least two writable domain controllers per domain. Its recovery guidance also requires the relevant administrative and Directory Services Restore Mode credentials. Preserve protected password history for the backups you retain, and test the supported restore method against your actual server and backup configuration.
Establish the Initial Recovery State
For a full forest recovery, Microsoft’s initial recovery procedure begins with a writable domain controller in the forest root domain. Recover parent domains before their children, using isolation and the prescribed handling of AD DS, SYSVOL, DNS, operations-master roles, and time configuration.
Do not reconnect unrecovered domain controllers simply because they become available. Their disposition belongs in the forest recovery plan, including isolation, metadata cleanup, and redeployment where required.
The first release decision should establish that the recovered directory is suitable to become authoritative. Additional capacity comes after that decision, not instead of it.
Reconcile Access Changes Made After the Backup
A historical restore loses later directory updates. The practical consequence is that it can also reverse a legitimate security action.
Suppose the selected backup predates an employee’s account disablement. Reconcile that change before allowing the recovered directory to serve production authentication. Apply the same review to privileged memberships, service identities, and other security-critical changes.
For compromise recovery, follow the prescribed administrative credential remediation. Microsoft’s separate krbtgt procedure requires two resets with a waiting interval based on the configured ticket lifetimes. Do not turn that into two immediate commands. Review group managed service accounts when their password-generation material may have been exposed.
Collect Diagnostic Evidence Without Changing Directory State
After the approved recovery steps, selected dcdiag tests provide useful diagnostic evidence. Run the following from an authorized Windows recovery administration environment with the AD DS diagnostic tools installed and connectivity to the selected domain controller. Replace the example hostname.
# Target only the domain controller approved for this recovery stage.
[string]$DomainController = "dc01.corp.example"
if (-not (Get-Command dcdiag.exe -ErrorAction SilentlyContinue)) {
throw "Install the approved AD DS diagnostic tools before continuing."
}
# Inspect advertising, required services, and SYSVOL readiness.
dcdiag.exe "/s:$DomainController" `
/test:Advertising /test:Services /test:SysVolCheck /v
# Inspect basic DNS configuration without requesting update tests.
dcdiag.exe "/s:$DomainController" /test:DNS /DnsBasic /v
These commands do not perform a restore or request repairs. Review the named test results and retain the output. Connectivity and permissions failures are not evidence that the directory itself is damaged.
Passing these tests is also not proof of security integrity, correct SYSVOL contents, or forest-wide replication health. Complete the remaining checks in the recovery plan and validate real authentication and authorization behavior.
Recover Entra Configuration Before Reconnecting Hybrid Changes
Treat tenant access, tenant configuration, and hybrid synchronization as separate recovery concerns. An administrator reaching the portal does not prove that application permissions are correct or that the next synchronization cycle is safe.
Confirm the Actual Authentication Dependency
Microsoft’s hybrid authentication guidance distinguishes cloud password validation through password hash synchronization, validation through on-premises pass-through authentication agents, and federation to another identity provider.
That distinction matters during AD recovery. A stopped synchronization server does not necessarily stop cloud authentication using already-synchronized credentials. Pass-through authentication and federation have different dependencies.
Password hash synchronization can support a planned contingency, but failover from pass-through authentication is not automatic. Establish and test the alternate method beforehand. During compromise recovery, also evaluate credential trust; continued authentication does not establish that the credential is safe.
Understand What Native Tenant Recovery Covers
As documented on September 10, 2026, Microsoft Entra Backup and Recovery automatically backs up supported directory objects daily and retains up to seven days of history. Microsoft documents difference reports and recovery scoped to supported object types or individual object IDs. Its listed prerequisites include a workforce tenant with Entra ID P1 or P2 licensing.
This is not a complete tenant rollback. Microsoft’s scope documentation limits recovery to supported properties and excludes recovery or recreation of hard-deleted objects. Group ownership changes and dynamic group rule changes are examples of coverage gaps.
Build an object-and-property coverage record for the configurations your critical applications require. Use native recovery where it fits, and retain protected configuration baselines and tested reconstruction procedures for uncovered requirements.
Review Synchronization Before Allowing Exports
For Microsoft Entra Connect Sync, staging mode allows imports and synchronization while suppressing normal exports. Password synchronization and password writeback also stop in staging mode. Microsoft documents reviewing pending changes before activating the server and maintaining only one active Connect Sync server.
Staging mode is not an isolation boundary: it still connects to directories, and an operator can manually force an export. Use it only within an approved recovery environment and controlled administrative process.
Stop before activation when pending changes contain unexplained deletions, identity-matching changes, or permission effects. Do not extrapolate Connect Sync staging behavior to Cloud Sync or another provisioning platform; those need their own supported procedures.
Recover Certificate Trust Separately From Certificate Issuance
A CA service and the services that validate its certificates do different jobs. Existing certificates do not require the issuing CA to participate in every transaction, but clients still need the applicable trust chain, validity checks, and revocation information.
The PKI recovery plan should therefore distinguish restoring issuance from preserving validation.
Protect the Complete CA Recovery Material
Microsoft’s Migrate a Certification Authority guidance identifies the CA database, private keys, registry configuration, CAPolicy.inf, and enterprise CA template list as backup material. It also explains that certificate templates and their CA associations reside in AD DS rather than being fully captured by the CA database backup. HSM-protected keys require the hardware security module vendor’s procedures.
Use that component inventory to test your recovery coverage. Do not treat the planned migration procedure itself as a complete compromise-recovery runbook.
In the exercise, require the PKI team to demonstrate access to the key material and supporting configuration. A backed-up server is insufficient when nobody can complete the required key-recovery process.
Test the Relying Service, Not Just the CA Console
Certificate validation needs to succeed from the systems that consume the certificate. Test the required chain, intended usage, validity period, and applicable revocation path from those locations.
For Microsoft Entra certificate-based authentication, the current documentation describes CRL caching and failure when required revocation information has expired and cannot be refreshed. It does not support OCSP. A healthy enterprise OCSP responder therefore does not prove that Entra certificate-based sign-in will work.
Reconcile revocations and publication state after a CA restore. Do not respond to a validation failure by broadly disabling certificate checking or publishing stale revocation information.
Separate Key Loss From Key Compromise
A securely recovered key may resolve key loss. It does not resolve key compromise.
RFC 5280 explains that a compromised CA signing key can enable fraudulent certificates and revocation information. That incident can require revocation, replacement certificates, and updated trust anchors, depending on the affected authority.
Keep the affected workload isolated until its required trust path is accepted. Restoring the old CA is not a substitute for replacing compromised authority.
Restore Privileged Access and Workload Identities
Recovering privileged access should return operators to controlled administration, not leave the environment dependent on broad emergency permissions.
For the privileged access platform, test the complete path: an approved operator reaches the service, uses the supported recovery mechanism, accesses the permitted target, and produces an attributable record. Include vault encryption dependencies and the credentials needed to operate the vault itself.
Before restarting automated credential rotation, reconcile the recovered vault state with the target systems. In the expense-application example, a vault backup and a restored database service may reflect different credential versions. Resolve the mismatch through the approved procedure rather than assuming that both restores selected a compatible state.
Distinguish Tenant Administration From Azure Resource Access
Microsoft documents Entra and Azure resource permissions separately. Global Administrator does not automatically provide administrative access to Azure subscriptions.
Its documented elevation mechanism grants User Access Administrator at root scope so access can be repaired. The same guidance requires removing that elevation after the necessary changes are complete.
Plan the permissions for the actual recovery task, including separate data-access permissions where needed. Record incident-specific grants, their owners, and their removal conditions.
Validate Application Identities and Residual Sessions
For each workload, record its expected principal identifiers, credential references, target permissions, and a representative transaction. Test the workload’s own identity rather than substituting an administrator account.
Existing sessions require separate attention. Microsoft’s emergency access-revocation guidance explains that applications control their own session cookies; Entra cannot directly revoke a cookie issued by another application. Microsoft also documents that previously issued managed identity tokens can remain usable after identity deletion, depending on the target’s authorization checks.
Test both fresh access and access established before containment. A failed new sign-in does not prove that an old session has lost its authority.
Release Workloads Against Evidence, Not Startup Status
Return to the expense-management application. Its release test should show that a permitted employee can authenticate, submit a test expense, and reach the intended backend using the application’s own identity. It should also show that a disabled test identity is denied and that the application identity cannot perform an administrative database operation.
That is a more useful result than a successful administrator login or a green virtual machine status.
Use a gate record that connects the test to an accountable owner:
| Release gate | Evidence required | Stop condition |
|---|---|---|
| Recovery administration | Approved operators can reach required management systems | Access depends on an unavailable or untrusted service |
| Directory and cloud configuration | Accepted identity state, reconciled critical changes, reviewed synchronization effects | Unexplained privilege, deletion, or matching changes remain |
| Certificate trust | Required chains and revocation paths validate | Compromised authority or unresolved validation failures remain |
| Privileged and workload access | Scoped permissions and attributable operations work | Broad exceptions are required to complete the test |
| Business transaction | The allowed transaction succeeds and prohibited access fails | Only cached access works, or a negative test succeeds |
Assign technical owners to the evidence and an incident authority to workload release. Different applications can have different dependency sets. A service that does not use the affected directory should not wait for it unnecessarily, while a dependent service should not bypass its gate because its recovery deadline is approaching.
Troubleshooting and Safe Fallbacks
A recovery runbook needs a controlled response when a gate fails. “Keep troubleshooting while production reconnects” is not an acceptable default.
Authentication Succeeds but the Transaction Fails
Inspect the identity used by the failing operation, the target permission, the credential version, and the certificate path. Preserve the failing transaction and its correlation information. Avoid using a broad administrator role as the workaround because it removes the authorization condition the test was meant to validate.
The Restored Environment Contains Unexplained Identity Changes
Hold affected synchronization and workload release. Compare the recovered state with the approved baseline and security-change record. For a compromise-driven recovery, remain isolated while the recovery point or remediation scope is reassessed.
Certificate Validation Fails After the CA Returns
Check publication endpoints, required chain material, time, and revocation freshness from the relying service’s perspective. Restore the missing dependency or use an already-approved alternate trust path. Do not create a general certificate-validation bypass to make the recovery dashboard green.
The Selected Recovery State Is Rejected
Return to a prior approved checkpoint or rebuild the affected component using the supported recovery method. Do not assume an identity recovery can be reversed like an application deployment. Credential rotation, synchronization exports, and changes consumed by downstream services require their own reconciliation decisions.
Before closing the incident, remove temporary grants, restore normal privileged workflows, review emergency access activity, and validate replacement backups. Measure time to trusted administration and time to the first accepted business transaction separately. Those measurements show where the next exercise should focus.
Conclusion
Recovering identity before workloads is not simply a decision to start domain controllers first. It is a decision to make trusted administration, accepted directory state, certificate validation, and controlled permissions prerequisites for dependent services.
Build the recovery plan around those dependencies. Separate availability incidents from compromise recovery, preserve an administrative starting point outside the failed identity path, and review the effects of restored configuration before reconnecting automation.
The next practical step is to select one critical application and rehearse its recovery without normal single sign-on, an existing administrator session, or a pre-unlocked vault. Require evidence for both permitted and denied actions before releasing it.
A workload is recovered when the right identities can use it, the wrong identities cannot, and the operating team can demonstrate both.
External References
- Microsoft: Active Directory Forest Recovery – Identify the problem
Canonical URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-identify-the-problem - Microsoft: Active Directory Forest Recovery – Determine how to recover the forest
Canonical URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-determine-how-to-recover - Microsoft: Active Directory Forest Recovery – Perform the initial recovery
Canonical URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-perform-initial-recovery - Microsoft: Active Directory Forest Recovery – Reset the krbtgt password
Canonical URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password - Microsoft: dcdiag
Canonical URL: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag - Microsoft: Manage emergency access accounts in Microsoft Entra ID
Canonical URL: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access - Microsoft: Choose the right authentication method for your Microsoft Entra hybrid identity solution
Canonical URL: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/choose-ad-authn - Microsoft: Microsoft Entra Backup and Recovery overview
Canonical URL: https://learn.microsoft.com/en-us/entra/backup/overview - Microsoft: Supported objects and recoverable properties in Microsoft Entra Backup and Recovery
Canonical URL: https://learn.microsoft.com/en-us/entra/backup/scope-supported-objects-limitations - Microsoft: Microsoft Entra Connect: Staging server and disaster recovery
Canonical URL: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-staging-server - Microsoft: Migrate a Certification Authority
Canonical URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/migrate-certification-authority - Microsoft: Microsoft Entra certificate-based authentication Certificate Revocation List (CRL)
Canonical URL: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-certificate-revocation-list - Microsoft: Elevate access to manage all Azure subscriptions and management groups
Canonical URL: https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin - Microsoft: Revoke user access in an emergency in Microsoft Entra ID
Canonical URL: https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access - Microsoft: Managed identities for Azure resources frequently asked questions
Canonical URL: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/managed-identities-faq - IETF: RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Canonical URL: https://www.rfc-editor.org/rfc/rfc5280.html
TL;DR Hybrid platform dependency mapping should explain what a business service needs to run, restart, change, and recover. An inventory tells you...