The read-only domain controllers (RODCs) are a great feature introduced with Windows Server 2008 in order to maintain a low-risk domain controller in locations where it cannot guarantee physical security and the maintenance. Throughout the chapter we have discussed possible scenarios where we required a domain controller in a remote site. When considering a domain controller in a remote site, the link between sites is not the only thing we need to focus on. When we deploy a domain controller, by default, it will be aware of any changes in the Active Directory structure. Once an update triggers, it updates its own copy of the Active Directory database. This ntds.dit file contains everything about the Active Directory infrastructure, including the identity data of the user objects. If it falls into wrong hands, they can retrieve data related to identities and compromise the identity infrastructure.

When considering information security, the physical security is also important. That's why the data centers have all sorts of security standards. So, when deploying a domain controller in a remote site, physical security is also consideration as we do not want to have loose ends. If you have a requirement for domain controller in a remote site and yet you cannot confirm its security, then RODC is the answer. RODC does not store any password in its database. All the authentication requests against an object will be processed by the closest writable domain controller. So, if people manage to get copy of the database, they will not be able to do much.

Other advantages of RODC include its one-way replication. When considering remote sites, you also need to consider how they will be maintained. Every organization cannot maintain IT teams for remote offices. Most of the maintenance tasks still can be carried out remotely, but there are certain situations where you will need to delegate some permissions to persons in remote sites. Most of the time, these people can be less experienced on IT. So, a simple mistake made by them can replicate to other domain controllers and make a mess. RODC's one-way replication will prevent this and no change will be replicated over to other domain controllers. Nice, huh?

By default, RODC does not save any passwords (except RODC objects) for Active Directory objects. Every time when authentication happens, it will need to retrieve the data from the closest domain controller. Using Password Replication Policy (PRP), we can allow certain passwords for objects to be cached. In that case, if the connection between a remote site and the closest domain controller is interrupted, RODC will be able to process the request. One thing to remember is, in order to process Kerberos request, it needs to cache the password for the user object as well as the computer object.

RODC deployment process involves the following stages. In this process, we can use a preselected account and promote the RODC using it instead of using a Domain Admin or an Enterprise Admin account:

1. Set up computer account for RODC domain controller.
2. Attach that account to the RODC during the promo process.

In order to create a RODC computer account, we can use the Add-ADDSReadOnlyDomainControllerAccount cmdlet:

Add-ADDSReadOnlyDomainControllerAccount -DomainControllerAccountName REBEL-RODC-01 -DomainName rebeladmin.com -DelegatedAdministratorAccountName "rebeladmindfrancis" -SiteName LondonSite

The preceding command will create the RODC domain controller account for REBEL-RODC-01. The domain name is defined using -DomainName, and -DelegatedAdministratorAccountName defines which account to delegate the RODC installation. The new RODC will be placed in LondonSite:

Now, we can see the newly added object under the Active Directory domain controllers:

Now, we have things ready for the new RODC and the next step is to promote it:

Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools

The preceding command will install the AD DS role in the RODC. Once it's completed, we can promote it using the following command:

Import-Module ADDSDeployment 
Install-ADDSDomainController ` 
-Credential (Get-Credential) ` 
-CriticalReplicationOnly:$false ` 
-DatabasePath "C:WindowsNTDS" ` 
-DomainName "rebeladmin.com" ` 
-LogPath "C:WindowsNTDS" `
-ReplicationSourceDC "REBEL-PDC-01.rebeladmin.com" `
-SYSVOLPath "C:WindowsSYSVOL" ` 
-UseExistingAccount:$true ` 
-Norebootoncompletion:$false 
-Force:$true

Once this is executed, it will prompt for the user account, and we need to input user account information, which was delegated for RODC deployment. The command is very similar to a regular domain promotion.

Now, we have the RODC and next steps to look in to PRPs.

The default policy is already in place, and we can view the allowed and denied lists using the following command:

Get-ADDomainControllerPasswordReplicationPolicy -Identity REBEL-RODC-01 -Allowed

The preceding command will list the allowed objects for password caching. By default, a security group called Allowed RODC Password Replication Group is allowed for the replication. This doesn't contain any members by default. If we need caching, we can add object to the given group:

Get-ADDomainControllerPasswordReplicationPolicy -Identity REBEL-RODC-01 -Denied

The preceding command lists the denied objects for password caching. By default, following security groups are in the denied list:

• Denied RODC Password Replication Group
• Account Operators
• Server Operators
• Backup Operators
• Administrators

These are high privileged accounts in the Active Directory infrastructure; these should not be cached at all. By adding objects to Denied RODC Password Replication Group, we can simply block the replication.

Apart from the use of predefined security groups, we can add objects to allow and denied list using the Add-ADDomainControllerPasswordReplicationPolicy cmdlet:

Add-ADDomainControllerPasswordReplicationPolicy -Identity REBEL-RODC-01 -AllowedList "user1"

The preceding command will add the user object user1 to the allowed list as shown in the following screenshot:

The following command will add the user object named user2 to the denied list:

Add-ADDomainControllerPasswordReplicationPolicy -Identity REBEL-RODC-01 -DeniedList "user2"

The following screenshot illustrates the preceding command: