|Laura E. Hunter|
One way in which the RODC improves the security of your AD environment is by providing a read-only copy of the Active Directory database. This means that no one -- user or administrator -- can make changes to the Active Directory database from a read-only domain controller.
You can connect to an RODC to read almost all of the same information just as you can from a writeable DC, but you will not be able to perform any write operations without connecting to a writeable DC using Remote Desktop. Or, you could update Active Directory by connecting to a writeable DC using an MMC snap-in, script or command-line tool.
Windows Server 2008 read-only domain controller uses a completely different replication model to help combat this. An RODC will receive changes from writeable Active Directory DCs, but an RODC itself 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.
Passwords protected in branch RODC
In managing remote servers, perhaps the most dangerous aspect of deploying DCs into unsecured locations is the risk that it creates for Active Directory passwords. Because AD domain controllers in Windows 2000 Server and Windows Server 2003 store password information for every user and computer account, your administrators would need to reset every single account password (some more than once!) if a Windows 2000 or Windows 2003 domain controller were compromised or stolen. Many organizations that are unwilling to tolerate the security risk of deploying DCs in remote offices have simply accepted the tradeoff of allowing remote users to authenticate over the WAN. By deploying RODCs to these offices, organizations can improve authentication times for remote users without exposing their organization to the inherent security risk of deploying a writeable domain controller to a potentially unsecured location.
Another security improvement in read-only domain controllers is that when the Active Directory database is replicated down to an RODC from a writeable DC, user account information is replicated without any user's password information. So, that means your servers are far more secure because 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. This further reduces the risks associated with deploying DCs to remote sites, as it minimizes the number of passwords that have the potential to be compromised.
Finally, the RODC allows for "Admin Role Separation." Instead of all of your remote administrators having access to the Active Directory database, the RODC allows you to assign a user local administrator rights to the RODC without configuring that person as a domain administrator. This is something 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. On an RODC, however, Admin Role Separation has the potential to reduce the administrative burden on central administrators by allowing them to delegate basic administrative responsibilities of the RODC to help desk personnel at a remote site. A remote help desk or desktop support person could, for example, perform basic maintenance of an RODC such as stopping and starting services or performing reboots without this person having unwarranted access to Active Directory itself.
It's important to note that the many benefits of deploying an RODC do not come without any operational implications for your Active Directory administrators.
For example, it is a best practice that administrators should never log onto an RODC using elevated credentials such as those of a domain administrator or an enterprise administrator, since that would render much of the security offered by the RODC's password controls moot. This may require additional training for your existing Active Directory administrators, since any administration of an RODC must be done using remote administration methods via the command-line, remote scripts or remote MMC consoles.
Additionally, if your central administrators ever need to log onto the console of an RODC (which should be a rare occurrence -- perhaps during extensive troubleshooting of the operating system), it is imperative that they log on using an administrative account that is local to the RODC only rather than using credentials that possess domain-wide administrative privileges. This will require your AD administrators to manage separate logons or smart cards for each RODC within your environment, which can create some administrative headaches when applied at scale.
One thing is clear about managing the administration of Windows Server 2008 RODCs. It will add some new challenges to managing your IT infrastructure, but the benefits are well worth it if you are charged with maintaining domain controller security and managing and securing remote servers in a decentralized branch office.
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 enterprise networks. Hunter 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 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.
This was first published in July 2007