Windows Server 2008 Directory Services: Read Only Domain Controllers

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
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 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.

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 writable 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).

Courtesy of ServerWatch.

Latest Articles

Follow Us On Social Media

Explore More