Directory Services Restore Mode (DSRM)

What is Directory Services Restore Mode (DSRM)?

Directory Services Restore Mode (DSRM) is a Safe Mode boot option for Windows Server domain controllers. DSRM enables an administrator to repair, recover or restore an Active Directory (AD) database. Restarting a domain controller in DSRM takes it offline so it functions only as a regular server.

DSRM is similar to the Safe Mode in the Windows operating system. However, it is only available in Windows Server domain controllers. The DSRM mode is available in these versions of Windows Server:

• Windows Server 2022.
• Windows Server 2019.
• Windows Server 2016.
• Windows Server 2012 R2.
• Windows Server 2008 R2.
• Windows Server 2008.
• Windows Server 2003.

The main purpose of DSRM is to help system admins log in to the system to restore or repair an AD database. To use DSRM, admins must create a DSRM local admin account with a password. They must use that account when they need to sign in to a domain controller with DSRM -- during server bootup -- and to restore AD backups after a system error or failure. The admin account password rarely changes during the deployment of a domain controller. However, it can be reset for any server in the domain without restarting the server using the Ntdsutil tool.

DSRM vs. Safe Mode

For a Windows Server domain controller, DSRM is not the same as Safe Mode. DSRM is used when the controller attempts to start in Safe Mode and is unable to. In general, DSRM is required only when the AD is damaged and doesn't allow an administrator to log on using their regular AD credentials. In such situations, the AD does not boot normally, so DSRM is required, especially when performing an AD domain-wide or forest-wide restore.

Process to log in to a DSRM account for admins

To restart a domain controller in DSRM, administrators must log in to the DSRM admin account. The process consists of these steps:

1. Boot DSRM, and click on Switch User > Other User.
2. As logon account name, type .\Administrator.
3. Reset the DSRM password for the .\Administrator account with the Ntdsutil command-line tool.
4. If the AD server is not working, reset the DSRM password with the lost-password recovery tool.

When logging in to the DSRM account, the initial logon prompt may show the account name as MyDomain\Administrator. However, that does not work, so the admin user must first click on Switch User and manually type the name .\Administrator.

Manual booting in DSRM is also possible by pressing the F8 key repeatedly after the BIOS power-on self-test screen and before the Windows logo appears. Doing this opens a text menu with advanced boot options, like Directory Services Restore Mode or DS Restore Mode. Admins can select the option and press the Enter key to enter DSRM.

Process to reset the DSRM admin password in Windows Server

When AD is installed on Windows Server and during the promotion process for the domain controller, the install wizard prompts the administrator to choose a DSRM password. This password provides the administrator with a backdoor to the database in case something goes wrong later on. The password is also essential for performing maintenance and recovery tasks in DSRM; however, it does not provide access to the domain or to any services.

If admins forget or lose the DSRM password, they can change it by using the Ntdsutil command-line tool. The tool is integrated with the Setpwd utility that has been part of Microsoft Windows since Windows 2000. The procedure to reset the DSRM admin password in Windows Server is as follows:

1. Click Start > Run, type Ntdsutil, and then click OK.
2. At the Ntdsutil command prompt, type set dsrm password.
3. At the DSRM command prompt, type either reset password on server null to reset the password on the current server or reset password on server servername to reset the password on another server.
4. Type the new password.
5. At the DSRM command prompt, type q.
6. At the Ntdsutil command prompt, again type q to exit.

The DSRM password can be reset for the server the administrator is currently working on or for another domain controller in the domain. Every time the password is changed, a Windows Event ID (4794) is generated so other authorized admins can see these attempts and determine if any attempt was made by a nonadmin or malicious user.

Security risks of DSRM

The password for the DSRM admin account can be exploited by malicious intruders, creating a huge security risk for organizations. For example, threat actors can use the password to create a permanent backdoor into the domain controller. This backdoor enables them to maintain persistence in the enterprise network and access AD at any time to gain entry to sensitive resources and data. They may also steal credentials from AD, manipulate privileged service accounts and intercept traffic packets by using the Local Loop Multicast Name Resolution function in Windows.

In some cases, hackers may also be able to steal privileged account hashes or elevate their privileges by exploiting open vulnerabilities or through social engineering. Forgotten, lost or default DSRM admin account passwords also increase the risk of malware attacks, Lightweight Directory Access Protocol reconnaissance and even domain dominance. Unfettered access to AD can also enable attackers to compromise the organization's backup process and extract all AD data from the ntds.dit file.

To avoid these risks, admin users must regularly update their DSRM account passwords. In addition, they must not use default passwords. It's also important to set unique account passwords for each domain controller.

Other good security practices to keep DSRM admin account passwords safe include the following:

• In the Registry, set the value of the HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior registry key to 1.
• In the Registry, ensure that the value of the HKLM\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior registry key is not set to 2.
• Monitor Windows Event ID 4794, and set alerts to notify admins if they occur.

Learn what techniques can be used to troubleshoot common issues in AD and tips on replication troubleshooting.