DS Restore Mode Password Maintenance

Ned here again. There comes a day in nearly every administrator’s life where they will need to boot a domain controller into DS Restore Mode. Whether it’s to perform an authoritative restore or fix database issues, you will need the local administrator password. Too often, we work with customers that have not been maintaining this password and do not have a way to get in to their DC’s. Sometimes it’s because the password was set by another admin who is not available or no longer works at the company. Other times it’s because the password was set at DC promotion years ago and no one remembers it anymore. Since the password can only be set when the DC is running in normal mode, you get a nasty chicken and the egg situation if the DC cannot start Directory Services correctly. Today we’ll talk about some methods to get this password under control.

The old fashioned way

All domain controllers have a hard-coded local Administrator account stored in their SAM database. This account and local database are not used or generally available when the DC is running normally. You probably remember setting this password during DCPROMO:

In addition, the password can be reset later while the DC is running by using the NTDSUTIL tool:

If you know the password, you can restart the domain controller into DS Restore mode using F8 or via the boot options exposed in MSCONFIG and away you go.

But what are the options to maintain this password, especially when your environment is in the hundreds or thousands of DC’s? Let’s dig in.

NTDSUTIL Password Pull

Beginning with hotfix KB961320 on Windows Server 2008, you now have the option to synchronize the DSRM password on a DC with a specific domain account. You must do every time the password is changed; it does not create an automatic sync partnership.

1. Create a standard domain user account and set it with a complex password. It does not need to be a member of any special groups or the Domain Admins group.

2. Install the hotfix on your DC and restart.

3. Logon to the DC normally.

4. In an elevated CMD prompt where you have logged on as a Domain Admin, run:

NTDSUTIL
SET DSRM PASSWORD
SYNC FROM DOMAIN ACCOUNT <your user here>
Q
Q

So for example (using NTDSUTIL’s ability to pass in all parameters on a single command-line):

Note how there is no need to provide the actual password being used, or provide the old password. This feature will also be included in Service Pack 2 for Win2008.

Group Policy Preference Automation of NTDSUTIL

So what if we want to automate this NTDSUTIL command so that is run via a scheduled task? This is easily done using Group Policy Preferences.

Note: Before you get too excited that I’ve missed something – no, GPP Local User password does not work with the DSRM passwords on domain controllers. You cannot use it to push a new password to the local administrator on DC’s; it only works only on member computers. Trust me, I’ve tried.

The beauty of this solution is that there is no password stored anywhere except in Active Directory itself and the system effectively self maintains – the only administrator intervention needed is to periodically change the special user’s password, and to make sure the scheduled task is working on the DC’s. The same way you should be checking to make sure those backups will actually function for a restore if you ever need to use this password.

So let’s set this up:

1. Start GPMC on a Windows Server 2008 or Windows Vista computer running RSAT.

2. Create and link a new policy on the Domain Controllers OU (you are doing all this in a test domain first, right?).

3. Create the GPP Scheduled task settings.

Note here that I have set:

A) Action of ‘Update’ (this will create the task if it does not exist).

B) Run command of the built-in GPP variable for %SystemDir% to specify the System32 directory, along with the ntdsutil.exe to be called.

C) The command line exactly as it would be done by hand with ntdsutil, including the quotation marks:

“SET DSRM PASSWORD” “SYNC FROM DOMAIN ACCOUNT DsrmUser” Q Q

D) The task is Enabled with a checkbox so that it will run, not just be created.

E) Then I have set this to run as a daily task at 9AM (it’s fairly likely that the DC will be running at that point). I could also run this hourly, weekly, etc – whatever I want.

4. After having created the policy and letting it apply to DC’s, I now see it is working by examining the scheduled tasks on one of my domain controllers. There it is (as well as another one I added to run every night too – can’t be too careful):

5. Once the right time has come and gone, I boot a DC into DS Repair mode and check – sure enough, my new password has taken affect automagically.

Update 1/1/2018 - A key point: having the same DSRM password on every DC and RODC can be a lateral movement attack vector. Consider using a per-DC/RODC password. If using a single account for multiple DCs, ensure that at least RODCs get their own separate password from writable DCs. For more excellent reading on this, review https://adsecurity.org/?p=3592.

And there you go.

- Ned ‘That’s the same combination I have on my luggage!’ Pyle

Reviewer’s note: We made Ned change his smart card PIN to something other than ‘12345’ after he let it slip in this blog post.

Comments

• Anonymous
  March 12, 2009
  PingBack from http://www.ditii.com/2009/03/12/password-maintenance-with-ds-restore-mode/

• Anonymous
  March 16, 2009
  This is an EXCELLENT post!  The Dir Team blog is a great resource - keep up the postings!!  Any ideas on how to accomplish this feat for an entire AD forest?  

• Anonymous
  March 16, 2009
  The comment has been removed

• Anonymous
  April 07, 2009
  The comment has been removed

• Anonymous
  April 07, 2009
  I don't know why it wouldn't work if it was the only DC in the forest. But if it was one of multiple DC's, you would get a USN rollback. In neither case would the DC not start at all - it just wouldn't replicate. Do you get a specific error?