In a previous post (here), I wrote about an automation framework to deploy scripts using GPP Scheduled Tasks to Domain Controllers, servers, and clients. This post is about a script, designed for use with that framework, to set the DSRM password of all of Domain Controllers by synchronizing it with a domain service account.
You can download the script here.
Wait, the DSRM what???
Before I get into the meat of the script itself, let’s cover what exactly DSRM and the DSRM account are.
Directory Service Restore Mode
Clients and members servers can enter into Safe Mode on boot.
Domain Controllers have Safe Mode and an additional option called Directory Services Restore Mode. This is essentially a special version of safe mode that is used to perform many repair operations for Active Directory.
Now that we’ve covered Directory Services Restore Mode (DSRM), let’s talk about the DSRM account.
Every Windows member server and client includes a local Administrator account that can always be identified by it’s Security Identifier (SID) as it always ends with 500. While you can rename and/or disable this account, it still has the relative identifier of 500.
Domain Controllers, on the other hand, have the Active Directory Administrator account. Once a server is promoted as a Domain Controller, this Domain Administrator is effectively the local Administrator for every Domain Controller. Unlike member servers and clients, the Administrator account password will be same on all DCs due to Active Directory replication. Similar to the local Administrator account, this Domain Administrator account also ends with 500.
Here’s where things get a little bit complicated. In addition to the Active Directory or Domain Administrator account, each Domain Controller also includes the DSRM account. This account is commonly referenced as the “DSRM Password” with no mention of an actual username. The key here is that the DSRM account is actually a local Administrator account unique to each Domain Controller. The password on this account is set during initial Domain Controller promotion, does not automatically change, does not replicate between Domain Controllers, and has no requirement to be the same on every DC. It is also normally only allowed to log on when in Directory Services Restore Mode and cannot be used to log on during a normal Domain Controller boot (though this is actually configurable, but should not be changed).
So, why do we care about the DSRM account?
There are Disaster Recovery scenarios where the DSRM account password is required. Without it, you may not be able to recover Active Directory objects, DNS zones, or whatever was lost/corrupted/deleted. This means that knowing the DSRM password for every Domain Controller is critical for your DR strategy. However, the DSRM account must be treated like any other shared, privileged account. This should include tight security controls, limited sharing of the password, documentation of the password in a safe place, and changing the password on a regular basis or when staff members leave the organization. However, since this account is local to each Domain Controller, we have to take steps to change this password on each one. Luckily, we’ve had the ability to reset this password since AD has been around. Even better, the preferred method of changing the DSRM password got better and more secure starting in Windows 2008 R2. Technically this was also added to Windows 2008 by a later update (kb961320).
Finally, to the script!
Since we need a method of resetting the DSRM password on each Domain Controller on a regular basis and ad-hoc, we’ll implement a password change script using the DAUNT framework. This script will synchronize, on a schedule bases, the password from an Active Directory account that you create. This means that you can simply change the password on the AD account and know that local DSRM password of all Domain Controllers will be reset and known (assuming of course that you properly document and safely store the password).
Here are the deployment steps:
1. Read my other artical on the DAUNT framework (link below) to understand the deployment approach.
2. Create a new service account in Active Directory. This account does not need any rights or any particular groups membership. For example, create an account with username svc-dsrm and disable it. Set this account with a long, complex passphrase (>14 characters)
3. Download sync-dsrm-task.ps1
4. Create the new Automation GPO, embed the script, set the trigger, and link to the Domain Controllers OU. My preference is to set the trigger for Friday @ 6:00pm. This is to force the password change of the DSRM account on each Domain Controller @ 6:00pm. Note that the script allows you to add arguments, such as the account username (though you could modify the default username in the script of course).
5. Log on to a Domain Controller, run gpupdate, and verify the new Scheduled Task is present.
6. Run the task and verify the presence of two informational events with ID 4813 in the Distributed Automation event log from source DSRM Password Sync – DA. The second event should indicate that the DSRM sync completed successfully. If the AD account is not present or was incorrectly specified, an Error event will be logged with ID 7813.