The DSRM Admin Password: Active Directory's Forgotten Local Backdoor

The Directory Services Restore Mode account is a local admin on every domain controller that never expires and is rarely audited. Here is how attackers abuse it for stealthy persistence and how to lock it down.

Every domain controller carries a second administrator account that most teams forget exists. When you promote a server with dcpromo (or the modern Install-ADDSDomainController), Windows prompts you for a Directory Services Restore Mode (DSRM) password. You type something, click Next, and never think about it again. That account is a local administrator baked into the DC's SAM hive — outside Active Directory, outside your password policy, outside your PAM rotation. For attackers who already have Domain Admin, it is one of the cleanest persistence mechanisms available. This post explains why DSRM is dangerous, how it is weaponized, and the exact controls that neutralize it.

What DSRM actually is

DSRM is a boot mode for repairing or restoring the Active Directory database (ntds.dit) when AD is offline. Because you cannot log in with a domain account when the directory itself is down, every DC keeps a break-glass local admin whose credentials live in the local SAM, not in AD. The password is set once at promotion and — critically — never expires and is not governed by any Group Policy. On a DC that was promoted five years ago, the DSRM password is often still whatever the admin typed that afternoon, undocumented and unrotated.

Why attackers love it

Two Microsoft behaviors turn a forgotten recovery account into a backdoor:

DSRM password sync. Since Server 2008, ntdsutil lets you sync the DSRM password to any domain account, including a low-value service account. An attacker with DA can set the DSRM hash to a value they control without touching the built-in Administrator.
Network logon with DSRM. By default DSRM only works at the console in restore mode. But a single registry value — DsrmAdminLogonBehavior under HKLM\System\CurrentControlSet\Control\Lsa — can be flipped to 2, allowing the DSRM account to authenticate over the network while the DC is running normally. Combine that with a known DSRM hash and you have pass-the-hash access to a domain controller that survives every user-password reset in the domain.

The attack in three commands

The technique (MITRE ATT&CK T1098 / T1207-adjacent) is compact enough to fit in a single console session:

# 1. Set the DSRM password from an existing account's hash
ntdsutil "set dsrm password" "sync from domain account svc-backup" q q

# 2. Enable network logon for the DSRM account
reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v DsrmAdminLogonBehavior /t REG_DWORD /d 2 /f

# 3. Later: pass-the-hash to the DC as the local Administrator
# (the DSRM account authenticates as the DC's local admin)

Nothing here trips a domain password policy, nothing shows up in a normal user audit, and the account name is simply Administrator on the DC — easy to overlook among legitimate local accounts.

Detecting DSRM abuse

The good news: every step leaves a trace if you are collecting the right events.

Registry change to DsrmAdminLogonBehavior. If this value exists and is not 0, someone deliberately enabled online DSRM logon. There is almost no legitimate reason for a value of 2 in steady-state operations.
Event ID 4794 — "An attempt was made to set the Directory Services Restore Mode administrator password." This fires on any ntdsutil DSRM password operation. It should be rare enough that every occurrence warrants a look.
Logon type 2/3 as the DC's local Administrator outside of an actual restore-mode boot — a strong signal that the network-logon behavior is being used in anger.

If your DCs are generating 4794 events you did not initiate, treat it as an active-intrusion signal, not a misconfiguration. Legitimate DSRM password changes are a scheduled, ticketed activity.

Locking it down

A defensible DSRM posture comes down to four things:

Keep DsrmAdminLogonBehavior at 0 (or unset). Only allow online DSRM logon during an actual, time-boxed recovery, then revert.
Rotate the DSRM password on a schedule and store it in your privileged vault. Microsoft's LAPS does not cover DSRM, so this is a manual or scripted process per DC — but it converts a static, decade-old hash into a rotating secret.
Use a unique DSRM password per DC. A shared DSRM password means one leaked hash unlocks every domain controller you own.
Alert on Event 4794 and the registry value so any attempt to sync or enable the account is caught the moment it happens.

Where WinSentinel fits

DSRM is exactly the kind of control that never appears on a dashboard until it is abused, because it lives in the registry and the local SAM rather than in AD. WinSentinel audits DsrmAdminLogonBehavior as part of its LSA and domain-controller hardening checks, flags any non-zero value, and surfaces it alongside the other credential-persistence findings on that machine — all 64 modules run in full on the free single-machine agent, no license gate on the DC checks that matter most.

For organizations running more than one domain controller, the Pro tier's fleet orchestration rolls those per-DC findings into a single view: the central node reports which controllers have online DSRM logon enabled, which have stale DSRM passwords, and raises a drift alert the instant one DC regresses to an insecure value. That is the difference between auditing one box and provably enforcing a DSRM baseline across every controller in the forest.

Whether you manage one server or fifty, the takeaway is the same: the DSRM account is a domain-controller-local admin that outlives every password reset in your directory. Audit it, rotate it, and alert on it — before someone else finds it first.