Secure a Branch Office Domain Controller With Windows Server 2008
Supporting remote branch offices while securing sensitive information is a difficult balancing act. Now, with the availability of Windows Server 2008, new technologies allow IT managers to deploy domain controllers (DCs) in unsecured locations safely, by encrypting drives, limiting the attack surface and separating server and Active Directory (AD) administrative privileges.
This article will instruct you on how to set up a Read Only Domain Controller (RODC) for a remote location, on Server Core with BitLocker providing extra security. In a production environment there are many factors related to these technologies (which are not discussed here) that you should consider carefully before deployment. For example, Exchange Server can’t as yet utilize RODCs. The instructions here require basic knowledge of AD and command-line administration and should be tried out in a test environment before deployment.
Server Core, BitLocker and RODCs — Safety in Numbers
RODCs host a read-only copy of AD, containing all objects and associated attributes except passwords. Applications that require write access to AD are referred by the RODC to a writable DC across a wide area network (WAN), usually located at a central site. RODCs don’t cache passwords locally by default, but Password Replication Policy can be configured so that only users in the branch office have their passwords cached on the appropriate RODC, limiting exposure in case the machine is compromised or stolen.
If DNS is installed on an RODC, zone data is also read-only, and clients are provided with a referral DNS server by the RODC, to which they must make any updates. The updated record is then replicated back to the RODC.
Local server administrator privileges can be delegated to an AD user or group for support and maintenance purposes without granting administrative access to AD. This is known as Administrative Role Separation and contrasts from usual DCs, where users must be added to the Domain Admins group, which poses a security risk to AD.
Server Core is a slim-line version of Windows Server 2008, in which only the required operating system components are installed, reducing resource utilization and improving security by limiting the attack surface. The most important difference between Server Core and the full installation of Server 2008 is that there is no graphical user interface (GUI) in Server Core.
BitLocker is Microsoft’s disk encryption technology and is built in to Vista and Server 2008. Unlike the Encrypted File System (EFS), BitLocker is capable of encrypting the entire Windows partition. BitLocker encryption keys can be stored on a built-in Trusted Platform Module (TPM) chip or on a removable USB device.
Prepare the Drive for BitLocker and Install Server Core
The following procedure will prepare the server’s disk for installing Server Core to support BitLocker drive encryption. We’ll use the diskpart command to create a boot partition (s:) that contains unencrypted boot files, and a larger partition (c:) for Windows, which we’ll later encrypt. Save the diskpart.txt file to a USB key before proceeding.
- Insert the Windows Server 2008 CD and proceed with installing Server Core.
- After selecting the appropriate language and regional options, click Repair your computer on the Install Windows screen.
- Click Next on the System Recovery Options dialog (as there is no operating system installed), and then click Command Prompt.
- Insert the USB drive. Run the following command to copy the diskpart script to RAM:
copy c:\diskpart.txt x:\
- Remove the USB drive and then run the following command:
diskpart /s x:\diskpart.txt
- Check the volume configuration before closing the command prompt and System Recovery Options window. Don’t click Shutdown or Restart.
- Proceed by installing Server Core on the larger partition (Figure 1).
- Once the installation is completed, configure a static IP addresses and a DNS server, usually a server at your central site, as appropriate for the remote site.
- Rename the server, RODC1 in this example, and reboot Server Core.
There must be at least one Windows Server 2008 DC that the RODC can use as a replication partner, and the forest and domain functionality levels should be set to a minimum of Windows Server 2003. In this example, ad.com is a 2008 domain and contains only Server 2008 DCs.
Create an RODC Computer Account in AD
- Log on to a standard Server 2008 domain controller in your central site as a domain administrator.
- Open Active Directory Users and Computers (ADUC) from Administrative Tools on the Start menu.
- Expand your domain in the left-hand pane of ADUC, right-click Domain Controllers, and select Pre-create Read-only Domain Controller account from the menu.
- Check Use advanced installation mode on the welcome screen, and click Next twice. In the Network Credentials dialog, leave the default setting My current logged on credentials selected, and click Next to continue.
- Enter a name (RODC1), and click Next.
- Select the remote site where the RODC will be installed, and click Next.
- Leave the default options of DNS and Global Catalog selected as additional options, and click Next.
- Click Add on the right of the Specify the Password Replication Policy dialog, select Allow passwords for the account to replicate to this RODC in the pop-up window, and click OK. Enter the name of the AD group (RODC1 Admins) that will be delegated permission to administer this RODC, and click OK. Should a connection to the central writable DC be lost, members of this group will still be able to log on to the RODC because their passwords will be cached locally (Figure 2 shows the RODC1 Admins group added to the password policy). Click Next.
- Click Set to add an AD group (RODC1 Admins) that will be able to administer the server.
- Click Next on the Delegation dialog, and then Finish.
- Add a domain user account (user1) to the RODC1 Admins group.
Figure 3 shows the currently unused RODC account in the Domain Controllers Organizational Unit (OU) in AD.
Install Directory Services With a Standard AD User Account
RODC hardware can be shipped to branch offices and AD installed by a nontechnical member of staff if necessary. Install From Media (IFM) has been improved so that passwords are removed for safer transportation.
- Log on to Server Core with the local Administrator account.
- Check connectivity to a writeable DC at the central site and successful DNS resolution. The server doesn’t need to be joined to the domain.
- Run the following command line to promote Server Core to a domain controller:
dcpromo /unattend /UseExistingAccount:Attach /ReplicaDomainDNSName:ad.com /UserDomain:ad.com
/UserName:AD\user1 /password:* /safeModeAdminPassword:* /rebootOnCompletion:yes
Now ad.com is the fully qualified domain name for our domain, and user1 is a domain user with no domain administrator privileges. (Replace * with appropriate passwords.)
Encrypt Server Core’s Drive Using BitLocker
Now we’ll configure BitLocker to store its encryption key on a removable USB drive. If your server doesn’t support booting from a USB device, the following procedure can still be used, but you’ll have to enter a recovery password every time Server Core is rebooted. In practice, I don’t recommend using BitLocker in remote locations where there’s no technical support on hand without a built-in TPM chip to store the encryption key.
- Configure Group Policy to enable BitLocker on hardware without a TPM chip and to back up keys and passwords to AD. Open GPMC on a DC at your central site, from Start > Administrative Tools, expand the Domain Controllers OU, right-click the Default Domain Controllers Policy and select Edit.
- In the Editor window, expand Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption and double-click Turn on BitLocker backup to Active Directory Domain Services. Check Enabled and ensure that Require BitLocker backup to AD DS is ticked before clicking OK.
- Double-click Control Panel Setup: Enable advanced startup options, and check Enabled. Make sure that Allow BitLocker without a compatible TPM is checked (Figure 4), and click OK. Close the Editor window.
- On Server Core, run the following command to ensure the new settings are applied: gpupdate /force
- Log on to Server Core as a domain administrator, and install BitLocker:
start /w ocsetup BitLocker
Click Yes when prompted to restart the system.
- Install the BitLocker Remote Admin Tool:
start /w ocsetup BitLocker-RemoteAdminTool
- Connect a USB key (in this example labeled f:) into the Server Core machine. Change the working directory to System32 and encrypt the c: drive. In the following command line, the -s switch should only be used if your server’s hardware doesn’t support booting from a USB drive:
cscript manage-bde.wsf –on c: -rp –sk f: -s
Even if you don’t intend to use a USB key to boot the system, you must specify the –sk (startup key) switch and save a key. The –rp switch creates a recovery password that can be used to boot the server if the USB key is not available.
- Make sure you save the recovery password before proceeding (Figure 5). You can check the status of encryption, which runs in the background using the following command:
cscript manage-bde.wsf –status
- Once fully encrypted, restart Server Core. At this point, you’ll have to plug in the USB drive or press ENTER and supply the recovery password.
In your production environment, you should create a separate Group Policy Object for the BitLocker settings and apply it to only the relevant machines.
Using these three new technologies in Windows Server 2008 together provides solid security for domain controllers that cannot be physically secured. However, RODCs and BitLocker add a level of complexity that might require additional training for administrators and special deployment considerations, especially concerning applications that make use of AD, such as Exchange. Server Core requires that administrators be familiar with the command line. Although BitLocker can be configured without any special hardware, it’s more difficult to use and support if the server doesn’t include a Trusted Platform Module.
Russell Smith is an independent consultant based in the United Kingdom who specializes in Microsoft systems management.