25 Mar

Back to the Basics – Securing the Directory Services Restore Mode Account

The Directory Services Restore Mode (DSRM) account is used to log on to a domain controller in Directory Services Restore Mode to perform maintenance and recovery tasks. This account is often forgotten by most AD administrators, which results in a significant security risk. If exploited, this security risk can cause high impact.

I have ran Active Directory security assessments for a number of small, medium, and large sized companies over the years. In almost every case, I have identified the DSRM account as a risk, because it was not being secured adequately. I felt compelled to use this post to emphasize the importance of securing the DSRM account.

This is not a post that describes how-to change the password on a DSRM account; there’s thousands of such articles on the web. This post aims to give you a thorough understanding of the risks associated with not properly securing DSRM accounts, the impact of exploited DSRM accounts, and my recommendations to secure DSRM accounts.


The Risks & Impact

In my experience, companies of all sizes have DSRM accounts with stale passwords. Furthermore, most companies fail to include DSRM accounts in their password change process.

Some of the questions I’ve asked companies include:

  • When were the DSRM account passwords last changed?
  • Do you have a formal process to change the DSRM account passwords?
  • Do you know the passwords for your DSRM accounts?
  • Does anyone outside of your team know the passwords for your DSRM accounts?
  • Do you change the passwords for your DSRM accounts when someone leaves your team?

In most cases, companies have not been able to provide the appropriate answer to most, if not all, of the above questions.

Because the DSRM account can be used to log on in Directory Services Restore Mode, and in this mode the tasks that can be performed are significant, an exploit of the DSRM account can be extremely detrimental to your AD DS forest. What follows is a partial list of tasks that can be performed in Directory Services Restore Mode:

  • Perform an authoritative restore of AD DS data
  • View and modify AD DS behavior
  • Manage AD DS database files
  • Create installation media for DCs
  • Manage LDAP protocol policies
  • Manage local administrative roles on an RODC
  • Perform metadata cleanup
  • Manage directory partitions
  • Transfer and seize operations master roles
  • Run database analysis

With the DSRM account, an attacker can modify the LDAP protocol policy in such a way that the performance of the DC is so poor during LDAP communication, that Denial of Service attack-like behavior is exhibited by the DC. To illustrate this a little better, consider the MaxActiveQueries LDAP protocol policy setting. By default, this setting has a value of 20, which means that when the number of concurrent LDAP search operations reaches 20, the DC will return a "busy" error. Now if an attacker were to change the value of the MaxActiveQueries LDAP protocol policy setting to 0 or 1, how would your DC perform?

With the DSRM account, an attacker can remove metadata associated with a domain, a naming context, a server. Can you imagine the impact of all metadata for a domain, naming context, and/or server being removed?

The fact of the matter is that you MUST secure the DSRM account on EVERY domain controller in your forest, just as you secure all other accounts that have elevated privileges in Active Directory. I cannot emphasize this enough.

Things to Know about Exploiting the Risks

It is important to mention that one must restart a domain controller to log on in Directory Services Restore Mode. To restart a domain controller, you 1) require the necessary permissions, and 2) need a means to restart the domain controller. The Shut down the system User Rights Assignment defines who can shutdown, and restart, a computer. By default, the following groups are granted this User Rights Assignment:

  • Administrators
  • Backup Operators
  • Server Operators
  • Print Operators

In my opinion, the default groups granted this permission far exceed the requirements. I discuss this in more detail in my recommendations below.

As previously mentioned, if even one has the necessary permission to restart a domain controller, they still require a means to do so. This requires that you have physical access to a domain controller, lights-out / console access, or the ability to logon through Terminal Services. If you have physical access to a domain controller, you can perform a hard reset of the server and then press F8 to select the Directory Services Restore Mode boot option. The same can be done if you have lights-out or console access to a domain controller. If you have access to log on to a domain controller by using the Remote Desktop client (in other words, you have the Allow logon through Terminal Services User Rights Assignment), then you can use System Configuration or bcdedit to modify the boot options so that the domain controller restarts in Directory Services Restore Mode.

Recommendations to Secure DSRM Accounts

For starters, you need to treat DSRM accounts as you do all other accounts that have elevated AD privileges. DSRM accounts must be secured to the same standards as the built-in Administrator account, and as accounts with membership in the default AD service management groups (Enterprise Admins, Schema Admins, Domain Admins, Administrators, etc). So how do you secure DSRM accounts? You need a comprehensive policy for DSRM accounts. A comprehensive policy should address the following:

Change the DSRM passwords on a regular basis

DSRM accounts must have their password changed on a regular basis. The question of how often is sufficient always sparks some good discussion. In my opinion, you should change the DSRM account passwords as frequently as you change the password for the rest of your privileged AD accounts. If you do not have an interval for this, then I suggest you change the password at least every 90 days. In environments that have higher security requirements, you should aim to change the passwords every month.

Use passphrases for DSRM accounts

There’s been an ongoing debate on the value of passphrases, compared to passwords, for a number of years. Microsoft published a good document that discusses this topic back in 2004, which can be found here. I am a firm believer that passphrases are more secure than passwords, so I suggest you use a passphrase for DSRM accounts. Also, the passphrase should be more than 15 characters long.

Limit the knowledge of DSRM account passwords

As with all passwords, the knowledge of the password must be limited to only those who require to know it. This is self explanatory for IT administrators.

Change the DSRM passwords immediately when someone who previously knew them leaves your team or company

If someone who has knowledge of your DSRM passwords leaves your team or company, you must change the DSRM passwords immediately. As a precaution, you should change the DSRM passwords as soon as someone leaves your team or company. You don’t know whether that individual will become disgruntled or not. This recommendation really goes hand-in-hand with the previous recommendation.

Audit the usage of Directory Services Restore Mode

In Windows Server 2008, the following event is logged when a domain controller is booted into Directory Services Restore Mode:

Product: Windows Operating System
ID: 16652
Source: Microsoft-Windows-Directory-Services-SAM
Version: 6.0
Message: The domain controller is booting to directory services restore mode.

 

You should audit this event, and include a means to be notified immediately when these events are logged. This will ensure you are aware of all instances where a domain controller is booted into Directory Services Restore Mode, including those that are not planned.

Minimize the number of users that can restart domain controllers

As previously mentioned, the default list of groups that have the Shut down the system User Rights Assignment is excessive. The default includes the following groups:

  • Administrators
  • Backup Operators
  • Server Operators
  • Print Operators

I recommend limiting this User Rights Assignment to only those who truly require it. Most times, this results in the Administrators group. However, you need to evaluate the security requirements of your organization.

Minimize the number of users that have the permission to log on to domain controllers locally

I also believe that the default number of groups that have the Allow log on locally User Rights Assignment is excessive. The default groups that have this User Rights Assignment include:

  • Account Operators
  • Administrators
  • Backup Operators
  • Print Operators
  • Server Operators

I also recommend limiting this User Rights Assignment to only those who truly require it. Most times, this results in the Administrators group. However, you need to evaluate the security requirements of your organization.

Conclusion

As I’ve stated many times, Active Directory is not secure out of the box. There are a number of reasons for this, both valid and unwarranted. However, it’s up to you to ensure you understand the all risks to Active Directory, and mitigate them accordingly.

I’ve tried to give you a thorough understanding of the risks associated with not properly securing DSRM accounts, the impact of exploited DSRM accounts, and my recommendations to secure DSRM accounts. I hope you find this information useful and use it to better secure your Active Directory environment.

Additional Resources and Links

    5 thoughts on “Back to the Basics – Securing the Directory Services Restore Mode Account

    1. Pingback: Featured IT Blogger of the Week: John Policelli - ITKE Community Blog

    2. Pingback: Do you know your DSRM password? « net stop beep

    3. Pingback: The things that are better left unspoken : How to add a DSRM startup option in Windows Server 2008 and Windows Server 2008 R2

    4. Pingback: The things that are better left unspoken : Rebooting Windows Server 2012-based Domain Controllers into Directory Services Restore Mode

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>