RODC Features

  • Article

Applies To: Windows Server 2008

Read-only domain controllers (RODCs) address some of the problems that might be caused by branch office locations that either have no domain controller or that have a writable domain controller but not the physical security, network bandwidth, and local expertise to support it. The following characteristics of RODCs help to solve these problems:

  • Read-only Active Directory database

  • RODC filtered attribute set

  • Unidirectional replication

  • Credential caching

  • Administrator role separation

  • Read-only Domain Name System

Read-only Active Directory database

Except for account passwords and other filtered attributes, an RODC holds the same user accounts and attributes that a writable domain controller holds. Clients, however, are not able to write changes directly to the RODC. Local applications that request Read access to the directory obtain access, whereas Lightweight Directory Access Protocol (LDAP) applications that perform a Write operation are referred to a writable domain controller in a hub site.

RODC filtered attribute set

Some applications that use AD DS as a data store may have credential-like data (such as passwords, credentials, or encryption keys) that you do not want to be stored on an RODC in case the RODC is stolen or compromised. For this type of application, you can take the following steps to help prevent unnecessary exposure of such attributes:

  • Add the attribute to the RODC filtered attribute set to prevent it from replicating to RODCs in the forest.

  • Mark the attribute as confidential, which removes the ability to read the data for members of the Authenticated Users group (including any RODCs).

Adding attributes to the RODC filtered attribute set

The RODC filtered attribute set is a dynamic set of attributes that is not replicated to any RODCs in the forest. You can configure the RODC filtered attribute set on a schema master that runs Windows Server 2008. When the attributes are prevented from replicating to RODCs, that data cannot be exposed unnecessarily if an RODC is stolen or compromised.

A malicious user who compromises an RODC can attempt to configure it in such a way that it tries to replicate attributes that are defined in the RODC filtered attribute set. If the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2008, the replication request is denied. However, if the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2003, the replication request could succeed.

Therefore, as a security precaution, ensure that forest functional level is Windows Server 2008 if you plan to configure the RODC filtered attribute set. When the forest functional level is Windows Server 2008, an RODC that is compromised cannot be exploited in this manner because domain controllers that are running Windows Server 2003 are not allowed in the forest.

You cannot add system-critical attributes to the RODC filtered attribute set. An attribute is system critical if it is required for AD DS, Local Security Authority (LSA), Security Accounts Manager (SAM), and any of Microsoft-specific Security Service Providers, such as the Kerberos authentication protocol, to function properly. A system-critical attribute has a schemaFlagsEx attribute value of (schemaFlagsEx attribute value & 0x1 = TRUE).

Make sure that the schema operations master is running Windows Server 2008 when you add attributes to the RODC filtered attribute set so that the attributes are verified to not be system critical. If you try to add a system-critical attribute to the RODC filtered set while the schema master is running Windows Server 2008, the server returns an LDAP error "unwillingToPerform" (0x35). The Windows Server 2003 operating system does not use the RODC filtered attribute set. If you try to add a system-critical attribute to the RODC filtered attribute set while the schema master is running Windows Server 2003, the operation will appear to succeed but the attribute will not actually be added to the set.

Marking attributes as confidential

In addition, we recommend that you also mark as confidential any attributes that you configure as part of the RODC filtered attribute set. To mark an attribute as confidential, you have to remove the Read permission for the attribute for the Authenticated Users group. Marking the attribute as confidential provides an additional safeguard against an RODC that is compromised by removing the permissions that are necessary to read the credential-like data.

Before you mark an attribute as confidential, thoroughly test the effect that this action might have on your applications. For more information about marking attributes as confidential, see article 922836 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=99814).

Default RODC filtered attribute set

The following attributes are configured as part of the RODC filtered attribute set. They are marked as confidential by default to support Credential Roaming and BitLocker Drive Encryption in Windows Server 2008:

  • ms-PKI-DPAPIMasterKeys

  • ms-PKI-AccountCredentials

  • ms-PKI-RoamingTimeStamp

  • ms-FVE-KeyPackage

  • ms-FVE-RecoveryPassword

  • ms-TPM-OwnerInformation

For procedures that describe how to add an attribute to the RODC filtered attribute set, see Appendix D: Steps to Add an Attribute to the RODC Filtered Attribute Set.

Unidirectional replication

Because no changes are written directly to the RODC and therefore do not originate locally, writable domain controllers that are replication partners do not have to pull changes from the RODC. This means that any changes or corruption that a malicious user might make at branch locations cannot replicate from the RODC to the rest of the forest. This also reduces the workload of bridgehead servers in the hub site and the effort required to monitor replication.

RODC unidirectional replication applies to both AD DS and Distributed File System (DFS) Replication of SYSVOL. The RODC performs normal inbound replication for AD DS and SYSVOL changes.

Note

Any other share resources on an RODC that you configure to replicate using DFS Replication are bidirectional.

Credential caching

Credential caching is the storage of user account or computer account credentials. Account credentials consist of a small set of attributes that are associated with security principals. For more information about the attributes that make up account credentials, see “User and computer credentials” in Appendix A: Technical Reference Topics (https://go.microsoft.com/fwlink/?LinkID=128273).

By default, an RODC does not store account credentials, except for its own computer account and a special krbtgt account for that RODC. You must explicitly allow any other credentials to be cached on that RODC, including the appropriate user, computer, and service accounts, to allow the RODC to satisfy authentication and service ticket requests locally.

When only users from the branch are encompassed by the Allow List, the RODC is not able to satisfy requests for service tickets locally, and it relies on access to a writable domain controller to do so. In a wide area network (WAN) offline scenario, this condition probably leads to a service outage.

The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different krbtgt account and password than the KDC on a writable domain controller uses when it signs or encrypts ticket-granting ticket (TGT) requests. This provides cryptographic isolation between KDCs in different branches, which prevents a compromised RODC from issuing service tickets to resources in other branches or a hub site.

After an account is successfully authenticated, the RODC attempts to contact and pull the user credentials or computer credentials from a writable domain controller that is running Windows Server 2008 at the hub site. The hub site can be any Active Directory site where writable domain controllers running Windows Server 2008 are securely deployed.

The Password Replication Policy (PRP) that is enforced at the writable domain controller determines whether the credentials of an account can be replicated from the writable domain controller to the RODC. If the PRP allows it, the RODC replicates the credentials from the writable domain controller and the RODC caches them. After the credentials are cached on the RODC, the RODC can directly service logon requests for that account until the credentials change.

By limiting credential caching to only accounts that have authenticated to the RODC and for which the PRP allows credentials to be cached, the potential exposure of credentials by a stolen RODC is also limited. This is because, typically, only a small subset of domain users and computers has credentials cached on any given RODC. Therefore, if the RODC is stolen, only those credentials that are cached can potentially be compromised.

Administrator role separation

Administrator role separation specifies that any domain user or security group can be delegated to be the local administrator of an RODC without granting that user or group any rights for the domain or other domain controllers. Accordingly, a delegated administrator can log on to an RODC to perform maintenance work, such as upgrading a driver, on the server. But the delegated administrator is not able to log on to any other domain controller or perform any other administrative task in the domain. In this way, a security group that comprises branch users, rather than members of the Domain Admins group, can be delegated the ability to effectively manage the RODC in the branch office, without compromising the security of the rest of the domain.

Read-only Domain Name System

You can install the Domain Name System (DNS) Server service on an RODC. An RODC is able to replicate all the application directory partitions that DNS uses, including ForestDNSZones and DomainDNSZones. If a DNS server is installed on an RODC, clients can query it for name resolution as they might query any other DNS server.

However, the DNS server on an RODC does not support client updates directly. When a client attempts to update its DNS records against an RODC, the server returns a referral. The client then attempts the update against the DNS server that is provided in the referral. In the background, the DNS server on the RODC attempts to replicate the updated record from the DNS server that made the update. This replication request is only for a single object (the DNS record). The entire list of changed zone or domain data is not replicated during this special, replicate-single-object request.