DSRM Password: How to Secure Active Directory's Emergency Recovery Account Before an Attacker Uses It
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The DSRM account is the AD equivalent of a root password -- it grants offline administrative access to the directory database without requiring domain authentication. Unlike domain accounts, it cannot be disabled, cannot be subject to Protected Users restrictions, and cannot be monitored via normal AD security controls. The mitigations are straightforward: rotate the password regularly (or use LAPS to automate rotation), audit the DSRMAdminLogonBehavior setting on all DCs, and restrict who can access the DSRM password.
Audit and Reset the DSRM Password on All Domain Controllers
Check when the DSRM password was last set:
# There is no built-in way to see the DSRM password age via PowerShell
# The DSRM password is stored in the local SAM on each DC
# Check the DC promotion date as a proxy -- if the DC was never promoted again,
# the DSRM password may be the original value from promotion
Get-ADDomainController -Filter * | Select-Object Name, WhenCreated, OperatingSystem
Manually rotate the DSRM password on each DC:
# Run on the DC itself (or via Invoke-Command)
# Method 1: ntdsutil (runs in DSRM or normal mode)
ntdsutil.exe
# At the ntdsutil: prompt:
set dsrm password
# At the Reset DSRM Administrator Password: prompt:
reset password on server [DCname]
# Enter new password when prompted
quit
quit
# Method 2: PowerShell on each DC (requires running locally or as local admin)
Invoke-Command -ComputerName 'dc01' -ScriptBlock {
$newPassword = Read-Host -AsSecureString 'New DSRM password'
ntdsutil.exe "set dsrm password" "reset password on server null" q q
}
# Note: ntdsutil does not accept SecureString directly -- use a scheduled task
# or the Windows LAPS approach below for automated rotation
Audit DSRMAdminLogonBehavior on all DCs:
# This key allows DSRM account to log in via network -- should be absent or 0
Get-ADDomainController -Filter * | ForEach-Object {
$dc = $_.Name
$val = Invoke-Command -ComputerName $dc -ScriptBlock {
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Lsa' `
-Name DsrmAdminLogonBehavior -ErrorAction SilentlyContinue
}
Write-Output "$dc - DsrmAdminLogonBehavior: $($val.DsrmAdminLogonBehavior)"
}
# Any DC showing value 1 or 2 is allowing DSRM network logon -- remediate immediately
# Fix: Remove-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name DsrmAdminLogonBehavior
Use Windows LAPS to Manage DSRM Passwords
Windows LAPS (the built-in version, April 2023+) can automatically rotate and store DSRM passwords.
Prerequisites:
- Windows Server 2019 or later DCs (with April 2023 cumulative update)
- Windows LAPS already configured for the domain (schema extended)
Configure LAPS to manage DSRM passwords via Group Policy:
Create a GPO linked to the Domain Controllers OU:
Computer Configuration > Administrative Templates > System > LAPS
- Configure password backup directory: Active Directory
- Password Settings: Enabled -- 30 days rotation, length 20, complex
- Enable password encryption: Enabled
- Enable DSRM account password management: Enabled (this is the DSRM-specific setting)
Retrieve the DSRM password for a specific DC:
# From an authorized admin workstation
Get-LapsADPassword -Identity 'DC01' -AsPlainText
# Returns the DSRM password for DC01, decrypted
# This operation is logged as a 4662 event on the DC
Restrict who can read DSRM passwords:
# Grant only senior AD admins read permission for DSRM passwords
Set-LapsADReadPasswordPermission `
-Identity 'OU=Domain Controllers,DC=domain,DC=com' `
-AllowedPrincipals 'DOMAIN\Tier0-Admins' `
-LapsAdminAccountSid (Get-ADGroup 'Domain Admins').SID
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detect DSRM-Based Attacks
DSRM credential attacks are rare but high-impact. Monitor for these indicators:
Detect DSRM network logon attempts (requires DSRMAdminLogonBehavior = 1 or 2 to succeed):
# Event ID 4624 on a DC with:
# Account Name: Administrator (the local DSRM account name)
# Logon Type: 3 (network) or 10 (remote interactive)
# Account Domain: [DC hostname] (not the domain -- this is a local account logon)
# This is suspicious even if DSRMAdminLogonBehavior is not set -- someone may have set it temporarily
Detect DSRMAdminLogonBehavior registry changes:
# Enable Object Access audit for the registry key:
# HKLM:\System\CurrentControlSet\Control\Lsa
# Event ID 4657 (Registry value modified) for DsrmAdminLogonBehavior
# Any modification to this key should generate an immediate alert
Detect DSRM password extraction attempts via NTDS.dit access:
# Attackers who have compromised a DC often attempt to copy NTDS.dit using:
# - ntdsutil snapshot commands
# - vssadmin to create a Volume Shadow Copy
# - Direct file copy via ntds.dit path
#
# Event ID 4663 (Object access) for NTDS.dit file access (requires File System auditing)
# PowerShell Script Block Logging Event 4104 for ntdsutil or vssadmin commands
# Event ID 7036 (Service Control Manager) for Volume Shadow Copy Service starting unexpectedly
The bottom line
DSRM hardening is a two-step process: configure Windows LAPS to rotate DSRM passwords automatically on all DCs (preventing password reuse across DCs and forcing rotation), and verify DsrmAdminLogonBehavior is absent or 0 on every DC (preventing network use of the DSRM credential outside of recovery mode). Store the DSRM password retrieval permission in a break-glass access procedure -- only a small number of senior AD administrators should be able to retrieve it, and every retrieval should trigger an alert.
Frequently asked questions
What happens if I forget the DSRM password and need to use it?
If you have Windows LAPS managing the DSRM password, retrieve it via Get-LapsADPassword. If you do not have LAPS and the password is unknown, you can reset it without knowing the current password: boot the DC into DSRM (press F8 during boot), then from the DSRM command prompt run ntdsutil and use the set dsrm password command -- it does not require knowing the old password. Alternatively, reboot the DC normally and use ntdsutil remotely via the reset password on server command, which requires domain admin credentials for the domain rather than the current DSRM password.
Is the DSRM password the same on all domain controllers?
By default, no -- each DC has its own DSRM password set independently during DC promotion. However, in many organizations the same password is intentionally set on all DCs for operational simplicity, or the password is set from a template that was the same for all deployments. This means if an attacker extracts and cracks the DSRM hash from one DC's NTDS.dit, they likely have the DSRM password for all DCs. Using Windows LAPS to manage DSRM passwords ensures each DC has a unique, automatically rotated password.
Can the DSRM account be renamed or disabled?
The DSRM account cannot be disabled -- it is needed for offline AD recovery. It can technically be renamed, but this is rarely done and the name change does not provide meaningful security (the account is identified by its SID, not its name). The recommended controls are password management (via LAPS), logon restriction (ensure DsrmAdminLogonBehavior = 0 or absent), and monitoring for any logon events using a local account on a DC -- which is inherently suspicious in a well-managed environment.
How is the DSRM attack different from a Golden Ticket attack?
Golden Ticket attacks forge Kerberos tickets using the krbtgt hash and work against the domain's Kerberos infrastructure. DSRM attacks use the local DSRM Administrator account and authenticate via NTLM (or LDAP) directly against the DC's local SAM -- they bypass the Kerberos infrastructure entirely. Rotating the krbtgt password (twice) mitigates Golden Tickets; it has no effect on DSRM. The two attacks require separate mitigations. In a full AD compromise, an attacker with access to NTDS.dit typically extracts both the krbtgt hash (for Golden Tickets) and the DSRM hash (for persistent DSRM backdoor).
How do I detect if the DSRM account is being used outside of legitimate recovery scenarios?
The DSRM account authenticates via NTLM to the DC's local SAM when DsrmAdminLogonBehavior is set to 1 or 2. Normal DC operations never involve local SAM authentication -- DCs use Kerberos and domain accounts for all standard operations. Alert on: Event ID 4776 (NTLM authentication to local SAM) on any domain controller, combined with Event ID 4624 (successful logon) with Logon Type 3 (network) or Type 2 (interactive) on a DC using the DSRM account name. These events together indicate either a legitimate recovery operation (which should match a change control record) or an attacker using the DSRM backdoor technique. Any occurrence without a corresponding change ticket warrants immediate incident response.
How should the DSRM password be stored and who should have access to it?
The DSRM password for each DC should be treated as Tier 0 credentials: stored in a physical safe or HSM-backed secrets manager with break-glass access procedures, documented with the specific DC name it applies to (each DC has a distinct DSRM password), and accessible to a maximum of two or three named senior administrators. It should NOT be stored in standard password managers accessible to the IT helpdesk, in shared team vaults, or in documentation wikis. The retrieval process should require two-person authorization: two senior administrators must both authenticate to retrieve a DSRM password. Annually, verify that the stored DSRM password is current (compare the stored hash against the DC's local SAM using offline extraction from backup, not by testing logon in production) and that the access list matches your current staff. For organizations using Windows LAPS, the DSRM password management can now be integrated with LAPS for automated rotation and AD-based secure storage.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.