Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
Before Windows Server 2008 R2, domain controllers could only be deployed with full
read/write replicas of domain objects. Any change initiated at a domain controller would
eventually replicate to all DCs in the forest. This would occur even if the change was
undesirable, such as in the case of accidental deletion of OUs.
In remote sites, physical security was an issue for these DCs. Although organizations
didn’t want to deploy DCs to these sites for security reasons, in many cases slow WAN
links would dictate that the remote office would need a local DC, or run the risk of dimin-
ished performance in those sites.
In response to these issues, Microsoft built the concept of RODCs into Windows Server
2008 R2. They also built functionality in RODCs that allowed only specific passwords to
be replicated to these RODCs. This greatly reduces the security risk of deploying domain
controllers to remote sites.
Outlining the Features of RODCs
Several key features of RODCs must be understood before they are deployed in an organi-
zation. These features and functionality are listed as follows:
ptg
. RODCs can be installed on a server with Server Core, to further reduce the security
risk by reducing the number of services running on the server.
. RODCs can be configured as global catalog servers, which effectively makes them
ROGCs.
7
. Domain and forest functional levels must be set to Windows Server 2003 or higher
levels to install RODCs.
. Replication to RODCs is unidirectional, as there is nothing to replicate back from the
RODCs.
. RODCs that run the DNS service will maintain a read-only copy of DNS partitions
as well. Clients who need to write their records into DNS will be issued a referral
to a writable DNS server. The record that they write will be quickly replicated back
to the RODC.
. An existing Windows Server 2008 R2 forest must be prepared to use RODCs by run-
ning dcpromo /rodcprep from the Windows Server 2008 R2 media. This allows for
the proper permissions to be set for the Read-only DNS Server partitions. This can be
run manually, but is run automatically during the dcpromo process for an RODC.
222
CHAPTER 7
Active Directory Infrastructure
Deploying an RODC
The process for deploying an RODC is similar to the process of deploying a regular domain
controller. In both scenarios, the dcpromo command is used to initiate the wizard. The
wizard is greatly improved over Windows Server 2003, however, and includes the ability to
make that server an RODC. To configure a server as an RODC, do the following:
1. From the domain controller, choose Start, Run.
2. Type dcpromo to initiate the wizard.
3. From the wizard welcome screen, check the Use Advanced Mode Installation check
box, and click Next to continue.
4. Read the warning about Operating System Compatibility and click Next to continue.
5. Choose Existing Forest and Existing Domain because RODCs can only be installed in
domains with existing domain controllers. Click Next to continue.
6. Enter the name of the domain the RODC will be installed into and enter Domain
Admin credentials into the Alternate Credentials field, as shown in Figure 7.13. Click
Next to continue.
ptg
FIGURE 7.13
Installing an RODC.
7. Select the domain again from the list, and click Next to continue.
8. Select a site to install the DC into from the list, and click Next to continue.
9. On the Additional Domain Controller Options page, check the box for RODC, as
shown in Figure 7.14; you can also define if the RODC is a global catalog server
and/or a DNS server. Click Next to continue.
10. On the Password Replication Policy page, specify if the passwords of any specific
accounts will be replicated to the RODC. Often, local users and passwords in the
Deploying Read-Only Domain Controllers (RODCs)
223
FIGURE 7.14
Choosing to make a server into an RODC.
remote location could be added here to allow for them to be replicated and to
improve logon times. After adding groups and/or users, click Next to continue.
ptg
11. On the Delegation of RODC Installation and Administration page, shown in Figure
7.15, specify any accounts or groups that will be local administrators on the box.
Windows Server 2008 R2 removes the requirement that local administrators of
RODCs be domain-level built-in administrators, which gives greater flexibility for
remote administration of the server. Enter a group (preferred) or user account into
7
the Group or User field, and click Next to continue.
FIGURE 7.15
Setting local administrator rights on the RODC.
224
CHAPTER 7
Active Directory Infrastructure
12. On the Install from Media page, choose to replicate either from an existing domain
controller or from local media. By storing the DC information on a burnt CD or other
media and shipping it to the remote location, replication time can be greatly reduced.
In this case, we are replicating from an existing DC, so click Next to continue.
13. On the Source Domain Controller page, choose to either let the wizard pick a DC, or
specify one yourself. Click Next to continue.
14. The next dialog box on database location, set the location for the SYSVOL, logs file,
and database, and click Next to continue.
15. Set a Directory Services Restore Mode password on the next page, and click Next
to continue.
16. On the summary page, review the options chosen, and click Next to continue.
17. Because new domain controllers require a reboot, it can be convenient to check the
Reboot on Completion check box, as shown in Figure 7.16, which is displayed
when the DC is being provisioned. By doing so, the RODC will automatically reboot
when complete.
ptg
FIGURE 7.16
Setting the DC to reboot after provisioning.
The separation of the directory model from the replication model in Windows Server 2008
R2 AD DS enables domain designers to have full flexibility when designing replication
topology and enables them to focus on replication efficiency. In addition, several features
in Windows Server 2008 R2, such as RODCs, IPv6 support, universal group caching, and
Install from Media DC promotion, give the replication topology an even greater edge and
allow for the realization of improved replication times and reduced bandwidth.
Best Practices
225
The following are best practices from this chapter:
. Utilize RODCs to allow for local DC functionality in sites with lesser physical security.
. Consider installing dedicated domain controllers using Server Core, to reduce the
overall security profile that a server presents.
. Use the automatically generated connection objects that are created by the KCC,
unless a specific reason exists to hard-code replication pathways.
. Ensure that all your sites listed in DNS contain the appropriate SRV records.
. Ensure that the schema version has been upgraded to R2 levels before preparing to
install Windows Server 2008 R2 on any domain controllers.
. Use the repadmin tool to troubleshoot and validate AD DS replication.
. Consider using IPv6 for environments consisting of Windows 7/Vista and Windows
Server 2008 R2 and other IPv6-compliant devices.
. Use IPv6 tunneling mechanisms such as ISATAP and 6to4 to provide long-term
compatibility between IPv4 and IPv6.
ptg
. Don’t turn off site link bridging unless you want to make your domain controller
replication dependent on the explicit site links that you have established.
7
This page intentionally left blank
ptg
IN THIS CHAPTER
Creating Federated
. Keeping a Distributed
Environment in Sync
Forests and Lightweight
. Active Directory Federation
Services
Directories
. Synchronizing Directory
Information with Forefront
Identity Manager (FIM)
. Harnessing the Power and
Windows Server 2008 R2 not only contains the tradi-
Potential of FIM
tional directory services known as Active Directory
Domain Services (AD DS), but it also includes a version of
directory services meant for specific applications and
smaller, more lightweight applications. This directory
services version is known as Active Directory Lightweight
Directory Services (AD LDS).
Keeping information and identities synchronized across these
ptg
directories can be a challenge, so Microsoft also included
Active Directory Federation Services (AD FS) and supports a
metadirectory synchronization tool known as Forefront
Identity Manager (FIM) to help with federation. This chapter
addresses the creation of federated forests and lightweight
directories for enterprise directory and application use.
When Microsoft originally developed Active Directory in
Windows 2000 Server, it was designed to be the only direc-
tory an organization would ever need. The idea was that all
services would be centralized within an organization’s
Active Directory environment, and applications would use
it as their own directory.
As information technology developed, the exact opposite
effect happened; a proliferation of directories within organi-
zations occurred. Not only were multiple directories created