Sites with Multiple Domain Controllers

As a general best practice, you should not deploy other domain controllers in the same site as a read-only domain controller (RODC). RODCs are designed to be placed in locations where the physical security requirements for a writable domain controller cannot be met. If you place an RODC in a site that has other domain controllers and the RODC is compromised in some way, any other computers in that site may also be compromised.

However, it is technically possible to place RODCs in sites that have the following types of domain controllers:

• Domain controllers running Windows Server 2003 or Windows Server 2008 from the same domain or a different domain
• RODCs from the same domain or from a different domain

There are a number of constraints on operations by RODCs and on clients that communicate with them when the RODCs are operating in a site with other domain controllers. There are also considerations for operations when an RODC is placed in a site that has no other domain controllers. These considerations pertain to operations when the wide area network (WAN) is offline. The following sections explain what you can expect with regard to client operations in a branch office that has another domain controller deployed with an RODC. The scenarios that are described in this section are not generally recommended for most branch office deployments. But organizations with more complex configurations might need to plan accordingly for situations when there is WAN connectivity between the RODC and a writable domain controller.

Placing an RODC and a writable domain controller from the same domain in the same site

This following table describes the results that you can expect for common client operations in a branch office when the WAN is offline and an RODC is deployed in the branch office with a writable domain controller. The results of the operations will vary depending on whether the writable domain controller is running Windows Server 2003 or Windows Server 2008.

You should not typically deploy an RODC in the same site as a writable domain controller because if the RODC is compromised, all resources in that site can also become compromised, including the writable domain controller. However, you might choose to have a writable Windows Server 2008 domain controller deployed in the same site as an RODC temporarily, for example, while you are replacing the writable Windows Server 2008 domain controller with an RODC or for some other special purpose.

Placing multiple RODCs from the same domain in the same site

One RODC is sufficient to service the authentication requests for even a large branch office that includes many users and computers.

You should not deploy an RODC to provide redundancy for another RODC in the same site because the RODCs cannot replicate information from each other. RODCs always ignore each other for the purposes of authentication and replication. You can also encounter the following problems if you deploy multiple RODCs in a site:

• The Password Replication Policy (PRP) on each RODC is different. This can lead to an inconsistent logon experience for users in the branch office when the WAN is offline, where they can fail to log on if they authenticate with one RODC but succeed if they authenticate with the other RODC in that site. To prevent logon failures, synchronize the PRP for each RODC and then use a tool such as repadmin /rodcpwdrepl to synchronize the passwords that are cached on each RODC after any of the passwords change.
• Each RODC can become out of sync as a result of Replicate Single Object (RSO) operations for dynamic Domain Name System (DNS) updates and password changes. When a DNS client attempts a dynamic update of a DNS record or when a user attempts a password change in a site with an RODC, the operation is performed on a writable domain controller in a different site and then the RODC performs an RSO operation to replicate in the update without waiting for the next scheduled replication cycle. The update is replicated to only the RODC that forwarded the request, and any other RODC in the same site will remain out of sync until the next scheduled replication cycle.

Placing an RODC and a domain controller (writable or read-only) from different domains in the same site

As a best practice, you should have users and resources from only one domain in a site where you deploy an RODC. If one domain is represented in the site, authentication in the site depends on reaching only a domain controller for that domain. If more than one domain is represented in the site, authentication can depend on reaching as many as four servers across WAN links.

The following illustration shows how authorization works across domains, when only RODCs from these domains are available in the site. The behavior occurs because RODCs do not store trust passwords, for security reasons. Trust passwords are generated by an administrator when the administrator creates a trust. They are privileged, and storing them on RODCs constitutes a potential security threat if the RODC is compromised.

The branch site contains an RODC for domain A and for domain B. A user from domain A (cached on RODC1), whose computer account is also in domain A (cached on RODC1), attempts to access a resource on server 1 in domain B (cached on RODC2). The following sequence occurs:

1. Using the ticket-granting service (TGS) issued by RODC1, the client computer presents a service ticket request for Server1 to a local domain controller for its domain—in this case, RODC1.
2. By reading files in the TGS, the RODC determines that the requested resource is in a different domain. To proceed, the Key Distribution Center (KDC) on the RODC must be able to provide the client computer with a referral ticket, which would allow the client computer to access a KDC in the next domain in the trust path. However, the RODC does not have the trust password. Therefore, it has to forward the request to a writable domain controller in the same domain (domain A).
3. The writable domain controller (Hub1) returns the referral ticket to the RODC (RODC1).
4. RODC1 returns the referral ticket-granting ticket (TGT) to the client computer (computer1).
5. The client computer uses the referral TGT to contact a local domain controller in the target domain (domain B) to request a TGS for the resource.
6. The domain controller, which again is an RODC (RODC2), cannot decrypt the request because it does not have the trust password. Therefore, the RODC refers the request to a writable domain controller in the same domain (Hub2).
7. The writable domain controller validates the request, issues the service ticket, and returns it to the RODC (RODC2).
8. The RODC returns the TGS to the client (computer1).

The client computer can then present the service ticket to the resource.

The RODCs in this scenario must contact writable domain controllers because they do not have the trust password. This means that any new cross-domain authentication requests will not work if the WAN is offline.