A. By definition, an RODC can't write data to its local database. Any write operations are forwarded to a read-write domain controller (DC). However, there are exceptions to protect an RODC from attack when the RODC can't communicate with a read-write DC.

Imagine a scenario in which a branch-office RODC loses connectivity with the data center and its read-write DCs. Normally, if someone attempts an account-password attack, the accounts would be locked for a period of time after a set number of failed attempts to protect the account from constant attack. But if the RODC doesn't know when to lock the accounts because it can't write logon failures to a read-write DC, you might have a major problem. RODCs have the following limited write capabilities for protection against attacks:

  • The msDS-LastSuccessfulInteractiveLogonTime attribute—tracks the most-recent successful logons. It isn't forwarded to a read-write DC.
  • The msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon attribute—tracks the number of failed interactive logons during the most-recent successful logons. It isn't forwarded to a read-write DC.
  • The msDS-LastFailedInteractiveLogonTime attribute—tracks the most-recent failed interactive logon attempts. It's forwarded to a read-write DC, which then replicates the attribute back to the RODC during the next replication cycle.
  • The msDS-FailedInteractiveLogonCount attribute—tracks the number of failed interactive logon attempts. It's forwarded to a read-write DC, which then replicates the attribute back to the RODC during the next replication cycle.