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.
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.
This article was first published on ServerWatch.com.