Share via

Read-Only Active Directory Database, SYSVOL, and Unidirectional Replication

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

This topic explains how the read-only copies of the Active Directory database and the SYSVOL shared folder work with unidirectional replication to prevent any potentially malicious changes on a compromised read-only domain controller (RODC) from affecting the rest of the forest.

Domain controllers replicate data by pulling in any changes that occur on other domain controllers. Inbound replication is single threaded. A domain controller can pull updates from only one replication partner at a time. When a domain controller has a large number of replication partners, replication can become a bottleneck.

Because no user-initiated changes are written directly to an RODC—and therefore no changes originate from RODCs—other domain controllers do not have to pull changes from RODCs. Therefore, the other domain controllers can ignore RODCs when they replicate changes. By replacing writable domain controllers in remote locations with RODCs, you can simplify the replication topology of your environment and reduce the load on domain controllers in central locations that are replication partners for a large number of other domain controllers in remote locations. Monitoring and managing replication is also simpler because there are fewer replication connections.

Restricting RODCs from originating changes also prevents any changes or corruption that a malicious user or application might make on an RODC from replicating to the rest of the forest, as described in the following examples:

  • A malicious user obtaining physical access to an RODC in a branch office in which there is only limited security and attempts to perform modifications locally on the database

  • Memory corruption of the database as a result of hardware failure

  • Accidental deletion of the SYSVOL folder by an administrator in the branch office

When a user or application in a site that is serviced by an RODC attempts to perform a write operation, one of the following actions can occur:

  • The RODC forwards the write request to a writable domain controller and then replicates the change back from the writable domain controller. For most write operations, the change is replicated back to the RODC during the next scheduled replication interval. In some other cases, the RODC attempts to replicate the change immediately. An RODC forwards a very limited set of writes, including the following:

    • Most types of password changes. For more information about password changes, see Password changes on an RODC.

    • Service principal name (SPN) updates. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update SPNs, the forwarding is done over RPC.

    • Some updates to client attributes over Netlogon: client name, DnsHostName, OsVersionInfo, OsName, Supported Encryption Types

    • LastLogonTimeStamp. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update these attributes, the forwarding is done over LDAP.

  • The RODC sends a referral for a writable domain controller to the client. The application from which the write operation originated can then chase the referral and target a writable domain controller to perform the write operation. By default, RODCs send referrals for Lightweight Directory Access Protocol (LDAP) updates and Domain Name System (DNS) record updates.

Note

During forwarding (or “chaining”), the RODC sends the write request to a writable domain controller and returns the result back to the client upon completion of the write request. Referrals are a hint that the client can chase. For example, in the case of an LDAP application, if chase referrals is enabled on the LDAP connection between the client and the RODC, the application never knows that the client received a referral from the RODC. The client is automatically redirected to the writable domain controller that is specified in the referral.

  • The write operation fails: it is neither referred nor forwarded to a writable domain controller. In this case, the application requesting the write should be updated to specifically target a writable domain controller. A number of RPC writes fall under this category.

For a small set of operations, an RODC attempts to inbound-replicate an individual change, where only the modified object is replicated by using a replicate-single-object (RSO) operation that is initiated by the RODC without waiting for the replication schedule. These operations are limited to the following:

  • Some types of password changes.

    For more information about RSO operations for password changes, see Password changes on an RODC.

  • DNS updates in which a client attempts to make a DNS update and is then referred to DNS server where the updates are registered and the RODC attempts to pull those changes back in by performing an RSO operation. This operation occurs only for Active Directory-integrated DNS zones.

    By default, this replication of DNS updates occurs within a timeframe anywhere from 30 seconds up to 210 seconds after the update is registered.

    For more information about RSO operations for DNS updates, see DNS updates for clients that are located in an RODC site.

  • Updates for the previously listed client attributes: client name, DnsHostName, OsVersionInfo, OsName, Supported Encryption TypesLastLogonTimeStamp.

The following sections explain in more detail how some of these processes work.

Read-only SYSVOL

The SYSVOL share on an RODC is effectively read only. For both the File Replication Service (FRS) and Distribute File System (DFS) Replication, updates to the SYSVOL share on an RODC are performed on a writable domain controller and then replicated to the RODC. However, there are differences in how FRS and DFS Replication handle updates to SYSVOL on an RODC. FRS is used to replicate SYSVOL at the Windows 2000 and Windows Server 2003 domain functional levels. At the Windows Server 2008 domain functional level, you can use DFS Replication to replicate SYSVOL, instead of FRS.

There have been improvements to DFSR for SYSVOL replication so that SYSVOL on an RODC that runs Windows Server 2008 R2 is absolutely read-only. In Windows Server 2008, a delegated administrator could still write changes to SYSVOL on an RODC, and the change would not be overwritten (although the changes would not replicate out either). In Windows Server 2008 R2, the changes are overwritten even if the delegated administrator for the RODC somehow manages to modify SYSVOL. The following table summarizes the behavior changes between FRS and DFSR and between Windows Server 2008 and Windows Server 2008 R2.

Windows Server 2008 RODC, where SYSVOL is replicated with FRS

Local changes are not replicated out, and they are not discarded.

Windows Server 2008 RODC, where SYSVOL is replicated with DFSR

Local changes are not replicated out, and they are discarded.

Windows Server 2008 R2 RODC, where SYSVOL is replicated with FRS

Local changes are not replicated out, and they are not discarded.

Windows Server 2008 R2 RODC, where SYSVOL is replicated with DFSR

Local changes are blocked by a file system filter driver.

If you are using FRS to replicate SYSVOL, it is possible for SYSVOL contents on an RODC to become out of sync with other domain controllers. For example:

  • If a delegated RODC administrator deletes a file or directory in the SYSVOL folder on the RODC:

    • The change is not replicated from the RODC to other domain controllers, but the contents of the SYSVOL folder on the RODC are now different from the contents of the same folder on other domain controllers. This change can affect any computer that obtains Group Policy objects or logon scripts from that RODC, not only computers that are defined in the PRP. In this case, the affected computers might not obtain intended Group Policy objects or logon scripts.

    • To synchronize the contents of the SYSVOL folder again, you can make a change on a writable domain controller to force the directory or file to replicate to the RODC, or you can set the Burflags registry setting to D2. For more information about setting the Burflags registry setting, see How to rebuild the SYSVOL tree and its content in a domain (https://go.microsoft.com/fwlink/?LinkID=70802).

  • If a delegated RODC administrator adds a file or directory in the SYSVOL folder on the RODC:

    • The change is not replicated from the RODC to other domain controllers. However, the contents of the SYSVOL folder on the RODC are now different from the contents of the same folder on other domain controllers. This change can affect any computer that obtains Group Policy objects or logon scripts from that RODC, not only computers that are defined in the PRP. In this case, the affected computers might obtain unintended Group Policy objects or logon scripts.

    • To synchronize the contents of the SYSVOL folder again, you have to manually delete the file or directory on the RODC or completely rebuild the SYSVOL tree. For more information, see How to rebuild the SYSVOL tree and its content in a domain (https://go.microsoft.com/fwlink/?LinkID=70802).

However, if you are using DFS Replication for SYSVOL, the DFS Replication service reverses all changes that have been made locally. Any changes that you try to make to the contents of the SYSVOL share on an RODC are not blocked. However, the DFS Replication service takes steps to revert those changes. The changes will not be replicated out to other domain controllers.

Note

No event is logged when the DFS Replication services reverts the changes.

This behavior is by design because FRS provides limited support for read-only SYSVOL on an RODC. We recommend that you use DFS Replication for SYSVOL as soon as possible because it provides better support for read-only SYSVOL on an RODC.

For more information about how DFS Replication reverts any changes to SYSVOL on an RODC, see How does DFSR function on Read Only Domain Controllers? (https://go.microsoft.com/fwlink/?LinkId=119624).

System attributes that are written on an RODC

There is a set of attributes that an RODC maintains directly as part of logon policies and bookkeeping. The following table lists the attributes that an RODC maintains for successful and failed logon attempts.

Successful logon

Failed logon

LastLogon, LogonCount, BadPwdCount are written.

If the authentication has succeeded only after a retry on the PDC emulator, the RODC determines that the password is no longer valid. The RODC nulls the password for the account (that is, the link between the password attribute value and its memory address is removed; the password itself is unchanged and remains stored in memory). This operation affects a set of attributes, including unicodePwd.

The Last interactive logon statistics are also written if it is enabled. (It is not enabled, by default.)

Site affinity is updated if the RODC is in a site that is enabled for universal and global group membership caching.

LastLogonTimeStamp is written locally on the RODC, and a best effort is made to forward this write to the writable replication partner.

BadPwdTime, BadPwdCount, and lockoutTime are written.

The Last (failed) interactive logon statistics are also written if it is enabled. (It is not enabled, by default.)

Site affinity is updated if the RODC is in a site that is enabled for universal and global group membership caching and a global catalog server could not be contacted.

Another attribute that is updated locally on the RODC is the ms-DS-Site-Affinity attribute. This attribute is present on user objects if they log on with a domain controller in a site that has universal group membership caching enabled. It is used by a periodic background refresh task on the domain controller to determine whether the cache for this user should be refreshed.

Connection objects for the RODC are also written locally under the NTDS Settings object for the RODC. They are written identically as they are written on any other domain controller. However, they do not replicate to other domain controllers. The Knowledge Consistency Checker (KCC) generates the replication topology for the forest. When the KCC runs on an RODC, it writes connection objects locally. These connections objects are subsequently writable on the RODC, and an administrator can modify or delete them.

The LastLogonTimeStamp attribute is handled in a particular way. This attribute was introduced in Windows Server 2003 as a way to detect stale accounts from a central place, without having to poll all domain controllers in the domain for the LastLogon attribute. For more information, see Dandelions, VCR Clocks, and Last Logon Times: These are a Few of Our Least Favorite Things (https://go.microsoft.com/fwlink/?LinkID=47965).

When a user authenticates with a writable domain controller, the domain controller updates the LastLogonTimeStamp attribute locally, and that value replicates to other domain controllers. However, updates that are written locally on RODCs do not replicate to other domain controllers. Instead, if the user is cached on the RODC and its LastLogonTimeStamp attribute needs to be updated, the RODC writes locally the new value for this attribute, and the RODC attempts to forward this write operation to a writable domain controller. At the next replication cycle, because the attribute update on the writable domain controller happened at a later time, its value overwrites the value that was written locally on the RODC.