(2010-06-15) Managing The DSRM Administrator Account

In a previous post I explained which type of accounts can be used to log on to a DC. For W2K8(R2) RWDCs/RODCs you can use the DSRM Administrator Account and domain accounts. When you can use which account depends on certain configuration as also specified in that same post.

With regards to the DSRM Admin Account, each DC has one, which also has a password that needs to be managed somehow. Let’s have a look at the different possibilities. The DSRM Admin Account Password is set/configured during the promotion of the server to a DC. Afterwards you can RESET its password through NTDSUTIL. The exact command for that is shown below in the picture.

In this case, specifying NULL as the server, means the local DC. You can also specify the name of any other DC.

What’s the downside of this approach? It is not scriptable, and that can be quite a pain when you have multiple DCs for which you want to manage the DSRM Admin Account password.

A former DS-MVP, which chose to join "the dark side" (I know you read this and you know who you are! J), wanted to script this and he solved this by using the SETPWD utility that was available in Windows 2000 Server SP2. But I think only the Windows 2000 SP3 vesion was scriptable. Check out MS-KBQ810037 and MS-KBQ239803. SETPWD is NOT available in Windows Server 2003 and later.

Unless you have a copy of that batch script, it cannot be downloaded anymore from its original location. But no worries! There is another way to achieve your goal! But seriously….Are you still running W2K? Hopefully not!

Since W2K8, there is another way to manage the password of the DSRM Admin Account. In W2K8(R2), the menu for "Set DSRM Password" in NTDSUTIL contains a new option as shown below in the picture.

Yes, the new option called "Sync from domain account %s" allows you to create and use a user in AD and sync the password from it!

Allow me to explain how you could implement this and what the rules are of using this new option. The following is just a way of how you could implement it and food for thought!

In this scenario I created a folder on drive C: called "SCRIPTS". In that folder a have a batch file (CMD) called "SYNC-DSRM-ACCOUNT-PASSWORD.CMD"

On RWDCs the content of that script is:

@ECHO OFF
CLS
COLOR 0E
ECHO ## START ## %COMPUTERNAME% ## %DATE% %TIME%>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG
NTDSUTIL "SET DSRM PASSWORD" "SYNC FROM DOMAIN ACCOUNT ADCORPDSRM-ADM-RWDC" Q Q>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG
ECHO ## END ## %COMPUTERNAME% ## %DATE% %TIME%>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG
ECHO.>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG
ECHO.>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

On RODCs the content of that script is:

@ECHO OFF
CLS
COLOR 0E
ECHO ## START ## %COMPUTERNAME% ## %DATE% %TIME%>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG
NTDSUTIL "SET DSRM PASSWORD" "SYNC FROM DOMAIN ACCOUNT ADCORPDSRM-ADM-RODC" Q Q>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG
ECHO ## END ## %COMPUTERNAME% ## %DATE% %TIME%>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG
ECHO.>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG
ECHO.>>C:SCRIPTSNTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

You might wonder WHY I’m using different scripts. Note the underlined lines above and check the differences. RODCs are implemented as one of the coolest features in W2K8 AD. By now you should understand the following two statements:

1. Each and every writable DC (RWDC) in the AD forest is and should be treated and considered as the most trusted and most secure machine. If an RWDC is compromised, the rest of your AD is toast if you do not react appropriately in time!

2. Each and every read-only DC (RODC) in the AD forest is and should be considered as an untrusted machine. When an RODC is compromised the impact on the AD forest is much much lower than when an RWDC is compromised.

Based upon the statements mentioned above, you DO NOT want to use the same 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 to easy!

For RWDCs you could use the same AD user account as all RWDCs should be treated equally.

For RODCs you could use the same AD user account as all RODCs should be treated equally. You may need more 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 an AD user account for each AD site containing one or more RODCs.

That script can then either be triggered remotely on-demand through for example PSEXEC OR you could create a scheduled task on every DC (RWDCs and RODCs) that executes on a regular basis and then syncs the password to the local DSRM Admin Account.

On each RWDC I created a scheduled task with the following command:

SCHTASKS /CREATE /TN "SYNC DSRM ACCOUNT PASSWORD" /RU "NT AUTHORITY\SYSTEM" /SC WEEKLY /D MON /ST 23:59 /TR "CMD /C C:SCRIPTSSYNC-DSRM-ACCOUNT-PASSWORD.CMD"

On each RODC I created a scheduled task with the following command:

SCHTASKS /CREATE /TN "SYNC DSRM ACCOUNT PASSWORD" /RU "NT AUTHORITY\SYSTEM" /SC WEEKLY /D MON /ST 23:59 /TR "CMD /C C:SCRIPTSSYNC-DSRM-ACCOUNT-PASSWORD.CMD"

If I still need to sync the password on-demand I can still use PSEXEC to remotely use SCHTASKS on every DC. Note that the scheduled task has the same name on every DC.

As you can see above, the scripts log the results in a very simple way to a local file.

An example of the log file on RWDCs looks like:

An example of the log file on RODCs looks like:

An example of the AD user accounts used for this:

And now the rules of engagement with regards to the AD user account(s) used to sync the password from:

• The AD user account must be in the same AD domain as the DC that will sync the password from it

• Treat the AD user account from which you sync the password from as an high-privileged admin account!

• The password of the AD user account must be stored in the local AD instance of each DC as NTDSUTIL will only look at the local AD instance. For RWDCs this is automatically achieved. For RODCs this is different and it means the following:

  • The AD user account used by an RODC to sync the password from must be in the "Allowed To Cache" list. This is needed to allow the storage of the password on the RODC.

  • The AD user account used by an RODC to sync the password from must have its password pre-populated on the RODC. The password of an AD user or computer account only replicates to an RODC, when the RODC requests it after forwarding authentication to the RWDC. It does not replicate automatically like other attributes. So, to prevent issues, you should pre-populate the password to the RODC on a regular basis, and especially when it is changed/reset. This can be done manually through ADUC/REPADMIN or automatically through a scheduled script that leverages REPADMIN. [1]

• Both RWDCs or RODCs do not need special permissions to sync the password from the AD user account when configured the scheduled tasks to use the System Account

• Synchronization of the password only works when the DC is operating in normal mode. It will not work when AD is stopped or when booted in DSRM

• When the password is changed or reset, make sure end-to-end AD replication is finished before synching the password from it to the DCs

• The AD user accounts used to sync the password from do not need any special permissions. The less, the better!

• The AD user account properties can be:

  • Change its primary group from "Domain Users" to "Domain Guests" (not really mandatory)

  • Disabled the user account (not mandatory, but recommended)

  • Configure it with "User cannot change password" (not mandatory, but recommended)

  • Configure it with "Password Never Expires" (mandatory, because the sync cannot occur from an AD user account that has an expired password!)

• The AD user account properties cannot be:

  • Smartcard required

  • Account has expired

• It is recommended to change/reset the password on a regular basis of the AD user account(s) from which the password is synched from to the DSRM Admin Account on a given DC

[1] If needed, to delegate the PWD pre-population of the password belonging to a certain AD user/computer account, you need at least the "Read Only Replication Secret Synchronization" extended right (or control access right – CAR). In addition to that you need read/write permissions on the "msDS-Site-Affinity" of each AD user/computer account in the AD domain for which you want to pre-populate the password. When delegated permissions have been configured and using ADUC you might get an error like "An attempt to update the group membership information in the universal group cache failed". This can be ignored safely.

Cheers,

Jorge

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

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER:

https://jorgequestforknowledge.wordpress.com/disclaimer/

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

############### Jorge’s Quest For Knowledge #############

#########

http://JorgeQuestForKnowledge.wordpress.com/ ########

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