In-Depth
Secure Branch Offices with Windows Server
Effectively securing a number of branch offices is a considerable challenge, but there are tools to help.
Although most branch office environments typically exhibit a similar set of characteristics, there are also organization-specific requirements that determine how the environment operates. The importance of security or the degree to which technology resources are centralized may differ from one remote office framework to another. Few environments are more challenging to support than the remote office.
Regardless of how any branch office operates, Windows Server 2008 R2 presents new opportunities to deploy updated technology that makes fundamental changes to how you can deploy and leverage domain controllers (DCs) in remote environments.
A Secure Solution
Securing branch office deployments is a common scenario for Active Directory Domain Services (ADDS). The unique characteristics and constraints of remote environments are well-suited for ADDS. Windows Server 2008 R2 has a considerable set of new features and updated approaches for deploying ADDS. Let's explore how to deploy Windows Server 2008 R2 in this type of environment in a secure manner. We'll cover typical branch office characteristics, key architectural design elements and recommended deployment options specific to deploying Windows Server 2008 R2.
The most noteworthy aspect of Windows Server 2008 R2 involves read-only domain controllers (RODCs). Generally speaking, RODCs are deployed in locations that require DC services, but lack the appropriate physical security measures. Because of the improved security and enhanced management features, replacing existing DCs with RODCs may exceed existing ADDS-related requirements in many branch office environments. For locations where there are currently no DCs, RODCs represent a substantial opportunity to introduce ADDS into the environment.
Another important factor here is the updated version of Server Core, an installation option in Windows Server 2008 R2 that provides a minimal environment for running specific, supported server roles such as the DC role. Selecting Server Core only installs the subset of binary files required by the installed server role, which in this case would be the RODC. This minimal installation results in reduced attack surface, reduced maintenance and easier management. It also helps the RODC server run on fewer resources.
Because many of these factors can help alleviate the constraints commonly associated with branch office environments, Windows Server 2008 R2 Server Core and RODCs are a compelling option for all remote environments. The following deployment considerations go into detail on the deployment and configuration options specific to Server Core and RODC components.
This exact configuration is a fairly common setup, although it may not meet every organization's branch office requirements. or instance, most major aspects of this configuration are already highlighted in the current best practices guide for the Windows Server 2008 Security Compliance Management Toolkit.
Here's a run-down of the critical deployment considerations associated with establishing a secure Windows Server 2008 R2 Server Core RODC solution for branch office environments. This covers solution assumptions, important design elements, infrastructure prerequisites and other detailed deployment options.
Preliminary Design Planning
As with any DC deployment, you have to make a number of critical design decisions prior to deployment. Some of these decisions include assessing hardware requirements, deciding the software upgrade strategy, determining the RODC server build and identifying the DC upgrade order. These decisions will dictate the overall deployment process and available configurations.
From a hardware assessment perspective, you must determine if your existing DC hardware complies with the recommended requirements. There are well-documented specifications, so these will probably not pose an issue for most organizations. With regard to supported software upgrade paths, there are a number of options that vary across versions, editions and different installation options of Windows.
Server Core requires a clean installation of branch office DCs. There is no way to upgrade to this installation option. With regard to installed server roles, for security purposes, it's generally recommended that all server roles and services not required for the RODC to function be eliminated from the server build. This RODC solution stipulates that Windows Server 2008 R2 Server Core RODCs host no additional services or server roles other than that of global catalog and DNS server, which is an increasingly common approach among enterprise organizations.
The order in which you deploy your DCs is another critical aspect of the process. The recommended order involves first installing ADDS in datacenters on pristinely built Windows Server 2008 R2 member servers for each domain, starting with the forest root, and then transferring all applicable operations master roles for each domain to these DCs. Continue deploying datacenter locations and fully decommissioning all legacy DCs in these sites. This helps stabilize ADDS in a large, well-administered location. It also contributes to simplifying the RODC deployment process itself. Once you've replaced the datacenter DCs, you can start on the branch office DCs.
Windows Server 2008 R2 Forest and Domain Preparation
Before deploying a single Windows Server 2008 R2 DC to the existing environment, you must prepare the Active Directory forest and domains by running Adprep.exe. First, update the forest schema on the DC hosting the schema operations master role with the adprep /forestprep command. At this point, you can update the forest to allow RODC installation with the adprep /rodcprep command. To prepare each child domain, you must run the adprep /domainprep /gpprep command on the DC hosting the infrastructure master role.
Last, you must deploy at least one writable DC running Windows Server 2008 R2 in the same domain where the RODCs will reside. As a side note, for environments where you ran the Windows Server 2008 version of the Adprep.exe commands, upgrading to Windows Server 2008 R2 still requires that you re-run all commands with the R2 version, with the exception of adprep /rodcprep, which makes no changes from the Windows Server 2008 version.
RODC Placement
From an architectural design perspective, RODC placement considerations have changed with the introduction of the Password Replication Policy (PRP). For example, RODCs must be able to establish domain partition replication with a Windows Server 2008 R2 writable DC. Because most branch office environments subscribe to hub-and-spoke network topologies, RODC ADDS sites are most likely to be separated by a single, lowest cost site link to the datacenter site, where Windows Server 2008 R2 writable DCs are located.
For instances where this might not apply, you'll be able to deploy additional writable DCs in intermediate sites, deploy new site link bridges, or create new site links to control how you create replication connections. You also have to ensure that other DCs aren't placed in the same ADDS site as the RODC. This condition is expected to be a non-issue for most branch office environments, which typically host a minimal number of servers. For locations hosting multiple DCs, deploying RODCs may simply not be an acceptable solution.
Credential Caching
Perhaps the most important security element here is the credential-caching model. This is a critical design component you'll have to carefully establish before you start branch office deployment. For many environments, the "few accounts cacheable" model will probably be the most common and appropriate model.
This approach, where only local accounts in an RODC site are configured as cacheable, provides suitable conditions with respect to principle of least privilege and service availability. One disadvantage to this approach is that it results in increased administrative responsibilities, because each RODC's PRP will be unique and require operational provisioning and de-provisioning of accounts as necessary.
How you deal with traveling users is another common design issue expected in many branch office environments. Often branch office environments include users and resources that may require their accounts to be cached on certain RODCs for service availability purposes. Ideally, these accounts would be provisioned in advance, similar to newly hired users. However, due to the random and unpredictable nature of travel behavior, this option is often not possible, especially for a large number of resources that travel across many RODC locations.
To address this issue, you could add additional accounts to the appropriate RODC PRPs. For extreme cases where a group of accounts require allowed access on all RODC PRPs, you can also leverage the default group "Allowed Read-Only Domain Controller Password Replication Group." However, this group should be used carefully, as membership in this security group makes all members cacheable on all RODCs.
Another consideration involves when cacheable accounts are actually cached. By default, this wouldn't occur until after initial logon to an RODC when the authentication request is forwarded to a Windows Server 2008 R2 writable DC and the credentials replicated to the RODC. Because branch office environments hosting existing DCs most likely possess preexisting requirements regarding service availability, the option to pre-populate credentials on RODCs may be critical.
This might be particularly important during the initial deployment of an RODC when all accounts in the RODC site have yet to cache their credentials. As soon as the PRP is configured and accounts are marked cacheable, you can use pre-populated passwords on an RODC. However, it's important to note that using the two traditional means for pre-populating passwords has some limitations. Currently, using the Active Directory Users and Computers console or the repadmin command does not allow for the usage of security groups.
Because pre-populating passwords one account at a time or in small batches based on organizational units may not be practical, you can use security groups in a scripted manner. For instance, in order to utilize the same security group that authorizes credential caching on a particular RODC, the following may be used:
For /F %%a in ('"dsquery group dc=corp,dc=contoso,dc=com -name <Groupname>| dsget group -members"') do (Repadmin /rodcpwdrepl <RODCname> <RWDCname> %%a)
RODC Staged Installation
Of the two DC installation methods provided by Windows Server 2008 R2, the staged installation option is preferable to direct installation. The direct alternative method equates to the traditional process available in previous versions of Windows. Staged installation uses Administrator Role Separation (ARS), a feature in Windows Server 2008 R2 that delegates non-service administrators the ability to install and administer RODC servers without granting Active Directory rights.
From a security perspective, staged installation removes the requirement to use highly elevated credentials in branch office locations that may not be secure. For this reason, arguments recommending DCs be staged in the data center to support remote offices may no longer apply. Staged installation separates the RODC installation process into two stages.
The first stage requires that an ADDS service administrator pre-create a computer account for the RODC and provide configurations such as computer name, the appropriate ADDS site, which server roles to install, the PRP configuration and ARS delegation. As best practice, the delegated administrator should be represented by a security group and each member should have his credentials cached on the RODC. The second stage involves the delegated RODC server administrator using his non-ADDS service administrator credentials to join a workgroup server to the pre-created RODC account and completing the RODC promotion process.
RODC Promotion Source
For the RODC promotion source, this configuration uses the Install from Media (IFM) installation option in conjunction with staged installation. This option significantly reduces the amount of data replicated to the RODC during the installation of ADDS. Using Ntdsutil.exe on a Windows Server 2008 R2 writable DC, there are four types of installation media available. Of these four, only two are pertinent here—RODC and RODC with SYSVOL.
The RODC media is similar to the Full installation media, but does not contain cached secrets like passwords. This is an important feature from a branch office security perspective. The only requirement to produce RODC media is that you must have a Windows Server 2008 R2 writable DC installed. However, the second installation media, RODC with SYSVOL, requires much more from an infrastructure perspective. Although Ntdsutil.exe will create the RODC with SYSVOL media, using that media during installation requires that Distributed File System Replication (DFS-R) for SYSVOL replication, which requires a domain functional level of Windows Server 2008 R2.
Given most organizations with branch office environments most likely will not meet this condition, that option to use the media will most likely be unavailable until initial deployment is finished. However, once this milestone is achieved, migrating to DFS-R and using both the RODC and RODC with SYSVOL installation media will significantly minimize the directory replication. It will also make installing future branch office DCs much more efficient.
Running DCPROMO
The Active Directory Domain Controller Installation Wizard will be unavailable as you deploy this configuration because it uses RODCs running Windows Server 2008 R2 Server Core. You can't use this during the actual RODC promotion. Therefore, in addition to staged installation with IFM, an unattend file with Dcpromo.exe will install the DC role. From a security and manageability standpoint, this aspect of the solution promotes secure and consistent DC build practices, which helps sustain ADDS security and configuration across the branch office environment.
In addition, automated, predictable, and repeatable build practices might minimize the possibility of unauthorized software, services, and configurations being introduced into the build process through manual intervention. The following is an example of the dcpromo command and a simple example answer file:
DCPROMO /unattend:c:\unattend.txt
[DCINSTALL]
ReplicaDomainDNSName=corp.contoso.com
UserDomain=corp
UserName=corp\<delegated RODC security group>
Password=*
ReplicationSourcePath=C: \IFM
modeadminpassword=<password>
It's important to note that if any manual PRP configurations are included in the answer file and not during the RODC account pre-creation section of staged installation, you must explicitly add all default PRP values. Manually adding explicit PRP configurations in the answer file essentially replaces the default PRP configuration with whatever configurations are specified in the answer file.
Replication
Because Windows Server 2008 R2 RODCs provide unidirectional replication, replacing existing branch office DCs with RODCs reduces the performance load on datacenter bridgehead servers that normally process inbound replication for branch office DCs. For branch office environments, this is significant. It increases scalability and can reduce the overall number of servers required in the datacenter.
RODCs also provide automatic distribution of outbound connection objects evenly across hub site bridgehead servers, something in Windows Server 2003 that required an additional tool such as Adlb.exe. For this reason, it's recommended that you upgrade all datacenter DCs to Windows Server 2008 R2 before deploying any RODCs. This ensures that inbound replication connections are evenly load-balanced and prevents the need for alternative measures that address issues associated with datacenter bridgehead server overload during RODC deployment.
This detailed design and deployment guidance can help with secure branch office deployment of Windows Server 2008 R2 Server Core RODCs. By covering key aspects of branch office characteristics, important architectural design elements and recommended deployment options, you can use this as a foundation for future best practices with RODC branch office deployments.