The two initial installments of our series dedicated to Windows Server 2008 Directory Services, provided a general overview of functionality incorporated into Active Directory since its introduction as part of Windows 2000 Server platform. It presented them in the context defined by modes and functional levels.
Going forward, we will focus on features specific to the latest operating system, describing their characteristics in a more detailed fashion. We will start this new approach by discussing a new concept: the Read Only Domain Controller (RODC).
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 enterprisewide 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:
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 writeable 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 writeable 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 Services representing inbound replication traffic from RODCs.