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.
Note
|
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
- Run
adprep /rodcprep
You do not have to perform this step if you are creating a new forest that will have only domain controllers running Windows Server 2008. - Install
a Writable Domain Controller That Is Running Windows Server 2008
- Optional:
Install an RODC on a Full Installation of Windows Server 2008
-or- - Optional:
Install an RODC on a Server Core Installation
- Optional:
Delegate RODC installation
- Optional:
Install RODC from media
- Optional:
Remove a Domain Controller That Runs Windows Server 2008
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.
Note
|
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.
Note
|
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
Note
|
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.
Note
|
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.
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 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
- View
Current Credentials That Are Cached on an RODC
- Review
Whose Accounts Have Been Authenticated to an RODC
- Prepopulate
the password cache for an RODC
- Reset
the Current Credentials That Are Cached on an RODC If It Is Stolen
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
Note
|
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