The name “read-only domain controller” implies that its database is read-only, and it is in nearly all situations, except for one group of attributes.

If a user requests a write operation to an RODC, the RODC forwards the request to a read-writable domain controller (RWDC), which then replicates the changes back to the RODC.

If an application tries to write to an RODC, the RODC responds with a referral notifying the application that it needs to write to an RWDC (which will crash some applications that don’t handle referrals).

Now, imagine that you have a branch-location RODC that loses its hub connectivity, so it can’t contact an RWDC, and during this outage, someone tries to hack an account.

With normal connectivity, the BadPwdCount would increment, and, after a password-policy designated number of attempts, the account would lock out.

If the RWDC can’t be contacted, and the RODC can’t write to its database, the BadPwdCount would never increment and the account would never lock out, leaving the RODC vulnerable.

For this reason, an RODC can write logon-count attributes—such as BadPwdCount and LastLogon—to its database, allowing an account to lock out.

Note from the fields: When the WAN is offline, an RODC can authenticate only the users and resources for which it has cached passwords. If you have a strong
requirement that any user must be able to authenticate in the branch office location, you may want to place a writable domain controller at that branch
office location. As an alternative, you can place an RODC at the branch office location and configure the RODC so that all users’ credentials are allowed to
replicate to it. You can then have an automated process in place that caches the credentials of the users, computers, and other resources that are located
in the branch office. This way, you can take advantage of other RODC features.