Windows Server Set-up

Since the inception of Windows-based domains, the ability to provide robust and resilient authentication mechanism in inherently non-secure locations constituted a challenging and risky undertaking. Placing a domain controllers in an office without appropriately protected data center or in a DMZ section of the network jeopardized confidentiality of its content, including all credentials stored in its database. Any accidental corruption (not unlikely in environments lacking qualified local support) or a malicious hack propagating back to the rest of the network could easily lead to an enterprise-wide disaster.

On the other hand, relaying authentication requests to domain controllers residing within properly protected main office or internal network frequently was not feasible due to security, performance or reliability implications. To address these issues, Microsoft customized some of standard Active Directory mechanisms, bundled them together and released the resulting combination as part of the new product feature set in the form of Read Only Domain Controller (or simply RODC).

The main purpose of this customization was to reduce the range and severity of vulnerabilities associated with hosting full-fledged domain controllers in environments where they could be easily compromised. In general, the resulting changes can be grouped in the following three categories, depending on the functionality they provide:
Preventing any unauthorized or potentially harmful changes from replicating back to the rest of domain controllers.

This goal was accomplished by having Active Directory database operating in read-only mode. In cases where write access is required (e.g., due to application-specific requirements), RODC returns a referral to a Windows Sever 2008 writable domain controller, which availability is, incidentally, one of the prerequisites for installing RODC.

The same rule applies to Active Directory integrated DNS zones, which are implemented typically in the form of ForestDNSZones and DomainDNSZones application partitions. Although the RODC is fully capable of responding to any query regarding its authoritative or cached records, new registrations or updates are handled through referrals (making the client responsible for contacting DNS server residing on a writable instance of Windows Server 2008-based domain controller). However, the local server will attempt to keep its copy of the respective zone up to date, by reaching out to the referenced server and requesting replication of the most recent change.

With no originating writes to the replica of the database and to the content of SYSVOL (hosting file system portion of Group Policies Templates), there is no reason for the RODC to participate in traditional multimaster replication, which has been one of the core principles in earlier implementations of Active Directory. Consistency of its content is ensured by maintaining uni-directional inbound replication (including Distributed File System Replication mechanism that, with Windows Server 2008 domain functional level in place, is used to keep SYSVOL current) from full-fledged domain controllers. This is reflected by the lack of connection objects in Active Directory Site.

Three basic mechanisms deliver this functionality. The first one relies on restrictions placed on caching of user and computer credentials in the RODC database, which are controlled by the Password Replication Policy; the second involves RODC-specific krbtgt accounts; and the third is based on filtering attributes of objects replicated to RODCs.

Password Replication Policy settings are revealed during setup of an RODC via the Active Directory Domain Services Installation Wizard. This allows you to designate security principals (users, groups and computers), for which the credentials caching allow or deny rules will apply. By default, the denied list includes four domain built-in groups (Administrators, Server Operators, Backup Operators and Account Operators) and the Denied RODC Password Replication Group (containing Cert Publishers, Domain Admins, Domain Controllers, Enterprise Admins, Group Policy Creator Owners, Read-only Domain Controllers and Schema Admins domain groups, as well as krbtgt domain-level user account). Allowed consists of a single Allowed RODC Password Replication Group (initially empty), but you can customize each to match your preferences, either directly from the same page or after the wizard completes. In the case of conflicting settings, deny rule always takes precedence.

During a local computer startup or user logon, RODC reaches out to a writable Windows Server 2008 domain controller to verify its credentials. If the response is positive, RODC requests the password hash so it can be stored locally and reused during subsequent authentication requests from the same security principal. Its full-fledged counterpart that provided this information verifies that the step will not violate established Password Replication Policy. Assuming that is not the case, it forwards the hash to RODC.
Source: enterpriseitplanet.com