This is the last post I’m intending to write based on the content from the recent Windows Server UK User Group meeting – this time inspired by Scotty Mc Leod‘s presentation on read only domain controllers (RODCs), a new feature in Windows Server 2008.

In my post from a few weeks back about some of the new features in Windows Server 2008, I wrote:

Backup domain controllers (BDCs) are back! Except that now they are called read-only domain controllers (with unidirectional replication to offer credential caching and whilst increasing the physical security of remote domain controllers, e.g. in branch offices).

That statement was slightly tongue-in-cheek and, if taken literally would be inaccurate. RODCs are more complex than Windows NT BDCs were. Active Directory still uses a multiple master replication model, but RODCs are really a means of providing a read-only replica of the directory (with outbound replication disabled) – for example at remote sites where to have a fully-functional domain controller would be a security risk. As far as Active Directory is concerned, an RODC is not a domain controller – it actually has a standard workstation account (with some extra attributes).

This has a major advantage in that, unlike a domain controller, an RODC has a local account database, with a local Administrators group (of which Domain Admins will be a member). In effect, this means that a user can be made a full administrator of the RODC, without needing to be a Domain Admin.

In order to create an RODC, the forest and domain need to be at Windows Server 2003 forest functional level with at least one (preferably more) Windows Server 2008 DC present. The forest and domain must also have been prepared for RODCs with adprep /rodc.

The next stage is to provision the computer account, selecting a site, and whether or not DNS/Global Catalog services will be enabled). Control over the information stored on an RODC is controlled with password replications policies – allow/deny lists for replication of passwords based on users, groups or computers. 2 new groups are created – DeniedRODCPassword and AllowsRODCPassword and as for other Windows NT ACLs, deny takes precendence over allow. Next, it’s necessary to define who will manage the RODC – this effectively defines a user account that can administer the server without needing Domain Admins membership (e.g. to apply patches, restart the server, etc.). One gotcha is that this is a user contact (not a group) – many organisations will circumvent this with service accounts, but that’s really not good practice.

Following this, a new computer account should be visible in the directory. The Windows Server 2003 version of Active Directory Users and Computers (ADUC) will see the account as disabled, whereas the Windows Server 2008 tools will report it as an unoccupied DC account. On joining the domain, the computer will be linked with its account and will become an RODC.

The RODC concept relies on a principle called constrained Kerberos delegation, which in turn needs value linked replication – hence the requirement for a Windows Server 2003 domain and forest dunctional level. In addition the requirement for a Windows Server 2008 DC with which to communicate is created as Windows Server 2003 DC will see the RODC as a “normal” computer – e.g. a workstation. Of course, the Windows Server 2008 DC is potentially a single point of failure, so more than one should be deployed.

The constrained Kerberos authentication works as follows:

• In addition to the krbtgt account that will already exist in the domain (a Kerberos ticket granting service account), each RODC will have its own TGT account created in the form krbtgt_identifier in order to issue its own Kerberos tickets without compromising domain security.
• If a user attempts to logon at a remote site, their credential
  s will initially be validated by the local RODC.
• Because password hashes are stripped from RODC replication, if this is the user’s first login attempt, or if they are not in the AllowsRODCPassword group, then the authentication request will be passed across the WAN to a full DC. When the ticket is returned, the RODC asks a full DC running Windows Server 2008 DC replicate a single attribute (the password hash), which is then held for future logins.
• If a login is authenticated by the RODC then a local Kerberos ticket is issued. This local ticket will not be valid elsewhere on the domain (effectively each RODC becomes a subdomain for authentication purposes) and requests to access other resources will be referred to a full DC running Windows Server 2008.

It is possible to force inbound replication to an RODC for a defined set of users (i.e. to pre-populate the information for users on a particular site); however this information can quickly become stale.

Scotty went on to mention a couple of things to beware of when planning to use RODCs:

• Because an RODC cannot be written to, some applications will see RODCs as an LDAP server, if an LDAP v3 referral is invoked then many applications will fail.
• Whilst Exchange Server will treat an RODC as a GC, Outlook will not.