The Ultimate Guide: What is DSRM in Active Directory

The Ultimate Guide: What is DSRM in Active Directory (Directory Services Restore Mode)?

Directory Services Restore Mode (DSRM) is a special boot mode for Windows Server domain controllers that allows administrators to perform maintenance tasks on the Active Directory database. This mode is primarily used for restoring or repairing the database when it becomes corrupted or encounters issues. DSRM is essential for tasks such as Active Directory restoration, password recovery, database repair, authoritative restore, system state recovery, and troubleshooting or diagnostics. By using DSRM, administrators can ensure the health and integrity of the Active Directory environment, enabling robust disaster recovery and maintenance capabilities.

Table of Content

Key Uses of DSRM

1. Active Directory Restoration:
   • When the Active Directory database becomes corrupted, administrators can boot into DSRM to restore the database from a backup, which is critical for recovering from catastrophic failures affecting directory services.
2. Password Recovery:
   • If the Active Directory administrator password is forgotten or compromised, DSRM can be used to reset the password. Administrators log in using the DSRM password to reset the Active Directory administrator credentials.
3. Database Repair:
   • DSRM allows administrators to run tools such as ntdsutil to perform integrity checks and repairs on the database. This mode facilitates offline maintenance of the Active Directory database without affecting the domain controller’s ability to service client requests.
4. Authoritative Restore:
   • In scenarios where specific objects or organizational units (OUs) need to be restored, administrators can perform an authoritative restore. This ensures that the restored objects are replicated across all domain controllers, even if newer changes exist in the environment.
5. System State Recovery:
   • DSRM is used to perform system state recoveries, essential when the entire system state (including the Active Directory database, registry, and system files) needs to be restored to a previous point in time.
6. Troubleshooting and Diagnostics:
   • Administrators can use DSRM to troubleshoot and diagnose issues related to Active Directory that cannot be resolved while directory services are running. This includes isolating issues and performing necessary patches or updates.

This post will explain how an attacker could find out the DSRM account password or its hash and how he could take advantage of it. Also, it demonstrates how to secure your environment to avoid this kind of vulnerabilities.

Why DSRM password is important?

It’s known that every Domain Controller has a local administrator account, which is defined in the wizard promotion from a server to a domain controller.

This password is the back door of Active Directory and can be used to restore backups, and execute offline maintenance tasks, but also, could be used in a wrong way to damage things, such as directly modifying the contents of the AD database.

Since Windows Server 2008 has introduced the ability to start and stop Active Directory like a normal Windows service, it has become each time more unusual to boot into DSRM mode, and it’s only used to restore an Active Directory backup.

So, as booting into DSRM is not that common as it was back in Windows Server 2003, sometimes system administrators just forget about changing DSRM password regularly, or simply, do not care about it and set the same password for all domain controllers, and worse than this, set the known-for-everyone password.

DSRM Logon Behavior

Windows Server 2008 has introduced as well, the possibility to change the DSRM logon behavior, which means now you could be able to logon using the local administrator DSRM account into a DC, without the need to reboot into DSRM.

To be able to do that, you need to create the REG_DWORD DSRMAdminLogonBehavior registry value, which is located under HKLM\System\CurrentControlSet\Control\Lsa, and set its value to 1 or 2, as shown below:

Value = 0 – Only log into the DC with a domain account, which requires that another DC is available to service the request, or use the DSRM administrator account only if the DC is started in DSRM mode, this is the default setting.

Value = 1 – Log into the DC with a domain account or the DSRM account, only when the AD service is stopped.

Value = 2 – Log into the DC with the DSRM account, regardless of whether the AD service is stopped or started (not good idea :] ).

How it could be used in a hacker attack?

Right, lets suppose now, to make life easier, you as a system administrator, had changed the DSRM Logon behavior to value 2 in all your domain controllers.

That’s good right? After all now you can execute tasks without rebooting the DC into DSRM and don’t need to stop AD services anymore.

No, that’s not good, at all.

Since this is a valid local administrator account and it can be used to authenticate over the network (remember, you have enabled the registry to 2, now you can do it), an attacker doesn’t need to know the actual DSRM password, only he needs to know is the password hash to be able to authenticate to DC using Pass-the-Hash method.

Once he has access to your domain controller as a local administrator, he could execute some funny things, like:

But the best part is, the attacker could find out the password hash of any domain account, including those ones with high forest and/or domain privilege access.

What’s worse in the case of the DSRM account is because this account is not included on your domain password policy changing, so even if every single account password on domain had been changed, the attacker would continue having access to your entire forest / domain with high privileges.

How to mitigate this vulnerability?

1 – Do not change the standard DSRM behavior in your domain controllers (value = 0).

The registry key DSRMAdminLogonBehavior should not exist when you browse HKLM\System\CurrentControlSet\Control\Lsa, as shown below:

2 – Define an unique DSRM password for each domain controller in your entire forest, and change it regularly.

How to change the DSRM password?

1 – Open the prompt as administrator:

2 – Next, execute the following commands:

You may be wondering if there is a way to do it automatically, right? Yes, there is if your domain controller is running Windows Server 2008 SP2 or newer versions. Have a look below how to do that in details.

Automating the DSRM password changing

Since Windows Server 2008 R2 a new feature was introduced that enables you to copy a password from a domain account, it makes maintenance of the DSRM across the entire domain much easier, since you can now schedule a task on each domain controller to copy the password of the domain account on a regular basis. You can do it following the below steps:

1 – Create a domain account with no administrator privileges, just a simple domain user, and leave it disabled, do not enable it:

2 – Repeat the above steps for each domain controller you will automate the DSRM password change, the result will be something like that:

3 – Next, let´s create a GPO to schedule the tasks to automatically change the DSRM password:

4 – Name it as GPO – Secure_AD_DSRM_Password_Sync and edit it:

5 – Create a new Schedule Task (at least Windows 7) under Preferences > Control Panel Settings > Schedule Task, as shown below:

6 – On the tab General, set up the settings as shown below:

7 – Next, on the tab Triggers, click on New… and on the screen New Trigger, set up the settings as shown below:

8 – Next, on the tab Actions, define the Action as Start a program, and type the following commands. After that, click on Ok twice to close the wizard.

Program/script: %windir%\System32\ntdsutil.exe

Arguments: “set dsrm password” “sync from domain account dsrm-win2k12dc01” q q

Note: This GPO will be applied only to the domain controller win2k12dc01 as shown in the next steps. For another domain controllers, you have to change the above argument to the respective domain account previously showed. Remember, each domain controller will have a dedicated domain account to synchronize the password.

9 – The output of this setting should be like below. Close the edit screen and return to Group Policy Management screen.

10 – Now, back to Group Policy Management, let’s remove the default group Authenticated Users, and select the Domain Controller computer object we want to apply this policy, in this example will be win2k12dc01:

Click on Add.., then click on Obect Types.. to select Computers, as shown below:

Type the domain controller computer’s object and then Ok:

The output should be like below:

11 -Now, select the OU Domain Controllers, right click on it, and select Link an Existing GPO…, as shown below:

12 – Select the GPO previously created and click on Ok:

13 – Open the prompt as administrator and run: gpupdate /force. Then restart the domain controller in order to get the new schedule task setting, as shown below:

14 – After to have rebooted the domain controller, open the Task Scheduler console and check if the new task DSRM Password Sync is showed correctly as below:

15 – Allow time to the task be executed and then, reboot the domain controller into DSRM. Use the same password you have set for the domain account. If everything was correctly done until this step, you should be able to successfully logon, as shown below:

Conclusion

Now, perform the above steps for every domain controller in your forest, and make sure to change the password for the domain accounts used to sync the password with the DSRM at least once a month.

The only way to make sure you have a safe environment is to set an unique DSRM password for every domain controller on your forest, and change it in a regular basis. Also, make sure the DSRMAdminLogonBehavior registry key is not set to 2.

Still need help to resolve Active Directory issues?

Running out of ideas and time on how to fix Active Directory issues in your environment?

Please, get in touch with me, I will be happy to provide a quick resolution for you on how to fix GPO with a fair price.

References:

Check out further details about the Pass-the-Hash attack using DSRM here.

Check out more similar articles below: