Read-Only Domain Controller

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.

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 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.

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.

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 \ .

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.