Read-Only Domain Controller for Remote Sites

A typical enterprise is characterized by a HQ hub site and several remote branch offices. Should a domain controller (DC) be placed in the branch office?

• Yes, it should. If not, all authentication and Kerberos ticketing activities will be directed to HQ, which might choke a slow & unreliable WAN link. In the event of WAN link failure, all activities will come to a halt.
  
• No, it shouldn't. It poises serious security challenges. DC contains the entire domain schema, including all object attributes, such as user secrets & confidential information. If the DC is accessed or stolen, it will compromise the entire AD integrity. Furthermore, if the data in the remote DC is corrupted or outdated from a backup restore, it will be replicated to the entire domain.

What a dilemma! Windows 2008, however, introduces the new Read-Only Domain Controller (RODC). RODC will receive all Kerberos requests from the clients and redirect to the hub site. But the requested data and user credentials can also be cached locally by configuring a password replication policy (PRP). It reduces reliance on WAN links & maintains only a small subset of the entire domain (restricting to only the users & machines logging on to that particular RODC). Even if the RODC were stolen, the compromise is limited to that small subset of user credentials that you can still manage to revoke. Furthermore, you just need a forest functional level of Windows 2003. In other words, RODC is supported in a hybrid mix environment of Windows Server 2003 and 2008 domain controllers.