Fortify Remote-Server Security - 07 Feb 2008

 Executive Summary:

Microsoft is marketing Windows Server 2008 as the most secure Windows OS ever. One of its most important new security features is the read-only domain controller (RODC), a combination of new technologies that not only increases the security of Active Directory (AD) data, but also drastically limits malicious and unauthorized access to your entire AD forest from remote domain controllers (DCs).

The RODC’s one-way replication is its most effective feature for thwarting malicious attacks, but the new component also incorporates password-caching restrictions and administrator role separation. Setup and configuration of an RODC requires you to be knowledgeable and familiar with the new technology to take full advantage of its potential.

The Value Proposition
AD operates in a multi-master replication model, meaning that every DC  holds a read-write copy of the AD database. If you're authorized to write to AD, you can change AD from any DC, and your changes are automatically replicated to the other AD instances in the domain or forest.

A consequence of AD data ubiquity is that malicious administrators who have physical access to a DC, such as an easily accessible DC in a branch office, can launch password cracking attacks against the AD database and obtain the passwords of all user and administrator accounts in the DC’s domain. They can then leverage the passwords for elevation-of-privilege attacks that will damage or destroy the entire AD forest and its dependent services.

The Windows Server 2008 RODC reduces those risks. An RODC is a special-purpose, read-only DC. It doesn’t let you write changes to its AD instance, but it can receive changes from other DCs, because it supports one-way (inbound) replication. You might think that the RODC is just a revival of the Windows NT 4.0 BDC, but it's much more than that.

RODCs have a one-way replication connection agreement with one or more writable DCs. Microsoft modified the Server 2008 AD replication architecture to ensure that an RODC’s one-way replication agreement cannot be changed. For example, RODCs are not members of the built-in Enterprise Domain Controllers security group, which grants writeable DCs various write permissions to the AD database.

By default, RODCs also do not store any passwords in their local copy of AD. To allow authentication when no central writeable DC is available (e.g., in the case of a WAN link outage), you can configure RODCs to store certain users’, administrators', and computers' passwords. Microsoft calls this feature credential caching. You set up credential caching by establishing RODC password replication policies (PRPs). When a user authenticates for the first time, the RODC has to talk to a writeable DC. If the PRP allows credential caching, the RODC will be able to fully authenticate the user's subsequent logons without contacting a writeable DC. Credential caching distinguishes the RODC from the NT 4.0 BDC, which never stores passwords and always requires a PDC for authentication.

The RODC’s one-way replication and restricted credential caching significantly reduce the AD attack surface and mitigate the risks of unauthorized AD access. An RODC makes it impossible for an AD information enumeration attack to reveal all user account password hashes in a domain and can better secure the AD servers in remote locations and other network sites that aren't as physically and logically secure as your corporate data center.

The RODC's one-way replication can also be useful in locations that connect to your data center over a low-bandwidth network. By placing RODCs in locations that require reliable authentication services even though they lack the physical security of a data center, you can let users at those sites authenticate even if the network link to the remote data center is unavailable.

RODCs are also beneficial when DCs must be managed by IT generalists who aren't AD experts and who might unknowingly compromise directory data (e.g., by accidently deleting an organizational unit that holds critical administrator and user accounts).

An RODC can even serve as an AD-integrated DNS server. DNS clients can't directly update data in an RODC’s DNS application because DNS AD application partitions are read-only. RODC DNS servers always act like secondary DNS servers, automatically referring clients to a server that hosts a primary read-write copy of the DNS zone file to update their DNS data.

Setup and Configuration
You can host RODCs only on Server 2008 machines. RODC functionality is included in all Server 2008 x86 (32-bit) and x64 (64-bit) platforms except for the Itanium edition, which doesn't support AD.

Before you can install an RODC, your AD environment must meet several prerequisites. Your AD forest must be at functional level 2 to enable link-value replication. You must move the PDC emulator Operations Master role in the RODC’s domain to either a Server 2008 or a Server 2003 SP2 DC because only those servers can correctly replicate with an RODC. Unless you install a brand-new Server 2008 forest, you need to upgrade your AD schema to the Server 2008 schema by using the Adprep command-line utility (included on the Server 2008 installation CD-ROM) with the /forestprep and /domainprep switches.

You also need to use Adprep's /rodcprep switch to update the AD application partitions' permissions. The /rodcprep switch ensures that application partitions, such as those used for DNS replication, can replicate to RODCs. Finally, there must be at least one Server 2008–writeable DC in the AD site with which your RODC AD site replicates. RODCs can't replicate the AD domain naming context with Windows 2003 or Win2K DCs  because those Windows versions don’t understand the concept of not replicating passwords to an RODC.

The Server 2008 Dcpromo AD installation wizard's Additional Domain Controller Options screen lets you install a server as an RODC, as Figure 1 shows. You can also install an RODC from media and as part of a Server Core installation—a minimal Server 2008 installation that installs only the bits needed to run a Windows server. A Server Core installation doesn't include applications or installation wizards. Because it also doesn't include the Windows Explorer UI, a Server Core installation must be managed from the command line.

The most important configuration task after your RODC is up and running is to define a PRP to control which user, administrator, and computer passwords can be replicated to and stored on the RODC. You can configure a PRP from the RODC's computer account properties in the Microsoft Management Console's (MMC's) Active Directory Users and Computers snap-in, as Figure 2 shows. To define a PRP, you must utilize user, administrator, and computer account group memberships. For each group you can specify whether the RODC is allowed to cache group members' passwords. The PRP's Deny permissions are stored in the msDS-NeverRevealGroup attribute of the RODC's AD computer account object, and Allow permissions are stored in the object's msDS-RevealOnDemandGroup attribute.

To further control the data that's replicated and stored on RODCs, use the RODC partial attribute set to block specific AD object attributes from being replicated to RODCs. Organizations can leverage the partial attribute set to protect sensitive data other than passwords—such as employee personal information.

The RODC's partial attribute set feature is similar to the classic AD Global Catalog (GC) partial attribute set, which determines the attributes replicated to a GC server. The primary difference between the two is that the logic for the RODC partial attribute set is negative: Attributes that are added to the RODC partial attribute set are not replicated to the RODC. AD attributes can be added to the RODC's partial attribute set using the attributes' searchFlags property. If you enable the tenth bit of an attribute’s searchFlags property (i.e., set the bit to binary 1), you ensure that the attribute is not replicated to the RODC.

The final RODC configuration item is administrator role separation. On Windows 2003 and Win2K DCs, separation of the administrator role is essentially impossible. On those OSs, every administrator right or service-level role granted to a user on a DC is valid for all domain DCs. For example, if you give a user administrator rights to a file server that's on a DC or assign him or her a service-level role on that DC, such as Server Operators or Backup Operators, those rights also let that user manage—or mismanage—other DCs on your domain. Consequently, you should never install a DC on a Windows 2003 or Win2K file server to which a user has such rights. Doing so can be particularly costly if you deploy DCs in branch offices where a single server fulfills all roles (including DC and file and print server roles).

On an RODC, you can easily separate server administrators from domain administrators. When you deploy an RODC on a branch office file server, you can grant the local staff administrative rights to manage that file server without extending those rights to other DCs. Administrator role separation isn't available on writeable Server 2008 DCs.

To set up administrator role separation for an RODC, you can use the MMC Active Directory Users and Computers snap-in to access the Managed By tab of the RODC computer object's properties and configure the managedBy attribute. Alternatively, you can configure role separation locally on the RODC using the Ntdsutil or Dsmgmt command line tool's local roles option. For example, to define user Jan as local administrator on an RODC, you'd run the command

dsmgmt "local roles" "add  Jan administrators"

This command enables the local branch administrator Jan to administer the local RODC. Jan can create file shares and add printer queues, but he doesn't have administrative rights on other DCs. If Jan were a malicious administrator, he could still launch offline attacks against the RODC AD database. However, the RODC wouldn't replicate his changes to any other DCs, so damage would be limited to that RODC.

Limit Your Vulnerability
RODCs will significantly change the way we design, maintain, and operate AD networks. The technology can greatly reduce the attack surface of DCs in perimeter AD infrastructure locations. An attack against an RODC will remain isolated and won't propagate to the AD forest. Also, since the RODC doesn't store administrator or user passwords, even a stolen RODC doesn't pose the same risk as the theft of a traditional DC. After you upgrade to Server 2008, you should deploy writeable DCs only in fully trusted networks (e.g., data centers) and install RODCs in all remote locations.