|Laura E. Hunter|
Recently I had the good fortune to spend the week at Microsoft's Tech Ed 2007 conference, staffing a booth to help answer customer questions about both old and new Active Directory technologies. Unsurprisingly, many of the questions we fielded during the week revolved around the new Active Directory technologies forthcoming in Windows Server 2008.
One topic that seemed to be on everyone's mind in Orlando was the read-only domain controller (RODC). What is it? What does it do? How do you set it up? Is it really just an NT4 BDC all over again? While we could spend hours discussing all of the technical details of the RODC, the key points to be familiar with are as follows:
RODC is read-only. As the name implies, the copy of the NTDS.DIT file that resides on an RODC is read-only. That is, you can't make any changes to the Active Directory database from a read-only domain controller. You can connect to an RODC to read any information you like (with a few exceptions, which we'll get to in a moment), but you will not be able to perform any write operations without connecting to or being referred to a writeable domain controller.
RODC does not perform any outbound replication. This is a fundamental change from the typical multi-master replication model that we've all become familiar with in Active Directory. In Windows 2000 Server and Windows Server 2003, an administrator can connect to any domain controller to make a change, and that change will be replicated out to the rest of Active Directory via outbound replication from the DC that the change originated from. This is not so with the RODC.
The read-only domain controller will receive inbound replication from other writeable Windows Server 2008 DCs, but it will not replicate any information whatsoever out to other DCs. This creates an additional layer of security such that, even if a malicious user were somehow able to modify the Active Directory database on an RODC, those modifications would not propagate out to the rest of the domain and forest.
No passwords stored locally by default. This is probably the one killer feature that will silence the naysayers who feel that the read-only domain controller is just a re-invented NT4 backup domain controller. This functionality is something we've never seen before in the Windows Server world. When the Active Directory database is replicated down to an RODC from a writeable DC, user account information is replicated down without the user's password information. This means that out-of-the-box, an RODC does not contain any password information whatsoever from within Active Directory. By default, the RODC will only store the password of its local administrator and krbtgt accounts, both of which are local to a single RODC only, and it cannot be used to access any other machines on the network.
To improve performance in a branch office environment, you can configure a list of users and groups whose passwords are permitted to be replicated either:
- to a single RODC only, or
- to all RODCs within a domain.
So if you have a branch office containing 20 user accounts who frequently log onto the single RODC in their location but who do not travel to other offices, you might allow those users' passwords to be stored on that RODC only. If, on the other hand, you have a group of traveling auditors who need to log onto numerous branch offices in various locations, you might allow these users' passwords to be stored on every RODC in the domain.
Conversely, you can configure any number of users or groups whose passwords are never permitted to be stored on a single RODC or that are never permitted to be stored on any RODC in the domain. By default, high-security group objects, like Domain Admins, Enterprise Admins and Schema Admins, are configured to never allow their passwords to be stored on an RODC. In fact, our friends in Redmond recommend as a best practice that you never log onto an RODC using elevated credentials such as those of a DA or an EA, since that would render much of the security offered by these password controls moot.
RODC allows for "Admin Role Separation." Because of the other security controls that are in place on an RODC -- particularly maintaining a read-only copy of the Active Directory database and allowing no outbound replication -- the RODC allows you to assign a user local administrator rights to the RODC without configuring that person as a Domain Admin. In this respect, Active Directory views the RODC as just another member server containing its own local Security Accounts Manager (SAM) database. You can configure the SAM on an RODC without necessarily conferring rights to the Active Directory database itself.
It's important to note that this is something that you can only configure on an RODC. As on a fully-writeable DC, there's still no distinction between the local administrator on the server and having administrative rights to Active Directory. Additionally, it's also critical to remember that you are still conferring local rights to the RODC, which effectively makes the person whom you're assigning these rights to all-powerful. Because of this, Admin Role Separation is largely designed to protect your Active Directory against hearing the word "Oops!" from a well-meaning (but lesser-skilled) branch office admin, not necessarily providing 100% security against a determined and malicious attacker.
In our next installment, we'll delve further into the world of the read-only domain controller, including some points to consider when you're getting ready to deploy RODCs on your production network.
Laura E. Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is an Active Directory Architect for a major engineering and staffing firm where she provides Active Directory planning, implementation and troubleshooting services for business units and schools across an enterprise network. Laura is a four-time recipient of the prestigious Microsoft "Most Valuable Professional" award in the area of Windows Server-Networking. She is the author of the Active Directory Field Guide (APress Publishing) as well as co-author of the Active Directory Cookbook, Second Edition(O'Reilly). You can contact her at firstname.lastname@example.org.