Now for the topic that you all have been waiting for. Building an RODC! Read only domain controllers are another one of those awesome additions to Server 2008. An RODC holds read only copies of parts of your AD. They’re ideal for branch offices or even your DMZ where you need heightened security but also still need access to your AD as well. RODCs don’t contain a copy of your credentials but only caches those that you set as per policy. In cases of customized AD-integrated applications you can also mark certain attributes in your AD as filtered. Filtered attributes do not replicate to an RODC, so if the RODC is ever compromised the attacker will not gain this critical information. Furthermore any changes made on an RODC do not replicate back out. If for instance someone makes some changes to the SYSVOL folder, those changes will not replicate out to all the other DCs in the forest. It will make that SYSVOL out of sync with the rest of the forest though and could cause some Group Policy idiosyncrasies. If you are using DFS replication for SYSVOL though this problem is fixed automatically. Later I may talk about how to enable DFS-R.
As a side note, anyone running VirtualBox under Linux and has switched to the newly released 2.6.29 kernel may be having a bit of trouble with their VB installation. If you are receiving an error message like this when starting a VM:
Failed to load VMMR0.r0 (VERR_SYMBOL_NOT_FOUND).
Unknown error creating VM (VERR_SYMBOL_NOT_FOUND).
Then you are in need of editing the vboxdrv Makefile. You should find this in /usr/src/vboxdrv-2.1.4/Makefile. You might need to tweak the version number depending upon your installed version. Uncomment the line # VBOX_USE_INSERT_PAGE = 1. Re-run your /etc/init.d/vboxdrv setup command under your root account (or just use sudo) and you should be good to go. More information about this is available here.
Let’s get a new VM created that we will be purposing for our RODC. Get it installed and joined to the domain, but we’ll be building a different answer file for the dcpromo. One important thing to remember by the way, for practical as well as testing purposes, is that to install an RODC requires a minimum forest functional level of Server 2003. Also for testing and practical purposes remember you only need one DC in your domain running Server 2008. No need to migrate over all your DCs yet. You also have to prep your forest. Login as an Enterprise Admin on your schema master, mount your Server 2008 DVD, and run:
D:\>xcopy /E D:\sources\adprep C:\adprep
This copies over adprep files and then preps the forest DNS partitions for replication to an RODC. Now to set up your answer file:
You will also want to specify ReplicationSourceDC= if you have Server 2003 DCs and need to point to your Server 2008 DC. You can also specify PasswordReplicationDenied to deny any additional users/groups replication to this RODC. Once you have your file created run the dcpromo as normal.
Upon success restart your RODC. If you have your site set up properly they should now be able to log into their systems with authentication through the RODC. Now to do some delving into management of your RODC specifically dealing with the Password Replication Policy (PRP). This is what defines what credentials will be cached and what will never be cached. What happens in the case of a denied password caching the RODC forwards the request on up the WAN to a writable DC for authentication. To view what is currently set for your RODC run:
C:\>repadmin /prp view JenovaCoreRODC allow
C:\>repadmin /prp view JenovaCoreRODC deny
This will show you what is currently allowed and denied for the RODC you have specified.
C:\>repadmin /prp view JenovaCoreRODC auth2
From this you will view all accounts that have been authenticated by this RODC. Finally to know what credentials have been cached by the RODC run:
C:\>repadmin /prp view JenovaCoreRODC reveal
It is important to know what credentials have been cached in case of the RODC being compromised. Now if you are wanting to update the list of what accounts you wish to allow caching for then run:
C:\>repadmin /prp add JenovaCoreRODC allow “CN=Lab Guests,OU=Lab Users,DC=shinra,DC=inc”
This uses the LDAP DN to the account or group that you wish to allow caching for. Something to remember is that an account won’t actually be cached until they have logged in authenticating to that RODC. You can pre-populate credentials via this command:
C:\>repadmin /rodcpwdrepl JenovaCoreRODC CloudCore “CN=Jeffery Land,OU=Lab Users,DC=shinra,DC=inc” “CN=Jeffery Land2,OU=Lab Users,DC=shinra,DC=inc”
You can specify as many users as you would like separated by a space. You will have to specify user accounts and not groups though. Most likely you would want to script this if you’re pre-populating an RODC for a site with limited/sporadic WAN connectivity. Remember that you not only want to allow caching for user accounts but also for any computer and service accounts that require authentication. Otherwise the RODC will attempt to forward the authentication on up and if the WAN is down it will fail due to not having a cached account. You are best off first working with an RODC in a lab environment prior to deployment so that you have worked through all such issues that could arise. Also if an account is both in the allowed and denied lists the account will be denied caching as deny takes precedence.
This should get you up to speed on RODC installation and management. Here is some reading for you to more thoroughly understand RODC implementation and management.