Partager via

RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC

  • Article

Applies To: Windows Server 2008, Windows Server 2012

This topic explains what the read-only domain controller (RODC) Filtered Attributes Set (FAS) is and how credential caching and the authentication process work for an RODC.

RODC FAS

RODCs contain a complete copy of the Active Directory database in the sense that they contain a read-only copy of all partitions that are held by an equivalent writable domain controller. For example, an RODC contains read-only copies of the schema and configuration partitions. If you are using Active Directory–integrated Domain Name System (DNS), an RODC that is a DNS server contains read-only copies of the DNS application directory partitions.

However, there is a set of attributes that, by default, are not replicated to an RODC:

  • Attributes that belong to the RODC FAS

  • Credentials, except for the RODC's own computer account credentials and a special krbtgt account for the RODC

The RODC FAS is a dynamic set of attributes that is not replicated to any RODCs in the forest. These attributes are not replicated to RODCs because they contain sensitive data. Because they are not replicated to RODCs, a malicious user who has managed to compromise an RODC cannot expose them.

The default RODC FAS contains the following list of attributes:

  • ms-PKI-DPAPIMasterKeys

  • ms-PKI-AccountCredentials

  • ms-PKI-RoamingTimeStamp

  • ms-FVE-KeyPackage

  • ms-FVE-RecoveryPassword

  • ms-TPM-OwnerInformation

These attributes are defined in the RODC FAS and marked as confidential to support Credential Roaming and BitLocker Drive Encryption.

Some other applications that use Active Directory Domain Services (AD DS) as a data store may also have credential-like data (such as passwords, credentials, or encryption keys) that you do not want to be stored on an RODC in case the RODC is stolen or compromised.

For applications with this type of data, you can take these precautions:

  • Extend the RODC FAS to include any credential-like attributes that you want to prevent from replicating to any RODC in the forest.

  • Mark the attributes as confidential, which removes the ability to read the data for members of the Authenticated Users group, which includes RODCs. This step is necessary so that if an RODC gets compromised, an attacker cannot—using the RODC account—read the data directly from the directory. This acts as an additional measure of protection by preventing an attacker from using a compromised RODC to read the attributes from the directory, even if they are not replicated to the RODC.

Note

In general, if an authenticated user requests READ_PROPERTY permissions for an attribute or for its property set, read access is granted. Default security in AD DS is set so that authenticated users have read access to all attributes.

When the attributes are prevented from replicating to RODCs, they cannot be exposed unnecessarily if an RODC is stolen or compromised.

A malicious user who compromises an RODC can attempt to replicate attributes that are defined in the RODC FAS. If the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2008, the replication request is denied. However, if the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2003, the replication request could succeed. Therefore, as a security precaution, you should ensure that the forest functional level is Windows Server 2008 if you plan to configure the RODC FAS. When the forest functional level is Windows Server 2008, an RODC that is compromised cannot be exploited in this manner because domain controllers that are running Windows Server 2003 are not allowed in the forest.

If an RODC is stolen, any attributes that were configured to be part of the RODC FAS will not be present on the RODC. Therefore, RODC FAS data cannot be read on a stolen RODC whether the forest functional level is Windows Server 2003 or Windows Server 2008. Other data that resides on the stolen RODC can be read, but the RODC FAS data will not be read because it will not be present.

We recommend that you also mark as confidential any attributes that you configure as part of the RODC FAS. Marking the attribute as confidential provides an additional safeguard against an RODC that is compromised by removing the permissions that are necessary to read the credential-like data.

For procedures that show how to add an attribute to the RODC FAS, see RODC Administration.

Credential caching

As mentioned earlier, by default an RODC does not store user credentials or computer credentials, except for its own computer account and a special krbtgt account for that RODC. For more information about the attributes that are part of a user or computer account credentials, see User and Computer Credentials.

When users or computers in a site that is serviced by an RODC attempt to authenticate to the domain, the RODC by default cannot validate their credentials. The RODC then forwards the authentication request to a writable domain controller. However, there might be a set of security principals that may need to be able to authenticate in a site that is serviced by an RODC, even in cases where they have no connectivity to writable domain controllers.

For example, you might have a set of users and computers in a branch office that you want to be authenticated even if there is no connectivity between the branch office and sites that contain writable domain controllers. To resolve this issue, you can configure the PRP for that RODC to allow the passwords for those users to be cached on the RODC. If the account passwords are cached on the RODC, the RODC can authenticate those accounts when connectivity to writable domain controllers is not available.

The PRP acts as an access control list (ACL). It determines whether an RODC is permitted to cache credentials for an account. After the RODC receives a user or computer logon request, it attempts to replicate the credentials for that account from a writable Windows Server 2008 domain controller. The writable Windows Server 2008 domain controller refers to the PRP to determine if the credentials for the account should be cached. If the PRP allows the account to be cached, the writable Windows Server 2008 domain controller replicates the credentials for that account to the RODC and the RODC caches them. During subsequent logons for that account, the RODC can authenticate the account by referring to the credentials that it has cached. The RODC does not have to contact the writable domain controller.

Note

The credentials are not actually stored in a cache, as in the traditional sense of a storage buffer. Instead, the credentials are stored directly in the Active Directory database. Also note that while there are approximately five attributes that comprise the credentials for each account, there can be any number accounts defined in the PRP.

A default PRP is defined that applies to any newly installed RODC. The default PRP specifies that no account passwords can be cached on any RODC, and certain accounts are explicitly denied from being cached on any RODC.

The PRP is defined by two multivalued Active Directory attributes that contain security principals (users, computers, and groups). Each RODC computer account has these two attributes:

  • msDS-RevealOnDemandGroup, also known as the Allowed List

  • msDS-NeverRevealGroup, also known as the Denied List

To help manage the PRP, two other attributes that are related to the PRP are maintained for each RODC:

  • msDS-RevealedList, also known as the Revealed List

  • msDS-AuthenticatedToAccountList, also known as the Authenticated to List

The msDS-RevealOnDemandGroup attribute specifies what security principals can have passwords cached on an RODC. By default, this attribute has one value, which is the Allowed RODC Password Replication Group. Because this domain local group has no members by default, no account passwords can be cached on any RODC by default.

The list of user and computer accounts whose credentials are permitted to be cached does not imply that the RODC has necessarily cached the passwords for those accounts. These accounts are considered “cacheable,” and if an administrator takes no further action other than setting the PRP, these users will have their passwords cached only after they log on against the RODC for the first time. However, an administrator can also have an RODC cache any accounts in advance of any authentication request. This way, the RODC can authenticate those accounts, even if the wide area network (WAN) link to the hub site is offline. You can cache passwords in advance by using the Active Directory Users and Computers snap-in or by using the repadmin /rodcpwdrepl command. For more information, see Administering the Password Replication Policy.

You must include the appropriate user, computer, and service accounts in the PRP so that the RODC can resolve authentication and service ticket requests locally (for the site). When only users (but not computers or service accounts) from the site are specified on the Allow list, the RODC is not able to resolve requests for service tickets locally, and it relies on access to a writable Windows Server 2008 domain controller to resolve the requests. Also, the RODC is not able to authenticate the computer account if the password for the account is not cached. In the WAN offline scenario, this is likely to lead to a service outage.

Note

RODCs have a feature known as Administrator Role Separation, which you can use to delegate to any domain user the credentials to be an administrator of an RODC, without granting that user any other privileges in the domain. However, the password for the delegated administrator is not cached by default. As a best practice, cache the password of the delegated RODC administrator and refresh the cache after each time that the password changes. For more information about the delegated administrator, see Administrator Role Separation.

The msDS-NeverRevealGroup attribute specifies what security principals are explicitly denied from having their passwords cached on an RODC. This is useful to help prevent credentials for highly privileged accounts from replicating to an RODC. That way, you can be assured that an attacker cannot obtain credentials for highly privileged accounts from a stolen or compromised RODC. This attribute has the following default values:

  • Account Operators

  • Server Operators

  • Backup Operators

  • Administrators

  • The Denied RODC Password Replication Group, which is a domain local group that includes the following:

    • Enterprise Domain Controllers

    • Enterprise Read-Only Domain Controllers

    • Group Policy Creator Owners

    • Domain Admins

    • Cert Publishers

    • Enterprise Admins

    • Schema Admins

    • Domain-wide krbtgt account

The msDS-NeverRevealGroup attribute takes precedence over the msDS-RevealOnDemandGroup attribute. Therefore, if an account is either directly or indirectly included in both the Allowed List and the Denied List, the account password cannot be cached on the RODC.

The msDS-RevealedList is the list of security principals (including computer accounts) whose current credentials have been replicated to the RODC.

Note

The msDS-RevealedUsers attribute is another attribute that is related to credential caching. The msDS-RevealedUsers attribute is used by the system to store information about the secrets of any security principal, including computers, which has ever had its secrets replicated to the RODC at any point in time. It contains separate entries for each secret of each security principal (when a security principal is said to be cached on the RODC, it means that five secrets are replicated to the RODC). The msDS-RevealedList, on the other hand, is a list of currently revealed secrets and their associated users or computers. It is a constructed attribute based on msDS-RevealedUsers. Unlike msDS-RevealedUsers, msDS-RevealedList contains only one entry for each user or computer. For more information about how msDS-RevealedList is constructed, see msDS-RevealedList (https://go.microsoft.com/fwlink/?LinkId=196390).

The msDS-AuthenticatedToAccountList on an RODC is the backlink of the msDS-AuthenticatedAtDC attribute and is the list of security principals that attempt to authenticate with the RODC. This list includes accounts whose passwords have not been cached by the RODC and all accounts whose passwords have been cached. This list provides administrators with information about which accounts are using an RODC for authentication requests and therefore might be good candidates to add to the msDS-RevealOnDemandGroup attribute (the Allowed List).

Note

The msDS-AuthenticatedToAccountList contains all accounts that have been granted a service ticket to the RODC. This means that any user who accesses a resource on the RODC will be added to this list. You should not use this list as a conclusive reference to decide which accounts to add to the Allowed List. Instead, carefully review the list and use it only to help you understand which accounts might be candidates to add to the Allowed List.
It is possible to have users in the msDS-RevealedList that are not in the msDS-AuthenticatedToAccountList. Accounts whose passwords are prepopulated on the RODC are not going to appear in the msDS-AuthenticatedToAccountList, but they will be in the msDS-RevealedList. This could also happen if you clear the msDS-AuthenticatedToAccountList by using repadmin /prp. For more information about prepoulating passwords, see Prepopulating the password cache for an RODC. For more information about clearing the msDS-AuthenticatedToAccountList, see Clearing the authenticated accounts list.

For more information about the attributes of an RODC account, see Read-Only Domain Controller Object (https://go.microsoft.com/fwlink/?LinkId=196366).

Key points for authentication through an RODC

This section covers some of the important points about how authentication works with an RODC. For a step-by-step description of how authentication occurs with an RODC, see How the authentication process works on an RODC.

If only user accounts are cached on an RODC in a particular site, users will not be able to log on using computers in that site when the RODC is unable to contact a writeable domain controller running Windows Server 2008.

All credentials for user, computer, and service accounts that should be cached must be specifically allowed by the PRP. For the RODC to locally authenticate the credentials of any account, those credentials must already be cached on the RODC.

Regardless of the PRP, the RODC attempts to cache accounts that are successfully authenticated. The PRP is enforced by the writeable domain controller running Windows Server 2008, which either allows or denies the caching of account credentials on the RODC.

RODCs are advertised as KDCs for the sites in which they are configured. RODCs use different krbtgt accounts than the KDCs on writable domain controllers for encrypting or signing TGTs. This provides cryptographic isolation between KDCs running on RODCs in different sites; a compromised RODC is therefore prevented from issuing service tickets to resources in other sites. Writable Windows Server 2008 domain controllers contain credentials for all accounts, including the credentials of the krbtgt accounts of the RODCs.

By limiting the caching of credentials on RODCs, the exposure of domain accounts is limited in the event that an RODC is compromised. In the event that an RODC is stolen or otherwise compromised, the accounts that were cached on that RODC are the only accounts that can be potentially compromised.