Non-Authoritative vs Authoritative Restore in Active Directory

Restoring a Domain Controller has two flavours. They use the same backup, the same DSRM boot path, the same wbadmin command — but a single decision afterward changes the entire outcome: non-authoritative or authoritative. Get the choice wrong and you either lose the data you tried to recover, or you wipe out perfectly good changes from the rest of the forest.

This is Part 5 of the AD Backup & Disaster Recovery pathway. Part 4 walked through the mechanics of the restore. This post is the conceptual model that decides which restore type to pick. Part 6 drives the authoritative procedure with ntdsutil.

The filing-cabinet analogy

Your company’s vital documents are stored in a giant filing cabinet system — that’s AD. A disaster happens: a fire (corruption, accidental deletion) damages parts of the system. An AD restore is rebuilding those damaged sections using backup copies.

You can rebuild two ways:

• Non-authoritative — you rebuild from backup, then ask your colleagues what they have. If they have something newer, you take theirs.
• Authoritative — you rebuild from backup and declare your rebuilt copy is the only correct version. Everyone else has to replace theirs with yours.

Non-authoritative restore — the follow-the-leader approach

The default. Most common in practice.

What happens

1. You restore a Domain Controller using a backup.
2. When that DC comes back online, it replicates with the other DCs in the domain.
3. Replication is the “asking colleagues” part. If other DCs have newer data, the restored DC accepts those updates.
4. Restored data is overwritten by current AD state.

The USN preserved view

Each object in AD has a USN (Update Sequence Number) on every attribute. When a DC writes a change, it stamps it with a higher USN. During replication, the DC with the higher USN wins. After a non-authoritative restore, your restored DC’s USNs are preserved from the backup — meaning they’re older than what the surviving DCs have. So when they replicate, the surviving DCs’ newer USNs win, and the restored DC gets the current AD state.

This is what you want when a DC fails but the rest of the domain is healthy. The restored DC catches up to the current state and rejoins the forest cleanly.

Concrete example

Friday 9:00 AM: DC01’s SSD dies. You take a backup nightly — the last good backup is Thursday 11:00 PM. Between Thursday 11:00 PM and the SSD death:

• A new user account (jdoe) was created.
• An existing user’s group membership changed.
• A GPO was edited.

You restore DC01 from the Thursday-night backup. It comes online and replicates with the surviving DC02. Within minutes:

• jdoe appears on DC01 (replicated from DC02’s newer USN).
• The group membership change is applied to DC01.
• The GPO edit shows up.

The changes made since the backup are preserved — because the surviving DC had them and they replicated to the restored DC. Backup is the floor, not the ceiling.

When to use non-authoritative

• A DC failed (hardware, OS corruption, ransomware on a single DC).
• The rest of the AD forest is healthy.
• You want the restored DC to catch up to current state.

Default behaviour

Every restore is non-authoritative unless you explicitly mark something authoritative before rebooting from DSRM. Bare-metal restore from Part 4 is non-authoritative. wbadmin start systemstaterecovery without -authsysvol is non-authoritative. You have to actively choose authoritative.

Authoritative restore — the I-am-the-law approach

The exception. Used when you need to roll back changes that have already replicated across the entire forest.

What happens

1. You restore a DC from a backup that contains the data you want back.
2. Before rebooting, you mark specific objects (users, groups, OUs) as authoritative.
3. When that DC comes back online and replicates, it forces all other DCs to overwrite their current data with the authoritative data.
4. Restored data becomes the new source of truth.

The USN bumped by 100,000 mechanism

How does AD decide the restored data “wins” against the newer data on the surviving DCs? The ntdsutil authoritative restore command bumps the USN of every marked attribute by 100,000. (Technically by the value in HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Restore Version High Version, which is 100,000 by default.)

After the bump, your restored attribute has a USN of (original + 100,000). Surviving DCs’ USNs are nowhere close to that. So at replication time, the bumped USN wins, and the marked objects are pushed out to every DC in the forest.

The 100,000 ceiling means a single object can only be authoritatively restored a few times before the USN ceiling causes problems. In practice, that’s not a limit you hit.

Concrete example

A rogue script accidentally deletes an entire OU containing hundreds of user accounts. The deletion replicates to all DCs in minutes. The AD Recycle Bin isn’t enabled (or the deletion is too old).

Procedure:

1. Reboot DC01 into Directory Services Restore Mode (DSRM).
2. Restore the system state from a backup taken before the deletion.
3. Don’t reboot yet. Open ntdsutil.
4. Mark the deleted OU as authoritative: restore subtree OU=deleted,DC=example,DC=local.
5. ntdsutil bumps the USNs by 100,000.
6. Reboot. DC01 replicates — the OU and its users are pushed out to all surviving DCs.

When to use authoritative

• Accidental deletion that has already replicated forest-wide.
• Incorrect modification (e.g., bulk group membership changes) that needs rollback.
• AD Recycle Bin can’t recover the object (pre-Server-2008-R2, recycle bin disabled, deletion older than recycled lifetime).

When NOT to use authoritative

• A single DC failed and the rest of the domain is healthy — use non-authoritative.
• You think you might want to restore something but aren’t sure — use AD Recycle Bin first.
• Forest-wide schema corruption — this is Forest Recovery, not authoritative restore. Different procedure.

Side-by-side comparison

Why PowerShell / ntdsutil for authoritative restore (not just a GUI checkbox)?

The Windows Server Backup GUI has a checkbox: Perform an authoritative restore of Active Directory files. It exists, and we briefly touch it in Part 6 — but it’s limited to whole-database authoritative restore. That’s almost never what you want.

Real authoritative restores need finer-grained control:

Granularity

ntdsutil can mark a single user, a single OU, an entire subtree, or the whole database. The GUI checkbox = whole database only. If you accidentally deleted one OU, do you really want to authoritatively restore every other user in the directory at the same time? No. You only want that one OU.

Precision

You specify the distinguished name (DN) of exactly what you want to mark. There’s no fuzzy matching, no “might be this, might be that.” restore subtree OU=Finance,DC=corp,DC=local means exactly that OU and everything below it.

Auditability

The ntdsutil session is loggable. The exact sequence of commands run, the timestamps, the DNs marked — all auditable. A GUI checkbox leaves no detail trail.

Safety through friction

Authoritative restore is dangerous. By forcing you to use a command-line tool with a DN syntax, Microsoft makes you think about exactly what you’re marking. The GUI checkbox lets you destroy a domain by accident.

Automation

For forest-recovery runbooks, ntdsutil commands can be scripted (carefully). GUI checkboxes can’t.

The decision tree

Should you do a non-authoritative or authoritative restore?

1. Is a DC physically dead and the rest of the forest is healthy? → Non-authoritative. Just restore the DC; it’ll catch up.
2. Did someone delete an object and you want it back?
   • AD Recycle Bin enabled and deletion is within recycled lifetime (default 180 days)? → Restore from Recycle Bin, no authoritative restore needed.
   • Recycle Bin not enabled, or deletion is too old? → Authoritative restore of the specific object/OU.
3. Did someone modify a bunch of objects incorrectly and the changes replicated? → Authoritative restore of the affected objects.
4. Did the entire forest schema get corrupted? → Forest Recovery — this is a distinct procedure, not authoritative restore.

Important considerations

Backups must be recent

Authoritative restore replays backup data. If your backup is from 30 days ago and the deletion was yesterday, you’re going to lose 29 days of intermediate changes on the marked objects. Backups must be recent enough that the data you want back actually existed in them. For real environments, this means daily backups, with shorter retention specifically for AD.

DSRM is required

You must boot the DC into Directory Services Restore Mode (DSRM) to do any AD restore. DSRM is a special boot mode where AD services don’t start — the database is offline, so you can modify it directly. Boot to DSRM via msconfig > Boot tab > Safe boot > Active Directory repair, or press F8 at boot (Server 2012 R2 and earlier).

Log in to DSRM with the DSRM administrator password you set when promoting the DC — not a domain admin. Domain accounts can’t authenticate in DSRM (AD is offline). If you forgot the DSRM password, reset it with ntdsutil set dsrm password — covered separately in the DSRM password reset post.

Replication latency after authoritative restore

Once you reboot the DC out of DSRM, the marked objects replicate to all other DCs. This takes seconds inside a site, minutes between sites (depending on your site links). Plan for replication latency — don’t expect the recovery to be instant on every DC. Watch repadmin /showrepl on each DC.

SYSVOL authoritative restore is separate

If you need to authoritatively restore SYSVOL (e.g., a GPO was deleted), that’s a separate flag: wbadmin start systemstaterecovery -authsysvol. The ntdsutil path covers AD database only. We’ll cover SYSVOL authoritative restore in a future post.

FSMO holder considerations

If the DC you’re authoritatively restoring is also a FSMO role holder, seize the role to another DC first — authoritative restore takes the DC offline for an unpredictable time, and FSMO operations (schema mod, password resets if PDC Emulator) need to keep working in the meantime.

Plan and document the procedure

Authoritative restore is high-risk and rarely practised — you don’t want to learn the syntax under pressure. Have the exact procedure documented for your environment, including DNs you might need, snapshot of normal replication state, and the DSRM password ready in your vault.

In summary

• Non-authoritative — restored DC pulls current state from peers. Use for failed-DC scenarios. Default mode.
• Authoritative — restored DC pushes its backup data to all peers. Use to roll back accidental deletions / modifications. Requires ntdsutil with object DNs. USN bumped by 100,000 per attribute to win replication.

GUI checkboxes are too coarse for the precision authoritative restore requires. ntdsutil gives you the surgical control needed to mark exactly what you want without collateral damage to the rest of the directory.

What’s next

Part 6 is the hands-on procedure: delete an OU, perform the system state restore from DSRM, mark the OU authoritative with ntdsutil restore subtree, reboot, and verify the OU comes back on all DCs. This is the final post in the pathway.