The Specify the Password Replication Policy wizard page in the Active Directory Domain Services Installation Wizard appears when you create a read-only domain controller (RODC) account—but only if you select the Use advanced mode installation check box on the Welcome to the Active Directory Domain Services Installation Wizard page in the wizard.
How the Password Replication Policy works
The Password Replication Policy (PRP) determines how an RODC performs credential caching. Credential caching is the storage of user or computer credentials.
When users or computers in a site that is serviced by an RODC attempt to authenticate to the domain, by default the RODC 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 the 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 domain controller that runs Windows Server 2008 or Windows Server 2008 R2. The writable 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 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.
The PRP in operation
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-Reveal-OnDemandGroup, 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-Reveal-OnDemandGroup 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.
This section explains how the Allowed List, Denied List, Revealed List, and Authenticated to 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 the 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) for that RODC, the request is allowed.
The following illustration shows how this operation proceeds.
The Denied List takes precedence over the Allowed List.
For example, suppose an organization has a security group for administrators named Admins. The organization has one site named S1 and a security group named Emp_S1 that contains employees in the site. The organization has another site named S2 and a security group named Emp_S2 that contains employees in the site.
Site S2 has only an RODC. Bob is an administrator who works at the site S2. Therefore, he belongs to both groups Emp_S2 and Admins. When the RODC in site S2 is installed, the security groups that are listed in the following table are added to the PRP.
| Security group | PRP setting |
|---|---|
|
Admins |
Denied |
|
Emp_S2 |
Allowed |
According to the specified policy, the credentials that can be cached on the RODC in site S2 are only the credentials for members of the Emp_S2 group that do not belong to Admins. Members of the Emp_S1 and Admins groups will never have their credentials cached on the RODC. Members of the Emp_S2 group may have their credentials cached on the RODC. Bob's credentials will never be cached on the RODC.
Default PRP settings
Each RODC has a PRP that defines which accounts are allowed to have their passwords replicated to the RODC and which accounts are explicitly denied from having their passwords replicated to the RODC. The default policy specifies the groups and settings in the following table.
| Group name | PRP setting |
|---|---|
|
Administrators |
Deny |
|
Server operators |
Deny |
|
Backup operators |
Deny |
|
Account operators |
Deny |
|
Denied RODC Password Replication Group |
Deny |
|
Allowed RODC Password Replication Group |
Allow |
The Denied RODC Password Replication Group has the following domain account members by default:
- Cert Publishers
- Domain Admins
- Enterprise Admins
- Enterprise Domain Controllers
- Enterprise Read-Only Domain Controllers
- Group Policy Creator Owners
- krbtgt
- Schema Admins
The Allowed RODC Password Replication Group has no members by default.
The default PRP improves the security of an RODC installation by ensuring that no account passwords are stored by default and that security-sensitive accounts (such as members of the Domain Admins group) are explicitly denied from ever having their passwords stored on the RODC.
Modifying the default PRP
You can modify the default PRP when you create an account for the RODC or after the RODC account is created. To modify the default PRP after the RODC account is created, right-click the RODC account in the Domain Controllers organizational unit (OU) in the Active Directory Users and Computers snap-in, click Properties, and then click the Password Replication Policy tab. (To open the Active Directory Users and Computers snap-in, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.)
To add accounts to the default PRP when you create the RODC account, click Add on the Specify Password Replication Policy wizard page, and then specify whether to allow or deny passwords for the account to be stored on the RODC. Then, use the Select Users, Computers, or Groups dialog box to select the accounts to add.
You must include the appropriate user, computer, and service accounts in the PRP to allow the RODC to satisfy authentication and service ticket requests locally. If you do not include the computer accounts that the branch users will use to log on to the network in the Allowed List, the RODC will not be able to satisfy requests for service tickets locally and it will rely on access to a writable domain controller to satisfy those requests. If the wide area network (WAN) is offline, this might cause a service outage.
The Deny setting takes precedence over the Allow setting. If both settings are specified for a given user—either directly, or indirectly because the user is a member of a security group that is specified (or nested within a specified security group)—the user's password cannot be stored on the RODC. It is important to note, however, that a user whose password cannot be stored on the RODC can still use the RODC for logon if the WAN connection to a writable domain controller is available. The password for the user is not replicated to the RODC, but the logon can be authenticated by the writable domain controller over the WAN.
The following table describes the advantages and disadvantages of three examples of configurations for a PRP.
| Example | Pros | Cons |
|---|---|---|
|
No accounts are cached (default). |
Most secure—users are authenticated by a writable domain controller, and they get their Group Policy from the RODC for fast policy processing. |
No offline access for anyone—a WAN is required for logon. |
|
Most accounts are cached. |
Ease of password management—this option is intended for organizations that care most about the manageability improvements of RODC, not security. |
More passwords are potentially exposed to an RODC. |
|
Few accounts are cached. |
Enables offline access for those users who need it, but provides more security than caching most accounts. |
This method requires more detailed administration. You may have to map users and computers to each branch that has an RODC. You may also use tools, such as repadmin /prp, to move accounts that have authenticated to an RODC to a group that is in the Allowed List, or you may have to use Identity Lifecycle Manager (ILM) to automate that process. |
The following sections explain each example in more detail.
No accounts are cached
This example provides the most secure option. No passwords are replicated to the RODC, except for the RODC computer account and its special krbtgt account. However, user and computer authentication relies on WAN availability. This example has the advantage of requiring little or no additional administrative configuration from the default settings.
You might choose to add your own security-sensitive user groups to the Denied List. Although no accounts are cached by default, adding your own security-sensitive user groups to the Denied List can protect those groups against accidental inclusion in the Allowed List, along with subsequent caching of their passwords on the RODC.
Note that the delegated RODC administrator account is not added automatically to the Allowed List. As a best practice, add the delegated RODC administrator account to the Allowed List to ensure that a delegated administrator can always log on to the RODC, regardless of whether the WAN connection to a writable domain controller is available.
Most accounts are cached
This example is the simplest administrative mode, and it removes the dependency on WAN availability for user and computer authentication. In this example, you populate the Allowed List for all RODCs with groups that represent a significant portion of the user and computer population. The Denied List does not allow security-sensitive user groups, such as Domain Admins, from having passwords cached. Most other users, however, can have their passwords cached on demand. You might choose to add your own security-sensitive user groups to the Denied List.
This configuration is most appropriate in environments where the physical security of the RODC will not be at risk. For example, you might configure the PRP this way for an RODC that you have deployed in a secure location primarily to take advantage of its reduced replication and administration requirements.
|
Important |
|
You must also add the users' computer accounts to the Allowed list so that those users can log on at the branch office when the WAN is offline. |
Few accounts are cached
This example restricts the accounts that can be cached. Typically, you define this distinctly for each RODC—each RODC has a different set of user and computer accounts that it is permitted to cache. This example is usually for a set of users who work at a particular physical location.
The advantage of this example is that a set of users will be able to log on to the network and be authenticated by the RODC in the branch office if the WAN is offline. 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 administrative overhead associated with populating the Allowed List and the Denied List in this example. There is no default automated method for reading accounts from the known list of security principals who have authenticated against a given RODC, and there is no default method for populating the Allowed List with those accounts. You can use the repadmin /prp move command to move these accounts to a group that is in the Allowed List, or you can use scripts or applications such as ILM to build a process.
Although you can add user or computer accounts directly to the Allowed List, you should instead create a security group for each RODC, add it to the Allowed List and then add user and computer accounts to the security group. This way, you can use standard group management tools such as the Active Directory Users and Computers snap-in or the Dsadd or Dsmod command-line tools to manage which accounts can be cached on the RODC.
The repadmin /prp move command requires that you specify a security group. If the security group that you specify does not exist, it creates the group and adds it to the Allowed list.
As with the previous example, you must also add appropriate computer accounts to the Allowed List.