Administrator Role Separation in Windows Server 2008

Those of you already familiar with Windows Server 2008 will know that one of the key Active Directory-related improvements is the introduction of the Read-Only Domain Controller (RODC).  With the RODC comes the ability to separate administrative roles.  This removes the restriction of having to use a Domain Administrators account when carrying out administrative tasks on a DC.   For example, changing the Network Card on a Domain Controller on a Windows Server 2003 DC requires a Domain Admin account, which is clearly overkill.  On a Windows Server 2008 RODC you can now delegate machine-specific administrative tasks to a local administrator.  The delegated account requires no elevated privileges within AD. 

You can specify an account or group to be the the local administrator for a RODC when pre-staging the creation of the RODC on a writeable DC (or at a later time if you prefer).  This pre-staging activity (also new in Windows Sever 2008) delivers the ability to complete the promotion of the RODC using the account (or members of the group) you specified to be the local administrator.  In the example below, I have specified a group named RODC1 Local Admins to be the local administrator for the RODC1 Domain Controller.  Note that the group name I use specifies the the machine name (i.e. RODC1).  This is because the group will typically be used for only one RODC, rather than for all RODCs.

The group or account that you specify will be assigned to the managedBy attribute value of the RODC’s computer object in AD.

You can then use the account (or member of the group you created if you used a group) to complete the promotion of the RODC by running DCPROMO on the server that is to become the RODC (see below).   Again, bear in mind that the account used does not need to be a member of Domain Admins.  You will however receive a warning during the DCPROMO process (see below), which you can safely ignore when completing the promotion of a pre-staged RODC.

The local administrator account can then subsequently be used to log on locally to the RODC and to perform administrative tasks.  Remember that the account will only have local administrator rights to the local RODC. 

We know that the managedBy attribute for the RODC is used to store the account or group that is allowed local administrator rights on the RODC.  But the authentication mechanism needs to provide for scenarios where AD is not available, so how is this information actually used by the RODC?   The information is actually stored in the registry on the RODC in the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RODCROLES

As you can see from the screenshot below, the Security Identifier (SID) shown in the “Repair Admins” REG_SZ value corresponds to the account or group specified in the managedBy attribute value on the RODC’s AD object.

Hint: You can use the SID Lookup feature of LDP.EXE to match a  SID to a friendly name.

If you need to include additional local roles, you can use the “Local Roles” feature within NTDSUTIL.   You can define the following local roles

Administrators
Users
Guests
Remote Desktop Users
Network Configuration Operators
Performance Monitor Users
Performance Log Users
Distributed COM Users
IIS_IUSRS
Cryptographic Operators
Event Log Readers
Certificate Service DCOM Access
Incoming Forest Trust Builders
Terminal Server License Servers
Pre-Windows 2000 Compatible Access
Windows Authorization Access Group
Print Operators
Server Operators
Account Operators
Backup Operators
Replicator

When a new local role has been defined, it will appear within the same RODCROLES registry key with a relative identifier that corresponds to the role.  In the example below, an account named “morgaaa” has been assigned the Print Operators local role. 

C:\Windows\system32\ntdsutil.exe: lo ro
local roles: add morgaaa “print operators”
Successfully updated local role.
local roles: show role “print operators”
        TMAD\morgaaa
local roles:

Given that the registry values show the relative identifer (e.g. 550), rather than the the friendly name (e.g. Print Operators) you can use the Microsoft KB article Well-known security identifiers in Windows operating systems to match the registry value to the role.

Remember to ensure that the passwords for the domain accounts used for local roles are cached on the RODC.   Unless you do this, you will not be able to log on to the RODC in situations where other DCs are not available (e.g. when the network link from the Branch office to the hub site is down).

The way in which the local roles are assigned and used is currently not well documented.  Hopefully this blog entry provides you with some useful additional information on how this new Windows Server 2008 feature.