Active Directory Security and certificates
Read-only domain controllers
Inspect password replication policy, distinguish allowed from cached credentials, and test the actual branch-office dependencies.
Read-only changes the branch’s failure modes
An RODC holds read-only directory replicas and receives inbound replication from writable DCs. It doesn’t accept originating directory updates or act as an outbound replication source. Those protocol distinctions don’t keep sensitive data off the local host. The role is useful where physical security or administration needs differ from the central environment, but it still holds directory information and permitted password material.
LDAP writes and password changes need a writable DC. A branch with an RODC is not automatically independent of its WAN. Name resolution, user and computer credentials, service account keys, cross-domain access, and application requirements all affect what continues working during an outage.
Identify the RODCs and their actual roles
From an AD PowerShell session:
Get-ADDomainController -Filter 'IsReadOnly -eq $true' |
Select-Object HostName, Site, IsGlobalCatalog, OperationMasterRoles
Check the branch DNS and GC design as well as the DC’s presence. A replicated read-only DNS zone cannot accept a local dynamic update the same way as its writable counterpart; the update needs a suitable writable server.
When using an administrative console, check which DC it is actually targeting. Launching AD Users and Computers or ADSI Edit on an RODC does not guarantee the console is displaying the local replica. Many operations deliberately locate a writable DC.
Allowed, authenticated, and cached are different lists
Password Replication Policy (PRP) determines which accounts may have their secrets cached. It does not mean all allowed passwords have already arrived. Denial takes precedence over allowance. The default Allowed RODC Password Replication group is empty, while the Denied group protects privileged identities. Review the groups and per-RODC policy together. RODC group defaults.
The domain-wide Allowed RODC Password Replication Group is broader than a branch-specific allow list: its membership permits replication to all RODCs in that domain, subject to the effective PRP. Microsoft’s well-known SID definition makes that scope explicit. If only one branch needs an identity, review the particular RODC’s policy rather than assuming the built-in group is a per-site setting.
Get-ADDomainControllerPasswordReplicationPolicy -Identity BRANCH-RODC -Allowed
Get-ADDomainControllerPasswordReplicationPolicy -Identity BRANCH-RODC -Denied
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity BRANCH-RODC `
-AuthenticatedAccounts
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity BRANCH-RODC `
-RevealedAccounts
The authenticated list shows accounts that authenticated through that RODC. The revealed list shows accounts whose password material has been stored there. Save both and compare them with the intended branch population. Microsoft’s usage command reference defines the distinction.
An older command-line view of the revealed list is:
repadmin /prp view BRANCH-RODC reveal
Ask for the resultant policy of the specific account
An account can be in an allowed group and still be denied through nested membership. Query the effective result for the RODC:
Get-ADAccountResultantPasswordReplicationPolicy -Identity 'alice' `
-DomainController 'BRANCH-RODC' -Server 'dc1.contoso.com'
Get-ADAccountResultantPasswordReplicationPolicy -Identity 'BRANCH-PC01$' `
-DomainController 'BRANCH-RODC' -Server 'dc1.contoso.com'
The results distinguish Allow, DenyExplicit, DenyImplicit and Unknown. If the result is Unknown, you don’t yet have an answer. -DomainController identifies the RODC whose policy is evaluated; -Server selects the replica to query. Resultant PRP reference.
Keep the policy result with the revealed-account list and timestamp. The policy may allow caching before the password arrives, or may have changed after the secret was revealed.
Cached secrets persist in the directory database. Restarting the RODC or waiting for a user’s ticket to expire won’t remove them. Each RODC has its own revealed population, so check the branches separately.
There is a specific, state-changing rODCPurgeAccount rootDSE operation for purging a principal’s cached secret attributes from a targeted RODC. It requires the Read-Only-Replication-Secret-Synchronization control-access right on the domain NC root; its supplied value identifies the principal whose secrets are to be removed. It is not an ordinary attribute to read or edit on the user. An approved purge must be coordinated with PRP and the credential-exposure response: otherwise an allowed credential may be obtained again, and deletion on the server cannot retract a copy already stolen.
Prepopulate credentials deliberately
Where an offline branch test requires a specific credential to be present, an authorized administrator can replicate that account’s password to the RODC after confirming PRP and source health:
Get-ADUser -Identity 'alice' -Server 'dc1.contoso.com' |
Sync-ADObject -Source 'dc1.contoso.com' -Destination 'BRANCH-RODC' `
-PasswordOnly
Repeat for the specific computer or service account only when required by the tested workflow. This copies secret material; it is not a read-only health check. Sync-ADObject documents password precaching, and the Repadmin password-replication procedure confirms source-side PRP enforcement. Verify the revealed list afterward, then test a fresh authentication rather than an existing ticket-bearing session.
Check the whole credential set for offline access
For an intended branch scenario, identify the user account, workstation account, resource-server account, and relevant service identities. A cached user password alone does not guarantee that the RODC can issue every ticket required by the application.
Test the actual sign-in and application workflow with a controlled WAN isolation exercise. Include a new sign-in, a password changed before the outage, and access to resources in other domains. Do not infer outage behavior from an already established session carrying tickets obtained earlier.
An RODC has its own krbtgt account. It cannot simply act as a writable KDC for every trust and service key in the forest. The exact ticket path matters when a branch application accesses another domain.
Include DNS in that isolation test. RODC DNS needs a suitable writable DNS/DC path for operations requiring updates. DNS event 4015 with extended error 00002095 has a specific writable-DC discovery investigation; it does not mean every 4015 event has the same cause. RODC DNS error conditions.
Keep privileged passwords out of the cache
Inspect the Denied RODC Password Replication group’s membership and any per-RODC exceptions. Broadly allowing branch staff through a group while accidentally allowing privileged identities through nesting defeats the intended separation.
Also review replication permissions. Unexpectedly broad Replicating Directory Changes All permissions can permit password replication beyond what the expected PRP suggests. Microsoft documents this incorrect-permission failure mode, including why GUI and repadmin views can disagree.
For that failure mode, check the domain naming-context ACL, the RODC’s effective group memberships and its PRP attributes across writable replicas. The documented expected RODC permission is Replicating Directory Changes, without the inappropriate All grant. Find whether the extra right came directly from the RODC, Enterprise Read-only Domain Controllers or another group before correcting it. Repairing the ACL won’t deal with credentials already exposed.
Changing the allowed or denied lists is not a substitute for the account-reset and recovery procedure required when secrets may already have been exposed. If an RODC is stolen or compromised, retain the revealed-account evidence and use the corresponding response plan. Do not assume a policy edit erased credentials an attacker already obtained.
Filtered attributes and confidentiality are separate
The RODC Filtered Attribute Set controls whether selected attributes replicate to an RODC. The confidential-attribute setting controls an additional access check. They answer different questions: whether a value is present on the replica, and who may read it through directory access.
For custom schema attributes containing credential-like data, review both alongside ordinary ACLs and replication rights. Some protected schema attributes cannot be placed in the filtered set. This requires schema design and testing, not a blanket edit of searchFlags across existing attributes.
searchFlags uses separate bits for confidentiality (0x80) and RODC filtering (0x200). Inspect the complete existing value, schema restrictions and access-control behavior before considering a change; setting a new integer can overwrite unrelated indexing or lifecycle flags. The schema flag definition and RODC schema guidance explain the distinction.
A local administrator is still powerful locally
RODC administrator-role separation can allow branch support to administer that server without becoming a domain administrator. It does not make local administrator actions harmless. Review who has that access, how privileged staff connect to the host, and which secrets the branch server can hold.
The administrator-role separation design delegates the local RODC task, not administration of all other DCs. Keep the membership and host controls under review. If the RODC is stolen, preserve the revealed-account inventory and coordinate account, computer and RODC-specific credential recovery. Microsoft’s identity-compromise response guidance explicitly includes RODC credential handling; changing PRP alone does not revoke material already taken.