RODC Administration

Applies To: Windows Server 2008, Windows Server 2012

This topic describes general administration tasks that you might have to perform for read-only domain controllers (RODCs). The tasks that are covered in this topic apply to any scenario in which you plan to use an RODC. For any specific scenario, there might be additional administration tasks that you have to perform in addition to the general tasks described here.

Using remote management tools to administer an RODC

As a best practice, you should not log on directly to a domain controller to perform any administration tasks. Instead, install administration tools on a trusted workstation where you perform your other day-to-day work assignments. Then, use the administration tools to connect to the domain controller remotely from that workstation.

You can use either of the following tools and technologies for remote RODC management:

• Microsoft Remote Server Administration Tools (RSAT)

• Windows Remote Management (WinRM) protocol and Windows Remote Shell (WinRS)

Using RSAT

To remotely manage Windows Server 2008 domain controllers, you can use the Microsoft Remote Server Administration Tools for Windows Vista. This tool set is available as a download file at Microsoft Remote Server Administration Tools for Windows Vista (KB941314) (https://go.microsoft.com/fwlink/?LinkID=95703). So that you can install RSAT, your workstation must be running Windows Vista with Service Pack 1 (SP1).

If the workstation is running a 64-bit version of Windows Vista, you can use Microsoft Remote Server Administration Tools for Windows Vista for x64-based Systems. The 64-bit version is available at Microsoft Remote Server Administration Tools for Windows Vista for x64-based Systems (KB941314) (https://go.microsoft.com/fwlink/?LinkId=120123).

You can use RSAT to remotely manage servers running either a Server Core installation or a full installation of Windows Server 2008.

You can also manage Windows Server 2008 domain controllers from another server that runs Windows Server 2008. To use a server that runs Windows Server 2008 for remote management, you have to install the Remote Server Administration Tools because they are not installed by default. To manage domain controllers, you need to install at least the Active Directory Domain Controller tools. Depending on what other administration you plan to perform, you might also choose to install Group Policy Management, Distributed File System (DFS) Management, and Windows Server Backup. For more information, see Installing Remote Server Administration Tools.

Using WinRM and WinRS

You can use WinRM and WinRS to manage remote servers, including RODCs. WinRM is the Microsoft implementation of the WS-Management protocol. WinRS is a shell tool that relies on WinRM to execute remote commands.

WinRM and WinRS are especially well suited for managing an RODC that is deployed in a perimeter network (also known as a DMZ) because they use TCP port 80, which is a standard Internet services port that most firewalls leave open. These tools are also well suited for branch office scenarios because they do not require an administrator to log on to an RODC to remotely manage it.

To use WinRM, install it on the computer that you use for administration and on the remote server that you want to manage.

For more information about using WinRM and WinRS, see the following resources:

• Windows Remote Management (https://go.microsoft.com/fwlink/?LinkId=120126).

• Installation and Configuration for Windows Remote Management (https://go.microsoft.com/fwlink/?LinkId=120127).

• How to enable Windows Remote Shell (https://go.microsoft.com/fwlink/?LinkId=120130).

• Hey, Scripting Guy! Desktop Management from beyond the Grave (https://go.microsoft.com/fwlink/?LinkId=120131).

To remotely manage a computer by using WinRS

1. On the computer that you want to manage, run the following command to enable WinRM:

   Winrm qc –quiet

2. Open an elevated command prompt. For example, type the following command, and then press ENTER:

   Runas <Administrator> cmd

   Where <Administrator> is the name of an account that is a member of the Administrators group on the computer that you want to manage.

3. In the command prompt window that opens after you run the previous command, use WinRS with the following syntax to run commands remotely.

   Winrs –r:<name of the computer you want to manage> <command to execute>

   For example, to view the replication partners for a domain controller, you can run the following command, and then press ENTER:

   Winrs –r:RODC01 repadmin /showrepl

Delegating local administration of an RODC

Administrator Role Separation (ARS) is an RODC feature that you can use to delegate the ability to administer an RODC to a user or a security group. When you delegate the ability to log on to an RODC to a user or a security group, the user or group is not added the Domain Admins group and therefore does not have additional rights to perform directory service operations.

However, the user or group can perform local administration of the server, including any tasks that can be performed by a member of the Administrators group on a member server. For example, a delegated RODC administrator can do the following on the RODC:

• Install hardware devices, such as network adapters and disk drives

• Manage disk drives and other devices

• Install software updates and drivers

• Stop and start Active Directory Domain Services (AD DS)

• Install and remove other server roles and features

• View logs in Event Viewer

• Manage shares and other applications and services

Steps and best practices for setting up ARS

You can specify a delegated RODC administrator during an RODC installation or after it.

During the RODC installation, you can set the name of the account in the Active Directory Domain Services Installation Wizard, at the command line, or in an answer file. In the wizard, set the name of the account on the Delegation of RODC Installation and Administration page, as shown in the following figure. If you are performing a staged RODC installation, this page appears when you precreate an RODC account. For more information about precreating an RODC account, see see Performing a Staged RODC Installation (https://go.microsoft.com/fwlink/?LinkID=103323)

If you are installing an RODC at the command line or by using an answer file, add the /DelegatedAdmin parameter to specify the delegated RODC administrator.

To specify the delegated RODC administrator after installation, you can use either of the following options:

• Modify the Managed By tab of the RODC account properties in the Active Directory Users and Computers snap-in, as shown in the following figure. You can click Change to change which security principal is the delegated RODC administrator. You can choose only one security principal. Specify a security group rather than an individual user so you can control RODC administration permissions most efficiently. This method changes the managedBy attribute of the computer object that corresponds to the RODC to the SID of the security principal that you specify. This is the recommended way to specify the delegated RODC administrator account because the information is stored in AD DS, where it can be centrally managed by domain administrators.

  

• Use the ntdsutil local roles command or the dsmgmt local roles command. You can use this command to view, add, or remove members from the Administrators group and other built-in groups on the RODC. For more information about syntax and examples for using this command, see local roles (https://go.microsoft.com/fwlink/?LinkId=120147).

Using ntdsutil or dsmgmt to specify the delegated RODC administrator account is not recommended because the information is stored only locally on the RODC. Therefore, when you use ntdsutil local roles to delegate an administrator for the RODC, the account that you specify does not appear on the Managed By tab of the RODC account properties. As a result, using the Active Directory Users and Computers snap-in or a similar tool will not reveal that the RODC has a delegated administrator.

In addition, if you demote an RODC, any security principal that you specified by using ntdsutil local roles remains stored in the registry of the server. This can be a security concern if you demote an RODC in one domain and then promote it to be an RODC again in a different domain. In that case, the original security principal would have administrative rights on the new RODC in the different domain.

Use a security group instead of individual user accounts

You can only specify one security principal to be the delegated RODC administrator. As a best practice, you should create a security group for each RODC and assign that group to be the delegated administrator. Then, you can add individual user accounts to the group, and each user can manage the RODC.

Using a security group helps you manage administrative permissions on the RODC more effectively and helps you avoid logging on to the RODC by using privileged account.

For example, suppose that you have two RODCs named RODC1 and RODC2, as shown in the following table.

In this example, RODC1Mgrs and RODC2Mgrs are the respective security groups that are the delegated administrators for each RODC. The membership of each group is comprised of the appropriate user accounts from the respective branch office.

Typically, a domain administrator can manage an RODC remotely without logging on to the RODC directly. In the rare case that a domain administrator must log on to an RODC, the administrator should create a temporary domain user account just for that purpose and add it to the delegated RODC administrator group account. The administrator can log on to an RODC using that domain user account instead of a domain administrator account and eventually delete the temporary account afterward for improved security.

Restrict logon with a privileged account in a site that has an RODC

Because you will deploy RODCs in locations where they might be compromised, you should manage them in the same way as you manage other potentially nonsecure computers. Always treat an RODC as though it is not secure. You should never log on to it—locally or remotely with Terminal Services, by using highly privileged credentials—such as Domain Admins or Enterprise Admins.

An attacker can use a compromised RODC that has a highly privileged account password to perform malicious operations in the forest. Even use of a smart card cannot mitigate the logon risk because a compromised RODC would have access to the security context and could use it maliciously.

It is not necessary for a compromised RODC to have cached the password of a privileged account to use that account maliciously. In addition, you do not want an administrative workstation to be authenticated by an RODC that you do not trust. Although you cannot control which domain controller authenticates the administrative workstation, RODCs do not register service (SRV) resource records for other sites. As a result, RODCs do not authenticate workstations from other sites. If the administrative workstation that you log on to is not in a site with an RODC, it cannot be authenticated by an RODC. Therefore, as a best practice, you should not log on to any workstation with a privileged account in any site that has an RODC—or log on to an RODC locally—unless you fully trust the RODC.

Cache the password for the delegated RODC administrator

So that the delegated RODC administrator can log on to the RODC when the wide area network (WAN) link to the hub site domain controller is not available, the delegated RODC administrator account password must be cached on the RODC. Note that the delegated RODC administrator account is not allowed to be cached on an RODC by default. Therefore, you have to modify the default PRP to allow the password to be cached, cache the password, and the recache it after every password change for successful logon to the RODC when the WAN is not available or a writable domain controller cannot be contacted. You must do this for every member of the security group that you specify as an administrator of the RODC.

Managing passwords and the PRP

Depending on your security and service availability requirements for your RODC site, you may want to change the default PRP. The PRP acts as an access control list (ACL). It determines whether an RODC is permitted to cache a password.

After the RODC receives an authenticated user or computer logon request, if it does not have the credentials cached locally, it forwards the logon request to a writable Windows Server 2008 domain controller. The writable domain controller refers to the PRP to determine whether the password for the account should be cached on the RODC. For more information about how the PRP works, see Credential caching.

You can change the PRP by modifying attributes of an RODC. For more information about changing the PRP, see Administering the Password Replication Policy.

Default PRP

By default, all RODCs have the same Password Replication Policy (PRP). The default PRP specifies that no account passwords can be cached on any RODC, and certain accounts are explicitly denied from being cached on any RODC.

The RODC PRP is determined by two multivalued Active Directory attributes that contain security principals (users, computers, and groups):

• msDS-Reveal-OnDemandGroup, also commonly known as the Allowed List

• msDS-NeverRevealGroup, also commonly known as the Denied List

The msDS-Reveal-OnDemandGroup attribute specifies what security principals can have passwords cached on an RODC. By default, this attribute has one value, which is the Allowed RODC Password Replication Group. Because this domain local group has no members by default, no account passwords can be cached on any RODC by default.

The msDS-NeverRevealGroup attribute specifies what security principals are explicitly denied from having their passwords cached on an RODC. By default, this attribute has the following values:

• Account Operators

• Server Operators

• Backup Operators

• Administrators

• Denied RODC Password Replication Group, which is a domain local group that includes the following:

  • Enterprise Domain Controllers

  • Enterprise Read-Only Domain Controllers

  • Group Policy Creator Owners

  • Domain Admins

  • Cert Publishers

  • Enterprise Admins

  • Schema Admins

  • Domain-wide krbtgt account

Modifying the PRP

By using a combination of the Allowed List and the Denied List for each RODC with the domain-wide password replication groups, you have great flexibility to decide precisely which accounts can be cached on specific RODCs. The following table describes three examples of ways that you might administer the PRP to manage how passwords are cached on the RODCs that you deploy. You can customize any of these examples to best suit your needs.

The following sections explain each example in more detail.

No accounts are cached

This example provides the most secure option. No passwords are replicated to the RODC, except for the RODC computer account and its special krbtgt account. However, user and computer authentication relies on WAN availability. This example has the advantage of requiring little or no additional administrative configuration from the default settings.

You might choose to add your own security-sensitive user groups to the Denied List. Although no accounts are cached by default, adding your own security-sensitive user groups to the Denied List can protect those groups against accidental inclusion in the Allowed List, along with subsequent caching of their passwords on the RODC.

Note that the delegated RODC administrator account is not automatically added to the Allowed List. As a best practice, add the delegated RODC administrator account to the Allowed List to ensure that a delegated administrator can always log on to the RODC, regardless of whether the WAN connection to a writable domain controller is available. For more information, see Cache the password for the delegated RODC administrator.

Most accounts are cached

This example is the simplest administrative mode, and it removes the dependency on WAN availability for user and computer authentication. In this example, you populate the Allowed List for all RODCs with groups that represent a significant portion of the user and computer population. The Denied List does not allow security-sensitive user groups, such as Domain Admins, from having passwords cached. Most other users, however, can have their passwords cached on demand. You might choose to add your own security-sensitive user groups to the Denied List.

This configuration is most appropriate in environments where the physical security of the RODC will not be at risk. For example, you might configure the PRP this way for an RODC that you have deployed in a secure location primarily to take advantage of its reduced replication and administration requirements.

Few accounts are cached

This example restricts the accounts that can be cached. Typically, you define this distinctly for each RODC—each RODC has a different set of user and computer accounts that it is permitted to cache. This example is usually for a set of users who work at a particular physical location.

The advantage of this example is that a set of users will be able to log on to the network and be authenticated by the RODC in the branch office if the WAN is offline. At the same time, the scope of exposure for passwords is limited by the reduced number of users whose passwords can be cached.

There is administrative overhead associated with populating the Allowed List and the Denied List in this example. There is no default automated method for reading accounts from the known list of security principals who have authenticated against a given RODC, and there is no default method for populating the Allowed List with those accounts. You can use the repadmin /prp move command to move these accounts to a group that is in the Allowed List, or you can use scripts or applications such as ILM to build a process.

Although you can add user or computer accounts directly to the Allowed List, you should instead create a security group for each RODC, add it to the Allowed List and then add user and computer accounts to the security group. This way, you can use standard group management tools such as the Active Directory Users and Computers snap-in or the Dsadd or Dsmod command-line tools to manage which accounts can be cached on the RODC.

The repadmin /prp move command requires that you specify a security group. If the security group that you specify does not exist, it creates the group and adds it to the Allowed list. For more information about using repadmin /prp move, see Moving accounts from the Auth2 list to the Allow list.

As with the previous example, you must also add appropriate computer accounts to the Allowed List.

Additional tasks and tools for managing passwords

You can perform the following additional tasks as necessary to manage passwords for an RODC.

Prepopulate the password cache for an RODC

After you initially deploy an RODC, you may want to prepopulate its password cache with the passwords for user and computer accounts that you want to be able to authenticate to the RODC when the WAN is offline. Remember that, by default, the credentials of the accounts whose passwords are allowed to be cached are not replicated to the RODC until the user or computer authenticates against the RODC. Therefore, if the WAN is not available, these users and computers will not be able to authenticate unless you prepopulate the password cache. If you prepopulate the password cache of an RODC with those accounts, the RODC does not rely on WAN availability to authenticate them.

For example, suppose that you are installing an RODC in a branch office, and you want the users and computers in that branch office to authenticate to the RODC when the WAN is offline. If you only add the accounts to the Allowed List, the passwords for those users and computers will be cached by the RODC as those users attempt to log on. If the WAN is not available when one of those users first attempts to log on, the authentication request for that user will fail.

By prepopulating the password cache right after the RODC installation, you can ensure that the passwords for all users and computers in the branch are cached, regardless of when they first attempt to log on.

You can use Active Directory Users and Computers or repadmin /rodcpwdrepl to prepopulate the password cache. The WAN link between the RODC and its replication partner must be available when you perform this task. You cannot prepopulate the password cache during RODC installation. For more information, see Populate the password cache for an RODC.

View current credentials that are stored on an RODC

You can view whose passwords are stored on an RODC. This can help if you want to reset those passwords if the RODC is stolen. This can also help you determine if you need to cache an account that is not yet cached. For example, you can ensure that the delegated RODC administrator account password is cached on an RODC. For more information, see Reviewing Accounts with Cached Passwords on the RODC.

Review whose accounts have been authenticated to an RODC

Periodically, you should review whose accounts have been authenticated to an RODC. This information can help you plan updates that you intend to make to the existing PRP. For example, you can look at which user and computer accounts have authenticated to an RODC so that you can add some of those accounts to the Allowed List so that they can be authenticated by the RODC when the WAN is offline.

You can use Active Directory Users and Computers or repadmin /prp to review whose accounts have been authenticated to an RODC. For more information, see Reviewing Accounts Authenticated to RODC.

Clear cached passwords that are cached on an RODC if it is stolen

There is no mechanism to erase passwords after they are cached on an RODC. If you want to clear a password that is stored on an RODC, reset the password in the hub site. This way, the password that is cached in the branch will no longer be valid for accessing any resources in the hub site or other branches. In the site that contains the RODC on which the password may have been compromised, the password will still be valid for authentication purposes until the next replication cycle, at which time its value that is stored on the RODC will be updated. The new password will be cached only after the user authenticates with it—or the new password is prepopulated on the RODC—and if the PRP has not been changed. Simply removing a user or computer from the Allowed List will not securely ensure that the password cannot be tampered with in case the RODC gets compromised. In the event that an RODC is compromised, reset the passwords for all accounts that have cached passwords and then rebuild the RODC.

You can use Active Directory Users and Computers to delete the account for an RODC that has been stolen. To delete the account, right-click the name of the RODC account in the Domain Controllers organizational unit (OU), and then click Delete. After you confirm that you want to delete the RODC account, you can choose to reset the passwords that are cached on it, as shown in the following figure. As an option, you can also select the Export the list of accounts that were cached on this read-only domain controller to this file check box to create a list of user accounts whose passwords must be reset after the RODC account is deleted. That list of accounts is not available after the RODC account is deleted.

You can also use the repadmin /prp command to delete the security principals from the msDS-AuthenticatedToAccountList attribute or from the msDS-RevealOnDemandGroup attribute that is associated with the RODC. Note however, that this action only clears the value from the attribute; it does not clear the cache on the RODC.

Adding attributes to the RODC filtered attribute set

This section explains how to add an attribute to the RODC filtered attribute set (FAS), and then mark the attribute as confidential. For an example, see Adding Attributes to the RODC Filtered Attribute Set. The example shows how to use the Ldifde command-line tool to add an attribute Contoso-App-Password from the Active Directory schema. This attribute is just an example of a possible secret-like attribute that you can add to a default schema.

Forest functional level recommendation when using the RODC FAS

As a best practice, make sure that the forest functional level is Windows Server 2008 if you plan to configure the RODC FAS. You can be assured that the RODC FAS is not replicated to RODCs only if the forest functional level is Windows Server 2008. This is because a compromised RODC can attempt to replicate attributes from the RODC FAS from a Windows Server 2003 domain controller, which cannot prevent replication from happening. However, by default, RODCs replicate only with Windows Server 2008 writable domain controllers, which ensures that attributes in the FAS will not get replicated. If an RODC is stolen without being compromised first, it will not contain any of the attributes in the FAS.

A compromised RODC may attempt to replicate attributes from the RODC FAS from a Windows Server 2003 domain controller because of the way that access rights to AD DS data are applied. The three possible access rights that can be granted for replication are as follows:

• Replicating Directory Changes All

  Provides access rights to secrets, such as passwords.

• Replicating Directory Changes Filtered Set

  Provides access rights to RODC FAS attributes.

• Replicating Directory Changes

  Provides access to all other Active Directory data that is not defined by the previous two access rights.

The following table explains how these access rights are applied to domain controllers that run different versions of Windows Server.

An RODC is granted only the Replicating Directory Changes right. This means that a rogue RODC could potentially replicate everything, including secrets and RODC FAS attributes, from a domain controller that runs Windows 2000 Server. However, if you want to deploy an RODC, the forest functional level must be Windows Server 2003 or higher, which excludes any domain controllers that run Windows 2000 Server from the forest.

A rogue RODC can replicate RODC FAS data from a domain controller that runs Windows Server 2003 by making a replication request (running as System on an RODC, and using repadmin /getchanges with proper parameters).

A rogue RODC cannot get secrets or RODC FAS data from a domain controller that runs Windows Server 2008. However, domain controllers that run Windows Server 2003 are granted the Replicating Directory Changes right, and, in the case of Windows Server 2003, it includes RODC FAS attributes. This means that any attribute that is part of the partial attribute set that is replicated to the global catalog and is also part of the RODC FAS will replicate to global catalog servers that run Windows Server 2003. Therefore, the presence of a Windows Server 2003 global catalog server represents an opportunity for a rogue RODC to replicate RODC FAS data.

Additional recommendations and restrictions for using the RODC FAS

You cannot add system-critical attributes to the RODC FAS. An attribute is system critical if it is required for AD DS, Local Security Authority (LSA), Security Accounts Manager (SAM), and any of Microsoft-specific Security Service Providers, such as the Kerberos authentication protocol, to function properly. A system-critical attribute has a schemaFlagsEx attribute value of (schemaFlagsEx attribute value & 0x1 = TRUE).

Make sure that the domain controller that holds the schema operations master (also known as flexible single master operations or FSMO) role is running Windows Server 2008 when you add attributes to the RODC FAS so that the attributes are verified to not be system critical. If you try to add a system-critical attribute to the RODC FAS while the schema master is running Windows Server 2008, the server returns a Lightweight Directory Access Protocol (LDAP) error "unwillingToPerform" (0x35). The Windows Server 2003 operating system does not use the RODC FAS. If you try to add a system-critical attribute to the RODC FAS while the schema master is running Windows Server 2003, the operation will appear to succeed but the attribute will not actually be added to the set.

To mark an attribute as confidential, you have to remove the Read permission for the attribute for the Authenticated Users group. Before you mark an attribute as confidential, thoroughly test the effect that it might have on your applications. For more information about marking attributes as confidential, see article 922836 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=99814).

If you are certain that you need to add an attribute to the FAS, there is some benefit to adding it before you install the first RODC in the forest. This way, the attribute never appears on any RODC at any point in time.

You can also add any attribute to the FAS after you install RODCs. AD DS will then dynamically remove links to the attribute value in the Active Directory database from all RODCs in the forest. This removal process is similar to the removal of an attribute from the partial attribute set that is replicated to the global catalog. The attribute values are not immediately deleted from the Active Directory databases on the RODCs. Instead, a link to the value is removed, which prevents AD DS from reading it.

Default RODC FAS

The following attributes are configured as part of the RODC FAS. They are marked as confidential by default to support Credential Roaming and BitLocker Drive Encryption in Windows Server 2008:

• ms-PKI-DPAPIMasterKeys

• ms-PKI-AccountCredentials

• ms-PKI-RoamingTimeStamp

• ms-FVE-KeyPackage

• ms-FVE-RecoveryPassword

• ms-TPM-OwnerInformation