Deploying Windows Server 2008 Read-Only domain controllers in your existing environment

One of the great new features of Windows Server 2008 Active Directory Services is the Read-Only Domain Controller (RODC). A read-only domain controller (RODC) is a new type of domain controller in the Windows Server 2008 operating system. The Read-Only Domain Controller (RODC) is primarily targeted toward branch offices or edge sites. RODC doesn’t store any passwords, by default. That way, if the RODC is compromised, then an administrator doesn’t have to worry about someone gaining access to the entire network using the information stored on that server. This addresses the lack of security that can occur at branch offices. So the threat to the Active Directory is drastically reduced.

RODC are read-only state with unidirectional (read-only) replication for Active Directory and FRS\DFSR. Each RODC has its own KDC KrbTGT account—this is the account that issues tickets. This provides cryptographic isolation. RODC uses workstation accounts, so it has very limited rights to write in Active Directory, to minimize unauthorized access. And since RODC's have workstation accounts, they have no EDC or Display Data Channel (DDC) group membership.

Because no changes are written directly to the RODC, and therefore do not originate locally, writable domain controllers that are replication partners do not have to pull changes from the RODC. This reduces the workload of bridgehead servers in the hub site, and the effort required to monitor replication.

RODC unidirectional replication applies to both AD DS and Distributed File System Replication. The RODC performs normal inbound replication for AD DS and Distributed File System Replication changes.

RODC also uses credential caching. Credential caching is the storage of user or computer credentials. Credentials consist of a small set of approximately 10 passwords that are associated with security principals.

With Role Separation you can delegate the local administrator role of an RODC to any domain user without granting that user any user rights for the domain, or other domain controllers. This permits a local branch user to log on to an RODC and perform maintenance work on the server, such as upgrading a driver. However, the branch user cannot log on to any other domain controller or perform any other administrative task in the domain. In this way, the branch user can be delegated the ability to effectively manage the RODC in the branch office without compromising the security of the rest of the domain.

RODC's provide a way to deploy a domain controller more securely in a branch office location. RODC's are designed to be placed in locations that require rapid, reliable, and robust authentication services but that might also have a security limitation that prevents deployment of a writable domain controller. With an RODC, organizations can easily deploy a domain controller in locations where physical security cannot be guaranteed.

I've worked with many customers with insecure branch office environments where the computer room can be anything from a cupboard under the stairs to non-existent altogether. RODC's are perfect for these environments. The following diagram gives a good summary:

Hub-and-spoke environment

Like many customers you may be planning an upgrade of your AD infrastructure to Windows Server 2008 but would like to take advantage of RODC functionality in a shorter timeframe. Well, you can! It is possible to deploy RODC's in your existing Windows Server 2003 AD environment without upgrading all of your AD infrastructure to 2008. Here's what you need to do:

  1. Ensure that your Forest Functional Level is at Windows Server 2003
  2. Run ADPrep /ForestPrep for Windows Server 2008 to extend your AD schema so that you can deploy Windows Server 2008 domain controllers
  3. Run ADPrep /DomainPrep /gpprep for Windows Server 2008
  4. Install a single instance of Windows Server 2008, dcpromo the server to make it a domain controller and assign it the PDC Emulator FSMO role for the domain
  5. Run ADPrep /RODCPrep to extend your schema to support RODC's

Once you have completed these steps you can deploy RODC's in your current Windows Sever 2003 AD environment. You can find out lot more information, including more detailed information on the procedure I've outlined here at the following link:

Skip to main content