In the most recent installment of our series dedicated to Windows Server 2008 Directory Services, we have covered basic features distinguishing Read Only Domain Controllers (RODCs) from their writable counterparts. These unique characteristics make them suitable for deployments in more vulnerable environments (such as branch offices lacking properly protected data centers or DMZ networks exposed to security exploits).
We revisit Read Only Domain Controllers, a bundle of standard Active Directory mechanisms that has been released as a new product feature set. Learn the requirements and restrictions that come into play when planning and managing a deployment.
In addition to being aware of advantages of RODCs, it is important to realize requirements and restrictions that come into play when planning and managing their deployment. This article presents a comprehensive overview.
As we explained earlier, each RDOC hosts a copy of Active Directory database protected from majority of direct, externally initiated changes. Its modifications consist mainly of updates propagating from its inbound replication partners (which have to function as full-fledged domain controllers), but some originating writes are allowed. Although the content of schema, configuration or application partitions can propagate from any domain controller in the same forest, its domain-level replication partner must be running Windows Server 2008, since earlier versions of the operating system are not aware of RODC-specific idiosyncrasies relevant in this context (e.g., Password Replication Policy).
Recent Articles About Windows Server 2008
Read More About Windows Server 2008
As the result, before you attempt to promote the first RODC, you must have at least one writable Windows Server 2008 domain controller in place. This, in turn, is contingent on the presence of Active Directory schema extensions introduced with the latest operating system release. In case of existing forests, it is necessary to perform the schema update by running ADPREP /forestprep while logged on as a member of Schema or Enterprise Admin group to the forest Schema Operation Master (ADPREP command-line utility is included with the Windows Server 2008 installation media and resides in the SOURCESADPREP folder). Prior to implementing this procedure, ensure all domain controllers in the forest are running Windows 2000 Server Service Pack 4 or later.
Once the schema update is successfully completed and has fully propagated throughout the entire forest, you must execute ADPREP /domainprep. /domainprep requires that the domain operates in the native mode, effectively precluding Windows 2000 mixed mode and Windows Server 2003 Interim functional level domains. It is executed in the security context of a member of the Domain Admins group on the Infrastructure Operation Master in each domain that will contain Windows Server 2008 domain controllers.
This results in the creation of new objects in the domain partition as well as modification of Access Control Entries for a number of existing ones. Furthermore, to accommodate changes to permissions on Group Policy Objects (facilitating cross-domain functionality of Group Policy Resultant Set of Policies Planning Mode), you should also run adprep /domainprep /gpprep. This operation will trigger domain-wide synchronization of the SYSVOL volume, resulting in a potentially significant increase in network traffic. For more information on this topic, refer to the Microsoft Knowledge Base article Q324392.
Unsure About an Acronym or Term?
In addition to changes necessary to facilitate installation of Windows Server 2008 domain controllers, you also must take care of RODC-specific requirements. Once again, you will have to employ the ADPREP command-line utility, by executing it with the /rodcprep switch while logged on using an account that is a member of the Enterprise Admin group. This procedure, which modifies permissions on DNS application partitions, allowing them to be replicated to RODCs that serve the DNS Server role, can be invoked from any computer that belongs to the targer forest. Note that ADPREP /rodcprep is peritinent to scenarios that involve Active-Directory-integrated DNS, and none of the ADPREP updates are necessary in a newly installed Windows Server 2008 based forest, since they are already included in its default configuration.
Pitfalls and Caveats
Due to their dependency on Kerberos constrained delegation and linked-value replication capabilities, RODCs require that both their domain and forest are at least at the Windows Server 2003 functional level and the Active Directory environment cannot contain any domain controllers running Windows 2000 Server. However, you will not be able to reap all benefits RODCs offer until all the domain controllers operate on Windows Server 2008 platform, with matching domain and forest functional levels. For example, if this is not the case, restrictions that the filtered attribute set impose, which prevent arbitrary schema attributes from replicating to RODCs, can potentially be circumvented.
Similarly, with both versions of Windows Server hosting Active Directory database, you might experience issues with automatic site coverage mechanism for which the main purpose is to determine how to handle authentication requests from clients residing on subnets without local domain controllers. Since Windows Server 2003 domain controllers do not recognize RODC presence, they consider its local site as a candidate for automatic coverage.
This could cause one of them (closest, in terms of site link cost) to register its site-specific service locator records in DNS, leading to misdirection of clients’ authentication requests. Even though the local RODC also registers its SRV records for the same site, such a situation results in inconsistent authentication behavior, negatively affecting users logon experience.
One way to avoid this issue is to ensure a site adjacent to the one containing RODC hosts a writable Windows Server 2008 domain controller. An alternative solution involves disabling automatic site coverage on all arbitrarily selected servers by setting AutoSiteCoverage DWORD type registry entry under the HKLMSYSTEMCurrentControlSetServicesNetlogonParameters key to 0 on each of them and manually managing DNS SRV records corresponding to RODC and Windows Server 2003 domain controllers to ensure clients will authenticate in a desired manner.
Regardless of how automatic site coverage is handled, the Windows Server 2008 domain controller sharing its domain naming context (and AD-integrated DNS application partitions) with RODC should reside in an adjacent site to optimize the flow of replication traffic and RODC referrals. You could also use site link bridging to facilitate connectivity to a writable domain controller across several sites, but such an arrangement is rather inefficient. Appropriate unidirectional connection objects from the site’s bridgehead servers with a writable replica of each respective naming context to the local RODC are created automatically by the Knowledge Consistency Checker (KCC) processes on the RODC and the site’s Intersite Topology Generator server.
Interestingly, in a Windows Server 2008 environment, if your site design follows hub-and-spoke topology with several bridgehead servers in the central site and individual RODCs located in remote branch offices, connections between them are automatically load balanced. Once the KCC process running on each RODC identifies a new bridgehead server (based on the updates to the Configuration partition), it can dynamically adjust its settings. This functionality is controlled by the value of Random BH Loadbalancing Allowed registry entry residing under HKLMSYSTEMCurrentControlSetServicesNTDSParameters key. The default of 1 keeps it active, and the value of 0 turns it off.
If an RODC is configured as a DNS Server, then read-only, unidirectionaly replicated AD content also includes domain-integrated DNS zones (residing in ForestDNSZones and DomainDNSZones application partitions). Although this approach satisfies name resolution needs, client name registration requests, which cannot be processed locally, are forwarded to a writable DNS server using RODC referral mechanism. Subsequently, within a few minutes, the same RODC makes an attempt to replicate individual, newly updated records from the DNS server that handled the registration. Similarly, RODCs do not register their own SRV records but instead send requests to a writable DNS sever and replicate back the updates. The set of records is smaller compared to full-fledged domain controllers, ensuring RODCs serve only clients local to their respective sites.
Promoting the RDOC
As we described in our previous article, the process of promoting an RODC has been modified to facilitate delegated installation by dividing it into two stages. The first one, performed by a member of Domain Admins group, involves creating an “unoccupied” RODC account in Active Directory, which can be accomplished directly from Active Directory Users and Computers console or by executing dcpromo /CreateDCAccount in combination with an unattended file. In the second stage, a designated RODC administrator performs promotion on the target server (e.g., by invoking dcpromo /UseExistingAccount:Attach command with remaining parameters stored in an unattended file), associating the new domain controller with the precreated RODC account. For more information on this procedure, refer to Performing a Staged RODC Installation article of Windows Server 2008 Technical Library.
When installing RODC from media, its content should be populated by either using backup of another RODC from the same domain or leveraging new functionality built into the NTDSUTIL utility, which generates an RODC-specific System State replica of a Windows Server 2008 writeable domain controller, removing in the process all cached secrets. It offers an option to include SYSVOL in the installation media by applying Create Sysvol RODC command within the IFM context. Afterward, when running Active Directory Installation Wizard interactively, you can simply point to the location containing restored files or assign appropriate value to the /ReplicationSourcePath parameter when performing unattended installation.
To optimize security and performance, consider installing RODC on a Server Core. Although it is possible to configure RODC as a Global Catalog, due to its non-writable nature, serving any of Operation Masters roles is beyond its capabilities (as expected). Bear in mind, however, that none of the currently supported versions of Microsoft Exchange Server — including its latest release — will be able to take advantage of this feature. The same restriction applies to the function of a bridgehead server, which handles the flow of intersite replication traffic, since RODCs are limited to unidirectional, inbound replication. This, in turn, has implications in situations where a site hosts, in addition to a single RODC, other domain controllers (including other RODCs).
In particular, maintaining multiple RODCs in the same site might result in increased intersite replication traffic as well as user confusion, since their logon experience could differ depending on which domain controller first responds to their authentication requests, especially in situations where connection to a writable Windows Server 2008 domain controller is not available.
There is no provision to allow replication between RODCs, so, consequently, they are unable to share cached credentials. More importantly, note that losing a site link to a writable Windows Server 2008 based domain controller results in logon failures for all users whose credentials are not cached on the local RODC. In fact, such an event has a much wider impact, affecting the ability to change user passwords, add new computers to domain, or even log on to local workstations, in case their passwords have expired following the failure.
To facilitate basic management or troubleshooting tasks on RODC in case of network-related problems, you should enable caching for at least one designated site-resident user, preferably the delegated RODC Administrator, by adjusting Password Replication Policy and credential caching settings.
Last, but not least, consider potential issues with applications that depend on the ability to connect to writable domain controller, do not recognize RODCs as a viable read-only source of Active Directory data or are not capable of leveraging RODC referrals. Be aware that services, which depend on the ability to register their Service Principal Names (SPNs) might fail if credentials of their accounts are not cached on a local RODC. To remediate this issue, make sure you prepopulate their passwords via Password Replication Policy tab of the RODC Properties dialog box in Active Directory Users and Computers console.
This concludes our coverage of basic features of Read Only Domain Controllers. The next article, will take a close look at granular password settings functionality introduced in Windows Server 2008 Active Directory.