What’s the Big Deal with RODC?

A challenge with any Win2K or Windows 2003 AD deployment has always been the placement of DCs in remote sites (such as branch offices) that aren’t necessarily as physically secure as a company’s data center.

Except for special Operations Master (FSMO) roles such as the Schema Master and the PDC emulator, all DCs prior to Server 2008 are basically equal. Administrators of any Win2K or Windows 2003 DC can write changes to the AD database and can replicate these changes to other DCs in their AD domain or forest. Therefore changes performed on a single DC can affect the whole domain or even the whole forest. A malicious user with physical access to a DC, say, in a branch office, can fairly easily make an elevation-ofprivilege attack to damage or even destroy a company’s entire AD forest and dependent services.

As shown in Figure 1, the malicious change on the rightmost branch-office DC replicates out to the central hub DC, which then replicates that change to all other DCs in the enterprise. Furthermore, because all DCs always copy the full AD domain partition, including the passwords of all users and administrators in that domain, a compromised DC would also allow a thief to perform password cracking attacks against the DC’s AD database, enabling additional remote attacks. (See that thief in Figure 1? He just stole a DC.)

The Server 2008 RODC was designed to reduce such risks. You can use an RODC in locations that might not offer the same physical security as a datacenter but require rapid, reliable, and robust authentication services, even if the network link to a remote datacenter is not available. Companies that require such authentication quality in their branch offices no longer have to deploy ordinary writable DCs into these sites. Organizations now have the option to deploy RODCs, which by default don’t replicate passwords locally and never replicate local changes back to any other DC. RODCs have a one-way only replication connection agreement with their writable DC replication partner. Various changes in Server 2008’s underlying replication architecture ensure that this agreement can’t be changed. For example, RODCs aren’t members of the Enterprise Domain Controllers security group, which grants writeable DCs various write permissions to the AD database.

Password Replication Policies (PRP) determine which passwords to replicate to an RODC. Determining how to configure PRPs for your company will be a key challenge for the management of RODCs. PRPs are managed per RODC and provide a list of groups, users, or computer accounts that are either allowed or denied permission to cache their password on an RODC. The PRPs are stored with the computer account object of the respective RODC in AD, as Figure 2 shows.

Deploying RODCs is an extremely attractive proposition to increase security in branch office and DMZ deployments. As Figure 3 shows, you would deploy writable DCs in a Server 2008 AD infrastructure only in fully trusted networks (data centers). You can safely deploy RODCs in edge networks. As a result, an AD infrastructure attack like the scenario shown in Figure 1 is now limited to the attacked RODC in the branch office. And because the RODC doesn’t store any administrator user secrets (passwords) by default and will typically be configured to cache only the passwords of the users in the RODC’s site, a stolen RODC doesn’t pose the same risk to a company that a fully writeable DC does.

An RODC can also be a Read-Only Global Catalog (ROGC). Note however, that while ROGCs are supported to be used as GAL servers for Outlook clients, they aren’t supported as GCs for use by Exchange servers. This will have an impact on administrators who want to deploy the RODC in a branch office but also maintain a local Exchange server.

You can compare the features of an RODC with those of a proxy server. If a user is authenticating in a site that has an RODC, the user’s client will locate this RODC like any other DC and attempt to authenticate to the RODC. In fact, clients usually won’t know if they’re talking to a writeable DC or an RODC, because the RODC will retrieve all the data it needs on behalf of the client. When the user authenticates for the first time to this RODC, the RODC will need to talk to a writeable DC (usually across the WAN to a DC in a hub site) and authenticate the user against this writeable DC. If the RODC is allowed to cache the user’s password hash, as determined by the RODC’s PRP, the RODC will be able to fully authenticate the user the next time without needing to contact a writeable DC.

RODCs have other attractive features that distinguish them from writable DCs: For example, you can delegate local administrator rights (or other roles) to domain users or groups to a specific RODC, without granting the users any special rights in your AD domain. You do so by using the managedBy attribute of an RODC computer object or by assigning local roles through NTDSUTIL. This capability saves you from requiring a domain admin account for maintenance tasks on branch-office DCs that can also be performed by users with lower privileges. (This includes the task of promoting new DCs.) This capability is restricted to RODCs.

News Source: WindowsITPro