Getty Images/iStockphoto
Deploy a read-only domain controller for security, speed
A read-only domain controller requires a fair amount of work for a proper deployment, but it can be a great option for quicker logins for users in branch offices.
It's safe to say Active Directory is the keystone for most enterprises due to its centralized management role, but there are times when certain components require unconventional configurations.
Active Directory handles identity and access management for many organizations, and a core component of the platform is the domain controller, which has a number of jobs, including handling user authentication and replicating data to other domain controllers to maintain consistency. But there are scenarios that would benefit from a read-only domain controller, such as when physical security or network speed is a concern. This article will explain how read-only domain controllers work, what is required to deploy them, and how to maintain and manage them to avoid disruptions.
When to use a read-only domain controller
Active Directory (AD) uses a standard multimaster replication design. This means administrators can add, modify or remove AD objects from any domain controller and the changes will replicate to the other domain controllers. In addition, each domain controller has a complete copy of the entire AD database, including all user and computer accounts. By extension, a domain controller with a writeable copy of AD may be placed at an insecure location. Furthermore, the site may be remote, forcing authentication over a WAN. This scenario isn't ideal.
It's reasonable to assume the remote site probably has no AD administrators who need read and write access to AD. The only AD changes that would originate from the site are password updates on standard user accounts.
There are two concerns in these environments:
- Physical security of a writeable domain controller cannot be guaranteed.
- Authentication over a slow WAN connection leads to logon errors.
Microsoft introduced read-only domain controllers with Windows Server 2008, yet many AD administrators might be unfamiliar with how and when to use them. Read-only domain controllers have no writeable copy of the AD database; in fact, they may not even have a complete copy of the database. These domain controllers are tuned for the challenges of remote and less secure environments.
Read-only domain controllers don't participate in AD replication the same way as regular domain controllers. Replication only goes one way from the writeable domain controllers to the read-only domain controller. In addition, administrators may configure the read-only domain controller to store only specific user and computer accounts. If there are only 30 users at the remote location, then the read-only domain controller caches these accounts. If a user tries to log on with an account that is not cached, the authentication attempt goes across the WAN.
Experienced AD administrators might wonder how using a read-only domain controller affects the integration of the DNS and AD databases. Read-only domain controllers maintain a read-only copy of the DNS database to let clients at the remote site resolve names quickly. This copy of DNS does not accept client registrations or updates; those go to the nearest writeable DNS server.
Another interesting read-only domain controller characteristic is administrator role separation. On a normal domain controller, one must have domain privileges to log on to the server and conduct general administrative tasks. Read-only domain controllers allow anyone with the logon privilege to sign on and run certain administrative tasks, such as updating drivers, applying Windows updates and performing backups. However, they cannot manage AD. For a small branch office, the read-only domain controller could act as a file or print server with a local administrator who is not an AD expert.
What are the reasons to use a read-only domain controller?
Not every AD environment needs read-only domain controllers, especially with today's improving WAN connections and cloud-based authentication security. Read-only domain controllers help in the following circumstances:
- Remote office with poor security, where a writeable copy of the AD database can be a liability.
- Remote office with a poor or inconsistent WAN connection, where local user authentication is useful for the employees based there.
- Remote office with a poor or inconsistent WAN connection, where typical AD replication would unnecessarily congest the connection.
There's more to a read-only domain controller than just the read-only state of the AD database. AD administrators use password replication policies to specify the accounts that can -- and cannot -- replicate to or be cached on the read-only domain controller.
Two default groups exist to manage account replication:
- Allowed RODC Password Replication Group.
- Denied RODC Password Replication Group.
By default, there are no members of the allowed group. The denied group contains AD admin accounts and groups. Administrators explicitly manage the membership of the allowed group by including the users who work at the remote office.
The read-only domain controllers also receive a copy of the SYSVOL folder, which contains Group Policy Objects (GPOs) AD administrators use to manage system configurations. The replication is one-way; no writeable copy of the GPOs exists on the read-only domain controller that might replicate back into the rest of the AD topology.
For example, suppose your environment includes three remote offices that warrant read-only domain controllers. After adding the read-only domain controllers to the infrastructure, you would explicitly add the users from each remote office to the read-only domain controller housed at that location. The lists would not replicate among the read-only domain controllers.
What are the read-only domain controller prerequisites?
The prerequisites for read-only domain controllers were a consideration when Microsoft introduced the feature with Windows Server 2008. Today, most AD environments will easily hit the mark. Here are the requirements and recommendations:
- Forest functional level: Server 2003 or higher but Server 2008 or later is recommended.
- Domain functional level: Server 2003 or higher.
- At least one writeable Windows Server 2008 domain controller in the AD topology.
- A writeable Windows Server 2008 domain controller should be the read-only domain controller's replication partner.
- Only deploy one read-only domain controller per AD site.
Determine if your replication topology (WAN links) and security requirements justify read-only domain controllers. Fast networks with secure remote offices should use traditional domain controllers.
How to deploy a read-only domain controller
Deploying a read-only domain controller will require creating a new domain controller. Much of the configuration is the same as a typical domain controller, but there isn't as much post-installation work.
Begin by installing your organization's chosen Windows Server edition and apply any updates. Next, promote the server to a read-only domain controller using the following steps.
Add the Active Directory Domain Services role using Server Manager.
In the Notifications area, under Post-deployment Configuration, select Promote this server to a domain controller.
When the Active Directory Domain Services Configuration wizard opens, select the radio button for Add a domain controller to an existing domain. Specify the domain name and credentials. Select Next.
When the Domain controller Options page appears, select the check boxes for Domain Name System (DNS) server, Global Catalog (GC) and Read-only domain controller (RODC). Set the Directory Services Restore Mode (DSRM) password and select Next.
When the read-only domain controller Options page opens, delegate local administrative control of the read-only domain controller and configure which users and groups can replicate to the read-only domain controller. You can also configure the accounts and groups after you build the read-only domain controller. Select Next when complete.
The remaining steps are the same as a traditional domain controller deployment. Specify an existing domain controller to replicate the AD database from, then define storage locations for the database folder, log files folder and SYSVOL folder. Select Next.
The Review Options page appears. Confirm the settings are correct, then select Next.
The system checks prerequisites, and then you can select Install. The installation process varies based on network speed and the size of the AD database.
The read-only domain controller's computer account moves to the Domain Controllers organizational unit.
What are the post-deployment configuration tasks?
There's little to set up after deploying a read-only domain controller. The primary management task is defining the credentials of the users and groups to cache in the read-only domain controller. Some documentation recommends adding existing AD groups, but I suggest you create a global group for each location and add the user accounts for the employees who work at those offices for better optimization and security.
Create a global group for the remote location
Open AD Users and Computers, select the appropriate organizational unit and create a new global group. To simplify matters, use the name of the remote location for the global group.
Add users to the global group
In the global group's Properties, select the Members tab and add the user accounts for remote-site employees. Any user whose credentials are not cached on the read-only domain controller will authenticate over the WAN, so there should not be any login problems if the person's credentials are not cached. The purpose of the read-only domain controller is efficient authentication for those who rely on it the most.
Configure cache settings
Next, find the read-only domain controller computer object in Active Directory Users and Computers, select its Properties, and find the Password Replication Policy tab. Nest the global group you created above to the Allowed read-only domain controller Password Replication Group. As users authenticate against the read-only domain controller, the system will cache their credentials.
There is a Denied read-only domain controller Password Replication Group in which you add users or groups to block credential caching. They can still authenticate, but this happens across the WAN. Configure this for administrative accounts.
There is the option to precache user accounts from the Advanced button to speed up the first authentication of a user from the remote site.
What are the benefits of a read-only domain controller?
There are few negative aspects to deploying read-only domain controllers, but they should only be configured at sites that meet the criteria. Read-only domain controllers offer lots of advantages in certain situations:
- Prevents malicious users at the remote site from making changes to AD if they get access to the read-only domain controller.
- Decreases AD replication traffic over a slow WAN connection.
- Simplifies the AD replication topology.
- Allows domain controller and DNS services to operate near the users in situations that would normally be difficult or inefficient.
- Users benefit from nearby domain controller and DNS services for quicker response related to logons, name resolution and Group Policy.
What are the disadvantages of a read-only domain controller?
While users at branch offices can benefit from a read-only domain controller, administrators need to be aware of some of the drawbacks:
- Limited AD administration at the remote site.
- Added cost for the business.
- Potential problems for application or service used at the remote site that requires a writeable domain controller.
- A poor connection from the read-only domain controller to a traditional domain controller could make authentication requests slow.
- Setup work in AD and caching user credentials requires setup work for administrators, which can be time-consuming.
- Guest users who don't frequent the remote site might have longer logons.
Is a read-only domain controller right for you?
Read-only domain controller deployments are straightforward, as are the account caching configurations. Long-term management is equally light. The technical requirements should no longer be a factor for most organizations. Evaluate your AD environment today to see whether read-only domain controllers have a place in your organization.
Damon Garn owns Cogspinner Coaction and provides freelance IT writing and editing services. He has written multiple CompTIA study guides, including the Linux+, Cloud Essentials+ and Server+ guides, and contributes extensively to TechTarget Editorial, The New Stack and CompTIA Blogs.
