msDS-RevealOnDemandGroup

What this attribute does in Active Directory

msDS-RevealOnDemandGroup is part of the Read-Only Domain Controller password replication policy. It defines the accounts whose passwords may be revealed to a specific RODC when needed, so the branch or edge server can authenticate approved users locally without exposing the full domain password store.

The attribute is best understood as a scoped allowlist. It works alongside the RODC’s caching model, where selected credentials can be stored locally while the rest remain unavailable to that controller. That separation matters because it limits the blast radius if an RODC is lost, stolen, or otherwise accessed by an attacker.

How it relates to RODC password caching

RODC password caching is designed for environments that need local logon performance or resilience at remote sites, but cannot accept the same credential exposure as a writable domain controller. msDS-RevealOnDemandGroup is one of the policy objects that makes that trade-off explicit by naming what may be revealed on demand rather than broadly cached.

In practice, the attribute sits within the broader Password Replication Policy model. Administrators use it to separate accounts that can tolerate local cache availability from accounts that should remain protected by central authentication only. The result is a controlled balance between usability and credential containment.

That balance is only safe when the approved set is intentionally small and reviewed with the surrounding RODC controls, including filtered attributes, delegated administration, and the recovery assumptions for a compromised branch server.

Why the separation matters for credential exposure

Any allowlist that governs which passwords can be revealed becomes a security boundary, not just a configuration detail. If the group is too broad, the RODC may hold credentials that were never meant to be available at a remote location, increasing the value of the server to an attacker and expanding the impact of physical theft or administrative abuse.

Because the attribute controls exposure rather than authentication strength itself, it is easy to underestimate. The real risk is not the presence of a cache, but the decision about which identities are eligible to be cached and therefore recoverable from that controller.

When read with an identity-security lens, the attribute is a privilege scoping mechanism for credentials. It does not grant access directly, but it determines where password material may exist and who may later benefit from that locality.

Operational use in branch and edge deployments

Organizations usually encounter this attribute where remote-site design has to reconcile availability with tighter trust boundaries. A branch office may need reliable local authentication even if the WAN link fails, yet the domain team still wants to keep Tier 0 credentials and sensitive administrative accounts off the remote controller.

The practical question is less “can the RODC authenticate locally?” and more “which accounts should ever be eligible for local password reveal?” That is why the attribute is usually managed as part of a larger policy conversation about delegated administration, staging, and response if an RODC is compromised.

For teams documenting or reviewing RODC policy, NHIMG’s Read-Only Domain Controller Security covers the surrounding controls and abuse paths that make this attribute operationally important.

Risk and Threat Considerations

An over-permissive reveal policy weakens one of the main reasons to deploy an RODC in the first place: limiting where passwords can exist. If a stolen or misused RODC can reveal credentials for too many accounts, the server becomes a more valuable offline target and a stronger pivot point for lateral movement.

Failure mechanism: Attackers or careless administrators exploit a broad reveal group to increase the set of passwords that can be cached or recovered from the RODC, then use that material for impersonation, privilege escalation, or persistence.

Impact: The resulting exposure can include user logon compromise, branch-to-core lateral movement, and loss of confidence in the RODC as a containment boundary, especially where administrative or high-value accounts were allowed to be revealed.

Practitioner Guidance

What to watch for: Treat this attribute as a security-relevant policy object, not a convenience list. The key governance question is whether every member of the reveal group is still appropriate for local cache exposure, especially after role changes, reorganization, or branch expansion.

Practitioner takeaway: Keep the reveal set intentionally narrow and review it in the same change-control flow as other RODC password replication decisions, because the attribute defines where password material is allowed to surface.

Related resources from NHI Mgmt Group

• How does msDS-KeyCredentialLink work?
• Why does msDS-KeyCredentialLink matter for security teams?
• What are the key msDS-KeyCredentialLink best practices?
• Why does msDS-AllowedToActOnBehalfOfOtherIdentity matter for security teams?