Windows Server 2008 – Read-Only Domain Controller – Administration and misc.
OK, so now, we have our first Read-Only Domain Controller (RODC) installed: SRO-LH-03.
Let us see what we can do with it .
First, some information that I rate important:
- To implement RODC in your environment you do not need all DCs on Longhorn. You need to have your domain and forest at the Windows Server 2003 mode, and the DC running the PDC-Emulator needs to run on a full version of Longhorn.
- As far as currently known there’s no support for multiple RODCs in a single location (they are unable to replicate between each other, each of them would replicate with the hub office).
Then, let’s connect to SRO-LH-03 (our RODC) and have a look at the ADUC (Active Directory Users and Computers) MMC snap-in. The Active Directory database is read-only. Well, first surprise, even when logged on locally, the snap-in points to SRO-LH-01, which is a writeable domcin controller:
As I really want to open the AD from SRO-LH-03, I forced the snap-in to connect to SRO-LH-03. Very nice, the tool is showing that the server is a RODC (have a look in the DC Type column):
I selected SRO-LH-03 and got the following message popping up, which is fine:
Now the ADUC snap-in shows up and points to SRO-LH-03. If we expand the Domain Controllers container, we can see the three current domain controllers. Again SRO-LH-03 is marked as Read-Only:
To prove that the AD database on SRO-LH-03 is well read-only, I am not event able to create a new user account as the option is not even present. This is the situation when pointing to SRO-LH-03 (RODC):
and when pointing to SRO-LH-01 (writeable DC):
OK, so that was to verify the read-only state of the Active Directory database on SRO-LH-03.
Now, if we look at the properties of the SRO-LH-03 computer object in AD, there is a completely new tab, Password Replication Policy, and an enhanced one, Managed By:
First, the Managed By tab. This is where we can specify which (normally) non-administrative user or group can perform the actual on-site installation of the RODC (see my previous post for some information on the staged installation of the RODC):
Let’s put my regular (= non-admin) account as manager of the SRO-LH-03 RODC:
The tab Password Replication Policy is brand new. It enables the administrators to
- specify the users/groups/computers of which the password may or may not be replicated to the RODC (remember that by default, no password is being cached, the only exception being the computer account of the RODC itself and a special krbtgt account):
- display the list of accounts whose passwords are stored on the in-question RODC (there is even an Export function):
- display the list of accounts that have been authenticated to this RODC (there is also the export functionality):
- prepopulate passwords of certain accounts to the in-question RODC; the idea being that you would pre-cache the password on the RODC of the site where the user belong for instance. Let’s say that I want to pre-populate the password of my regular account to the SRO-LH-03 RODC (of course, my account must be included in the allowed list of passwords that can cached on this RODC):
Now you could ask yourself “What’s behind all these functionalities?”. Well, it is all about SECURITY. Remember that I said that RODC are perfectly suitable for branch deployment. The idea is that the RODC contains a full copy of the Active Directory database but in read only mode. Any write operation will be redirected to a writeable domain controller. So if the security of the server in the branch is compromised, it will not jeopardize the whole corporate AD.
Now even if the RODC would be hacked somehow, and if defined so (remember that by default, there is no password caching at all – you have to explicitly turn it on and specify for which accounts), it would only contain the password of the accounts of this site and not the passwords of all the accounts and certainly not the password of the administrative accounts, as these are excluded from password-caching. Should the RODC be tampered with, then you could easily retrieve the list of users for which the password was cached on this particular system (see above) and simply reset the password.
Having dealt with a largely-distributed domain controller base in the past, I am really excited by this RODC feature as it could have solved a lot of my nightmares.