Partager via

Advantages That an RODC Can Provide to an Existing Deployment

  • Article

Applies To: Windows Server 2008, Windows Server 2012

This topic describes the fundamental changes that read-only domain controllers (RODCs) provide and how these changes can affect your considerations for using RODCs in your environment.

Security

The following new features that are associated with RODCs can provide security benefits for your deployment:

  • Unidirectional replication. Unidirectional replication refers to how RODCs can replicate changes inbound but outbound replication does not occur. No other domain controllers replicate changes from an RODC. Unidirectional replication helps to improve security by restricting potentially malicious updates that can originate in a branch office. Because no changes can replicate from an RODC, only the RODC in the branch office can be compromised.

  • Special krbtgt account. Each RODC has a special krbtgt account that also helps to restrict malicious updates from affecting the rest of the forest. The RODC can issue a ticket-granting ticket (TGT) based on its krbtgt account to security principals whose passwords can be cached locally. If a TGT that an RODC issues is used to request a service ticket from a writable domain controller, the authorization data in the TGT is discarded and recalculated before it is added to the TGT.

    This means that the krbtgt account for an RODC is useful only in the local branch where the RODC is deployed. Even if an RODC is compromised, a user cannot use a ticket that has been maliciously created by a compromised RODC to access resources in a different site.

    For example, suppose that a user in branch A tries to access a resource in branch B. If the password for the resource is cached on the RODC in branch A and connectivity is available, the Privileged Authentication Certificate (PAC) that the RODC in branch A creates can be used to access the resource. However, if the password for the resource cannot be cached on the RODC in branch A, the RODC in branch A will forward the request to a hub site domain controller.

    The hub site domain controller discards the PAC from the TGT, recalculates the PAC, and then makes the connection. This way, a branch-signed krbtgt can be used at any writable Windows Server 2008 domain controller in the forest for service tickets for any resource in the forest, but an attacker cannot modify a PAC on an RODC and use that PAC to access resources that cannot be cached by that RODC.

  • Password Replication Policy (PRP). Each RODC has a PRP that, by default, does not allow any passwords to be cached on the RODC. This helps ensure that you can deploy RODCs more securely, because, if the default configuration is unchanged, no account passwords can be obtained from a compromised RODC.

  • RODC filtered attribute set (FAS). You can also restrict which application data can replicate to RODCs in your forest by adding attributes to the RODC FAS and marking them as confidential. When the attributes are prevented from replicating to RODCs and marked as confidential, that data cannot be exposed on an RODC that is stolen or compromised.

Manageability

The following new features that are associated with RODCs can provide manageability benefits for your deployment:

Branch office server administration. RODCs provide Administrator Role Separation (ARS), which you can use to delegate administration of an RODC to a nonadministrative user or group. This means that it is not necessary for a highly privileged administrator to log on to the domain controller in the branch office to perform routine server maintenance.

Note

If a wide area network (WAN) link to a hub site is not available, the password for the delegated RODC administrator must be cached on the RODC so that the delegated administrator can log on to the RODC. As a best practice to enable RODC administration when a WAN is not available, make sure that the PRP allows the delegated RODC administrator account password to be cached, cache the password, and ensure that it is cached again after every password change. For more information, see Administrator Role Separation.

Domain administrators, on the other hand, can continue to remotely manage directory service issues on the RODC as necessary. However, you should not use a domain administrator account to log on to an RODC or to log on to a workstation that is serviced by an RODC. For more information about logging on to manage RODCs, see Steps and best practices for setting up ARS.

Branch office application administration. You might also deploy an RODC for special requirements related to administering applications in a branch office. For example, it might be necessary to run a line-of-business (LOB) application on a domain controller in the branch office. To administer the application, the LOB application owner must log on to the domain controller interactively or by using Terminal Services.

In this case, an RODC can provide a secure mechanism for granting nonadministrative domain users the right to log on to the domain controller without jeopardizing the security of Active Directory Domain Services (AD DS). Furthermore, any Active Directory data that is tampered with locally cannot replicate from the RODC to other domain controllers.

Note

Many applications and operating system components use data that is stored in AD DS. Typically, these applications perform read operations, and they are not affected by using a read-only database. However, some applications must update information that is stored in AD DS, and they might rely on the ability to write data to AD DS. These applications might not function correctly if they perform write operations against an RODC. For more information, see Planning for Application Compatibility with RODCs.

Scalability

The following new features that are associated with RODCs can provide scalability benefits for your deployment:

Unidirectional replication. Writable domain controllers that are replication partners do not have to pull changes from an RODC. This applies to both AD DS and Distributed File System (DFS) Replication of SYSVOL. In larger branch office environments, inbound replication typically puts a significant load on bridgehead servers in a hub site because it is serialized, which means that the bridgehead server cannot process changes from all of its replication partners simultaneously. RODCs that are deployed in the spoke sites can relieve the inbound replication load on bridgehead servers in the hub site because they never replicate any changes.

This can help to reduce the number of domain controllers that you need to deploy in the hub site. The total number of connection objects that have to be created is also reduced by about half, because inbound connection objects do not have to be created on the hub domain controllers for each branch domain controller. Consequently, you do not have to plan for as much configuration of hub site Windows Server 2008 domain controllers as compared with Windows Server 2003 domain controllers.

This can also help to reduce the end-to-end synchronization time for an enterprise. Writable domain controllers in the hub can be configured to replicate updates to a higher number of RODCs concurrently. This can help to implement security changes, such as updates for fine-grained password policies or updates to the RODC FAS, more rapidly.

DFS Replication versus FRS for SYSVOL replication. Windows Server 2008 contains both the File Replication Service (FRS) and Distributed File System (DFS) Replication for replicating SYSVOL. FRS enables interoperability with domain controllers that run Windows 2000 Server or Windows Server 2003. DFS Replication is used to replicate SYSVOL if the domain functional level is Windows Server 2008.

Due to some limitations with how SYSVOL can be restored when it is replicated by FRS in a large-scale environment, the Windows Server 2003 Branch Office Guide recommended that you not exceed 1,200 domain controllers in a domain. Existing branch office deployments might include multiple domains because of this limitation. For example, if you had more than 1,200 branch offices and you wanted to place a domain controller in each branch, you may have created multiple domains.

DFS Replication is a new state-based, multimaster replication engine that supports scheduling and bandwidth throttling. It uses a new compression algorithm to replicate only the changes—not the entire files—when files are updated. This helps DFS Replication to scale up to include a larger number of domain controllers in a domain than can be used with FRS. However, if you want to use DFS Replication, the domain functional level must be Windows Server 2008. You have to continue using FRS to replicate SYSVOL until all domain controllers in the domain are running Windows Server 2008. Plan for migrating from FRS to DFS Replication, and then perform the migration. For more information about planning for the migration, see SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process (https://go.microsoft.com/fwlink/?LinkId=119296).

DC Locator improvements. Domain controller Locator (DC Locator) is a mechanism that clients use to discover the closest domain controller. Windows Server 2008 includes a new Registry or Group Policy setting that enables Windows Vista and Windows Server 2008 client computers to attempt to locate the next closest domain controller if the closest domain controller is not available. The Try Next Closest Site setting improves the performance of DC Locator by helping to streamline network traffic, especially in large enterprises that have many branch offices and sites. By default, DC Locator does not consider a site that has an RODC when it determines which site is the next closest site. If necessary, you can modify the default behavior of the clients (by modifying the NextClosestSiteFilter value on the Windows Server 2008 or Windows Server 2008 R2 domain controllers that respond to client DC Locator requests) so that clients do consider a site that has an RODC when they determine which site is the next closest site.

You can apply the Try Next Closest Site setting to Windows Vista and Windows Server 2008 client computers by using Group Policy or by editing the registry. For more information see Enabling Client Computers to Locate the Next Closest Domain Controller.