Read-Only Domain Controller (RODC) – Best Practices for AD Administration. Part 2
Note: this post has been originally published on Veeam Blog
Read the full series:
Ch.1 – Protecting the Active Directory Domain Services
Ch.2 – Read-Only Domain Controller (RODC)
Ch.3 – Recovering the Active Directory Domain Services
Introduction
In Part 1, Protecting the Active Directory Domain Services – Best Practices for AD administration, I focused on protection steps to protect your domain service locally. Unfortunately, most environments have multiple locations, otherwise known as ROBOs (Remote Office Branch Offices). Examples include remote, colocation and cloud data centers, retail stores, satellite offices, distribution centers, manufacturing plants and more. These locations are often geographically separated by many hundreds or thousands of miles, require only simple file, print and share services and are often without an IT staff. Server virtualization has drastically improved the way these services are deployed. However, remote management, operation and maintenance of these services remains a challenge for IT organizations. Most of all, IT needs to ensure that the authentication processes, DNS (domain name system) lookups and applications function as well remotely as they do at the organization’s headquarters.
The challenge
Traditional, old-school, writable domain controllers are deployed at ROBO sites so IT admin can resolve application performance. See Figure 1. This practice prevents authentication traffic from traversing the WAN (wide area network) and delays in response times. As a result, things look and feel just like the customer is seated at the main headquarters location. Unfortunately, this practice creates huge security vulnerabilities! Imagine if an unwanted, mischievous user gains physical or virtual access to the network, bidirectional replication would allow this guest to make changes that could severely impact the ENTIRE AD (active directory) forest.
There are things that can be done to mitigate this risk such as delegated security, limitations on which user accounts have access to elevated groups and replication lag sites. As a best practice, it is imperative that you complete daily backups of your AD domain controllers. Veeam® Explorer™ for Active Directory makes it very simple to mount the ntds.dit, or AD database, and restore individual objects, attributes and even tombstoned items. It’s also important to test your restore processes frequently!
Figure 1: Traditional domain controller deployment
The resolution
In Windows Server 2008, Microsoft introduced the concept of a Read-Only Domain Controller (RODC), this allows IT to deploy AD Domain Services remotely at branch offices, without having the security worries that traditional writable domain controllers present. See Figure 2. RODCs offer inbound, *unidirectional replication and maintain a local read-only copy of all AD data and the SYSVOL folder. This benefits IT greatly because:
- It mitigates and helps remove replication concerns if a mischievous guest user gains physical or virtual access to the infrastructure
- It prevents accidental deletion of AD objects and/or the SYSVOL by admin within the branch office
- It prevents rogue applications, such as a virus, malware, spyware, from making changes to the AD schema.
*For more on Read-Only domain controllers, unidirectional replication and their benefits, visit: Microsoft TechNet. Figure 2: Read-Only Domain Controller deployment.
Windows Server 2012 and higher versions simplify the deployment process by leveraging Server Manager instead of the deprecated DCPromo utility. After installing the basic AD domain services, you will immediately be prompted to take additional steps if you require the server (a VM) to become a domain controller. See Figure 3.Figure 3: Server Manager Feature Wizard
Once you click Promote this server to a domain controller and choose Add to an existing forest, you’ll check the checkbox called Read only domain controller (RODC) to promote the DC to a RODC (Figure 4). Figure 4: Active Directory Domain Service Configuration Wizard
Once you go through the remaining steps, you will end-up with a secure and functional RODC! For years, protection of domain assets at an environment’s perimeter has been a challenge faced by IT pros. RODCs can be a great addition to an infrastructure to solve perimeter security concerns, while also adding functionality and mitigating risk. Pairing secure local protection policies with functionality that RODCs provide will ensure that an environment runs at the highest availability levels, with security every day, 365 days a year. In Part 3, my next blogpost, I will discuss individual domain controller protection, individual object restoration and testing of your DC backups!
Read the next chapter: