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.
Recent Articles About Windows Server 2008
» Win Server 2008 Directory Services, Windows Server 2008 Functional Levels Overview
» Win Server 2008 Directory Services, Functional Levels Overview
» 10 Coolest Features in Windows Server 2008
Read More About Windows Server 2008
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 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.
Limiting the amount of locally stored confidential information and minimizing potential impact of its accidental or malicious exposure
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 writeable 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.
The list of accounts that requested authentication in this manner, as well as those that have their password cached is maintained and replicated throughout the domain. This way, if RODC is compromised, it is straightforward to determine which accounts are vulnerable and minimize their exposure. As a matter of fact, such option is automatically presented during deletion of the RODC computer account in Active Directory Users and Computers console. After you select the Delete option from the computer object's context sensitive menu (or simply press Delete key) and confirm your intent to proceed, an additional dialog box will give you opportunity to reset all passwords for all locally cached credentials (users and computers), as well as view or export their listing to a csv-formatted file.
Following the RODC promotion, Password Replication Policy settings can be managed from the Properties dialog box (via the Password Replication Policies tab) of its computer object in Active Directory Users and Computers console. Using this interface, you can add or remove arbitrary security principals and assign Deny or Allow policy. Clicking the Advanced... command button gives you access to Policy Usage listing (where you can determine accounts with passwords currently stored on this particular RODC as well as accounts that have been authenticated by it) and Resultant Policy dialog box (from which you can evaluate whether credentials of a particular user or computer will be cached locally).
Within the same interface, you will also find Prepopulate Password... command button, allowing you to proactively cache credentials of arbitrarily chosen users or computers, provided that you point the Active Directory Users and Computers to a writeable Windows Server 2008 domain controller.
Regardless of the Password Replication Policy settings, RODC does, however, store credentials of at least two security principals, as indicated by the content of the Advanced Password Replication Policy dialog box. In the context of this discussion, the first one, designating its own computer object, has limited significance from security perspective. The other represents a powerful krbtgt account (providing keys for signing and encrypting Ticket Granting Ticket communication, which is critical for Kerberos authentication). In the traditional arrangement, its identity is shared across all domain controllers in the same domain, making its potential compromise a major security concern. This concern is addressed by assigning a unique krbtgt account to each RODC, considerably limiting its scope, and allowing other domain controllers to detect any authentication requests originating from it. This, in turn, is used to facilitate the credential caching mechanism.
Additionally, you can prevent certain Active Directory attributes from replicating to Read Only Domain Controllers by including them in RODC filtered attribute set. This is done by setting the 10th bit of their searchFlags attribute to 1 (which corresponds to the hex value of x200) via any utility that offers direct access to the schema (such as ldp or ldifde). It is important to note that this feature does not apply to system critical attributes, identified by the value of their schemaFlagsEx attribute (0x1), which are essential for proper operations of Active Directory and related services.
Restricting domain-wide privileges of local support staff
Local staff can be perform the installation and administration of RODC, but they will not have the domain-wide implications associated with adding its members to the local domain Administrator group. This is shared across every domain controller in the same domain, so from an Active Directory management perspective, such an approach is equivalent to granting them Domain Admins privileges.
In particular, if you do not have access to the location where the new server will be installed, you can perform a staged installation of RODC. This involves pre-creating a RODC computer account in Active Directory (the actual computer should not be a member of the domain at this point), using the "Pre-create Read-only Domain Controller account..." option (from the context-sensitive menu of the Domain Controllers Organizational Unit in Active Directory Users and Computers console running on Windows Server 2008 computer). This, in turn, triggers Active Directory Domain Services Installation Wizard.
During its course, you would not only specify all the information typically provided during RODC promotion (such as its computer name, target Active Directory site, addition of DNS or GC roles, and Password Replication Policy), but also designate (on the Delegation of RODC Installation and Administration page) a non-privileged user or group that will be permitted to associate the new server to the domain controller computer account you are creating.
This will generate an unoccupied DC Account marked this way in Active Directory Users and Computers interface. It must be activated in the second stage by having the group to which you delegated installation rights complete the process and re-run the Active Directory Domain Services Installation Wizard on the target server. To simplify this process, leverage an unattended file, which you can create at the end of initial DCPROMO process.
The same group or user you designated will also be automatically granted local Administrative permissions on that particular RODC. This does not imply the same membership on other domain controllers or any Active Directory level privileges. This lets them perform standard maintenance and support tasks, which require elevated rights (e.g., installation of software drivers) while minimizing risks due to excessive privileges. This feature is controlled using dsmgmt.exe command line utility (via commands implemented as part of its Local Roles context).
The next article of our series will examine the steps necessary to implement RODC and explore several caveats that deal with their unique characteristics.