Placing Several RODCs in the Same Site

Applies To: Windows Server 2008, Windows Server 2008 R2

This topic provides best practice guidance for placing several read-only domain controllers (RODCs) in the same site in the following scenarios:

• Branch office

• Perimeter network (also known as a demilitarized zone (DMZ) or screened subnet)

The focus is on these two scenarios because RODC deployments are most commonly used in these scenarios.

The following sections provide background information for placing several RODCs in the same site. Later sections contain details about the suggested configurations for RODCs in these scenarios.

• DCLocator and DNS general records registration

  • Domain join

  • Client site move and DCLocator

• RODC cryptographic separation

• Connectivity failure

  • Password caching

DCLocator and DNS general records registration

RODCs do not register Domain Name System (DNS) general records (records that are associated with the domain itself and not with a specific site), as read/write domain controllers (RWDCs) do. This is the default behavior of RODCs. Although you can tune an RODC to register DNS general records, we recommend that you not change the default behavior.

The main impact of RODCs not registering DNS general records is that a client computer cannot find an RODC in its site without reaching an RWDC (that is, a domain controller that registers the general records) if the client computer does not have a record for the name of the site where the client computer is placed. This can be an issue in perimeter-network or branch-office scenarios where traffic to the hub site in which the RWDCs are located is blocked. This situation occurs commonly during domain joins from a branch office or perimeter network and in situations in which computers are moved from site to site.

The effects of this issue can be mitigated by the fact that DCLocator domain controller discovery is based on DNS and Lightweight Directory Access Protocol (LDAP). DCLocator falls back to legacy NBT (NetBIOS over TCP/IP) / NBTNS (NetBIOS over TCP/IP Name Server) domain controller discovery mechanisms, based on the broadcast where an RODC should be located if the traffic is not blocked within the site where the client computer and RODC are located (in the branch-office or perimeter-network site). The client should be able to locate an RODC even if it is not able to reach an RWDC.

In the case of a domain join issue, there are several topics and best practices that already provide guidance about how to use scripts or tools to join computers through the RODC, specifying the name of the site or even the name of the domain controller (RODC) that you want to join through. For example, see the section “Add computers to the perimeter network site” in Deploying RODCs in the Perimeter Network (https://go.microsoft.com/fwlink/?LinkId=164009).

In situations in which a computer is moved from one site to another, there is no guarantee that a domain-joined computer will reach the RODC in its new site during the first logon attempt. To ensure that the client computer reaches an RODC during the first logon attempt, you can adjust the SiteName registry key. For more information about how to adjust the SiteName registry key, see SiteName (https://go.microsoft.com/fwlink/?LinkId=164014). For information about how to adjust the SiteName registry key using Group Policy Object Editor, see SiteName (https://go.microsoft.com/fwlink/?LinkId=164017).

RODC cryptographic separation

For security reasons, an RODC does not have the same Kerberos krbtgt account as the rest of the domain controllers in the domain. (Each RODC has its own Kerberos krbtgt account.) This means that a ticket-granting ticket (TGT) that an RODC issues will be valid only for requesting ticket-granting service (TGS) tickets against the same RODC or any other RWDC. (RWDCs have the krbtgt secrets of all RODC krbtgt accounts.) However, if an RODC receives a TGS request based on a TGT that is not valid (that is, where the TGT was not issued by the RODC) and if the RODC has the secret to issue a valid TGT for that account, it returns a Kerberos error asking the client computer to issue a new TGT request against itself. If the RODC does not have the secrets necessary for issuing such a TGT, the RODC forwards the TGS request to the RWDC and the RODC works as a proxy, forwarding the answer from the RWDC directly to the client computer. At the same time, the RODC triggers the process of caching the required secrets for a TGT so that it will be able to serve such a TGT later. The caching succeeds if the Password Replication Policy (PRP) allows the secrets to be cached to the RODC; otherwise, it fails.

The important point is that each RODC uses its own Kerberos TGT account, and the TGT that an RODC issues will not be valid for TGS requests that are sent to a second RODC in the same site. This creates extra traffic if an RWDC is available. If the wide-area network (WAN) is not available, authorization failure occurs until all the RODCs in the site have cached the same secrets.

Connectivity failure

Normally, one of the reasons for placing a domain controller in a remote site is to ensure the availability of Active Directory Domain Services (AD DS) during a WAN failure. If the site is unreliable from a security perspective, it is probably best to place an RODC in this site, not an RWDC. It is important to remember that an RODC with no connectivity to its RWDC replication partner will only be able to authenticate accounts for which it has already cached the secrets, and it will only be able to serve AD DS read requests, because no writes are allowed to a RODC. Therefore, to ensure that authentication requests continue to work, you must ensure that the RODC has all the necessary secrets cached before the link to the WAN becomes unavailable.

Secrets can be cached on the RODC by several means, including the following:

• The regular logon process, using the RODC for authentication

• Prepopulated passwords on the RODC, using the Active Directory Users and Computers snap-in for Microsoft Management Console (MMC) or the command-line tool repadmin

If the PRP for the RODC is configured to allow secrets to be cached on that RODC and there is connectivity between the RODC and its RWDC replication partner, when a user logs on over the RODC in the branch office or perimeter network, the user’s account secrets are cached on that RODC.

RODCs are not aware of other RODCs. This means that in a site with several RODCs, each of the RODCs works independently—without any interaction between them. In particular, RODCs in the same site do not replicate from each other, and they maintain their password caches independently.

At the same time, if an RWDC and an RODC are in the same site, the RWDC treats the RODC as if they are in different sites. No particular change in the way that they interact occurs simply because the partner RWDC for an RODC is in the same site.

Best practices

The previous sections of this topic provide background information for placing several RODCs in the same site. This section describes some best practices and considerations for the following:

• Placing an RWDC in a site with an RODC

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

• Placing two RODCs in a branch office

• Placing two RODCs in a perimeter network

Placing an RWDC in a site with an RODC

An RODC, by design, has enhanced security benefits and administrative simplicity that make it a good fit for a perimeter network or a branch office deployment. If an RODC is compromised, it expose only the resources within its site (when it has a well-configured PRP in place). The moment that an RWDC (whether it is a Windows Server 2003 or a Windows Server 2008 RWDC) is placed in a site with an RODC, the benefit is lost because, if the RWDC is compromised, the resources of the whole domain are exposed.

If a Windows Server 2003 RWDC is placed in the same site as an RODC, unwanted side effects can occur, such as the distribution of attributes in the filtered attribute set (FAS) and DNS registration issues.

If you decide that an RWDC is needed in a site and that you need a second domain controller in that same site, we recommend that you place two RWDCs in that site. Placing an RODC in the same site with an RWDC does not provide an advantage with regard to RODC features.

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 one 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. Authorization works this way because, for security reasons, RODCs do not store trust passwords. Trust passwords are generated by an administrator when the administrator creates a trust. These passwords 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 TGS that RODC1 issues, 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 store the trust password for the domain. 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 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.

Placing two RODCs in a branch office

In branch office sites where AD DS is critical to operational success, it may be necessary to have a second domain controller in the site for fault tolerance and workload balance. Although these are valid reasons for placing a second domain controller (whether it is an RODC or an RWDC), WAN failure is usually the most common point of failure in branch-office deployments of AD DS.

If you have deployed an RODC in your branch office and you have decided that it is necessary to have two RODCs for work load balance and fault tolerance, there are certain considerations that are explained in the following sections.

Increased replication traffic

If there is more than one RODC in a branch office site, there is an increase in replication traffic. Replication traffic is increased across the WAN by n, where n is the number of RODCs in the site. This means that the more RODCs you add to the site, the more inbound traffic replication will occur. This is because inbound replication happens with all the RODCs in the site; the RODCs ignore other RODCs in the site and none of them assumes a bridgehead server role for the site.

Increased authentication traffic

With multiple RODCs in the same site, there is a decreased likelihood for either RODC to be used for authentication requests and a corresponding increased likelihood for authentication to be performed by RWDCs across the WAN. The increased authentication traffic will probably occur even if you manage to synchronize the PRPs for the RODCs.

Example:

• Site 1 contains RODC1 and RODC2. They replicate from an RWDC across a WAN.

• A new user (UserA) with laptopA logs on in Site 1.

• UserA and LaptopA are both allowed to be cached on RODC1 and RODC2, but neither account is cached on either RODC before the first logon attempt.

The following process occurs, first for LaptopA and then again for UserA:

1. The account requests a logon with RODC1.

2. RODC1 does not have the account cached. Therefore, it forwards the request to an RWDC across the WAN.

3. The RWDC authenticates the account and sends the response to RODC1.

4. RODC1 forwards the request to the account and then requests to cache the credentials from the RWDC.

5. The RWDC checks the PRP, and then sends the credentials by means of a ReplicateSingleObject (RSO) operation to RODC1 to cache them.

6. At the next logon attempt, the account is authenticated by RODC2 (this is not controllable), and the process occurs again, even though both RODCs have the same PRP.

It is not enough to make sure that PRPs are synchronized; you have to make sure that the password caches themselves are synchronized to avoid authentication failure if User A and LaptopA tries to authenticate against RODC2 the first time when the WAN link is unavailable. Synchronizing PRPs between two RODCs is not easy to do with the Active Directory Users and Computers snap-in because synchronization must be performed one RODC at a time. For situations such as the one described in this example, it is best to use the repadmin command-line tool. For more information about using repadmin to cache passwords on an RODC, see Repadmin /rodcpwdrepl (https://go.microsoft.com/fwlink/?LinkId=164018).

Synchronized PRPs

If you decide to place a second RODC in a branch office site, we highly recommend that you have all the RODCs in the site share the same PRP and that you enable a mechanism to synchronize all the accounts in the site (computer, user, and service accounts) on both RODCs. As mentioned earlier in this section, the most common cause of failure to access AD DS in branch office deployments is a WAN outage. If a WAN outage occurs, the PRPs are not synchronized between the two RODCs and the site accounts are not cached on both RODCs.

For example, say that a client computer begins to search for a domain controller in its site. It finds and uses one of two RODCs in the site. (In this example, the RODCs are called RODC1 and RODC2.) If a PRP policy includes this computer account, the first time that the client computer attempts to authenticate against the domain by using RODC1, it caches the credentials of the computer account that it receives from an RWDC. This is beneficial because, if the WAN is unavailable, when the client computer again attempts to authenticate, RODC1 does not have to forward the request to an RWDC because the computer account’s credentials are now cached on it.

So far, everything is working as planned in this example, but the DCLocator cache tends to keep this client computer associated with the same RODC (in this case RODC1) where its secrets were cached on first use. Now, on RODC2 (because this client computer has never authenticated itself against RODC2) the client computer account has never been cached on it (RODC2). If in this situation the WAN fails, the client computer can exhibit unexpected behavior. If the client computer switches from RODC1, which has the client computer’s credentials cached, to RODC2, which does not have the credentials cached, authentication fails. This is because RODC2 has not yet cached the client computer’s credentials, and RODC2 is not able to reach the RWDC to check the validity of the provided credentials.

This example illustrates the importance of ensuring, if a second RODC is introduced in a branch office site, that the PRPs are synchronized and that the site’s account secrets are cached on both RODCs. By doing this, you ensure Active Directory access even if the WAN is unavailable.

It is important to remember that a password change also causes the PRPs on the RODCs to become unsynchronized. The password change is registered on the RODC through which the client computer authenticated, but it is not cached on the RODC that has yet to authenticate the client computer.

To ensure that the PRPs are synchronized between both RODCs in the site, we recommend that you:

• Monitor which accounts are cached on each RODC on a regular basis.

• Create a list of the cached accounts on each RODC.

• Compare the lists to ensure that there are no discrepancies.

For more information about PRP, see the following:

• Password Replication Policy (https://go.microsoft.com/fwlink/?LinkId=164019)

• Password Replication Policy Administration (https://go.microsoft.com/fwlink/?LinkID=129064)

Placing two RODCs in a perimeter network

As with branch office deployments, your organization may need to place more than one RODC in a perimeter network site for workload balance and fault tolerance.

In general, the link between the perimeter network site and the RWDC site is not an issue. DCLocator on the client computer is likely to connect with the same RODC for days or even weeks. Member servers probably run continually for weeks or months because of the nature of the hardware setup in the perimeter network. Also, to further ensure connectivity with the RWDC in the internal site, you can place failure-tolerant connectivity devices in the perimeter network site to ensure that the RODC and RWDC are always connected.

Because DCLocator on the client computer connects with the same RODC for such an extensive amount of time, the overload due to account authentication requests can be quite small, although it should still be taken into account. Because of the potential for simple PRP configurations and because the connectivity between the RODC and the internal RWDC can be considered to be permanent, the need to keep the RODC cached accounts synchronized is minimal. Because the connectivity between the RODC and RWDC can be considered to be permanent, we recommend that you not cache regular user accounts on the RODC. (Regular user accounts are accounts that are used by users who authenticate to the RODC on a day-to-day basis.) The exception is the Administrator Role Separation (ARS) roles. The credentials for these roles should be cached and synchronized between the RODCs in the perimeter network. You may need to log on to the RODC locally for troubleshooting purposes, such as recovering a failed RODC. If you do not have the ARS account cached on the RODC, you will not be able to log on to diagnose issues that may arise.