Almost 15,5 years ago I wrote a blog post about how to manage the DSRM Administrator Account Password. That old blog post can be found here. A few days earlier back then I wrote a blog post how and when you could log on with the DSRM Administrator account. That old blog post can be found here.

Looking at todays new capabilities and threats, I felt it was needed to rewrite those blog posts, especially the first one, to match today’s modern age and technology.

[BACKGROUND]

So every single time you promote an RWDC or an RODC, you have to specify a password for the Directory Services Restore Mode (DSRM) Administrator account as you can see below in figure 1.

When the NTDS service fails to start, or when you want to restore the system state non-authoritatively or when you want to perform an authoritative restore of certain objects, you need to use the DSRM Administrator account. That account is a local administrator account on the DC and it does not have any permissions in AD. It does however have full control over the local server itself. Taking that into account with the available tools and methods today, with that account you basically own the local server and with additional steps the AD service and content itself. The DSRM Administrator account should therefore be considered as a Tier 0 account with very high-privileges. In this case, it is very simple…. if you control the server/DC > you control AD!

Because of that, the password should be long/strong (at least 30 characters or even longer) and preferably machine generated. If you want to do it easier, use a really long pass-phrase instead, like for example: “mYSup3rSecur3d5rmP@$$w0rd1tryNOT2f0rget!” (please DO NOT use this password!). A best practice for high-privileged accounts, especially the one not owned by any person, is to reset or change the password on a regular basis, like for example every 3 or 6 months, to mitigate the risk of the password or password hash being stolen/compromised followed by misuse. Think about the following question: “Are YOU resetting/changing the DSRM Administrator Account password on a regular basis?“

For changing/resetting the password on a regular basis, there are multiple options. Let me walk you through all of them, so that you understand and are able to choose wisely what fits best for you.

[OPTION 1] – Do It Yourself Manually Per DC

When you start NTDSUTIL and go into the SET DSRM PASSWORD submenu you can see the option “RESET PASSWORD ON SERVER %s”. “%s” is either the FQDN of a remote server, or NULL when on the local server. See figure 2.

That option must be used against every individual RWDC or RODC to set a new password. Obviously the amount work depends on how many DCs you have in the AD forest and if you can reach all of them from one location. The more you have, the more work, and probably more challenges, you will have. Nevertheless, nothing stops you from querying for all DCs in the AD forest and with a ForEach loop process the previous command against each DC. I would not consider this the best way to go as there are better options.

[OPTION 2] – Do It Yourself Per DC Type And Per AD Domain

Looking again at figure 2 above, you also see the option “SYNC FROM DOMAIN ACCOUNT %s” where “%$” now is the Principal Name (i.e., the sAMAccountName prefixed with the NetBIOS or FQDN Domain Name, e.g. ADTEC.NET\dsrm.RWDCs). That option basically means, you have a so called placeholder user account in AD from which you sync the password hash from into the local DSRM Administrator account. Now THAT sounds really interesting! It is a feature introduced in Windows Server 2008 R2.

The placeholder user account in AD DOES NOT need, or better, SHOULD NOT be high-privileged or have high-privileges. It can be a simple regular account that is disabled. It is just a placeholder for the password and nothing more than that.

If you have both RWDCs and RODCs in a certain AD domain, then you should create 1 placeholder user account in AD for each! Therefore, 1 DSRM placeholder user account in AD for RWDCs, and 1 DSRM placeholder user account in AD for RODCs. DO NOT use one for both! The main reasons are:

• Each and every writable DC (RWDC) in the AD forest is and should be treated and considered as the most trusted and most high-privileged machine. If an RWDC is compromised, the rest of your AD, the service itself and all accounts (users, computers, sMSAs, gMSAs and dMSAs) are compromised!
• Each and every read-only DC (RODC) in the AD forest is and should be considered as an untrusted machine, yet preferably it still should have adequate security. When an RODC is compromised the impact on the AD forest is much lower than when an RWDC is compromised. The scope of impact is lowered to only those accounts (users, computers, sMSAs, gMSAs and dMSAs) that have their password cached in the NTDS.DIT of the RODC! Depending on the configuration and scenario, RODCs could be used to attack the RWDCs and the AD service as explained here.

Based upon the statements mentioned above, you really DO NOT want to use the same DSRM placeholder AD user account to sync the password from for both RWDCs and RODCs. That’s why you need at least two AD user accounts. One for RWDCs and one for RODCs. You do not want an RODC Admin to gain access to your RWDCs easily like that and/or you also do not want some hacker to pull out the password from a compromised RODC and use it on the RWDCs. That would be really too easy!
For RWDCs within the same AD domain you could use the same AD user account as all RWDCs should be treated equally.
For RODCs within the same AD domain you could use the same AD user account as all RODCs could be treated equally. You may need more DSRM Placeholder AD user Accounts if for example each AD site contains one or more RODCs which is/are managed by a different admin than in other AD sites. In that case you could create a DSRM Placeholder AD user Account for each AD site containing one or more RODCs. How much separation you want to achieve on RODCs depends on your situation and requirements. Thinking about it, to be honest, that also applies for RWDCs, but that (option 1) comes with a very high management price, for the little additional security you get by making all unique. That, however, could be solved by using Windows LAPS (option 3 later on). However, in return when using Windows LAPS, the AD service must somehow (online or offline) be available! Later, more about this. Remember, compromise one RWDC in any given AD domain, and the rest is also considered to be compromised. These days, it is really not that difficult to do that. But, is it worth having unique passwords for the DSRM administrator account on each and every RWDC within the same AD domain? I do not think so and because of that I consider it to be a good idea to only have one DSRM placeholder account in AD for servicing the DSRM administrator account on all RWDCs in any given AD domain. One important rule of thumb is to have a unique strong/long password for every DSRM Placeholder AD User Account used in and between every AD domain! To use this sync feature keep the following technical requirements in mind:

• The DSRM Placeholder AD User Account must be in the same AD domain as the DC that will sync the password hash from that DSRM Placeholder AD User Account. It cannot be in a different AD domain
• The DSRM Placeholder AD User Account must have its password hash in the local NTDS.DIT of the DC that wants to sync the password hash from the DSRM Placeholder AD User Account. This is because NTDSUTIL only looks on the local instance of the NTDS.DIT database. For RWDCs this is automatically achieved. For RODCs, however, this is different and it means the password must be explicitly allowed to be cached and it must therefore be pre-populated on demand before initiating the sync from AD. The password of an AD account only replicates to an RODC, when the RODC requests it after forwarding authentication to the RWDC or when forced on demand (pre-populating). It does not replicate automatically like other attributes.
• Both RWDCs or RODCs do not need special permissions to sync the password hash from the DSRM Placeholder AD User Account when configuring the scheduled tasks to use the SYSTEM account. The SYSTEM account has the highest permissions possible in the local NTDS.DIT instance.
• Synchronization of the password hash only works when the DC is operating in normal mode. It will not work when AD is stopped or when booted into DSRM, which is obvious.
• When the password of the DSRM Placeholder AD User Account is reset, make sure end-to-end AD replication is complete before synching the password hash from it to the DCs. Therefore, after resetting the password either allow enough time for AD replication to complete or forcibly initiate AD replication within the domain partition!
• The DSRM Placeholder AD User Account must…:
  • … be configured with “Password Never Expires” as the synchronization cannot occur from an AD user account that has an expired password.
  • … not be expired itself
  • … must not be configured with “Smartcard required”

From a security perspective, configure any DSRM Placeholder AD User Account, as follows:

• The DSRM Placeholder AD User Account DOES NOT NEED to have any special permissions or privileges in AD. The less the better! Remember, it is just a placeholder for that password hash and nothing more than that. However, all DSRM Placeholder AD User Accounts should be treated as Tier 0, and accordingly be protected and hidden using an Admin Tiering model. Why you ask? Well think about it. Anyone that has access to that account and its password hash would be able to logon to any DC, under special conditions, that syncs the password from it!
• Configure the DSRM Placeholder AD User Account as follows to secure it as best as possible. All options are not mandatory, but are for sure highly recommended to enhance its security!:
  • Disable the DSRM Placeholder AD User Account
  • Add the DSRM Placeholder AD User Account to the “Domain Guests” group, and change its primary group from “Domain Users” to “Domain Guests”
  • Remove the account from the “Domain Users” group
  • Configure it with “User cannot change password”

Now you can obviously configure all this yourself and/or try to figure everything out yourself, but you could also try out the following scripts. If you do use the PowerShell scripts/code, think about the following:

• Either use the configured DSRM Placeholder Account Names, or use different Account Names. If you do make sure to update ALL THE SCRIPTS correctly
• In the scripts to create the DSRM Placeholder AD User Account, either accept the configured USERS container to create the objects in, or preferably choose an OU with maximum security that is part of an Admin OU Tiering Model. Remember, the DSRM Placeholder AD User Accounts are indirectly high privileged Tier 0 accounts!
• If you want or need to place the password hash sync script in another folder on the DCs, feel free to do so. Just make sure to update the configuration of the Scheduled Task accordingly.
• All scripts can be used with either scriptmode ADSIorSDSP (default) or ADPoSH. Configure as needed. Both scriptmodes do exactly the same, just using different mechanism.

The PowerShell script/code Creating-The-DSRM-Placeholder-Account-For-RWDCs.ps1 helps you create the DSRM Placeholder AD User Account for RWDCs within an AD domain. Remember, you have to run the script within every AD domain. When you execute it as a Domain Admin account, you will see something similar like figure 3.

If you have RODCs in your AD domain, the PowerShell script/code Creating-The-DSRM-Placeholder-Account-For-RODCs.ps1 helps you create the DSRM Placeholder AD User Account for RODCs within an AD domain. Remember, you have to run the script within every AD domain. When you execute it as a Domain Admin account, you will see something similar like figure 4.

To further secure the DSRM Placeholder AD User Accounts, a Password Settings Object (PSO), specifically for the DSRM Placeholder AD User Accounts, is also created. This can be done using the PowerShell script/code Creating-And-Configuring-The-PSO-For-DSRM-Placeholder-Accounts.ps1. When you execute it as a Domain Admin account, you will see something similar like figure 5. The importance of the PSO is explained later.

Now with all the objects created in AD, it is time to focus on the DCs themselves. The DCs, both RWDCs and if applicable RODCs, need to use something to sync the password hash from the corresponding DSRM Placeholder AD User Account. For that I also have the PowerShell script/code SYNC_DSRM_ACCOUNT_PASSWORD.PS1. That PowerShell script needs to be placed on every DC in the same folder to make sure the Scheduled Task deployed through a GPO is able to find it. In my case I chose the folder “D:\Support-Stuff\ADDS”. When running the script interactively, as SYSTEM, you will see something similar like figure 6 and figure 8. The output displayed in figure 6 applies to both RWDCs and RODCs. The output displayed in figure 8 is very specific to RODCs. The different is that for an RWDC the password hash is synched immediately, and an RODC the password is first synched from the RWDC to the RODC using the Replicate Single Object for secrets only, and only after that the password hash is synched. For RODCs that additional step is needed to make sure the most recent password of the DSRM Placeholder AD User Account for RODCs is cached locally in the NTDS.DIT of the RODC. Remember, the password hash sync is always done from the local NTDS.DIT! The sync restrictions mentioned are something I implemented in the code to protected the DSRM Placeholder AD User Accounts. Later more about this.

In figure 6 you can see the output when trying to sync the password hash while the restrictions are in place.

Running the password sync hash script on either an RWDC or an RODC with the sync restrictions in place produces the log file output similar to what is displayed in figure 7.

Running the password sync hash script on an RODC without the sync restrictions in place produces the log file output similar to what is displayed in figure 9.

Now with the password hash sync script on every DC, something is needed to trigger that script to execute on a regular basis. The perfect mechanism for that is a Scheduled Task deployed to all DCs, RWDCs and if applicable RODCs, using 1 GPO. That GPO must therefore target all RWDCs and RODCs. Based on the type of DC (writable or read-only), the password hash sync script will choose the correct DSRM Placeholder AD User Account if those are named correctly accordingly. In my environment I did the following with regards to the configuration of the Scheduled Task in the GPO.

• GPO “GPO_C_All-Domain-Controllers”
  • Linked To “OU=Domain Controllers”
  • Security Filtering: Authenticated Users
  • User Settings Disabled, Computer Settings Only
  • Configuration For Scheduled Task:
    • Node: Computer Configuration > Preferences > Control Panel Settings > Scheduled Tasks
    • Name: AD MGMT – Sync DSRM Account PWD From AD To DCs (GPO)
    • Run: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    • Arguments: -NoProfile -NonInterActive -Command “D:\Support-Stuff\ADDS\SYNC_DSRM_ACCOUNT_PASSWORD.PS1”
    • Start In: D:\Support-Stuff\ADDS
    • Enabled: TRUE
    • Schedule: Daily @ 14:00:00
  • Enable option “Allow Task To Be Run On Demand“

After the new GPO settings have replicated to all DCs, and all the DCs have processed the GPO (max 5 minutes), or after executing GPUPDATE /FORCE, the scheduled task will be available on every DC. As you can see, the scheduled task will execute the PowerShell Sync script and sync the password hash to the DC from the DSRM Placeholder AD User Account, if the sync restrictions are not in place. The script will determine if the DC is a Read-Only DC or a Writable DC and use the correct DSRM Placeholder AD User Account, if named correctly accordingly. In case the DC is an RODC, the PowerShell Sync script performs an additional task before actually synching the password hash from the DSRM Placeholder AD User Account. That task is to make sure the most recent password exists on the local RODC, and is done by executing a Replicate Single Object operation for the corresponding DSRM Placeholder AD User Account from a source RWDC. It then checks if the source RWDC and the target RODC have the same value for “Originating Date/Time” and “Version”. If the values are the same, the password is recent, and password hash sync occurs, otherwise it does not.

Now you might think: “Wait! If I own and compromise an RODC I could update the PowerShell script and instead sync the DSRM Placeholder AD User Account for RWDCs to get the password hash.” Technically this is true, but it will not work. The main reason is that the DSRM Placeholder AD User Account for RWDCs is added to the “Denied RODC Password Replication Group” security group, which prevents the password hash in replicating to the RODC and being stored in the local NTDS.DIT of the RODC. Remember that the sync of the password hash only works if the password is in the local NTDS.DIT. It does not work remotely against remote (RW)DCs. Finally, because the SYSTEM account is used for the Scheduled Task, only the data in the local NTDS.DIT can be accessed, and not any data in remote NTDS.DITs. When the local SYSTEM access data remotely, it uses its computer account as the identity. In case of an RODC computer account, it is very limited in terms of what kind of permissions it has in AD.

As said before, the DSRM Placeholder AD User Accounts, although not having any special privileges in AD, should be considered and treated as Tier 0 accounts as with those credentials you are able to respectively logon to any RWDC or RODC. Preferably the DSRM Placeholder AD User Accounts are located within a Admin OU Tiering Model structure where those are protected and hidden.
In addition to all that, let’s have a look at a few scenarios to see what could go wrong.

When somebody somehow compromises a DSRM Placeholder AD User Account, it could be misused to logon to a DC. True! That is why in this process, you should know at what time the DCs try to sync the password hash from the DSRM Placeholder AD User Account. Before that happens, and taking into account the required time needed for end-to-end AD replication (HINT: check out this script to determine AD Replication Convergence within the AD domain – Check-AD-Replication-Latency-Convergence) you reset the password of the DSRM Placeholder AD User Account using a known (i.e., displayed!) machine generated password and remove any password sync restrictions from that account. When the times come, the Scheduled Task on the DCs kicks in and runs the PowerShell script to sync the password hash. The password hash sync script runs as SYSTEM. When executing it checks if the DSRM Placeholder AD User Account actually can be found in AD in the local NTDS.DIT and if the control attribute (configured in the PowerShell code, “extensionAttribute1”) has the correct control value (also configured in the PowerShell code, “RESET”). If all is OK and good to go, it will initiate the sync of the password hash. If the sync of the password hash is successful, the computer will update a reset acknowledgement attribute (also configured in the PowerShell code, “info”) with the version and the originating date/time of the password. This allows you to check which DCs have which version of the password. Something to be aware of, is that RWDCs are able to update the reset acknowledgement attribute (“info”) locally in their own local NTDS.DIT, which then replicates out. RODCs, however, are read-only and do not support local LDAP writes. Any local LDAP write against an RODC is forwarded to an RWDC. When the RODC use SYSTEM locally, remotely it will use its computer account identity. For the update of the reset acknowledgement attribute (“info”) to succeed on the RWDC, the RODC computer account must have the correct LDAP write permissions. All accounts in AD, have LDAP write permissions on their “Personal Information” attribute set. So, to make sure this works for both RWDCs and RODCs, an attribute from the “Personal Information” attribute set was chosen to be the so called reset acknowledgement attribute (“info”).

Now some time after the Scheduled Task completed you reset the password of the DSRM Placeholder AD User Account again using a ransom and unknown (i.e., not displayed!) machine generated password and add the password sync restrictions back onto the corresponding DSRM Placeholder AD User Account. The password restrictions mentioned are: (1) removing a control value (RESET) from the control attribute (“extensionAttribute1”) that allows the password hash sync to occur or not and (2) configuring a DENY:FullControl ACE for SYSTEM on the DSRM Placeholder AD User Account so that the DC is not able to find it in its local NTDS.DIT. When it does not find the DSRM Placeholder AD User Account in AD, the script automatically aborts and does not do anything. Don’t worry about it, AD replication for that DSRM Placeholder AD User Account will still work as expected. The idea behind the DENY:FullControl ACE is to prevent anyone owning the local DC also controlling the password hash sync. This has been implemented for both RWDCs and RODCs, but it is especially needed for RODCs!

But wait! The password hash of the DSRM Placeholder AD User Account that was synched to the DSRM Admin Account, is still available on the password hash history of the DSRM Placeholder AD User Account! True indeed! And that is where the Password Settings Object (PSO) comes in that is specifically created for the DSRM Placeholder AD User Account(s). That PSO has password hash history configured of 0, which essentially means “no history of passwords is kept!”. So, after setting the known machine generated password and having it synched, an unknown machine generated password is set on the account. Because there is no password hash history, it is not possible to retrieve the password hash that was actually synched from the DSRM Placeholder AD User Account to the DSRM Admin Account. By adding the sync restriction, you make sure, the unknown machine generated password (hash) is not synched to the DSRM Admin Accounts as the DC cannot find the DSRM Placeholder AD User Account due to the DENY:FullControl ACE for SYSTEM on the DSRM Placeholder AD User Account.

Now with all the mechanics in place it is time to put it all to work.

To reset the password of the DSRM Placeholder AD User Account for RWDCs, you can use the PowerShell script/code Resetting-The-DSRM-Placeholder-Account-Password-For-RWDCs.ps1.

To reset the password of the DSRM Placeholder AD User Account for RODCs, you can use the PowerShell script/code Resetting-The-DSRM-Placeholder-Account-Password-For-RODCs.ps1.

Obviously you can also reset the password of DSRM Placeholder AD User Accounts manually. However, if you do, do not forget about the removal and addition of the sync restrictions. Using the PowerShell makes this process a lot easier as it takes those sync restrictions into account.

As an example you can view the first password reset without the sync restrictions for RWDCs in figure 14 and for RODCs in figure 15. This must be done before the DC tries to sync the password hash from the DSRM Placeholder AD User Account. In both figures pay special attention to the values for “Org Date/Time On RWDC” and “Version”. the blue marked password values, should be secured and stored in a password vault!

After the Scheduled Task has executed an synched the password hash from the corresponding DSRM Placeholder AD User Account, you can check AD if and which DCs have done that. To test this without waiting for the correct time of the scheduled task, you can obviously trigger the scheduled task manually on demand using the PowerShell script/code Triggering-Scheduled-Task-On-DCs-On-Demand-To-Initiate-DSRM-Password-Sync.ps1 as displayed in figure 16.

REMARK: The red marked DCs are DCs that exist in AD, but are turned of or not available

Now some moments after the scheduled task on the DCs have executed, it is interesting to understand if and which DCs have sync the latest version of the password. For that you can run the following PowerShell script/code Displaying-DSRM-Sync-State-Across-All-DCs-In-AD-Domain.ps1. Running that code will return information similar to what is displayed in figure 17.

The DCs with “DC Type” being RWDC should have a value (“Org Date/Time On RWDC” and “Version”) that matches with what was set (see figure 14). The DCs with “DC Type” being RODC should have a value (“Org Date/Time On RWDC” and “Version”) that matches with what was set (see figure 15). If the values match, you are sure the password hash was reset/synched correctly. If some DC has a mismatching value, it can mean 1 of the 2 situations, being: (1) AD replication is not yet complete, or (2) the password reset/sync did not succeeds. That may need some troubleshooting by looking at the local log file on the DC.

REMARK: The 2 RWDCs with no value are offline, hence those have no value. The last DC with “DC Type” UNKNOWN is an RODC placeholder for the Cloud Kerberos Trust feature. There is no real RODC behind it, hence it has no value.

As an example you can view the second password reset with the sync restrictions for RWDCs in figure 18 and for RODCs in figure 19. This must be done after the DC has synched the password hash from the DSRM Placeholder AD User Account.

As a guideline you would need to repeat this process at least every 6 months to make sure you mitigate the risk of password (hash) compromise.

Every single time you reset the password during the first iteration, you need to store the displayed password in a secure password vault and make sure only authorized people have access to the DSRM passwords during emergencies. Because there is not dependency on AD, the password can always be retrieved from the password vault during any emergency. This does assume the password vault itself does not depend on AD for authentication and authorization.

[OPTION 3] – Let Windows LAPS In Windows Server Manage The DSRM Admin Account Password

REMARK: Windows LAPS is more than just backing up DSRM Administrator Account passwords. For a complete overview see Windows Local Administrator Password Solution (Windows LAPS). This part, however, will only focus of managing DSRM Administrator Account passwords.

LAPS, Local Administrator Password Solution, was first introduced as a separate package, and was called officially Microsoft LAPS. It could be used for clients and servers, but not for DCs. Now fast forward to 2023, and Windows LAPS became available integrated in the Operating System. It is available for Windows 10 + Update package, Windows 11 + Update package, Windows Server 2019 + Update package, Windows Server 2022 + Update package and Windows Server 2025. It now supports managing local administrator account password on clients and servers, and the DSRM administrator account password on DCs!. Depending on the scenario, the password is either backupped in AD or Entra ID. The following rules apply:

• Computers that are only joined to Entra ID can only backup the password to Microsoft Entra ID
• Computers that are only joined to Active Directory can only backup the password to Active Directory
• Computers that are hybrid joined (joined to both Active Directory and Entra ID) can back up the password to either Active Directory or Entra ID, but not both.
• Domain Controllers can only backup their DSRM administrator account password to Active Directory and not to Entra ID. In addition encryption must be enabled and used!
• To be able to use encrypted passwords and encrypted password history, the domain functional level must at least be configured with “Windows Server 2016”

To use Windows LAPS on DCs to manage the DSRM Administrator Account password, you need to use a GPO that targets all DCs, both RWDCs and if applicable RODCs. If that is done, you cannot use option 2 above. It is either one or the other. However, it is possible to use option 2 for RWDCs and only have 1 DSRM Administrator Account password per AD domain, which is always (hint!) available, and use this option 3 for RODCs. By configuring it like this, you manage yourself the DSRM Administrator Account password that matters and is independent of AD being available, and leave the management of the DSRM Administrator Account password for RODCs to Windows and AD. The reason for this is that for RWDCs, at least 1 RWDC must be available to be able to retrieve its DSRM Administrator Account password. As RODCs cannot function on their own and heavily depend on RWDCs, you might as have the DSRM Administrator Account passwords be managed by Windows/AD. That would also give you unique DSRM Administrator Account password per RODC! To achieve this, you would need 1 GPO (for option 2) that only targets RWDCs, e.g., security filtered using the “Domain Controllers” group and another GPO (for option 3) that only targets RODCs, e.g., security filtered using the “Read-Only Domain Controllers” group. You could almost say “best of both worlds!”.

In figure 20 below you can see the Windows LAPS settings in a GPO that can be used to manage DSRM Administrator Account passwords. The Windows LAPS settings displayed below as “Not Configured” cannot be used to manage DSRM Administrator Account passwords.

After the DC has applied the GPO with the new settings you will something similar as displayed in figure 21, which is the view when using Active Directory Users And Computers MMC. It shows the current expiration date/time, the account for the DSRM Administrator Account (which cannot be changed!), and the current configured DSRM Administrator Account password, which I chose to be a long pass-phrase of multiple words.

And the similar is true when viewed through PowerShell in figure 22.

With regards to the DSRM Administrator Account password, the default authorized decryptor is always the Domain Admins group in the AD domain the DC is part of. This cannot be changed, and which makes sense! If you do not have the permissions to retrieve the DSRM Administrator Account password, then nothing is displayed, not even an error.

If you have an IFM set, you could load the NTDS.DIT from it using DSAMAIN, as displayed in figure 23, and make that AD instance available through a custom port.

Now that AD instance is available through the custom port, use can use PowerShell to retrieve the DSRM Administrator Account password. You still need to be a member of Domain Admins for this to succeed, and the AD service must be up and running for this to work!

Trying to do the exact same thing on a member server with an account that does not have the permissions (figure 25 and 26) or a workgroup machine with the local administrator account of the machine (figure 27 and 28), the attempt to retrieve the DSRM Administrator Account password fails.

As you can see, currently it just does not work on non-domain joined computers!

It appears though that Microsoft is working on the scenario where all RWDCs are not available due to a catastrophic event, while you still need access, and indeed can access the DSRM Administrator Account password using the procedures as mentioned in Retrieve passwords during Windows Server Active Directory disaster recovery scenarios. This appears to be only available with Windows Insider build 27695 and later.

Now with regards to logging on with DSRM Administrator Account, the default is to only to be able to do that when the DC is booted into DSRM mode (mode 0). However, using the configuration described here, it is ALSO possible to allow logon of the DSRM Administrator Account when either the NTDS service is stopped (mode 1) or running (mode 2) and it is running in normal DS mode. The latter 2, and especially mode 2 is a serious security issue and SHOULD NOT be configured by default. You could also go that far by configuring the following registry configuration in a GPO that targets all DCs (RWDCs and RODCs) to always force it to mode 0 (figure 29). This does not prevent anyone from configuring mode 1 or 2 in the registry of the DC, but if that happens, it will automatically jump back to mode 0, to prevent a forgotten setting becoming a security issue!

Hope this helps you in making the correct decision in how to reset the DSRM Administrator Account password on a regular basis!

Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-