Authoritative restore is used when you want recovered data to win during replication, such as after accidental deletion or unauthorized bulk change. Non-authoritative restore is used when rebuilding a failed domain controller and letting healthy controllers repopulate it. The first changes directory data across the environment, while the second reintroduces a server without overriding current directory state.
How authoritative restore changes the replication outcome
Authoritative restore is the recovery choice when the directory state you restore should overwrite newer replicas. In practice, that means the restored objects are marked so replication treats them as the source of truth, which is useful after accidental deletion, mass attribute damage, or malicious changes that spread to other domain controllers.
That makes it different from a simple restore of a database or file copy. The technical point is not just recovery, but recovering identity systems after compromise in a way that intentionally wins the replication race for selected objects rather than accepting the most recent replicated state.
The practical consequence is scope. Authoritative restore is usually reserved for directory data that is known to be correct at the backup point and must be propagated back into the environment. If you apply it too broadly, you can resurrect stale accounts, group memberships, or policy settings that were already removed for good reason.
How non-authoritative restore brings a domain controller back
Non-authoritative restore is the rebuild path when the server itself is the problem, not the directory contents. You restore the failed domain controller from backup, but you do not force its data to override the rest of the forest. Once it returns, healthy controllers replicate current directory state into it.
That is why it is the safer default for a damaged or replaced domain controller. It reintroduces a server into the replication topology without asserting that its local copy is the best copy. In operational terms, the restored host is expected to catch up, not to overwrite everyone else.
The difference matters most when the issue is infrastructure failure versus directory corruption. For example, a hardware loss or OS rebuild points to non-authoritative restore, while a mistaken deletion or destructive change that has already replicated points to authoritative restore. The distinction is about which side of replication should prevail.
Why the distinction matters during incident recovery
Both methods are recovery techniques, but they solve opposite problems. Authoritative restore is about preventing bad replicated state from surviving. Non-authoritative restore is about restoring availability while preserving the current directory truth held by healthy controllers.
That makes the decision tightly coupled to compromise assessment. If you are recovering from an attack that may have modified objects, group memberships, trust settings, or privileged accounts, the recovery plan has to decide whether the restored state is trustworthy enough to replicate outward. If not, a non-authoritative restore alone can simply reintroduce the problem.
For identity teams, the useful mental model is “correctness versus reintegration.” Prioritised AD and Entra ID hardening is what reduces the chance that recovery ever has to choose between those two outcomes in the first place, by limiting who can change directory state and how far that change can travel.
Risk and Threat Considerations
Directory recovery can become a security event, not just an availability task, because the wrong restore mode can preserve compromise or reintroduce removed changes. The main risk is that administrators assume “restore” means “safe,” when the real question is whether the recovered objects should replace current replicas or be repopulated from them.
Failure mechanism: An attacker or operator error changes directory objects, and the recovery step either lets the bad state replicate again or fails to reassert the known-good state where it is needed. That can re-enable deleted privileged accounts, revert group memberships, or leave malicious configuration intact.
Impact: The environment may return to service while still carrying the original trust failure, which can extend compromise, weaken privilege boundaries, or cause the same incident to recur after recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CP-10 — System Recovery and Reconstitution | Restores and reconstitution are central to choosing the correct AD recovery mode. |
| CP-9 — System Backup | Authoritative and non-authoritative restore both depend on trustworthy directory backups. | |
| SI-2 — Flaw Remediation | Accidental or malicious directory changes often require remediation before recovery is trusted. | |
| Recommendation — Define recovery procedures that distinguish object restoration from system reconstitution. Maintain tested backups that support both object-level recovery and controller rebuilds. Remediate the underlying directory issue before returning restored controllers to service. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Executed | AD restore mode selection is part of executing the right recovery plan after disruption. |
| Recommendation — Execute the recovery plan that matches whether directory state or server availability failed. | ||
| ISO/IEC 27001:2022 | A.5.30 — ICT readiness for business continuity | Directory restore mode is a business continuity decision about which state to reinstate. |
| Recommendation — Plan directory recovery paths as part of continuity and disaster recovery preparation. | ||
Practitioner Guidance
What to verify: Before choosing the restore mode, confirm whether the problem is object-level corruption or server-level failure. If the directory state itself is untrusted, treat the restore as a data integrity decision, not just a platform recovery action.
Decision rule: If the objects on the backup should become the new directory truth, use authoritative restore for that scope; if the server should merely rejoin and sync, use non-authoritative restore. Do not mix the two assumptions in the same recovery step.
What practitioners underestimate: The hardest part is often not the restore procedure but the blast-radius judgment beforehand. Recovery teams should know which objects, groups, and policy changes are allowed to win replication, and they should document that decision before the outage becomes time-pressured.
Practitioner takeaway: Authoritative restore answers “which copy should win,” while non-authoritative restore answers “which copy should catch up,” and getting that wrong can either resurrect bad directory state or fail to repair it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org