Translate

RODC

What Is an RODC?

An RODC is an additional domain controller for a domain that hosts read-only partitions of the Active Directory database. An RODC is designed primarily to be deployed in a branch office environment. Branch offices typically have relatively few users, poor physical security, relatively poor network bandwidth to a hub site, and little local IT knowledge.
The following figure illustrates the RODC branch office environment.
RODC Placement Considerations for Windows Server 2003 Domains

An RODC must replicate domain data from a domain controller running Windows Server 2008. Therefore, replication is among the most important considerations for determining where to place RODCs. This section provides guidance for placing RODCs in sites where they can maintain necessary replication connections.
It then discusses other points to keep in mind regarding RODC placement, in addition to considerations pertaining to the client operating system.


Active Directory Replication Considerations

Domain controllers running Windows Server 2008 can replicate Active Directory database partitions as listed in the following table. Although an RODC can replicate data from domain controllers running Windows Server 2003, it can replicate updates of the domain partition only from a domain controller running Windows Server 2008 from the same domain. RODCs cannot be a source domain controller for any other domain controller because they cannot perform outbound replication. Application directory partitions include Forest DNS Zones and Domain DNS Zones.

Destination domain controller
Windows Server 2003 source domain controller
Writable Windows Server 2008 source domain controller
Windows Server 2003
Schema
Configuration
Domain
Application directory partitions
Partial attribute set of the other domain partitions in the forest (global catalog)
Schema
Configuration
Domain
Application directory partitions
Partial attribute set of the other domain partitions in the forest (global catalog)
Writable Windows Server 2008
Schema
Configuration
Domain
Application directory partitions
Partial attribute set of the other domain partitions in the forest (global catalog)
Schema
Configuration
Domain
Application directory partitions
Partial attribute set of the other domain partitions in the forest (global catalog)
RODC
Schema
Configuration
Application directory partitions
Partial attribute set of the other domain partitions in the forest (global catalog)
Schema
Configuration
Domain
Application directory partitions
Partial attribute set of the other domain partitions in the forest (global catalog)
Writable domain controllers running Windows Server 2008 and domain controllers running Windows Server 2003 can perform inbound and outbound replication of all available partitions. Therefore, they do not require the same placement considerations that RODCs require.
Because an RODC can replicate the domain partition only from a writable domain controller running Windows Server 2008, the placement of each becomes important and requires careful planning. The placement of an RODC and writable domain controllers running Windows Server 2008 might be affected by the site topology and network constraints.
Each RODC requires a writable domain controller running Windows Server 2008 for the same domain from which the RODC can directly replicate. Typically, this requires that a writable domain controller running Windows Server 2008 be placed in the nearest site in the topology. The nearest site in this sense is defined as the site that has the lowest-cost site link for the site that includes the RODC.
For example, suppose you have Sites A, B, and C with site links A – B and B – C and the Bridge all site links option is disabled, as shown in the following figure. In order to put an RODC in Site C, a domain controller running Windows Server 2008 for the same domain should be placed in Site B to replicate the domain partition to the RODC. Placing only a domain controller running Windows Server 2003 in Site B would permit the RODC in Site C to replicate the schema, configuration, and application directory partitions, but not the domain partition.
If the Bridge all site links option is enabled, as shown in the next figure, a domain controller running Windows Server 2008 could be placed in Site A rather than Site B. This is because physical connectivity between Site A and Site C is now implicitly available.
Generally, the introduction of an RODC should require minimal, if any, replication topology changes. For example, consider a multitier replication topology where:
  • The Bridge all site links option is disabled.
  • RODCs are placed in tail sites.
  • Writable domain controllers running Windows Server 2008 are placed in the hub site.
This is shown in the following figure. In this case, you might create additional site links between the hub site and the tail sites to accommodate the need for direct replication between the RODC and the writable domain controller running Windows Server 2008.

Known Issues for Deploying an RODC

This section describes some of the known issues for deploying an RODC running Windows Server 2008. Some of the problems are avoided or mitigated by following the guidelines (described earlier) for placing RODCs. For more information, see RODC Placement Considerations for Windows Server 2003 Domains.

Client and Server Operating System Issues

RODCs do not require any changes to client computers to allow them to use an RODC. Client computers running any of the following operating systems are supported for use with RODCs:
  • Microsoft Windows 2000 Server
  • Windows XP
  • Windows Server 2003
  • Windows Vista™
  • Member servers running Windows Server 2008
However, depending on your environment, you might need to apply the following hotfix or make configuration changes to address the following known issues:
  • Microsoft Knowledge Base article 929768
  • If you attempt to attach a server to a read-only domain controller (RODC) account in a highly-secured environment, the operation may fail with the error "Replication access denied."

    To avoid this, perform a complete non-delegated installation of the RODC using a Domain Administrator account.

    You can also correct this issue by adjusting the permissions for the following objects:
·         On the organizational unit of the domain controller, grant Read permission to Authenticated Users.
·         On the Infrastructure container, grant Read permission to Authenticated Users.
  • If an RODC is present in the site, applications may fail to register their Service Principle Names (SPNs).

    To correct this, identify the service account of any application that has failed to register its SPN and cache the account on all RODCs in the same site.

    To identify which RODCs have currently cached the password of the service account, open Active Directory Users and Computers, right-click the service account object, click
    Properties, and click the Password Replication tab.

    To cache the password on a specific RODC, open Active Directory Users and Computers, click
    Domain Controllers, right-click the RODC account object, click Properties, and then click the Password Replication Policy tab. Click Advanced, and then click Prepopulate Passwords.
  • After you add an RODC to a site that has a Windows Server 2003 global catalog server, you might see an Event ID 1645 error logged on the Windows Server 2003 global catalog server. The error indicates that a replication SPN could not be registered for the RODC. This is by design, and you can disregard the error. It occurs because the RODC requests replication notifications from the Windows Server 2003 global catalog server, but the Windows Server 2003 global catalog server does not use notifications to the RODC.
noteNote
As a best practice, you should not deploy an RODC in a site that has a writable domain controller because, if the RODC is compromised, then all other resources in that site can be compromised, including other domain controllers. However, there may be situations in which you temporarily have an RODC running in the same site as a writable domain controller, such as when you are replacing the writable domain controller with an RODC.

Domain Controllers Running Windows Server 2003 Perform Automatic Site Coverage for Sites with RODCs

To ensure that clients can locate a domain controller in the nearest available site, domain controllers attempt to register their DNS service location (SRV) resource records. These resource records pertain to sites that contain no domain controller for the domain of which they are a member. This functionality is commonly known as "automatic site coverage."
Automatic site coverage factors in the cost associated with the site links of a site without a domain controller. This cost helps determine which domain controller registers its SRV resource records for that site. The SRV resource records are registered by domain controllers from the site that has the lowest cost between its site link and the site that has no domain controller. This makes it possible for clients in the site without a domain controller to use the least expensive network connection to contact a domain controller in another site.
Domain controllers running Windows Server 2003 do not consider RODCs when they evaluate site coverage requirements. As a result, they perform automatic site coverage for any site regardless of the presence of an RODC for the same domain.

Impact

If a domain controller running Windows Server 2003 registers its DNS SRV resource records for a site that contains an RODC, clients that attempt to discover a domain controller in the RODC site also find the domain controller that is running Windows Server 2003. As a result, they might not authenticate with the RODC as planned.

Solution

There are a few possible solutions for this problem:
  • Install the RODC compatibility pack on Windows Server 2003 domain controllers. To download the RODC compatibility pack, see article 944043 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=122974).
  • Ensure that only domain controllers running Windows Server 2008 are present in the site closest to the RODC site.

    Unlike domain controllers that run Windows Server 2003, domain controllers that run Windows Server 2008 do consider RODCs when they perform automatic site coverage. As a result, they do not attempt to register SRV resource records for the RODC site. Domain controllers running Windows Server 2003 do not attempt to register SRV resource records for the RODC site because they are not in the closest site.
  • Disable automatic site coverage on domain controllers running Windows Server 2003.

    By editing the registry of the domain controllers running Windows Server 2003, you can prevent them from performing automatic site coverage.

    To disable automatic site coverage on a domain controller running Windows Server 2003
1.     Click Start, click Run, type regedit, and then click OK.
2.     Navigate to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3.     Click Edit, point to New, and then click DWORD Value.
4.     Type AutoSiteCoverage as the name of the new entry, and then press ENTER.
5.     Double-click the new AutoSiteCoverage registry entry.
6.     Under Value data, type 0 to disable automatic site coverage or type 1 to enable it.
RODCs Do Not Perform Domain Controller Certificate Enrollment

The Enterprise Read-Only Domain Controllers group is not included in the default groups that are defined in the Domain Controller certificate template. This prevents them from enrolling for a domain controller certificate and from being automatically enrolled.
A domain controller requires a Domain Controller certificate to authenticate a logon that uses a smart card. Because the RODCs cannot obtain the domain controller certificate by default, they cannot authenticate a smart card logon by default.

Impact

Smart card logons that are authenticated by an RODC fail. An error message appears that states that the operation is not supported.

Solution

To make it possible for an RODC to authenticate smart card logons, modify the following certificate templates:
  • On the Domain Controller certificate template, allow Enroll permissions for the ERODC group.
  • On the Domain Controller Authentication and Directory E-Mail Replication certificate templates, allow Enroll and Autoenroll permissions for the ERODC group. Allow Read permission for the Authenticated Users group.

Steps for Deploying an RODC

This section contains information about deploying an RODC. It first lists high-level tasks that must be performed, in addition to optional tasks. This list is followed by detailed information, including information about administrative credentials and procedures necessary for performing some of these tasks.
To deploy an RODC, complete the following high-level tasks:

Ensure that the forest functional level is Windows Server 2003 or higher

Administrative credentials
Any domain user can verify that the current forest functional level is Windows Server 2003 or higher. To raise the forest functional level, you must be either a member of the Domain Admins group in the forest root domain or a member of the Enterprise Admins group.
To ensure that the forest functional level is Windows Server 2003 or higher
1.     Open Active Directory Domains and Trusts.
2.     In the console tree, right-click the name of the forest, and then click Properties.
3.     Under Forest functional level, verify that the value is Windows Server 2003 or Windows Server 2008.
4.     If it is necessary to raise the forest functional level, in the console tree, right-click Active Directory Domains and Trusts, and then click Raise forest functional level.
5.     In Select an available forest functional level, click Windows Server 2003, and then click Raise.

Run adprep /rodcprep

Administrative credentials
This step updates the permissions on all the DNS application directory partitions in the forest. This allows them to be replicated successfully by all RODCs that are also DNS servers. To run adprep /rodcprep, you must be a member of the Enterprise Admins group.
To run adprep /rodcprep
1.     Log on to a domain controller as a member of the Enterprise Admins group.
2.     Copy the contents of the \sources\adprep folder on the Windows Server 2008 installation DVD to the schema master.
3.     Open a command prompt, change directories to the adprep folder, type the following command, and then press ENTER:
adprep /rodcprep

Install a writable domain controller that runs Windows Server 2008

An RODC must replicate domain updates from a writable domain controller that runs Windows Server 2008. Before you install an RODC, be sure to install a writable domain controller that runs Windows Server 2008 in the same domain. The domain controller can run either a full installation or a Server Core installation of Windows Server 2008. In Windows Server 2008, the writable domain controller does not have to hold the primary domain controller (PDC) emulator operations master role.
For more information and step-by-step procedures for installing a writable domain controller that runs Windows Server 2008, see the Step-by-Step guide for Windows Server 2008 Active Directory Domain Services Installation and Removal (http://go.microsoft.com/fwlink/?LinkId=86716).

Optional: Install an RODC on a full installation of Windows Server 2008

You can install an RODC on either a full installation of Windows Server 2008 or on a Server Core installation of Windows Server 2008. You can start the Active Directory Domain Services Installation Wizard in a variety of ways. For a complete list, see the Step-by-Step guide for Windows Server 2008 Active Directory Domain Services Installation and Removal (http://go.microsoft.com/fwlink/?LinkId=86716).
After you install the first RODC in your domain, allow enough time for the new Password Replication Policy groups to replicate to other domain controllers in the domain before you try to install additional RODCs. This helps prevent errors that might occur during the RODC installation if the groups are not available on the source domain controller.
Administrative credentials
To install an RODC on a full installation of Windows Server 2008, you must be a member of the Domain Admins group.
To install an RODC on a full installation of Windows Server 2008
1.     Log on to the server as a member of the Domain Admins group.
2.     Click Start, type dcpromo, and then press ENTER to start the Active Directory Domain Services Installation Wizard. The server can belong to a workgroup. Alternatively, if you are not delegating the installation, the server can already be joined to the domain in which you want it to be an RODC.
noteNote
If you select the Useadvanced mode installation check box on the Welcome to the Active Directory Domain Services Installation Wizard page, you can configure the Password Replication Policy for the RODC and other settings during the AD DS installation. In this guide, a procedure for configuring the Password Replication Policy is provided in Steps for Administering an RODC. For a complete list of settings that you can configure when you select the Useadvanced mode installation check box, click the advanced mode installation Help link.
On the Choose a Deployment Configuration page, click Existing forest, click Add a domain controller to an existing domain, as shown in the following illustration, and then click Next
1.     On the Network Credentials page, type the name of a domain in the forest where you plan to install the RODC. If necessary, also type a user name and password for a member of the Domain Admins group, and then click Next.
2.     Select the domain for the RODC, and then click Next.
3.     Click the Active Directory site for the RODC, as shown in the following illustration, and then click Next.
1.     Select the Read-only domain controller check box, as shown in the following illustration. By default, the DNS server check box is also selected.
noteNote
To run the DNS server on the RODC, another domain controller running Windows Server 2008 must be running in the domain and hosting the DNS domain zone. An Active Directory–integrated zone on an RODC is always a read-only copy of the zone file. Updates are sent to a DNS server in a hub site instead of being made locally on the RODC.
1.     To use the default folders that are specified for the Active Directory database, the log files, and SYSVOL, click Next.
2.     Type and then confirm a Directory Services Restore Mode password, and then click Next.
3.     Confirm the information that appears on the Summary page, and then click Next to start the AD DS installation. You can select the Reboot on completion check box to make the rest of the installation complete automatically.

Optional: Install an RODC on a Server Core installation

Administrative credentials
This is an optional task. If you choose to install an RODC on a Server Core installation of Windows Server 2008, you must be a member of the Domain Admins group or you must have been delegated the ability to perform the installation.
To install an RODC on a Server Core installation of Windows Server 2008, you must perform an unattended installation of AD DS. The following procedure includes the parameters that can be specified in the answer file during an unattended installation. You can also specify these parameters at a command line if you use the
dcpromo /unattend command
To install an RODC on a Server Core installation of Windows Server 2008
1.     Install a second server computer that is running a Server Core installation of Windows Server 2008.
2.     Copy the following answer file settings to a text file. The InstallDNS, PasswordReplicationAllowed, PasswordReplicationDenied, and ReplicationSourceDC settings are optional. Replace the placeholder information (in italics) with the correct information for your environment. Then save the text file with the name that you will use for your answer file during the installation:
[DCInstall]
InstallDNS=Yes
ConfirmGc=No
CriticalReplicationOnly=No
DisableCancelForDnsInstall=No
PasswordReplicationAllowed= The name(s) of groups whose members' passwords will be allowed to be cached on the RODC
PasswordReplicationDenied= The name(s) of groups whose members' passwords will NOT be allowed to be cached on the RODC
Password= Domain Admin password
RebootOnCompletion=No
ReplicaDomainDNSName= Full DNS name of the domain
ReplicaOrNewDomain=ReadOnlyReplica
ReplicationSourceDC= Name of a Windows Server 2008 domain controller in the same domain
SafeModeAdminPassword= Choose an appropriate password to use for Directory Services Restore Mode
SiteName= RODC Site Name
UserDomain= DomainName
UserName= Domain Admin account name
noteNote
The groups that are specified as values for PasswordReplicationAllowed and PasswordReplicationDenied must already exist. You must specify the groups either by using the Windows NT format (domain\user_name or domain.com\user_name) or by using the user principal name (UPN) format (user_name@domain.com). Add another entry for each additional group. For example:
PasswordReplicationAllowed=CN=AllowedGroup,OU=Users,DC=spruce,DC=example,DC=contoso,DC=com
PasswordReplicationAllowed=CN=AllowedGroup2,OU=Users,DC=spruce,DC=example,DC=contoso,DC=com
If you do not want to specify any groups during the installation, leave this entry blank.
3.     At a command line, type the following command, and then press ENTER:
dcpromo /unattend: PathToAnswerFile

Optional: delegate RODC installation

You can perform a staged installation of an RODC in which the installation is completed in two stages by different individuals. The first stage of the installation, which requires domain administrative credentials, creates an account for the RODC in AD DS. The second stage of the installation attaches the actual server that will be the RODC in a remote location, such as a branch office, to the account that was previously created for it. You can delegate the ability to attach the server to the account to a nonadministrative group or user in the remote location.
During the first stage of the installation, the wizard records all the data about the RODC that will be stored in the distributed Active Directory database, including the read-only domain controller account name and the site in which it will be placed. This stage must be performed by a member of the Domain Admins group.
The administrator who creates the RODC account can also specify at that time which users or groups can complete the next stage of the installation. The next stage of the installation can be performed in the branch office by any user or group who was delegated the right to complete the installation when the account was created. This stage does not require any membership in built-in groups, such as the Domain Admins group. If the user who creates the RODC account does not specify any delegate to complete the installation (and administer the RODC), only a member of the Domain Admins group or the Enterprise Admins group can complete the installation.
During the second stage, the wizard installs AD DS on the server that will become the RODC, and it attaches the server to the domain account that was previously created for it. This stage typically occurs in the branch office or other remote location where the RODC is deployed. During this stage, all AD DS data that resides locally, such as the database, log files, and so on, is created on the RODC itself. You can replicate the installation source files to the RODC from another domain controller over the network, or you can use the install from media (IFM) feature. To use IFM, use Ntdsutil.exe to create the installation media.
The server that will become the RODC must not be joined to the domain before you try to attach it to the RODC account. As part of the installation, the wizard automatically detects whether the name of the server matches the names of any RODC accounts that have been created in advance for the domain. When the wizard finds a matching account name, it prompts the user to use that account to complete the RODC installation.
You can use the Active Directory Users and Computers snap-in to create an RODC account.
noteNote
You can automate a staged installation of an RODC by typing dcpromo at a command prompt with the appropriate parameters or by using an answer file. For more information about automating the installation, see the Step-by-Step guide for Windows Server 2008 Active Directory Domain Services Installation and Removal .
To create an RODC account by using the Windows interface
1.     Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
2.     Double-click the domain container, then you can either right-click the Domain Controllers container or click the Domain Controllers container, and then click Action.
Click Pre-create Read-only Domain Controller account, as shown in the following figure

1.     On the Welcome to the Active Directory Domain Services Installation Wizard page, if you want to modify the default the Password Replication Policy, select Use advanced mode installation, and then click Next.
2.     On the Network Credentials page, under Specify the account credentials to use to perform the installation, click My current logged on credentials, as shown in the following figure, or click Alternate credentials, and then click Set. In the Windows Security dialog box, provide the user name and password for an account that can install the additional domain controller. To install an additional domain controller, you must be a member of the Enterprise Admins group or the Domain Admins group. When you are finished providing credentials, click Next.


1.     On the Specify the Computer Name page, type the computer name of the server that will be the RODC.
2.     On the Select a Site page, select a site from the list or select the option to install the domain controller in the site that corresponds to the IP address of the computer on which you are running the wizard, and then click Next.
3.     On the Additional Domain Controller Options page, make the following selections, as shown in the following figure, and then click Next:
·         DNS server: This option is selected by default so that your domain controller can function as a DNS server. If you do not want the domain controller to be a DNS server, clear this check box. However, if you do not install the DNS server role on the RODC and the RODC is the only domain controller in the branch office, users in the branch office will not be able to perform name resolution when the WAN to the hub site is offline.
·         Global catalog: This option is selected by default. It adds the read-only directory partitions of the global catalog to the domain controller, and it enables global catalog search functionality. If you do not want the domain controller to be a global catalog server, clear this option. However, if you do not install a global catalog server in the branch office or enable universal group membership caching for the site that includes the RODC, users in the branch office will not be able to log on to the domain when the WAN to the hub site is offline.
Read-only domain controller. When you create an RODC account, this option is selected by default and you cannot clear it.




1.     If you selected the Use advanced mode installation check box on the Welcome page, the Specify the Password Replication Policy page appears. By default, no account passwords are replicated to the RODC, and security-sensitive accounts (such as members of the Domain Admins group) are explicitly denied from ever having their passwords replicated to the RODC.
To accept the default setting, click Next.
-or-
To add other accounts to policy, click Add. If you want the accounts to be allowed to have their passwords replicated to the RODC, click Allow passwords for the account to replicate to this RODC. If you want the accounts to be denied from having their passwords replicated to the RODC, click Deny passwords for the account from replicating to this RODC. Then, click OK. When you are done adding other accounts, click Next.
When you install the first RODC in a domain, domain group accounts that are required for RODCs to function are created. Depending on your replication topology, the wizard might return an error indicating that these group accounts are not available when you try to install another RODC in the domain. In this case, wait for replication to complete before you install the additional RODC.
For more information about configuring the Password Replication Policy, see Steps for Administering an RODC.
2.     In Select Users, Computers, and Groups, type the names of the accounts that you want to add to the policy, and then click OK.
3.     On the Delegation of RODC Installation and Administration page, type the name of the user or the group who will attach the server to the RODC account that you are creating, as shown in the following figure. You can type the name of only one security principal.

To search the directory for a specific user or group, click Set. In Select Users, Computers, or Groups, type the name of the user or group. We recommend that you delegate RODC installation and administration to a group.
This user or group will also have local administrative rights on the RODC after the installation. If you do not specify a user or group, only members of the Domain Admins group or the Enterprise Admins group will be able to attach the server to the account.
When you are finished, click Next.
1.     On the Summary page, review your selections. Click Back to change any selections, if necessary.
To save the settings that you selected to an answer file that you can use to automate subsequent AD DS operations, click Export settings. Type a name for your answer file, and then click Save.
When you are sure that your selections are accurate, click Next to create the RODC account.
2.     On the Completing the Active Directory Domain Services Installation Wizard page, click Finish.
After you create the account for the RODC, the user or group to whom you delegated installation and administration of the RODC (in step 11 in the previous procedure) can run the Active Directory Domain Services Installation Wizard on the server that will become the RODC to complete the RODC installation. Make sure that the server is not joined to the domain before you start the wizard.
To attach a server to an RODC account using the Windows interface
1.     Log on as local Administrator to the server that will become the RODC, and then open a command prompt.
2.     Type the following command, and then press ENTER:
dcpromo /UseExistingAccount:Attach
3.     On the Welcome to the Active Directory Domain Services Installation Wizard page, click Next, or, if you want to install from media or identify the source domain controller for AD DS replication, select the Use advanced mode installation check box.
4.     On the Network Credentials page, type the name of any existing domain in the forest where you plan to install the additional domain controller, as shown in the following figure. Under Specify the account credentials to use to perform the installation, click Alternate credentials, and then click Set. In the Windows Security dialog box, provide the user name and password for an account that was delegated the ability to install and administer the RODC when the RODC account was created. When you are finished providing credentials, click Next.

1.     On the Select Domain Controller Account page, confirm that the wizard has found an existing RODC account that matches the name of the server, and then click Next.
2.     If you selected advanced installation mode, you can specify the following advanced options:
a.     On the Install from Media page, you can provide the location of installation media to be used to create the domain controller and configure AD DS or you can choose to have all data replicated over the network. Note that some data will be replicated over the network even if you choose to install from media. For information about using this method to install the domain controller, see Optional: Install RODC from Media.
b.     On the Source Domain Controller page, you can specify a domain controller from which to replicate the configuration and schema directory partitions (or the entire Active Directory database if you do not choose to install from media). If you select This specific domain controller, you can select the domain controller that you want to provide source replication to create the new domain controller, and then click Next.
3.     On the Location for Database, Log Files, and SYSVOL page, type or browse to the volume and folder locations for the database file, the directory service log files, and the system volume (SYSVOL) files, and then click Next.
Windows Server Backup backs up the directory service by volume. For backup and recovery efficiency, store these files on separate volumes that do not contain applications or other nondirectory files.
4.     On the Directory Services Restore Mode Administrator Password page, type and confirm the restore mode password, and then click Next. This password is used to start AD DS in Directory Service Restore Mode for tasks that must be performed offline. The password complexity and length must comply with the domain security policy.
5.     On the Summary page, review your selections. Click Back to change any selections, if necessary.
To save the settings that you selected to an answer file that you can use to automate subsequent AD DS operations, click Export settings. Type a name for your answer file, and then click Save.
When you are sure that your selections are accurate, click Next to install AD DS.
6.     You can either select the Reboot on completion check box to have the server restart automatically or you can restart the server to complete the AD DS installation when you are prompted to do so.

Optional: Install RODC from media

In previous versions of Windows Server, administrators were encouraged to use Ntbackup.exe to create domain controller installation media. In Windows Server 2008, administrators are encouraged to use ntdsutil.exe to create installation media. You can use the new ifm subcommand in ntdsutil to remove cached secrets (such as passwords) from the installation media to use it for an RODC installation. Ntbackup.exe cannot remove cached secrets from the installation media.
To install an RODC from media, first use Ntdsutil to create the installation media. Then, specify the IFM option as appropriate for the installation method that you are using, as listed in the following table.

 

Installation method
Action required to specify the IFM option
Active Directory Domain Services Installation Wizard
Select the Use advanced mode installation check box on the Welcome page (for both delegated and nondelegated installations).
Command-line installation
Type dcpromo /unattend /ReplicationSourcePath:"path to installation media"
Add other parameters as required to complete the installation.
Answer file
Create an answer file that includes an entry for ReplicationSourcePath="path to installation media"
Specify dcpromo /unattend:"path to answer file" at a command prompt.
For more information about installing from media, see the Step-by-Step guide for Windows Server 2008 Active Directory Domain Services Installation and Removal (http://go.microsoft.com/fwlink/?LinkId=86716).

Optional: Remove a domain controller that is running Windows Server 2008

Administrative credentials
This is an optional task. If you choose to remove a domain controller that is running Windows Server 2008, you must be a member of the Domain Admins group.
To remove a domain controller on Windows Server 2008
1.     Copy the following answer file settings to a text file. The InstallDNS and ReplicationSourceDC settings are optional. Replace the placeholder information (in italics) with the correct information for your environment, and then save the text file:
[DCInstall]
InstallDNS=Yes
AdministratorPassword=Member Server Administrator password
RebootOnCompletion=No
UserDomain=DomainName
UserName=Domain Admin Account name
Password=Domain Admin password
ReplicationSourceDC=Name of a Windows Server 2008 domain controller in the same domain
2.     At a command line, type the following command, and then press ENTER:
dcpromo /unattend: PathToAnswerFile
Steps for Administering an RODC
As stated, an important benefit of an RODC is that it requires less administration than a writable domain controller. It requires only inbound replication, and no erroneous information can be written to the Active Directory database.
However, the Password Replication Policy for an RODC presents minor administrative requirements. An RODC also requires maintenance activities that are similar to those of a writable domain controller. These include routine backups of system state data and the application of software updates.
This section contains information and steps pertaining to the following:
  • The Password Replication Policy
  • Password Replication Policy Administration
  • Administrator Role Separation
Password Replication Policy
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.
noteNote
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 RODC Password Replication Policy is determined by four multivalued AD DS attributes that contain security principals—users, computers, and groups. Each RODC computer account has these four attributes:
  • msDS-Reveal-OnDemandGroup, also commonly known as the Allowed List
  • msDS-NeverRevealGroup, also commonly known as the Denied List
  • msDS-RevealedList, also commonly known as the Revealed List
  • msDS-AuthenticatedToAccountList, also commonly known as the Authenticated to List
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-Reveal-OnDemandGroup 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.

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.
Password Replication Policy Administration
This section provides procedures for the following administrative tasks that are related to Password Replication Policy for an RODC:

Configure the Password Replication Policy for an RODC

Administrative credentials
To configure the Password Replication Policy for an RODC, you must be a member of the Domain Admins group.
To configure the Password Replication Policy for an RODC
1.     Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
2.     Ensure that Active Directory Users and Computers points to the writable domain controller that is running Windows Server 2008, and then click Domain Controllers.
3.     In the details pane, right-click the RODC computer account, and then click Properties.
Click the Password Replication Policy tab, as shown in the following figure


1.     The Password Replication Policy tab lists the accounts that, by default, are defined in the Allowed List and the Denied List on the RODC. To add other groups that should be included in either the Allowed List or the Denied List, click Add. To add other accounts that will not have credentials cached on the RODC, click Deny. To add other accounts that will have credentials cached on the RODC, click Allow.
Accounts that will not have credentials cached on the RODC can still use the RODC for domain logon. The credentials, however, will not be cached for subsequent logon using the RODC.

View current credentials that are cached on an RODC

By default, the only credentials that are cached on an RODC are for the computer account of the RODC itself and a krbtgt account.
Administrative credentials
Any domain user can view current credentials that are cached on an RODC.
To view current credentials that are cached on an RODC
1.     Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
2.     Ensure that Active Directory Users and Computers points to the writable domain controller that is running Windows Server 2008, and then click Domain Controllers.
3.     In the details pane, right-click the RODC computer account, and then click Properties.
4.     Click the Password Replication Policy tab.
5.     Click Advanced.
6.     In the drop-down list, click Accounts whose passwords are stored on this Read-only Domain Controller, as shown in the following illustration.


Review whose accounts have attempted to authenticate to an RODC

Periodically, you should review whose accounts have tried to authenticate to an RODC. This information can help you plan updates that you intend to make to the existing Password Replication Policy. For example, look at which user and computer accounts have tried to authenticate to an RODC so that you can add those accounts to the Allowed List. After their credentials are cached on the RODC, the accounts can be authenticated by the RODC in the branch office when the wide area network (WAN) to the hub site is offline.
You can use the repadmin /prp move command to automatically move accounts that try to authenticate to an RODC to the Allowed List for that RODC. For more information, see Repadmin /prp
Administrative credentials
Any domain user can view which user and computer accounts have authenticated to an RODC.
To review the accounts that have been authenticated to an RODC
1.     Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
2.     Ensure that Active Directory Users and Computers points to the writable domain controller that is running Windows Server 2008, and then click Domain Controllers.
3.     In the details pane, right-click the RODC computer account, and then click Properties.
4.     Click the Password Replication Policy tab.
5.     Click Advanced.
In the drop-down list, click Accounts that have been authenticated to this Read-only Domain Controller, as shown in the following illustration


Prepopulate the password cache for an RODC

You can prepopulate the password cache for an RODC with the passwords of user and computer accounts that you plan to authenticate to it. When you prepopulate the RODC password cache, you trigger the RODC to replicate and cache the passwords for users and computers before the accounts try to log on in the branch office.
Prepopulating the password cache helps ensure that a user can log on to the network in the branch office, even if the WAN link to the data center is offline. For example, suppose that a user who normally works in the data center travels to a branch office and attempts to log on there with a laptop. The RODC contacts the writable domain controller in the data center. If the Password Replication Policy allows it, the RODC caches the password. However, if the WAN link is offline when the user attempts to log on, then the logon attempt fails because the RODC has not yet replicated the password for the account.
To avoid this problem, you can prepopulate the password cache of the RODC in the branch office with the password of the user and the laptop. This eliminates the need for the RODC to replicate the password from the Windows Server 2008 domain controller over the WAN link.
In addition, prepopulating the password cache is a good idea if you build an RODC in a central location, such as in a data center, before you transport the RODC to the branch office. By prepopulating the password cache with the users and computers who will log on in the branch office, the RODC can authenticate those accounts without contacting the Windows Server 2008 domain controller over the WAN link.
You can prepopulate the cache only for accounts that the Password Replication Policy allows to be cached. If you try to prepopulate a password of an account that the Password Replication Policy does not allow to be cached, the operation fails.
You can prepopulate the password cache for an RODC by using Active Directory Users and Computers or by using the Repadmin command-line tool.
Administrative credentials
To prepopulate the password cache for an RODC, you must be a member of the Domain Admins group.
To prepopulate the password cache for an RODC by using Active Directory Users and Computers
1.     Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
2.     Ensure that Active Directory Users and Computers points to the writable domain controller that is running Windows Server 2008, and then click Domain Controllers.
3.     In the details pane, right-click the RODC computer account, and then click Properties.
4.     Click the Password Replication Policy tab.
5.     Click Advanced.
6.     Click Prepopulate Passwords.
7.     Type the name of the accounts whose passwords you want to prepopulate in the cache for the RODC, and then click OK.
8.     When you are asked if you want to send the passwords for the accounts to the RODC, click Yes.
To prepopulate the password cache for an RODC by using the Repadmin command-line tool
1.     Log on to a writable domain controller that is running Windows Server 2008.
2.     Click Start, right-click Command Prompt, and then click Run as administrator.
3.     If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
4.     Type the following command. and then press ENTER:
repadmin /rodcpwdrepl [DSA_List] <Hub DC> <User1 Distinguished Name> [<Computer1 Distinguished Name> <User2 Distinguished Name> …]
In the command, use the values from the following table.

 

Placeholder
Value
DSA_List
The name of the RODC whose password cache you want to prepopulate.
Hub DC
The name of the writable Windows Server 2008 domain controller that is the replication partner of the RODC.
User1, Computer1, ….
The names of the user and computers whose passwords you want to cache on the RODC. You must add the computer accounts of the users or they cannot log on.
For example, the following command prepopulates the password cache for RODC15 with the passwords for Mike Danseglio and his computer, MikeDanLaptop. The hub domain controller is named HUBDC12.
Repadmin /rodcpwdrepl RODC15 HUBDC12 CN=MikeDan,OU=DatacenterUsers,DC=contoso,DC=com CN= MikeDanLaptop,OU=DatacenterComputers,DC=contoso,DC=com

Reset the current credentials that are cached on an RODC if it is stolen

Administrative credentials
To reset the current credentials that are cached on an RODC, you must be a member of the Domain Admins group.
To reset the current credentials that are cached on an RODC if it is stolen
1.     Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
2.     Ensure that Active Directory Users and Computers points to the writable domain controller that is running Windows Server 2008, and then click Domain Controllers.
3.     In the details pane, right-click the RODC computer account, and then click Delete.
4.     To confirm the deletion, click Yes.
In the Deleting Active Directory Domain Controller dialog box, select the Reset all passwords for user accounts that were cached on this read-only domain controller check box, as shown in the following figure. As an option, you can also select the Export the list of accounts that were cached on this read-only domain controller to this file check box to create a list of user accounts whose passwords must be reset after the RODC account is deleted. That list of accounts is not available after the RODC account is deleted.


Administrator Role Separation Configuration
This section provides procedures for creating a local administrator role for an RODC and for adding a user to that role.
For more information about what is Administrator Role Separation, see RODC Features.
Administrative credentials
To initially configure Administrator Role Separation for an RODC, you must be a member of the Domain Admins group.
To configure Administrator Role Separation for an RODC
1.     Click Start, click Run, type cmd, and then press ENTER.
2.     At the command prompt, type dsmgmt.exe, and then press ENTER.
3.     At the DSMGMT prompt, type local roles, and then press ENTER.
4.     For a list of valid parameters, type ?, and then press ENTER.
By default, no local administrator role is defined on the RODC after AD DS installation. To add the local administrator role, use the Add parameter.
5.     Type add <DOMAIN>\<user> <administrative role>
For example, type add CONTOSO\testuser administrators
noteNote
After a user has been added to the administrator role on an RODC, that user can log on locally and can further configure Administrator Role Separation.
The following table lists the parameters that are available for Administrator Role Separation.

Parameter
Description
Add %s1 %s2
Adds an account %s1 to the local role %s2.
Connections
Connects to a specific Active Directory domain controller or an AD LDS instance.
Help
Shows pertinent Help information.
List Roles
Lists defined local roles.
Quit
Returns to the previous menu.
Remove %s1 %s2
Removes an account %s1 from the local role %s2.
Show Role %s
Shows local role members.

No comments:

Post a Comment