Read-Only Domain Controller (RODC) Information

The RODC is one of the most interesting new features of Windows Server 2008.

RODCs provide the following:

• Read-only Active Directory Database – Read-only copy of Active Directory provides a more secure option for distant locations such as a branch office. Changes attempted against the RODC are referred to the next upstream DC.
• Read-only DNS Server – DNS on the RODC can be configured as a DNS Secondary of the Active Directory Integrated DNS zone file or of a Primary standard DNS zone.
• Credential Caching – By default, no passwords are stored on a RODC (including computer passwords), though specific groups can be configured for password caching.  Physical attacks on Active Directory stored domain credentials on RODCs are not possible when password caching is disabled.
• Administrator Role Separation – Administration of a RODC can be delegated to a domain user account without providing “keys to the kingdom” access or significantly decreasing the security posture of Active Directory.
• Reduced Exposure – Filtering specific object attributes to ensure they don’t exist on RODCs.  For example, there may be attributes that were added after the instantiation of Active Directory such as specific attributes that are confidential (SSNs, clearance, etc).
• Unidirectional Replication – The only replication that occurs on a RODC is inbound replication from a fully writable 2008 DC.  This reduces the amount of replication traffic that occurs in the environment as well as the number of connections and connection objects at the primary site.  This also protects the rest of the directory from memory corruption of the database due to hardware failure or improper shutdown.
• SYSVOL Modification Isolation – If SYSVOL is modified on a RODC in the field, the change stays on the RODC and is not replicated out.  This includes added, deleted, and modified SYSVOL files.

There are several key differences between a writable DC and a RODC.
These differences include the following:

• Active Directory Database – DCs host the only writable copies of the Active Directory database and therefore can perform read and write operations against the directory database. RODCs host read-only copies of the AD database which do not include security principal secrets (passwords).  Since RODCs are unable to perform write operations on the RODC hosted AD database, some write operations are forwarded to full DCs and other times the RODC provides referrals to clients  in order for the client to locate a writable DC.
• Active Directory Replication – Writable DCs replicate among themselves frequently and as needed to ensure directory consistency. RODCs never replicate to or from another RODC. RODCs also never send replication data to other DCs. RODCs can only receive replication from a 2008 writable DC.  This replication method is the same for replicating SYSVOL.
• Local AD database storage – Writable DCs host a full copy of the Active Directory database including security principal credentials.  RODCS host a copy of the database except for attributes that are part of the RODC Filtered Attribute Set (FAS) and security principal credentials. Specific credentials can be identified and selected for password replication to the RODC.
• Administration – Writable DC are administered by the domain Administrators and Domain Admins groups; however, membership in these groups also grants enhanced Active Directory rights. RODCs provide the capability to delegate a standard user account and/or user group full administrative rights to the RODC without providing elevated Active Directory permissions.

When placing a RODC at a site, there are several important considerations:

1. Think twice about placing a RODC in the same site as a DC.  RODCs are meant to be used where there are security and/or other concerns (delegation, replication, etc).  If a writable DC is in the site, it makes more sense to place another DC there instead of a RODC.
2. If a location requires a DC that hosts additional services (roles), the DC placed at the site should be a RODC.  DCs should not host services beyond core Active Directory services.
3. There must be a 2008 (or newer) DC upstream from the RODC to enable proper replication. It is best to have two 2008 (or newer) DCs nearby to enable efficient replication.
4. All of the users located at the site serviced by a RODC should be members of a site group which is added to the password policy for the RODC.  This will ensure the user passwords are cached for logon in the event the network connection to a nearby writable DC is down.
5. All of the computers (workstations & servers) located at the site serviced by a RODC should be members of a site group which is added to the password policy for the RODC.  This will ensure the computer passwords are cached ensuring proper computer operation in the event the network connection to a nearby writable DC is down.
6. RODCs never communicate with other RODCs.  This means if there are multiple RODCs in the same site, they may have different accounts cached and possibly different password policies. This scenario is why it may not make sense to place two RODCs in a site.

Note: If items 3 & 4 are not configured to enable password caching, a writable DC must be available to service authentication (Kerberos) requests; both the computer & user passwords must be cached in order for a Kerberos ticket to be granted.

Here are some excellent RODC resources:

• RODC Overview
• Read-Only Domain Controller Planning and Deployment Guide
• RODC Technical References
• RODC Authentication Details (with packet captures)