Writable DC, Global Catalog, and RODC: Differences in authority, data, and password caching

1. Core mechanism

Keep three questions separate when choosing a DC: which data can it search, which changes can it accept, and which accounts' password information may be cached locally? GC supports forest-wide search and can run on either a writable DC or an RODC. Adding the GC role does not make an RODC's naming contexts writable. PRP separately governs its password-cache scope.

Interfaces and specifications

• A writable DC accepts directory changes and replicates them to other writable DCs. This is separate from GC search coverage and client-side credential caching.
• A writable GC DC holds full writable replicas of the schema, configuration and its own domain naming contexts, plus partial read-only replicas of other domains. On an RODC with the GC role, the hosted domain copy remains read-only. GC search coverage and the write path are separate properties.
• An RODC hosts a read-only copy of AD DS. PRP allow/deny rules determine which user and computer accounts may have password information cached on that RODC.
• If the required secret is not cached, the RODC contacts a writable DC for authentication. If that dependency is unreachable, the RODC alone does not guarantee uninterrupted authentication.

Search, writes and password caching

A writable DC can accept ordinary directory changes; an RODC's domain copy is read-only. GC answers a different question: which objects and attributes can be searched across the forest? A writable DC can be a GC, and so can an RODC.

On a writable GC, its own domain is a full writable replica and other domains have partial read-only replicas. Adding GC to an RODC does not make its own domain writable. For example, a branch RODC+GC may find a user in a search, but a change to that user's directory record must be made on a writable DC and replicated to the RODC. A search result is not evidence of write capability.

PRP separates permission from actual cache state

RODC Password Replication Policy determines whether an account’s password may be cached on that RODC. An allowed result does not prove that the secret is already cached; policy and actual cache state are separate inventory questions. Deny rules help keep privileged or risky accounts off the branch device.

If the secret is absent from the cache, the RODC contacts a writable DC for authentication; a WAN outage may break that path. Having the secret cached does not remove a separate dependency: in a multi-domain forest, logon must also obtain universal-group memberships. The branch needs a reachable GC, including a GC role on the RODC, or UGMC enabled for the site with this user's memberships previously cached. Enabling UGMC alone does not establish that the user's information is available.

A single-domain forest has a different authentication condition: every DC acts as a virtual GC for this purpose, while queries on the GC port still require the designated GC role. Do not apply the multi-domain branch example unchanged to every topology. DNS/DC discovery, account state and the chosen logon path also need separate evaluation. A client's cached interactive logon is not RODC domain authentication.

Mixing trust limit with data coverage

GC's partial replica set makes it easy to find all forest objects; it does not mean that an object has a full set of attributes. Therefore, a search result should not count full evidence of management or access decision. For missing attribute, you need to read connected to DC that holds full replica.

RODC is a design tool for reducing physical security risk, it is not a limit that eliminates all risk of identity. PRP should be designed with local administration and writable DC dependence. A role must be documented where the account can be cached and which the transaction should be writable DC.

State and data flow

1. When an application is looking for the user across the forest, GC may find the object through the partial replica; if the desired attribute is not in GC, it is necessary to read additional to DC that holds full replica with the object DN.
2. A branch client sends authentication request to RODC. If the secret of the account is not in the cache on this RODC, the RODC writable DC is directed; the verification may continue if there is connection.
3. When PRP allows caching and the required secret is already cached, the RODC can use that secret for local authentication. This does not establish all prerequisites for domain logon. In a multi-domain forest, universal-group memberships also require a reachable GC or UGMC enabled for the site with this user's memberships already cached. The allow list alone is not proof of a cached secret.
4. When a directory change is required, write path goes to writable DC. GC search role or the local cache of RODC is not a proof of writability.

2. Exploitation

Broken trust assumption

The assumption that the presence of RODC in the branch provides unconnected authentication for all users and determines the behaviour of the GC role determines writability or password-cache behavior.

Technical prerequisites

• The result of PRP for the relevant account is that the type of account and the actual cache status in RODC is not known.
• The connection between the branch and writable DC can be cut or delayed.
• Design document GC uses writable DC and RODC labels as alternative to each other in the same capacity table.

Exploitation mechanism

This assumption produces unexpected authentication failure when disconnected or leads to caching in the branch RODC of inappropriate secrets. It also leads to wrong authorization/intervention decisions to count full attribute or write-path evidence of GC search results. The risk is evaluated not from its role name, which data, write path and cache decides really.

Branch resilience requires a cache inventory

Placing an RODC in a branch does not mean every domain account can authenticate during a connectivity outage. An account disallowed by PRP or not yet cached remains dependent on a writable DC. For privileged accounts this restriction is often intentional; expanding cache scope for convenience changes the security boundary.

For defense, record which accounts may be cached on each branch RODC, which are actually cached, and which workflows can continue during an outage. This lesson does not provide credential extraction or cache-forcing procedures.

A search result is not a decision result

GC can find an object but does not contain all inputs of the attribute set, full object or authorization decision. If you have full attribute or writable DC over the GC result, it is to make a decision of management with missing data.

Similarly, it does not RODC instead of RODC to carry the role of a DC to carry it instead of writable or writable. GC status for each server in design review, writable/read-only status, PRP coverage and writable DC dependence should be kept in separate lines.

3. Defense & Detection

Telemetry scope

• For each DC, record writability, GC role, site and the path to a writable DC. For an RODC, record PRP allow/deny results separately from the actual cached-account inventory.
• Do not treat a GC query result as evidence of the full attribute set. If an attribute is outside the partial attribute set, use the object DN to read it from a full replica; that is separate evidence.
• For branch outages, verify the PRP result separately from the actual password cache. A cache miss requires the writable-DC path. In a multi-domain forest, also check GC reachability or site UGMC containing this user's memberships; record DNS/DC discovery and the logon path. A running RODC does not prove this whole chain is ready.

Events and relevant fields

• PRP allow/deny and peer account list answers different questions: the first policy result, the second is that the current password cache in RODC is the fact.
• Rotation of RODC to writable DC can be normal design behavior for a secret that is not in the cache; it is not evidence of bad intent or reapp failure alone.
• GC's partial replica value feature is search proof; it does not mean that there is no attribute in GC, the object is destroyed or the access is rejected.

Limit Role matrix with two columns

If the single column “DC type” in Blue runbook, the Writable/read-only difference disappears. You need at least four domains: write ability, GC ability, RODC PRP result and current cache/connection status. This matrix prevents wrong resolution of a branch logo failure in the same team with a call failure.

Critical question “Do I have a password on RODC?” not, which allows policy for the account in RODC, what is the question of what the expected behavior when there is no access to the current cache, writable DC. These questions combine operational continuity in the same proof line with security design.

Open tuition limit Tags

SIEM or inventory can be useful to connect the name and time of a server, but PRP decision is not authoritative source. Likewise, GC query supports to find objects, but it does not support full attribute and write path decision.

If these limits disappear, the operation team can attack a cache miss, a GC result may also think full directory record. The role of the incident review should then separate the principles of policy/cache, the final signs of network and authentication.

Detection logic · KQL

DeviceInfo
| where DeviceName in ("RODC-BR01", "DC01")
| project DeviceName, Timestamp, OSPlatform

Query assumptions

• This KQL is a format example for only inventory correlation; does not claim that RODC PRP or GC role is extracted from DeviceInfo chart.
• Real domain names and data source depend on SIEM/EDR connector; role, PRP and cache inventory should also be verified from authoritative AD management surface.
• The question has not been run in no live environment and the artifact is synthetic.

False positives

• A device is not evidence of RODC-BR01, RODC role or PRP result; inventory name may not be wrong or current.
• A network event belonging to Writable DC connection is not the only reason for cache miss; network, DNS or service failure should also be reviewed.
• Negative sample: An account located in PRP allow list may not be cached yet; the allow result cannot prove the downtime resistance alone.

Hardening

• RODC PRP is designed with allow/deny list; evaluate privileged and recovery accounts with an open deny strategy.
• Periodic compare of PRP policy with real language-account list; combining one in the same metric with the permitted cache.
• Define which accounts and logon/workflows must remain available during a WAN outage. Alongside password-cache coverage, plan a branch GC or site UGMC populated with the relevant user memberships for a multi-domain forest, plus DNS/DC discovery dependencies. An enabled policy is neither a populated cache nor a verified outage outcome.
• Check whether the attribute required in GC queries is in the appropriate attribute set; verify full replica data for critical decisions.
• Manage DC roles as separate areas in inventory: writable/read-only, GC, site and PRP. Using a role tag as a result of security of the other.

Read the examples

O:SYG:SYD:(A;;RP;;;AU)(D;;RP;;;DA)

Two reality checks

Assumption: Global Catalog, writable DC and RODC are three types of DC selected to replace each other.

In fact: Writable/read-only describes whether the DC accepts changes; GC describes forest-wide search coverage. Both a writable DC and an RODC can be a GC. An RODC+GC keeps its own domain copy read-only; the GC role alone determines neither the write path nor password-cache state.

Assumption: A user allowed by PRP is guaranteed to log on through the RODC during a WAN outage.

In fact: PRP allow permits caching; it does not prove the secret is currently cached. A cache miss needs a writable DC. Even with the secret present, a multi-domain forest also needs a GC or site UGMC populated with the user memberships. DNS/DC discovery, account state and logon path matter too. Client cached interactive logon is not domain authentication through the RODC.

Sources

• Microsoft · Global Catalog
  The partial replica of each naming context; schema/configuration naming contexts; forest-wide search and automatic replication topology.
• Microsoft · Attributes Included in the Global Catalog
  Partial Attribute Set; binding to the DC that holds the full replica by object DN for an attribute that is not present in the GC.
• Microsoft · Administering the Password Replication Policy
  RODC PRP allow/deny policy, password cache inventory, and managing accounts cached or leaked on an RODC.
• Microsoft · RODC installation and Global Catalog option
  Perform a Staged RODC Installation: Additional Domain Controller Options, Global catalog and Read-only domain controller selections; GC adds read-only partitions.
• Microsoft · Planning Global Catalog Server Placement
  Single-domain virtual GC distinction; multi-domain universal-group membership and site UGMC.
• Microsoft · Cached domain logon information
  Summary and More information: client-local cached desktop logon when no logon server is available; network resources requiring domain validation remain a separate condition.