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.

Steve

Windows Server 2008 – Read-Only Domain Controller – Installation

In this post, we will see how to install a replica read-only domain controller to an existing Active Directory domain.

You will see that from an installation perpective, the process does not differ much from a standard domain controller installation.

The name of the domain is still SRO-LH.local.

I have installed a new server, SRO-LH-03 and run the command dcpromo.exe.

The first thing the process does is to check whether the ADDS binaries are installed on the server:

As this is is a brand new system, neither the ADDS role not the binaries are installed. So, this is taken care of:

Welcome screen of the ADDS Installation Wizard:

Yes, we want to add a new domain controller to an existing domain:

We have to specify the name of the domain in which we want to install the additional domain controller:

At this moment in time, I am logged on as a local administrator of the server and have therefore no right to perform the ADDS installation. For this reason, I specify some alternate credentials, i.e. the domain’s administrator credentials, by clicking on the Set… button:

 

Confirmation:

Then, we need to confirm the domain for this additional domain controller:

We also need to define in which Active Directory site the new domain controller will be put:

On this page, we explicitly specify that we want to make the server a RODC:

As per Microsoft Technet article, you can perform an installation of an RODC in which the installation is completed in two stages by different individuals.

1. The first stage of the installation, which requires domain administrative credentials, creates an account for the RODC in AD DS.
2. The second stage of the installation attaches the actual server that will be the RODC in a remote location, such as a branch office, to the account that was previously created for it. You can delegate the ability to attach the server to a nonadministrative group or user, which is a feature I find pretty neat from the deployment perspective.

During this first stage, the wizard records all data about the RODC that will be stored in the distributed Active Directory database, such as its domain controller account name and the site in which it will be placed. This stage must be performed by a member of the Domain Admins group. The administrator who creates the RODC account can also specify at that time which users or groups can complete the next stage of the installation.

The next stage of the installation can be performed in the branch office by any user or group who was delegated the right to complete the installation when the account was created. This stage does not require any membership in built-in groups, such as the Domain Admins group. If the user who creates the RODC account does not specify any delegate to complete the installation (and administer the RODC), only a member of the Domain Admins or Enterprise Admins groups can complete the installation.

During the second stage, the wizard installs AD DS on the server that will become the RODC and attaches the server to the domain account that was previously created for it. This stage typically occurs in the branch office where the RODC is deployed. During this stage, all AD DS data that resides locally, such as the database, log files, and so on, is created on the RODC itself.

At this point of the installation process, we can specify any group or user who will later be able to install and manage the RODC. As we are not in such deployment scenario, we leave the field empty:

The next step is about specifying the folders for the AD database, the log files and the SYStem VOLume:

 

Then, we specify the Directory Services Restore Mode (DSRM) password for the Domain Controller:

The wizard offers to review all the options selected and even provides a way to export the settings to an answer file for future re-use:

Finally, the actual installation and replication process starts. You also have the possibility to decide whether you want the server to reboot automatically at the end:

This concludes the installation of the RODC in itself.

Steve

iPhone Review by Engadget

As you might know, I am also an Apple-freak.

I have been reading a lot of reviews about Apple’s iPhone. But the one I liked the most for its completeness is to be found on Engadget.

Steve