Understanding When to Leverage RODCs

As you can see, branch offices were faced with numerous challenges. Because of the many features of RODCs, however, branch offices can now have domain controllers on site without compromising security.

The main benefits of running RODC in branch offices are associated with the following:

. Read-only Active Directory Domain Services
. Reduced replication workload over the network
. Credential caching
. Administrator role separation
. Read-Only DNS
. Read-Only SYSVOL

These features of RODCs, which are discussed in detail in the following sections, assist in alleviating concerns and dilemmas for organizations.


Read-Only Active Directory Domain Services
Poor physical security is typically the most common rationale for deploying an RODC at a branch office. A read-only copy of the domain controller provides fast and reliable authentication, while simultaneously protecting against data loss in the event the server is compromised or stolen. Because no changes can originate from an RODC, a malicious hacker or IT support personnel with little knowledge of Active Directory administration cannot make changes at the branch level. On a writable domain controller, not only can changes be made, but these changes would propagate to all other domain controllers, eventually damaging or polluting the Active Directory domain and forest.


Reduced Replication Workload over the Network
As mentioned earlier, RODCs do not participate in Active Directory replication in the same fashion as writable domain controllers. Replication with RODC is one-way, meaning all changes from a writable domain controller are propagated to the RODC. An RODC receives changes, but does not partake in or perform any outbound replication to other domain controllers. This results in the replication workload being minimized over the network because changes do not have to be pulled from an RODC and because Active Directory replication is unidirectional. Also reduced is the amount of time required to monitor replication, which is another plus for having an RODC.


Credential Caching
Credential caching with an RODC provides numerous security enhancements for a domain controller residing at a branch office. Take, for example, a new functionality in RODCs that increases security in the event an RODC is stolen. When replication transpires between a writable domain controller and an RODC, only a user’s account information is replicated—not the user’s password. Equally important, passwords are not stored on an RODC. In the event the RODC is stolen, the only accounts that can be hacked and compromised are the local administrator accounts and the RODC account, which is specific to the RODC server. These accounts are not considered to be highly privileged, nor do they have access authorization on the forest and domain. On the other hand, traditional writable domain controllers store both the user’s account information and password on a domain controller, ultimately leaving users very vulnerable.

Because an RODC by default does not store user accounts or passwords locally, branch office users must authenticate against a writable domain controller in a hub site. This is often not practical for branch office users, especially if the WAN link between the sites is slow or unavailable. In this case, it is possible to configure password replication caching for specific branch office users on the branch office RODC. After the credentials are cached on the RODC, the domain controller will service users the next time they try to log on and every other time after that until the credentials change. Typically, a branch office only has a few users, so only a subset of an organization’s users’ accounts are cached on the RODC at the branch office, limiting the exposure of credentials in the event of a system breach.

To provide an additional level of security and at the same time reduce the amount of information exposed in the event an RODC is stolen, a domain administrator can use tools within Active Directory Users and Computers to delete the RODC from the Active Directory domain/forest and reset the passwords for user accounts cached on the RODC.


Administrator Role Separation
Organizations are encouraged to use RODCs when there is a need to satisfy unique administrative requirements and to maintain administrator role separation and isolation. The use of an RODC is especially encouraged if the domain controller situated in a branch office hosts more than one server function or server role, such as a print server, messaging server, file server, and much more. The use of an RODC is also recommended when there are other applications installed on the domain controller. Traditionally, in this situation the administrator of these applications has privileges not only to the applications, but also to the entire Active Directory, which can pose a threat. With RODC, however, you can delegate permissions to local administrators, granting them rights to a particular server, roles, or LOB applications without ever granting them access to Active Directory or
domain resources beyond the scope of the branch. As a result, the local administrator at the branch can perform his or her administrator work activities effectively without compromising the entire Active Directory environment.


Read-Only DNS
When using RODCs, it is possible to add the DNS role/service to the RODC. After the DNS service is added to an RODC, the RODC will replicate Active Directory–integrated DNS information such as DNS-related AD partitions, including both the ForestDNS and DomainDNS zones.

Running DNS on an RODC is very similar to running DNS on a writable domain controller. Users can query the local DNS server residing on the branch office RODC for A records and other DNS-related items such as Internet requests. However, unlike traditional writable domain controllers, DNS on RODC does not support dynamic updates. The DNS zone information is entirely read-only.

If a client wants to update their DNS A or PTR record in the local branch office, the RODC will send a DNS replicate-single-object change request to a writable domain controller running the traditional DNS service. The DNS change for the client will occur on the writable DNS server and, eventually, the change will be propagated back to the RODC via unidirectional Active Directory replication.


Read-Only SYSVOL
In Windows Server 2008, it was still possible for changes to be made to the sysvol folder of an RODC. When changes were made to the contents of the sysvol folder, those changes persisted until being overwritten by the next DFS Replication cycle. In Windows Server 2008 R2, Microsoft made changes to the RODC functionality such that the sysvol folder is now read-only on an RODC.

Source of Information : Sams - Windows Server 2008 R2 Unleashed