Identity Has to Recover Before Most of the Datacenter Matters

A recovered application cannot authenticate a user against a directory that is still offline. An administrator cannot fix the rest of the environment if the only administrative path depends on the identity system that was just lost.

That is why I treat identity differently during recovery. Under normal conditions, Active Directory and Microsoft Entra ID look like shared platform services. During a destructive outage or cyber event, they become recovery infrastructure.

Rubrik Security Cloud can protect and recover Active Directory forests, domains, domain controllers, and Microsoft Entra ID objects. Rubrik's Active Directory forest recovery workflow also includes DNS handling, Windows time settings, global catalog behavior, KRBTGT reset options, alternate recovery hosts, and support for replicated snapshots.[1][2][3][4] Protecting and recovering the forest currently requires an identity recovery entitlement and Rubrik CDM 9.2.2 or later.[1] Those capabilities matter because identity recovery is not the same thing as restoring one more VM.

Identity Is Recovery Infrastructure

Most enterprise applications depend on identity even when the application diagram does not show it.

Windows servers use the domain for computer accounts, Kerberos, group membership, service identities, and policy. Applications use service accounts and directory groups for authorization. DNS frequently rides on domain controllers. Certificate enrollment, file access, database authentication, management tools, and automation can all depend on the same directory state.

A VM can therefore boot successfully while the service remains unusable. The guest is running, but users cannot sign in, service accounts cannot authenticate, DNS records are missing, or the application cannot reach a dependency because the trust relationship behind that connection is not available.

Microsoft's forest recovery guidance starts from the same operational reality. It begins with a writable domain controller in the forest root domain, then moves through the remaining domains with parent domains recovered before their children. The initial recovery keeps those domain controllers isolated while privileged accounts and damage from the incident are addressed before the rest of the forest is redeployed.[10]

Architecture point If the recovery plan treats identity as an ordinary application tier, it is likely to discover too late that the recovery tools, recovered servers, or application dependencies were waiting on identity first.

Bootstrap Access Before You Depend on the Directory

The first identity problem during recovery is administrative access.

If the operators who need to recover Active Directory can authenticate only through the damaged Active Directory environment, the runbook has a circular dependency. The same problem exists in cloud identity when every privileged administrator depends on federation, Conditional Access, multifactor authentication, or a device state that is unavailable during the incident.

Microsoft recommends emergency access accounts for Microsoft Entra ID that are cloud only and independent of federated identity providers. It also recommends keeping the emergency access path distinct from on premises emergency access so one identity failure does not remove both administrative paths.[11]

The exact implementation will vary, but the design question is simple: who can still administer Rubrik, the recovery hosts, networking, virtualization, and identity when normal identity is unavailable?

I would validate that path before a recovery event, not while the directory is already down. The team should know where the emergency credentials are stored, who can use them, which systems they reach, what approvals apply, and how their use is audited.

Recover the Forest as a System, Not as a Domain Controller VM

Rubrik's current Active Directory forest workflow reflects that forest recovery is larger than restoring a Windows guest.

RSC can discover the forest hierarchy and protect it under SLA Domain policy. During forest recovery, the workflow allows the operator to choose a test, cyber, or disaster recovery reason, select the latest or a specific point in time, recover to original or alternate Windows hosts, configure DNS behavior, select a domain controller for each domain, and control metadata handling for domain controllers that are not selected for recovery.[1][2] Rubrik documents that recovery starts with the root domain and then moves through the forest hierarchy, and that at least one domain controller in every domain must have a backup for forest recovery to proceed.[13]

Restoring a domain controller VMDK or system volume is a storage operation. Forest recovery also has to restore a coherent directory state, account for domain ordering, and repair DNS and trust relationships.

Choosing another Windows host changes the destination. It still leaves the recovery method and integrity of the restored operating system to be verified. Rubrik's established System State Recovery and Bare Metal Recovery methods restore operating system state along with the directory. Moving that restore to another host does not automatically exclude malicious code or configuration from the recovered system. For a cyber event, I would verify the recovery point, OS state, target compatibility, and selected recovery method before trusting the recovered domain controller.[14]

Rubrik described a different method, Identity-First Recovery (IFR), in September 2026. It moves the AD database and SYSVOL into a fresh Windows installation instead of restoring the original OS. At that announcement, Rubrik said IFR would require CDM 9.5.3p2 or later and was not yet generally available. This is separate from the existing forest recovery workflow's CDM 9.2.2 minimum. Confirm current availability, licensing, Windows Server version compatibility, and support before including IFR in a recovery plan.[14]

Rubrik also exposes forest specific settings that would make little sense in a generic VM restore. The advanced recovery options include Windows time service configuration, global catalog rebuild behavior, and a KRBTGT password reset option.[3] Rubrik's documentation uses different names for the required identity recovery entitlement. I would verify the entitlement in the tenant and contract rather than hard-code one commercial label in the runbook.[1][2][3]

Recovery still has to establish usable time and DNS, a directory that can authenticate users and services, and a safe path to reconnect the rest of the environment.

DNS and Time Belong in the Identity Recovery Plan

DNS and time are easy to list as dependencies and easy to underdesign.

Rubrik's forest recovery workflow includes explicit DNS recovery choices. Operators can let RSC configure DNS automatically, provide DNS IP addresses, or leave the existing DNS configuration intact.[2] Rubrik's protection guidance also requires DNS configuration on the Rubrik cluster for forest protection.[5]

Windows time is exposed separately in Rubrik's advanced forest recovery settings. The workflow can restore the prior time configuration or use specified external time sources.[3]

That matters because authentication failures can look like application failures. A recovered server may be online while name resolution points to the wrong place. Kerberos can fail when clocks are outside expected tolerances. Service discovery can fail because DNS records or delegations do not match the recovered environment.

I would not hide DNS and time inside a generic line that says "recover Active Directory." They need explicit recovery settings, validation checks, and ownership.

Replicated Identity Copies Still Need a Recovery Path

A secondary copy of Active Directory is useful only if the team can actually recover identity from it when the primary site or Rubrik cluster is unavailable.

Rubrik supports Active Directory forest recovery from source snapshots on the source cluster or replicated snapshots on a replication target. For recovery to alternate hosts, RSC can select snapshots from multiple clusters and target a host associated with the selected cluster.[4]

The details matter more than the phrase "AD is replicated."

For recovery to the original host from a replicated snapshot, Rubrik documents additional requirements around replication targets, host registration, and which Rubrik cluster is configured as primary for the Windows host.[4] Those settings should be tested before the source cluster is unavailable.

Operational view A replicated domain controller snapshot is not an identity recovery plan until the team has proved which Rubrik cluster will orchestrate the recovery, which hosts are available, which DNS path is usable, and which credentials remain valid during a site loss.

Hybrid Identity Creates Two Recovery Surfaces

Many environments now have Active Directory and Microsoft Entra ID tied together operationally. They should not be treated as one recovery object.

Rubrik Security Cloud Foundation, Business, and Enterprise Editions cover protection and recovery of Microsoft Entra ID users, groups, and roles. Rubrik Identity Recovery adds supported Enterprise Applications, App Registrations, Conditional Access policies, Administrative Units, and other identity objects.[15] The policy-recovery capability should not be assumed to exist in every RSC subscription. Confirm the Rubrik entitlement, the tenant's Microsoft Entra licensing and permissions, and the exact objects needed for recovery.[9][15][17]

The recovery semantics are important. For Entra relationships, Rubrik provides a rollback mode that restores selected relationships to the snapshot state and an update mode that merges snapshot relationships with current relationships.[7] Conditional Access recovery has its own object and permission requirements.[9]

RSC also documents limits that affect hybrid designs. Properties of on premises users and groups synchronized from Active Directory cannot be recovered through the Entra ID recovery path. Relationship recovery covers supported top level relationships, not a recursive rebuild of every relationship. Rubrik lists mail-enabled security groups and distribution groups as unsupported for group recovery. A single user recovery operation supports up to 1,000 users. Recheck those restrictions against the version in use.[8]

That means the recovery authority for an object depends on how the identity is mastered. For synchronized users and groups, the on premises directory remains the source of authority for synchronized properties. Rubrik cannot recover those properties through its Microsoft Entra ID recovery path.

Restoring the AD forest does not, by itself, restore separate cloud-native Entra objects or Conditional Access policies. The runbook should identify which objects are mastered on premises, which are cloud native, which entitled Entra recovery tasks must run separately, and which emergency administrators remain usable while that work is happening.

Recover Enough Identity to Start the Service, Then Expand

Recover the trusted identity services needed for the first application wave. Other identity objects can be addressed as their dependent services return.

For a forest wide failure, Microsoft starts with the forest root domain and requires parent domains to be recovered before their child domains.[10] Rubrik follows the same hierarchy model: recovery starts with the root domain and moves through the forest, with a backup of at least one domain controller required in every domain.[13] Rubrik also supports alternate hosts when the original infrastructure is not the right target.[2]

From there, application recovery can proceed in controlled waves as identity services become available and trusted.

A practical sequence often looks like this:

1. Establish independent administrative access to Rubrik, virtualization, network, and identity tooling.
2. Recover the forest root domain first to isolated or controlled infrastructure, then recover parent domains before their child domains. For compromised domain controllers, confirm the backup is trusted and the selected recovery method and target OS are suitable.
3. Validate DNS, Windows time, global catalog behavior, privileged access, and the required forest security actions.
4. Validate Microsoft Entra ID access separately. Recover supported cloud identity objects, relationships, and policies as the incident requires and the tenant is licensed to use.
5. Prove the service accounts, groups, computer accounts, DNS records, and authentication paths needed by the first application wave.
6. Recover dependent applications and validate real authentication from the recovery environment before expanding the wave.

That sequence is not a vendor supplied universal runbook. It is the recovery logic I would expect the architecture to make explicit.

Trust Has to Be Validated Before Applications Are Released

A recovered directory that answers LDAP or allows one administrator to sign in is not enough evidence for the rest of the datacenter.

The recovery team should prove the specific identity functions the applications will consume. That includes DNS lookup, domain authentication, group membership, service accounts, computer trust, required role assignments, and any cloud identity or Conditional Access state used by the application path.

For Active Directory, the test should also confirm that the recovered forest is in the intended recovery state before broad reconnection. Rubrik exposes recovery controls for global catalog handling and KRBTGT reset, while Microsoft's forest recovery guidance includes cleanup, trust restoration, DNS reconfiguration, and redeployment of the remaining domain controllers.[3][10][12]

In a forest compromise, selecting a KRBTGT reset option in a recovery wizard is not proof that the security work is complete. Microsoft calls for two KRBTGT password resets with a 10-hour wait under the default ticket policy. If the ticket lifetime differs, the wait needs to be greater than the configured maximum lifetime. The team also needs evidence for privileged account remediation, trust cleanup, and other compromise-specific recovery actions before reconnecting services.[10][16]

I would keep application servers isolated until those checks pass. Otherwise, a fast VM recovery can reconnect hundreds of systems to an identity service that has not yet been validated after the event that damaged it.

Design the Dependency Map From Identity Outward

An application recovery diagram usually starts with the application. For a destructive identity event, I would reverse the view and start with the identity services.

The table is not a universal startup order. It is a design check. For each application, identify which rows it actually depends on and which proof is required before the application can be considered recovered.

Twelve Questions I Would Ask Before Approving Identity Recovery

1. Can the recovery team administer Rubrik and the recovery infrastructure without production Active Directory?
2. Is there a tested emergency access path for Microsoft Entra ID that does not depend on federation or the failed on premises directory?
3. Which Active Directory forest and domains are protected, does every domain have at least one trusted recoverable domain controller backup, and what is the forest root and parent before child recovery order?
4. When original domain controller OS instances are suspect, which supported recovery mode restores to a verified clean target, and what are its OS compatibility and availability requirements?
5. Can recovery use replicated snapshots if the source Rubrik cluster or site is unavailable?
6. What DNS configuration will exist during recovery, and who owns the change from isolated recovery DNS back to steady state?
7. What is the authoritative time source during forest recovery?
8. What is the planned global catalog and KRBTGT handling, and how will the two-reset KRBTGT sequence and other compromise remediation be verified in cyber recovery?
9. Which privileged accounts, service accounts, computer accounts, groups, and trusts are required before the first application wave?
10. Which Microsoft Entra ID objects are cloud native, which are synchronized from Active Directory, and which recovery path owns each one?
11. Which Conditional Access or other cloud identity policies could block recovery, and are the necessary Rubrik entitlement, Microsoft licenses, and permissions confirmed?
12. What test proves that a recovered application can actually authenticate users and service identities through the recovered identity path?

If those answers exist only inside the heads of the identity team, the recovery architecture is incomplete.

Recover the Trust Foundation Before You Chase Application Boot Order

Application boot order still matters. It just starts later than many recovery plans assume.

The first ordering question is whether the recovery team can administer the environment. The second is whether the identity system can safely provide DNS, authentication, roles, and trust to dependent workloads. Only after that does the usual database, middleware, and application startup sequence become meaningful.

Rubrik provides forest protection and recovery, alternate target hosts, replicated snapshots, DNS and time settings, global catalog and KRBTGT options, and Microsoft Entra ID recovery. The recovery method and licensing determine which capabilities are actually usable for a given incident, including Conditional Access restoration.[1][2][3][4][7][14][15]

The architecture still has to decide what must be trusted first, what can remain isolated, which administrative paths survive the failure, and what evidence is required before applications are allowed to depend on identity again.

Source Notes

Product behavior changes. Original workflow references were checked on September 22, 2026. Additional public Rubrik and Microsoft sources were reviewed on October 16, 2026. Authenticated Rubrik documentation was not freshly verified.

Source access: The Rubrik documentation links below may require an authorized Rubrik OnePassport account. If a link opens a sign-in page, sign in to OnePassport to view the reference. The current contents of pages behind authentication have not been independently reverified for this revision.