Partager via

Password Replication Policy

  • Article

Applies To: Windows Server 2008

When you initially deploy an RODC, you must configure the Password Replication Policy on the writable domain controller that will be its replication partner.

The Password Replication Policy acts as an access control list (ACL). It determines if an RODC should be permitted to cache a password. After the RODC receives an authenticated user or computer logon request, it refers to the Password Replication Policy to determine if the password for the account should be cached. The same account can then perform subsequent logons more efficiently.

The Password Replication Policy lists the accounts that are permitted to be cached, and accounts that are explicitly denied from being cached. The list of user and computer accounts that are permitted to be cached does not imply that the RODC has necessarily cached the passwords for those accounts. An administrator can, for example, specify in advance any accounts that an RODC will cache. This way, the RODC can authenticate those accounts, even if the WAN link to the hub site is offline.

Note

You must include the appropriate user, computer, and service accounts in the Password Replication Policy in order to allow the RODC to satisfy authentication and service ticket requests locally.

When only users from the branch are encompassed by the allow list, the RODC is not able to satisfy requests for service tickets locally and it relies on access to a writable Windows Server 2008 domain controller to do so. In the WAN offline scenario, this is likely to lead to a service outage.

Initially, you should define an administrative model for the Password Replication Policy. Then, review or manually update that Password Replication Policy periodically. If the RODC is stolen, you must reset the passwords for all users and computers whose passwords are cached on it.

Choosing an administrative model for RODC password replication

Business, organizational, and administrative requirements affect how you choose an appropriate administrative model for RODC Password Replication Policy. These requirements include security, ease of management, and the reliability and availability of the WAN connections.

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 commonly known as the Allowed List

  • msDS-NeverRevealGroup, also commonly 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 commonly known as the Revealed List

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

For more information about these attributes, see RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC (https://go.microsoft.com/fwlink/?LinkId=151602).

At any time, the RODC can replicate the passwords for accounts in the Allowed List, regardless of whether the account has attempted to log on against the RODC. The operation is triggered by user logon merely for administrative convenience.

This means that the Password Replication Policy is the security boundary for the RODC. The Password Replication Policy can differ for each RODC. However, if no Password Replication Policy is modified, the effective policy for all RODCs in a domain the same.

Password Replication Policy Allowed and Denied lists

Two new built-in groups are introduced in Windows Server 2008 Active Directory domains to support RODC operations. These are the Allowed RODC Password Replication Group and Denied RODC Password Replication Group.

These groups help implement a default Allowed List and Denied List for the RODC Password Replication Policy. By default, the two groups are respectively added to the msDS-RevealOnDemandGroup and msDS-NeverRevealGroup Active Directory attributes mentioned earlier.

By default, the Allowed RODC Password Replication Group has no members. Also by default, the Allowed List attribute contains only the Allowed RODC Password Replication Group.

By default, the Denied RODC Password Replication Group contains the following members:

  • Enterprise Domain Controllers

  • Enterprise Read-Only Domain Controllers

  • Group Policy Creator Owners

  • Domain Admins

  • Cert Publishers

  • Enterprise Admins

  • Schema Admins

  • Domain-wide krbtgt account

By default, the Denied List attribute contains the following security principals, all of which are built-in groups:

  • Denied RODC Password Replication Group

  • Account Operators

  • Server Operators

  • Backup Operators

  • Administrators

The combination of the Allowed List and Denied List attributes for each RODC and the domain-wide Denied RODC Password Replication Group and Allowed RODC Password Replication Group give administrators great flexibility. They can decide precisely which accounts can be cached on specific RODCs.

The following table summarizes the three possible administrative models for the Password Replication Policy.

Model Pros Cons

No accounts cached (default)

Most secure, still provides fast authentication and policy processing

No offline access for anyone; WAN required for logon

Most accounts cached

Ease of password management; intended for customers who care most about manageability improvements of RODC and not security

More passwords potentially exposed to RODC

Few accounts (branch-specific accounts) cached

Enables offline access for those that need it, and maximizes security

Fine-grained administration is new task; must map user and computers per branch; requires watching Authenticated to attribute list to manually identify accounts, or use Microsoft Identity Integration Server (MIIS) to automate

The following sections explain each model in more detail.

No accounts cached

This model provides the most secure option. No passwords are replicated to the RODC, except for the RODC computer account and its special krbtgt account. However, transparent user and computer authentication relies on WAN availability. This model has the advantage of requiring little or no additional administrative configuration from the default settings. Customers might choose to add their own security-sensitive user groups to the default list of denied users. This can protect those user groups against accidental inclusion in the list of allowed users and subsequent caching of their passwords on the RODC.

Most accounts cached

This model provides the simplest administrative mode and permits offline operation. The Allowed List for all RODCs is populated with groups that represent a significant portion of the user population. The Denied List does not allow security-sensitive user groups, such as Domain Admins. Most other users, however, can have their passwords cached on demand. This configuration is most appropriate in environments where the physical security of the RODC will not be at risk.

Few accounts cached

This model restricts the accounts that can be cached. Typically, administrators define this distinctly for each RODC—each RODC has a different set of user and computer accounts that it is permitted to cache. Typically, this is based on a set of users who work at a particular physical location.

The advantage to this model is that a set of users will benefit from offline authentication, should WAN failure occur. At the same time, the scope of exposure for passwords is limited by the reduced number of users whose passwords can be cached.

There is an administrative overhead associated with populating the Allowed List and Denied List in this model. There is no default automated method for reading accounts from the known list of security principals who have authenticated against a given RODC. Nor is there a default method for populating the Allowed List with those accounts. Administrators might be able to use scripting or applications such as MIIS to build a process for adding these accounts directly to the Allowed List.

There are two ways to add these accounts. Administrators can either add the user directly to the Allowed List or, preferably, they can add them to a group that is already defined in the Allowed List for that RODC. Administrators can create "RODC-specific" groups to enable this. Or they can use existing groups in AD DS whose member scope is appropriate.

Password Replication Policy in operation

This section explains how the Allowed List, Denied List, Authenticated to List, and Revealed List attributes are used.

When an RODC makes a request to replicate a user's password, the writable Windows Server 2008 domain controller that the RODC contacts allows or denies the request. To allow it or deny the request, the writable domain controller examines the values of the Allowed List and Denied List for the RODC that presents the request.

If the account whose password is being requested by the RODC is in the Allowed List rather than the Denied List set for that RODC, the request is allowed.

The following flowchart shows how this operation proceeds.

The Denied List takes precedence over the Allowed List.

Clearing cached passwords

There is no mechanism to erase passwords after they are cached on an RODC. If you want to clear a password that is stored on an RODC, an administrator should reset the password in the hub site. This way, the password that is cached in the branch will no longer be valid for accessing any resources in the hub site or other branches. In the branch that contains the RODC on which the password may have been compromised, the password will still be valid for authentication purposes until the next replication cycle, at which time its value that is stored on the RODC will be changed to Null. The new password will be cached only after the user authenticates with it—or the new password is prepopulated on the RODC—and if the PRP has not been changed.