Configuring a Read-Only Domain Controller

Consider an enterprise that is characterized by a main site and  branch offices. The branch offices connect to the main site over WAN links that might be congested, expensive, slow, or unreliable. Users in the branch office must be authenticated by Active Directory to access resources in the domain. Should a DC be placed in the branch office?

Use the buttons below to navigate through the lesson

If a DC is not placed in the branch office, authentication and service ticket activities will be directed to the main site over the WAN link. Authentication occurs when a user first logs on to his or her computer in the morning. Service tickets are a component of the Kerberos authentication mechanism used by Windows Server 2008 domains.

If a DC is placed in the branch office, authentication is much more efficient, but there are several potentially significant risks.

A DC maintains a copy of all attributes of all objects in its domain, including secrets such as information related to user passwords. If a DC is accessed or stolen, it becomes possible for a determined expert to identify valid user names and passwords, at which point the entire domain is compromised. At a minimum, you must reset the passwords of every user account in the domain. Because the security of servers at branch offices is often less than ideal, a branch office DC poses a considerable security risk.

A second concern is that the changes to the Active Directory database on a branch office DC replicate to the hub site and to all other DCs in the environment. Therefore, corruption to the
branch office DC poses a risk to the integrity of the enterprise directory service. For example, if a branch office administrator performs a restore of the DC from an outdated backup, there
can be significant repercussions for the entire domain.

The third concern relates to administration. A branch office domain controller might require maintenance, for example, a new device driver. To perform maintenance on a standard domain controller, you must log on as a member of the Administrators group on the domain controller, which means you are effectively an administrator of the domain. It might not be appropriate to grant that level of capability to a support team at a branch office.

Read-Only Domain Controllers

The RODC is designed specifically to address the branch office scenario. An RODC is a domain controller, typically placed in the branch office, that maintains a copy of all objects in the domain and all attributes except secrets such as password-related properties. When a user in the branch office logs on, the RODC receives the request and forwards it to a domain controller in the main site for authentication.

You are able to configure a password replication policy (PRP) for the RODC that specifies user accounts the RODC is allowed to cache. If the user logging on is included in the PRP, the RODC caches that user’s credentials, so the next time authentication is requested, the RODC can perform the task locally. As users who are included in the PRP log on, the RODC builds its cache of credentials so that it can perform authentication locally for those users.

Because the RODC maintains only a subset of user credentials, if the RODC is compromised or stolen, the effect of the security exposure is limited; only the user accounts that had been
cached on the RODC must have their passwords changed. Writable domain controllers maintain a list of all cached credentials on individual RODCs. When you delete the account of the stolen or compromised RODC from Active Directory, you are given the option to reset the passwords of all user accounts that were cached on the RODC.

The RODC replicates changes to Active Directory from DCs in the main site. Replication is one way (from a writable domain controller to a RODC); no changes to the RODC are replicated to any other domain controller. This eliminates the exposure of the directory service to corruption resulting from changes made to a compromised branch office DC. Finally, RODCs, unlike writable DCs, have a local Administrators group. You can give one or more local support personnel the ability to maintain an RODC fully, without granting them the equivalence of domain administrators.

Installing an RODC

An RODC must replicate domain updates from a writable domain controller running Windows Server 2008. It is critical that an RODC is able to establish a replication connection with a writable Windows Server 2008 domain controller. Ideally, the writable Windows Server 2008 domain controller should be in the closest site to the main site. In the following lesson we will create an RODC called Branchrodc attached to the Es-net domain. We will create a branch office security group and users, then configure a Password Replication Policy (PRP)

Type dcpromo in the run box and click OK. Check if Active Directory binaries are installed. Active Directory installation wizard starts. Click Next to continue. Operating System compatibility page click Next. Ensure add a domain controller to an existing domain is checked and click Next.

Enter domain you wish to join and specify credentials, then click Next. Select domain then click Next. Select site for new domain controller and click Next. Ensure Global Catalog and Read-only domain controller (RODC) are checked and click Next. Click Next. Type in and confirm restore mode password and click Next. Review selections and click Next. Installation of Active Directory begins. Installation completed. Click Finish. To complete the install click Restart Now.