Incorporating RODCs into Active Directory

Practically everyone has an Active Directory (AD) domain these days, and every AD domain has problems from time to time. Maybe part of your AD domain isn’t secured according to the industry’s best practices. Possibly one of your branch office’s domain controllers (DCs) is exposed. You might not have good locks—or any locks—on the data center doors in one of your secondary sites. Perhaps you need to expose your AD domain to the Internet, but the idea of baring one of your DCs and its data to the rest of the world scares you. All these situations create serious problems with AD design because they indicate decisions that violate established security directives.

Ignoring security best practices leads to the possibility that your AD data will be compromised or destroyed. Of course you need to protect your network against a catastrophic failure—but your DCs must still be able to provide the necessary services. If you have branch offices or secondary sites, or if you need to share AD data with others outside your firewall, the best solution might be to incorporate read-only domain controllers (RODCs) into your AD design. In this article I discuss situations in which RODCs make the most sense, and I guide you through the design decisions you’ll need to make in order to implement RODCs correctly.

Writeable DC Limitations

Suppose your business has a main office and two branch offices. Figure 1 depicts such a scenario, in which the main office houses two DCs that replicate to one another for redundancy. Writeable DCs in both branch offices provide authentication and logon support for the users in those sites.

Perhaps you installed DCs at the remote sites because of a limitation in your network’s LAN connectivity, such as low network throughput or high latency. Rather than increase the bandwidth between sites, you opted to house local DCs in your branch sites to speed up the logon process. However, branch offices by nature typically house less of the IT infrastructure than the main office does. Branch offices often don’t have a fully realized data center—sometimes they don’t even have a locked closet in which to house an IT server.

Having unsecured servers in a branch office isn’t necessarily a problem, because such machines tend to contain less sensitive data than what’s housed on the secured servers in the main office. However, the type of data stored on a typical DC is more sensitive. DCs tend to contain all your users’ usernames and passwords, AD-stored attributes including personally identifiable information such as employee IDs and Social Security Numbers, and sensitive information such as employees’ home addresses and supervisor/subordinate details.

Every fully writeable DC in your AD forest contains a copy of every AD attribute because the main office’s DC automatically replicates information such as employee IDs to the branch office DCs shortly after you enter the information in AD. This fact doesn’t cause problems for the DCs that are locked in your main office’s data center, but your branch DCs that aren’t physically secured are another story. If a would-be attacker or an industry competitor wanted to steal data about your organization, he or she would only need to break into one of your branch offices and abscond with your poorly protected DC. Inside the DC’s database, he or she could find all the information necessary to learn about every employee, including personally identifiable information whose loss could immediately create a regulatory compliance problem (assuming your company stores this information in its AD database). Worst of all, the would-be attacker would have all your users’ usernames and passwords. To protect your internal IT resources, you’d have to reprovision every single account password.

RODC Solutions

Microsoft introduced RODCs in Windows Server 2008. Although many administrators focus on the read-only aspect of RODCs, their real power comes from the fact that you can configure an RODC to contain only a limited number of your AD passwords. 

The main intent of this password subset is to limit the exposure that a lost DC might bring. Consider Figure 2, which depicts RODCs replacing the branch office DCs. The domain administrator can use the RODCs’ built-in Password Replication Policy (PRP) to identify only the accounts for the individuals who actually work in each site (e.g., Jim and Brenda for Site A, and Bob and Jane for Site B). Passwords for these users are cached only on the local RODC. By default, no passwords are cached on the RODC, although some attributes are cached.

Some attributes are actually written to an RODC. These attributes are necessary for the RODC to do its job and to keep an accurate account of the activities occurring within its services. The LastLogon, LogonCount, and BadPwdCount attributes are written to the local RODC to ensure successful logons. These attributes ensure that security policies can be measured based on activities at the local RODC. Additional attributes written to the RODC by default include Last Interactive Login (if enabled), ms-DS-Site-Affinity, and LastLogonTimeStamp. For failed logons, the BadPwdTime, BadPwdCount, Last (failed) Interactive Login (if enabled), and ms-DS-Site-Affinity attributes are written to the local RODC database.

By default, an RODC’s PRP creates two multivalued AD attributes that contain security principals such as users, computers, or groups: msDS-Reveal-OnDemandGroup, which is exposed as the Allowed RODC Password Replication Group in the Users container, more generically considered the Allowed List, and msDS-NeverRevealGroup, which is exposed as the Denied RODC Password Replication Group in the Users container, commonly called the Denied List. Security principals in the Allowed List include those user accounts whose passwords are allowed to be cached on the RODC. This list should generally contain the users (typically via group membership) who work in the branch office where the RODC also resides. Another set of security principals includes those that should never be replicated to an RODC, including high-level administrators, service accounts, and any domain accounts such as the domain-wide Kerberos KRBTGT account—all of which require extra protection.

Determining which password hashes should be cached on a particular RODC depends on your domain topology and your security policy goals. You can cache only those accounts for individuals who work in a particular remote site, thus protecting all other accounts; or you can replicate a larger set of accounts if those users will need to use local authentication.

Another alternative for extremely high-security environments is to not to cache any passwords on the RODC. As I previously mentioned, this is the default setting. This design ensures that the loss of an RODC won’t affect any user data. In such a case, all authentication requests are referred to an upstream writeable DC; however, logon performance is improved because Group Policy processing occurs at the local RODC.

Note that users whose accounts aren’t cached on the local RODC can still log on. For these accounts, the RODC refers the request to an upstream writeable DC for authentication if an account password isn’t locally cached.

Pollution Protection

The one-way replication of writeable DCs to RODCs provides additional protection against the inadvertent or malicious insertion of polluted data into AD. Consider the situation in which a would-be attacker doesn’t want to gather usernames and account information but instead wants to pollute your AD domain with garbage or corrupted information. Or consider the concerns of test environments in isolated AD sites that need to interact with AD. In either of these cases, the ease of polluting the AD database is remarkable. If a would-be attacker or test environment made just one data change, that change would quickly replicate throughout the forest. Inadvertently or maliciously overwriting data can happen in the blink of an eye, with AD’s built-in replication spreading the corruption throughout an organization. 

RODCs enjoy a one-directional replication topology with their nearest writeable DC. This means that the writeable DC can send targeted updates to the RODC; however, the RODC can’t replicate changes back to the writeable DC. Leveraging an RODC in a partially trusted environment protects the environment against this pollution by preventing a local attacker from using the DC as a launching point for data manipulation.

This pollution protection isn’t limited to just the contents of the AD database itself. AD’s SYSVOL share is similarly protected. An RODC’s SYSVOL is also a read-only construct, updatable via one-way replication from a writeable DC.

Note that this SYSVOL protection is only fully realized when your AD replication solution is upgraded to use DFS Replication (DFSR) rather than the older File Replication Service (FRS) technology. A would-be attacker (or a fat-fingered local administrator) could still make a change to SYSVOL, but if you upgrade to DFSR, SYSVOL replication recognizes when such a change is made and deletes the offending data.

This reason, among others, is why migrating SYSVOL replication away from FRS and onto DFSR as soon as possible is a good practice. For information about SYSVOL migration, including detailed implementation steps, see the Microsoft SYSVOL Migration Series at go.microsoft.com/fwlink/?LinkId=119296.

Administrative Flexibility

Another unique RODC feature is the increased ability to delegate administrative responsibility to local site administrators. Consider again the typical business with branch offices. Such a business typically employs its top-tier IT administrators in the main office. Because branch offices tend not to have the same IT infrastructure as the main office, IT administrators in those locations might not have the same level of skill and experience. In many cases, the “IT person” in a satellite location is only a partial member of the IT team. Often, the most technical branch office employee is handed the job of “Occasional IT Pro.”

Such individuals introduce a risk to the IT environment when part of their responsibility is to administer local DCs. Recall that in order to log on to a DC, you must be a member of the Administrators or Domain Administrators group. For branch offices with writeable DCs, the “Occasional IT Pro” might require godlike domain admin access if he or she must reboot, patch, or perform other regular maintenance on those computers.

RODCs provide the added flexibility of permitting assignment of a delegated administrator to manage the RODC. This person basically has local administrator privileges on the server, but without the extra set of domain administrator privileges that are necessary to manage AD. The capacity for delegated administrator assignment introduces the possibility of RODC use simply for improved management, even in situations in which account and password protection aren’t necessarily high priorities. For more information about the administrative flexibility that RODCs provide, see “Ntdsutil in Windows Server 2008.”

Personal Data Protection with Filtered Attribute Sets

A default RODC instance receives a complete copy of the domain directory partition, including all objects and their linked attribute values. By default, an RODC doesn’t necessarily protect against the exposure of user data. However, RODCs have a built-in service that limits which attributes and values are replicated to all RODCs. This mechanism is an all-or-nothing approach, meaning that disabling an attribute for replication does so for all RODCs at once.

The mechanism uses a Filtered Attribute Set (FAS), which consists of a dynamic list of attributes that aren’t replicated to any RODCs in the AD forest. The intent for attributes that are part of an FAS is the protection of sensitive user data, such as employee IDs or Social Security Numbers. Adding such values into an FAS means those values won’t be present on any RODC that’s compromised at a branch office location.

Microsoft’s website provides numerous articles that explain the exact steps required for adding attributes into an FAS. In making your own design decisions, remember that some attributes might be necessary for application functionality. For example, an application in your organization might require employee IDs or Social Security Numbers to accomplish certain tasks. If those attributes aren’t present on the RODC, the application might fail. Before you add an attribute into an FAS, perform a test to ensure that the restricted attributes aren’t needed by your applications.

Active Directory in the DMZ

A final use of RODCs is when AD information is needed outside the traditional confines of the corporate network. Organizations with applications that reside on the Internet—or organizations that need Internet-enabled authentication services—can improve the security of those services by using an RODC positioned within the demilitarized zone (DMZ). Although extending AD into DMZ environments is typically an edge case scenario, the use of RODCs in the DMZ can increase the protection associated with users, their passwords, and their attribute values.

Incorporating an RODC into a DMZ is a complex process that in many cases might violate established security policies—particularly with the large number of firewall exceptions necessary to pass AD traffic. For information about using RODCs in a DMZ, see the Microsoft TechNet article “Active Directory Domain Services in the Perimeter Network (Windows Server 2008).”

Pervasive AD Security

Because every part of your Windows network rests on your AD infrastructure, ensuring the total security of that infrastructure is paramount. When your computing environment includes branch offices that lack capable physical controls, securing your network requires a mindset shift regarding your DCs. RODCs are an excellent solution for reducing the attack surface of a vulnerable DC, as well as lessening the effect of a lost DC. RODCs aren’t necessary in every environment, so you need to carefully consider your AD design before you decide whether to incorporate them.