6.1.

RODC
A read‐only domain controller (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 because branch offices
often have relatively few users, poor physical security, relatively poor network
bandwidth to a hub site, and limited local IT resources.

The following table describes the features of RODCs.

Feature Description
The new administrator role separation (ARS) feature allows
RODCs to provide a secure mechanism for granting non‐
administrative domain users the right to log on to a domain
controller without jeopardizing the security of AD DS. This
allows the domain user to perform local administrative tasks
like installing drivers or security updates.

 The domain user will not have any user rights for the
entire domain or any other domain controllers in the
Administrator
domain. This is done to minimize the risk to the security
role separation
of the entire domain and to prevent the domain user
from accidentally modifying the Active Directory.
 To initially configure the administrator role separation
feature for an RODC, you must be a member of the
Domain Admins group.
 All local, built‐in administrator accounts can also be
configured through administrator role separation,
including backup operators and server operators.

An RODC only supports unidirectional replication, meaning

that it solely performs inbound replication. The benefits of
Unidirectional unidirectional replication are:
replication
 Writable domain controllers that are replication partners
do not pull changes from the RODC.
  No changes originate at the RODC because no changes
are written directly by the RODC.
 Any changes or corruption that a malicious user might
make at branch locations cannot replicate from the
RODC to the rest of the forest.
 Workload reduction for bridgehead servers in the hub
and the effort required to monitor replication.

Unidirectional replication causes the following limitations:

 An RODC cannot act as a bridgehead server because

bridgehead servers replicate changes from other sites.
 RODCs cannot be a source domain controller for any
other domain controller.

Other than account passwords, an RODC contains all of the AD

DS objects and attributes that a writeable domain controller
Read‐only data contains. LDAP applications can be redirected to a writeable
domain controller in a hub site if changes need to be made to
Active Directory objects.
Password replication allows a writable domain controller to
replicate user or computer credentials to an RODC. These
credentials are then cached so that the RODC can perform
authentication without contacting a writeable domain
controller. To understand how password replication and
credential caching work, you should understand the RODC
authentication process, which is as follows:
Password
replication
1. A workstation sends a logon request to the RODC.
2. The RODC forwards the logon request to a writable
Windows Server 2008 (and above: 2008 R2, 2012, 2012
R2, etc.) domain controller, which authenticates the
request and returns the result (either positive or
negative) to the RODC.
3. The RODC sends the result to the workstation.
 4. The RODC asks the writable domain controller to
replicate the user's credentials to its replica of the Active
Directory database.
5. The writable domain controller checks the password
replication policy to see if the RODC is permitted to
cache the credentials for the user. The following occurs:
o If the user's account is on the allowed list, the
writable domain controller allows replication of
the account credentials to the RODC.
o At the same time that the writable domain
controller sends the credentials requested by the
RODC, it writes the distinguished name of the
user's account to the msDS‐RevealedList attribute
of the RODC computer account, creating a record
that the user's credentials are cached on the
RODC.
6. The RODC stores the user's credentials in the
appropriate attributes of the user account in the Active
Directory database. The next time this user tries to log
on, the RODC will not have to contact the writable
domain controller because it has already cached the
user account credentials. It uses the cached credentials
to grant or deny authentication.
Note: An RODC still performs password validation
forwarding in cases when a user presents a password
that does not match the credentials cached on the RODC.

If the WAN link to a writable domain controller is not available

and the password for a computer account is not cached, a user
in the branch office cannot log on to the computer because the
workstation cannot retrieve the service ticket for that
computer account. If the WAN is offline but the credentials are
cached, authentication can still be granted locally.
DNS servers running Windows Server 2008 (and above: 2008
DNS Server R2, 2012, 2012 R2, etc.) support a new type of zone on RODCs
service called the primary read‐only zone (or branch office zone). The
primary read‐only zone is a full, read‐only copy of the
 application directory partitions used by DNS, including the
domain partition, ForestDNSZones partition, and
DomainDNSZones partition. The primary read‐only zone is
created by the RODC when it is installed.

 Installing DNS on an RODC allows client computers to

query the RODC for name resolution, but DNS on an
RODC does not support dynamic DNS.
 Name Server (NS) resource records for any Active
Directory integrated zone that the RODC hosts are only
referred by the RODC, they are not registered.
 If a DNS client on the RODC wants to update its record
(or if a new client wants to register its record), the
following occurs:
o The RODC refers the client to a writeable DNS
server.
o The client updates the record against the
writeable DNS server.
o The record is replicated from the writeable DNS
server to the RODC.

© Sergey Gorokhod
MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+®
E‐mail: sergey@infosec.co.il
Mob: (+972) 526848757
6.2. RODC Requirements
The following requirements must be met before RODCs are installed in a domain:

 The domain and forest functional level must be at the Windows Server
2003 functional level or higher. The Active Directory functional level must
support:
o Linked‐value replication for reduction of lost updates. This feature
allows you to replicate individual values of a multi‐valued attribute
for a higher level of replication consistency.
o Kerberos constrained delegation. This feature allows you to forward
the computer account credentials or user account credentials to all
or only specific computers in the domain.
 The primary domain controller (PDC) emulator must run Windows Server
2008 (and above: 2008 R2, 2012, 2012 R2, etc.) for the following reasons:
o A PDC emulator running Windows Server 2008/2012/2016 creates a
special KRBTGT account for each read‐only domain controller to
ensure its uniqueness. This account cannot be created with earlier
versions of Windows Server.
o Windows 2008/2012/2016 allows the RODC and the PDC emulator
running Windows Server to share a secure channel during
communication when a password is changed against a read‐only
domain controller. This PDC emulator feature in Windows 2003 or
earlier versions will not recognize the request and the password
change action will fail.
 The RODC cannot be the first domain controller in a domain. To create a
new domain, install AD DS on a writable domain controller, then install the
RODC.

Be aware of the following when deploying an RODC:

 You can reduce Active Directory replication traffic by using RODCs because
RODCs never replicate any changes.
 The Windows Server 2008/2012/2016 writable domain controller with
which the RODC replicates can run either a full installation or a Server Core
installation of Windows Server 2008/2012/2016.
 The Windows Server 2008/2012/2016 writable domain controller does not
have to hold the Primary Domain Controller (PDC) emulator operations
master role.
 RODCs must replicate the domain partition from writable domain
controllers that runs Windows Server 2008/2012/2016 because only a
writable domain controller that runs Windows Server 2008/2012/2016 can
enforce the Password Replication Policy (PRP) for an RODC.
(Note: The RODC can replicate other partitions, including application
directory partitions and global catalog partitions, from any writable domain
controller that runs either Windows Server 2003 or Windows
Server 2008/2012/2016
 Although RODCs are designed to be placed in sites that do not contain any
other domain controllers, an RODC being placed in a site with another
domain controller is still a supported configuration.
 RODCs can only replicate updates of the domain partition from a domain
controller running Windows Server 2008/2012/2016 from the same
domain. Data can be prevented from being replicated to an RODC by
setting a filter and marking it as confidential.
 If an RODC was unable to satisfy a change directly, it will immediately
attempt inbound replication. This happens in the following situations:
o Password changes that are created using the Security Accounts
Manager (SAM) interface rather than the Lightweight Directory
Access Protocol (LDAP).
o DNS updates in which a client attempted to make a DNS update, but
is then referred to DNS server where the updates are registered and
the RODC attempts to recover the changes.
 Consider implementing drive encryption on RODCs to prevent unauthorized
users from breaking Windows file and system protection in the event the
RODC is lost or stolen. Tools such as Windows BitLocker encrypt all user and
system files on an entire volume, including the swap and hibernation files.
 Use the Windows SysKey Utility to additionally secure the RODC by moving
its encryption key off the Windows‐based computer. The SysKey utility can
also be used to configure a start‐up password that must be entered to
decrypt the system key so that Windows can access the RODC.
6.3. RODC Installation
Use the following general steps to install a read‐only domain controller (RODC):

1. Ensure that the forest functional level is Windows Server 2003 or higher.
2. Make sure you have the PDC emulator role running on a Windows Server
2008/2012/2016 system. If necessary, take the necessary steps to prepare
for the installation of a Windows Server 2008 domain controller in your
network (prepare the forest and the domain).
3. Copy the contents of the \sources\adprep folder on the Windows
Server 2008/2012/2016 installation DVD to the schema master. Run the
adprep /rodcprep command before you install the first RODC (you must be
a member of the Enterprise Admins group to run this command). This will
enable the RODC to replicate DNS partitions.
4. Create an RODC account in the Domain Controllers OU. Delegate the
necessary permissions to allow non‐administrative users to perform
administrative tasks on the RODC as part of this step.
5. Install the Active Directory role on the RODC server.
6. Log on as a local administrator to the server that will become the RODC and
run dcpromo /UseExistingAccount:Attach. This starts the Active Directory
Domain Services wizard. After you enter your administrative credentials as
a step in the wizard, the wizard automatically detects the name of the
server and try to match it (attach it to) with the RODC account that you pre‐
created for it. Follow the steps in the wizard to complete the configuration.
To install an RODC on a Server Core installation of Windows Server 2008,
perform an unattended installation using the dcpromo /Unattend
<filename> command.

You should know the following about RODC installation:

 To install an RODC on a full installation of Windows

Server 2008/2012/2016, you must be a member of the Domain Admins
group. To install an RODC on a Server Core installation of Windows
Server 2008/2012/2016, you must be a member of the Domain Admins
group or you must have been delegated the ability to perform the
installation.
  Verify that the server is not joined to the domain before you start the
Active Directory Domain Services wizard.
 The installation source files can be replicated to the RODC from another
domain controller over the network or by using the Install From Media
(IFM) feature. Ntdsutil.exe can be used to create the installation media for
IFM.
o Use the ntsdutil ifm command on a writable domain controller or an
RODC that runs Windows Server 2008/2012/2016 to create
installation media for an RODC.
o Ntsdutil removes cached secrets (such as passwords) from the
installation media.
o Some data will be replicated over the network even if you choose to
install from media.

© Sergey Gorokhod
MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+®
E‐mail: sergey@infosec.co.il
Mob: (+972) 526848757
6.4. Password Replication Policy
A password replication policy determines whether or not an RODC can cache a
password when the RODC receives an authenticated user or computer logon
request. Password replication policies:

 Must be configured on an RODC's writable domain controller replication

partner when the RODC is initially deployed to allow users to be
authenticated locally.
 Act as Access Control Lists (ACLs) for password caching. Users whose
accounts are on the list or who are members of a group on the list can have
their passwords cached on the RODC.
 Lists both the accounts that are permitted to be cached, and the accounts
that are explicitly denied from being cached.
 Make subsequent logons more efficient by allowing user and computer
credentials to be cached.

Windows Server 2008/2012/2016 Active Directory provides two new built‐in

groups to support password replication.

Group Description
This group is added to the Allowed List of each new RODC;
Allowed RODC
however, by default, it does not contain any members. The
Password
result of this is that new RODCs do not cache user
Replication Group
credentials.
This group is added to the Denied List of each new RODC,
and by default, it contains the following members:

 Enterprise Domain Controllers

Denied RODC  Enterprise Read‐Only Domain Controllers
Password
 Group Policy Creator Owners
Replication Group
 Domain Admins
 Cert Publishers
 Enterprise Admins
 Schema Admins
  Domain‐wide krbtgt account

You should remember the following about password replication policies:

 By default, users or groups added to the Allowed RODC Password

Replication Group and Denied RODC Password Replication Group have their
passwords cached or denied on all domain RODCs. You can easily allow
password caching on all RODCs by adding a user or a group to the Allowed
group.
 To allow individual RODCs to cache user and computer credentials in
specific locations, configure the Allowed and Denied Lists on the Password
Replication Policy tab for the properties of each individual RODC account in
the Domain Controllers OU. For example, instead of adding the users at the
branch location to the Allowed RODC Password Replication Group, create a
specific group for those users and add the group to the Password
Replication Policy list for the appropriate RODC with the Allowed setting.
 All passwords for all users and computers whose passwords are cached on
an RODC should be reset if an RODC is stolen.
 To allow logon when a writable domain controller is unavailable, you must
cache both the user and the computer account passwords.
 By default, credentials are cached only when the user or computer
attempts to log on. If you want to allow logon when the writable domain
controller can't be contacted, users and computers must log on at least
once when the writable domain controller is available. Alternatively, you
can prepopulate the RODC with the user and computer passwords. This
caches the passwords for all allowed users and computers without a logon.
 Because RODCs for the same domain in the same site cannot share cached
credentials, having two RODCs in the same site can lead to inconsistent
logon experiences for users if the WAN to the hub site is offline. Users may
be allowed or denied logon depending on the RODC and where their
credentials are cached.

In general, there are three administrative models to manage password replication

policies:
Model Description
With the no accounts cached model, password caching is disabled,
except for the RODC computer account and its special krbtgt
account.

 This model provides the greatest security because no

passwords are replicated to the RODC.
No
 To allow logon, contact with a writeable domain controller is
accounts
required. Because of how the RODC is typically deployed, this
cached
means that the writeable domain controller will typically be
in another site, separated by a WAN link.
 If the WAN link is down, users will be unable to log on. For
this reason, implement this model only if the branch site is
connected to the main site with reliable WAN links.

With the most accounts cached model, you add users and groups to
the Allowed or Denied RODC Password Replication Groups.
Password caching for all RODCs uses the same configuration.

Most  This model poses some security risk because passwords are
accounts replicated to the RODCs, so it is most appropriate when the
cached physical security of the RODCs is not in question.
 Password management is facilitated because most users can
have their passwords cached on demand.
 Users can have offline access through this model.

With the few accounts cached model you manually configure

password caching on each RODC based on the users within a site.
Few Caching on each RODC is allowed only for users within the site.
accounts
 This model provides the benefit of ensuring security of
cached
passwords by restricting the number of passwords replicated
to the RODC and enabling offline access for users whose
passwords are cached.
  The administrative overhead of this model is greater because
administrators must manually add users (or preferably
groups) to the Allowed List.

© Sergey Gorokhod
MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+®
E‐mail: sergey@infosec.co.il
Mob: (+972) 526848757
6.5. Administrative Role Separation
With administrative role separation, you can grant non‐administrative domain
users the right to log on to a RODC, allowing them to perform local administrative
tasks such as installing drivers or security updates.

Configuring Administrator Role Separation requires you to be a member of the

Domain Admins group. You can configure role separation using one of the
following methods:

 When you create the RODC account, specify the user or group who can
manage the RODC.
 Edit the RODC account and modify the setting on the Managed by tab.
 From the command prompt on the RODC,
1. Run the dsmgmt.exe command.
2. Enter local roles. (You can list valid parameters at this point by
entering ?.)
3. Enter add <domain>\<user> <administrative role>.

© Sergey Gorokhod
MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+®
E‐mail: sergey@infosec.co.il
Mob: (+972) 526848757
6.6. RODC Removal
If the security of a RODC has been compromised, for example if the system has
been hacked or stolen, it is possible that passwords cached on the RODC could be
retrieved. To protect user passwords in the event of a security breach, delete the
RODC computer account in Active Directory. When you delete the computer
account, you are given the following choices:

 Reset user account passwords cached on the RODC. When this option is
chosen, the following process must be followed to re‐allow user logon:
1. An administrator must manually reset the password to a known
value. A common practice is to require the user to change the
password at the next logon.
2. The new password must be given to the user. Following logon, users
change the password to a value they choose.
 Reset computer account passwords cached on the RODC. This option
disjoins the computer from the domain. Computers must be rejoined to the
domain.
 Export a list of accounts that were cached on the RODC. Using the file, you
can get a list of accounts whose passwords were cached. You would then
need to manually reset the passwords on those accounts or rejoin the
domain for computer accounts.

© Sergey Gorokhod
MCT/MCSE/MCITP/MCTS/MCSA/CCSE/CCSA/CCNA/A+®
E‐mail: sergey@infosec.co.il
Mob: (+972) 526848757