Securing Branch Office Networks using RODCs

Nowadays networks are not anymore limited to only one single LAN connecting computers together. Companies are growing and so are the networks. Companies have branch offices in remote locations all connecting together through different types of network mediums. So, network are expanding at the speed of the light.

Talking about branch offices, there are so many challenges when configuring a network environment in a branch office and a lot of things need to be considered. I would like to briefly describe three of these challenges here:

Cost Control: Reduce the cost of managing and supporting remote offices (including making most efficient use of network links).

Security: Improve Security of Data and Access.

Agility: Providing a flexible infrastructure that maximizes IT investment.

In this blog post I am only going to talk about security as one of the most important concerns when implementing branch offices and this note will mostly revolve around the network environments implemented and configured on Microsoft systems.

One major component of Windows Server 2008 R2 that has a direct impact on securing your branch offices is Read-Only Domain Controller (RODC).

As the name suggests, RODCs are read-only databases of the AD DS meaning that they require only unidirectional replication for Active Directory, as well for the File Replication Service (FRS) and Distributed File System Replication (DFSR).

This one-way replication brings along a security benefit. Any compromise or other issue that introduces poisoned data into the RODC’s local copy of the AD DS database cannot be replicated back to the rest of the domain controllers in the other locations from the affected RODC. This is certainly a mitigation that can help stop a local problem from becoming a global problem.

One-way replication brings benefits in terms of designing your replication topology and controlling replication traffic, as well. Bridgeheads and hubs do not have to poll the RODC for changes. The RODC performs normal inbound replication for AD DS and FRS and any DFSR changes.

Because the RODC is a member of the domain, sometimes it has a need to write to Active Directory. However, it does not write to the local database, but will instead connect to a writable domain controller, just like a workstation. The RODC computer account is a workstation account, so it has very limited rights to write to AD DS—again to minimize any damage to the enterprise AD DS if the RODC is compromised. Because they are “workstations” in this sense, RODC computer accounts are not members of the Enterprise Domain Controllers (EDC) or Domain Domain Controllers groups.

Administrative Role Seperation:

With Role Separation you can delegate the local administrator role of an RODC computer to any domain user without granting that user any rights to the domain itself or to other domain controllers. In Windows Server 2003, DCs didn’t have a local administrator; if you could administer a DC, you could administer the whole domain.

Administrative Role Separation can allow a local branch user to log on to an RODC and perform maintenance work on the server, such as upgrading a driver, without allowing that user to log on to any other domain controller or manage the domain.

All in all, RODCs provide a way to deploy domain controllers more securely in a branch office location because they are designed to be placed in locations that require rapid, reliable, and robust authentication services but that might also have a security limitation that limits or prevents deployment of a writable domain controller. With an RODC, organizations can mitigate risks with deploying a domain controller in locations where physical security cannot be guaranteed.