Windows Server 2008 R2 Unleashed (51 page)

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.

Summary

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

Best Practices

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

CHAPTER 8

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.

Keeping a Distributed

Environment in Sync

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