Deciding Which Type of Domain Controller Meets the Needs of a Branch Office Location
Applies To: Windows Server 2008
When you are planning a deployment of domain controllers in branch office locations, first, decide which locations require domain controllers. Then, for the locations that do require domain controllers, decide whether to install writable domain controllers or read-only domain controllers (RODCs).
In general, you should plan to use as few domain controllers as possible, to help reduce costs. Start by determining which domain controllers must be placed in the larger locations, such as datacenters and hub locations, and then do the same for the remaining locations.
Datacenters and hub locations
Plan to place at least two writable domain controllers for each domain in datacenters and hub locations. Application servers (such as servers running Microsoft Exchange Server) are often placed in datacenter and hub locations. These servers in turn may need access to a writable domain controller if they are Active Directory–integrated servers and they perform updates. In most cases, deploying writable domain controllers is the best approach if these locations can be secured and they have information technology (IT) personnel on site.
These locations also often have data that must be secured, such as human resource (HR) records. They may also have other types of applications that include sensitive data, such as user account provisioning systems. Because they often include data that requires a high level of security and that is critical for maintaining operations in the organization, these locations typically have strong physical security, a reliable networking infrastructure, and an experienced IT staff. These characteristics also make these locations better suited for writable domain controllers than for RODCs.
RODCs provide only limited security benefits for locations that also have writable domain controllers deployed. However, some RODC features can provide administrative advantages. For example, Administrator Role Separation makes it possible for RODC administration to be delegated to a nonadministrative domain user. Because RODCs do not perform outbound replication, they cannot replicate lingering objects to other domain controllers. For only those administrative benefits, you might use an RODC in a location that has a writable domain controller.
Branch offices and satellite locations
For your branch offices and other satellite locations, consider which of these locations requires a domain controller of any type, whether read only or writable.
If you decide that a particular location requires a domain controller, consider other factors, such as the type of data and services that are required to run in that location, the level of trust that you have that the data and services will be handled securely, the frequency in which applications in that location make writes to Active Directory Domain Services (AD DS), and the level of physical security of the location, to decide which type of domain controller to place there.
The following sections and flowchart can help you decide whether to deploy domain controllers in branch office locations and which type of domain controllers to deploy.
Deciding whether a branch office location requires a domain controller
The first decision to make is whether you should place a domain controller in the branch office or not. This is decided mostly by the quality of the wide area network (WAN) link between your branch office and the hub site. If the WAN is highly reliable and available and if the performance of directory-enabled applications and logons in the branch office is acceptable, you do not have to place a domain controller at that branch office location.
Consider these factors when you are deciding whether to place a domain controller in a branch office location:
If a location has no domain controller locally, users in that branch office location are at risk of being unable to log on and access some critical network resources if a WAN link fails, which can lead to a loss of productivity. Each organization has to make a trade-off between reliable availability of services to branch users and the cost of deploying and maintaining infrastructure services, such as domain controllers, in the branch office. In addition, to enable user logons in a multidomain forest, a domain controller for the user’s domain must be available. Also, the domain controller in the branch office must be a global catalog server, or universal group caching must be enabled in the corresponding site. For more information about these two options, see Plan Global Catalog Servers.
If you want to improve the logon times in a branch office, you can place a domain controller in the branch office. The local domain controller can provide Group Policy objects (GPOs) and logon scripts, which can improve logon performance.
A local domain controller can help reduce network logon traffic between the branch office and the datacenter, but that benefit is offset by Active Directory replication traffic. However, you can schedule Active Directory replication traffic to occur during nonbusiness hours.
For example, consider a network that has branch offices that are connected through slow links to the headquarters. If the daily logon traffic and directory search traffic of a few remote-site users causes more network traffic than replication of updates to the branch office, or if you want to dedicate more bandwidth to business-critical applications during business hours, consider adding a domain controller to the branch office location. An RODC does not create any outbound replication to the hub site. An RODC can also apply GPOs to all the client computers that are in its site, including accounts that are not cached on the RODC.
If reducing the cost of maintaining infrastructure services, such as domain controllers, is more important than network traffic, or if the risk of productivity loss if the WAN is unavailable or congested is considered very minor, centralize the domain controllers for that domain and do not place any regional domain controllers at the branch office location.
Deciding which type of domain controller to deploy
If a branch office has a writable domain controller and it meets your requirements in terms of security, the service that it provides to end users, and the total cost of ownership (TCO) for management, there is probably no reason to change your current infrastructure. Otherwise, factors such as the trustworthiness of the location, the sensitivity of data that will be stored there, and application compatibility can determine the type of domain controller to deploy.
For example, if the location has a Structured Query Language (SQL) server that includes all employee account information, it requires a higher level of trust and should be secured in an appropriate manner. In this case, deploying an RODC may not improve the security of that location.
RODCs are designed to be deployed in locations that have a critical need for local authentication and authorization services but that also lack the trustworthiness and physical security requirements that are appropriate for a writable domain controller.
.gif) Security Note |
|---|
| Accounts that are members of the Domain Admins group (or similarly privileged accounts) should logon interactively only to a trusted computer. If a computer in a branch office, such as an RODC or a File server, is not trusted, then privileged accounts should not use the console or remote desktop to log on to it, thus providing that computer with the clear text password or the logon session. RODCs provide mechanisms to delegate local administration of the RODC without requiring privileged accounts. Delegated RODC administration mitigates risk but still provides the benefits of having Active Directory Domain Services deployed close to users and computers. |
In many cases, branch offices are locations that lack trustworthiness. Therefore, if a branch office requires a domain controller, RODCs should be the first choice over writable domain controllers because they are designed specifically for branch office environments. Some of the functionality that RODCs provide helps meet branch office challenges in very practical ways:
Read-only database and one-way replication
An RODC performs only inbound replication. Therefore, no data ever replicates out of the branch office. This improves security by preventing malicious or accidental updates in a branch office from replicating to the rest of the forest. It also reduces the load on hub site domain controllers that replicate with domain controllers in branch offices. This helps resolve one of the most critical bottlenecks for branch office deployments that use domain controllers running Windows Server 2003: inbound replication on hub site domain controllers. For more information about inbound replication on hub site domain controllers, see the Windows Server 2003 Active Directory Branch Office Guide (https://go.microsoft.com/fwlink/?LinkID=28523).
Another important benefit of unidirectional replication is the reduced cost to manage the Active Directory replication topology in branch offices. If you use RODCs in branch offices, you do not have to use the Active Directory Load Balancing tool (Adlb.exe) to stagger replication connections or schedules, as recommended in the Windows Server 2003 Active Directory Branch Office Guide. RODCs have a built-in mechanism to automatically redistribute connections across a number of possible Windows Server 2008 bridgehead servers when you add or remove bridgehead servers in the hub site. Also, unidirectional replication eliminates the need to manage and monitor complex schedules for the bridgehead servers to replicate updates from the branch offices.
DFS Replication of SYSVOL content
At the Windows Server 2008 domain functional level, you can use Distributed File System (DFS) Replication, instead of File Replication Service (FRS), to replicate updates to the SYSVOL folder between domain controllers. Because it is more scalable than FRS, DFS Replication of SYSVOL makes unnecessary the recommendation in the Windows Server 2003 Active Directory Branch Office Guide to limit the number of domain controllers for each domain to 1200. However, if you plan to deploy more than 1200 domain controllers in a single domain, you should be extremely careful about the monitoring processes and troubleshooting procedures that you have in place to support a deployment of that scale. Microsoft System Center Operations Manager 2007 can help you monitor your branch office environment.
Computer replacement after system failure
Replacing a failed RODC is easier than replacing a failed writable domain controller. This operation can be delegated to a nonadministrative user, and there is no data that must be retrieved and saved before the replacement. RODCs never maintain any unique critical pieces of information. No write operations are performed on the RODCs. Therefore, they never contain information that is not yet replicated to other domain controllers. For more information, see RODC Removal and Reinstallation (https://go.microsoft.com/fwlink/?LinkId=151600).
Password Replication Policy and Filtered Attribute Set
The Password Replication Policy (PRP) and Filtered Attribute Set (FAS) features of RODCs help improve the security of branch offices, compared to writable domain controllers. A common problem in branch offices is the lack of physical security and a higher potential for the domain controller in the branch office to be either compromised or stolen. RODCs make it possible for you to limit credentials and credential-like data in the branch office. For more information about these features, see RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC (https://go.microsoft.com/fwlink/?LinkId=151602).
If an RODC is stolen, most likely only the user credentials that are replicated to it must be reset. (You can reset the credentials with the Active Directory Users and Computers snap-in.) Also, the attacker cannot read any credential-like data that is included in the FAS locally on the RODC. For more information, see Securing Accounts After an RODC Is Stolen (https://go.microsoft.com/fwlink/?LinkId=151603).
Deployment and administration
An RODC can be installed directly onsite by a domain user who has been delegated the right to promote only that particular RODC. This user, who does not have to be a domain administrator, can then perform tasks that a normal server operator would perform, such as applying updates, performing disk defragmentation, and so on. The ability of a delegated user to install an RODC and the ability to install the RODC directly in the branch office are two factors that can make it unnecessary to use a staging site to prepare a domain controller before it is installed in the branch office. This makes deployment of the branch office domain controller easier. It also significantly reduces the cost of maintaining the domain controller in the remote location.
Another new feature that aids RODC deployment is Install from Media (IFM). For RODCs, you can create installation media that does not contain any credentials or any attribute from the FAS. The RODC media prevents secrets, such as passwords, from being on the installation media during transport or while the RODC is getting installed or running. For more information, see Installing Active Directory Domain Services from Media (https://go.microsoft.com/fwlink/?LinkID=132630).
WAN link utilization
RODCs can reduce network traffic by satisfying user and computer logon and authorization requests and performing Active Directory searches locally in the branch office. A general principle for deploying infrastructure is to deploy it physically as close as possible to the users who will use the services.
For example, suppose that you deploy an RODC with the global catalog server option in a branch office. In addition, you have the RODC cache the passwords for branch office users, their computers, and the other branch office servers that host resources that the users need to access. In this situation, the RODC in the branch office can provide authentication and authorization to local resources, and it can satisfy Lightweight Directory Access Protocol (LDAP) searches within the branch office without requiring any WAN connectivity to the hub. The RODC also applies Group Policy to any branch office user and computer, even those users whose passwords are not cached on the RODC.
This use of an RODC helps reduce network traffic in comparison to not placing any domain controller in the branch office. It can also help avoid unavailability of the directory service for the branch office users when the WAN connection is not available. Although changes that happen elsewhere in the forest have to replicate to the RODC in the branch office, you can schedule that replication to occur during off-peak hours. This can help free up bandwidth for line-of-business (LOB) applications during peak hours. Note that write operations, however, must be performed by a writable domain controller in a hub site. Therefore, they require bandwidth.
When you consider whether to place a writable domain controller or an RODC in a branch office location, consider the trade-off between completeness of service offered in the branch office on one side and reduction of both the TCO of having a branch office domain controller and the risk due to the lack of physical security in the branch office on the other side.
Physical security ensures that unauthorized users cannot turn domain controllers on or off, add or remove hardware, insert or remove removable media, log on by using the keyboards and displays of domain controllers, or remove backup media.
While the items in the previous list explain the advantages of RODCs that can help reduce the cost of administering a domain controller in a branch office location, there are still certain conditions under which organizations cannot deploy RODCs in their branch offices:
Application compatibility
Most directory-enabled applications only have to read data from the directory. As a result, these applications should work without problems with RODCs anytime—even if connectivity to a writable domain controller is not available, for example, when the WAN is offline. However, some applications must be able to write to AD DS. If these applications are located in the branch office and they cannot be relocated to the hub, you may have to install a writable domain controller in the branch office if the applications have to make updates to AD DS even when the WAN is not available.
For more information, see the Read-Only Domain Controllers Application Compatibility Guide (https://go.microsoft.com/fwlink/?LinkID=117785).
You should test applications that run in the branch office to make sure that they work with RODCs. One widely used application that is known to not work with RODCs is Exchange Server. Therefore, you should carefully consider whether you really need to run Exchange Server in the branch office location or you should consolidate your Exchange Server infrastructure in a centralized location.
In addition, some applications may not work correctly if they are installed directly on an RODC. If the RODC is the only server in the branch office and the branch office must run this type of application, consider the following alternatives:
Deploying a writable domain controller in the branch office location
Running the RODC or the application in a virtual machine (VM)
Deploying additional server hardware to the branch office location to run the other application.
Finally, an application may target a writable domain controller even though the application only performs read operations. In this case, you must either deploy a writable domain controller to support the application; reconfigure the application to work with RODCs; or relocate the application to a place, such as a datacenter or hub location, where it can use a writable domain controller. The assumption for these solutions is that having these applications access domain controllers across the WAN is not acceptable.
Service with the WAN offline
When the WAN is offline, an RODC can authenticate only the users and resources for which it has cached passwords. If you have a strong requirement that any user must be able to authenticate in the branch office location, you may want to place a writable domain controller at that branch office location. As an alternative, you can place an RODC at the branch office location and configure the RODC so that all users’ credentials are allowed to replicate to it. You can then have an automated process in place that caches the credentials of the users, computers, and other resources that are located in the branch office. This way, you can take advantage of other RODC features.
If a location requires a writable domain controller, deploy it where you can ensure its physical security and only allow authorized administrators to access it. A malicious person who has physical access to a writable domain controller can gain access to sensitive data that is stored in AD DS, such as passwords, by using a variety of methods. For example, in this situation an attacker can:
Access physical disks by starting an alternate operating system.
Remove (and, possibly, replace) physical disks on a domain controller.
Obtain and manipulate a copy of a domain controller system state backup.
Take appropriate precautions to restrict unauthorized access to branch office domain controllers. Windows® BitLocker™ Drive Encryption can partially mitigate a few of these risks, but it does not completely eliminate the risks that are inherent with inadequate physical security of a server. For more information about BitLocker, see BitLocker Drive Encryption (https://go.microsoft.com/fwlink/?LinkId=141479).
If you place a writable domain controller in the branch office, you must also make sure that it can be administered and maintained by a domain administrator.
You can use the following flowchart to decide whether a branch office location requires a domain controller and which type of domain controller it requires.
.gif)