Read-only domain controllers (RODCs) can transform the way branch offices authenticate users, enabling them to do so quickly, efficiently, and reliably – and without running the risk of compromising security throughout the organization. The ability to run RODCs is one of the most significant new security features to have been added to Microsoft's Windows Server 2008 operating system.

What is an RODC? Essentially it's a new type of domain controller in Windows Server 2008 that hosts read-only partitions of an organization's Active Directory Domain Services (AD DS) database. Although an RODC is read-only, this doesn't mean that the AD-DS databases it hosts can't be updated; it simply means that changes can't originate at the RODC. Changes to the AD DS database made on writable domain controllers are propagated to RODCs while writable domain controllers don't try to pull changes from RODCs -- in fact, as far as Active Directory is concerned RODCs aren't domain controllers at all.

To understand how this can enhance overall security, consider the situation in a typical branch office. While corporate data centers have tight security controls in place to prevent unauthorized people from gaining physical access to servers, branch offices are rarely able to provide this level of security. But the likely consequences of a malicious intruder gaining access to a domain controller in a branch office and altering its contents are severe: changes to the AD DS database would be replicated from the branch office to the other domain servers in the forest, and a hacker could wreak havoc all over the organization with his newly bestowed privileges.

An obvious alternative to hosting a domain server in a branch office is simply to make users connect to a physically secure server situated in the corporate data center using a wide area network (WAN) link. But WAN links from branch offices can be slow and unreliable, leading to lengthy log-on times, and when the WAN link is unavailable, users and applications are unable to work.

An RODC provides a solution to this problem. Located in the branch office, it can authenticate users quickly and efficiently, yet the security risk associated with hosting a domain controller in an insecure environment is substantially reduced because an intruder can't change the domain services database. An unreliable WAN link is only a potential problem if the necessary credentials for authentication are not cached on the RODC.

Let's explore this in more detail. After a writable domain controller authenticates a branch office account over a WAN link, the branch office RODC can request a copy of the appropriate credentials to cache. The writable domain controller will only supply the credentials to the RODC if the Password Replication Policy permits it for that particular RODC. Once cached in the RODC, the RODC can handle users logon requests locally from then on, without the need to consult a writable domain controller using the WAN – at least until the credentials are changed.

As we mentioned earlier, an RODC can substantially reduce (rather than remove entirely) the security risk of hosting a domain controller at a branch office. There remains a risk associated with caching credentials on the RODC. If the RODC were to be compromised by an intruder then the credentials could be cracked. But the number of users' credentials on the RODC is limited to those that have authenticated on it (and whose credentials are permitted to be cached by the server's Password Replication Policy). In the worst case this would only be a small proportion of the domain users as a whole. In theory, you could disable all credential caching, but then all authentication requests would be forwarded to a writable domain controller over the WAN link – one of the things that an RODC is designed to obviate.

Before introducing an RODC into a branch office, there are a couple of things that need to be considered. For example, who will administer it and carry out day-to-day management tasks? It's important to remember that an inexperienced user given administrator privileges at a remote site is a potential security risk to the organization. To make things more secure, Windows Server 2008 enables a local user at a branch office to be given the role of administrator for the RODC at that branch (and that branch alone) by giving them local administrative permissions without the ability to log on to any other domain controllers or to carry out administrative tasks elsewhere in the domain. This means any risks associated with allowing a less-skilled local user to carry out administrative tasks is limited to the branch office itself, without the possibility that their actions, inadvertent or otherwise, could have an effect elsewhere in the organization.

Another important thing to consider is how applications that integrate with Active Directory will work with an RODC. If the applications only need read access to the AD DS database there should be no issues when connecting to an RODC. If they need write access, on the other hand, things are a little more complicated.

When a particular application requests a write operation to the database, the RODC will give the application an LDAP referral response directing it to a writable domain controller. There are two important implications of this. First, the application must obviously be able to support LDAP referrals, and secondly, it must be able to cope gracefully with the possibility that write operations may be impossible from time to time when the WAN link is unavailable.

This illustrates the point rather elegantly that running an RODC is not without its limitations, but those very limitations make an RODC more secure. There's always a fine balance to be struck between functionality and security, and the RODC feature of Windows Server 2008 provides a high level of security while delivering fast and efficient authentication to branch offices.