Improving the Security of Authentication in an AD DS Domain

Lesson 3: Configuring Read-Only Domain Controllers

Branch offices present a unique challenge to an enterprise’s IT staff: If a branch office is separated from the hub site by a wide area network (WAN) link, should you place a domain controller (DC) in the branch office? In previous versions of Windows, the answer to this question was not a simple one. Windows Server 2008, however, introduced a new type of domain controller—the read-only domain controller (RODC)—that made the question easier to answer. In this lesson, you explore the issues related to branch office authentication and domain controller placement, and you learn how to implement and support a branch-office RODC.

Authentication and Domain Controller Placement in a Branch Office

Consider a scenario in which an enterprise is characterized by a hub site and several branch offices. The branch offices connect to the hub site over WAN links that might be congested, expensive, slow, or unreliable. Users in the branch office must be authenticated by Active Directory to access resources in the domain. Should a DC be placed in the branch office?

In branch office scenarios, many of the services provided by IT are centralized in a hub site that is carefully maintained by the IT staff. In larger organizations, the hub site may include a robust datacenter. Branch offices, however, are often smaller sites at which no datacenter exists. In fact, many branch offices have no significant IT presence other than a small handful of servers. There may be no physically secure facility to house branch office servers. There may be few, if any, local IT staff to support the servers.

If a DC is not placed in the branch office, authentication and service ticket activities are directed to the hub site over the WAN link. Authentication occurs when a user first logs on to his computer in the morning. Service tickets are a component of the Kerberos authentication mechanism used by AD DS domains. You can think of a service ticket as a key issued by the domain controller to a user. The key allows the user to connect to a service such as the file and print services on a file server. When a user first tries to access a specific service, the user’s client requests a service ticket from the domain controller. Because users typically connect to multiple services during a workday, service ticket activity happens regularly. Authentication and service ticket activity over the WAN link between a branch office and a hub site can result in slow or unreliable performance.

If a DC is placed in the branch office, authentication is much more efficient but there are several potentially significant risks. A DC maintains a copy of all attributes of all objects in its domain, including secrets such as information related to user passwords. If a DC is accessed or stolen, it becomes possible for a determined expert to identify valid user names and passwords, at which point the entire domain is compromised. At a minimum, you must reset the passwords of every user account in the domain. Because the security of servers at branch offices is often less than ideal, a branch office DC poses a considerable security risk.

A second concern is that changes to the Active Directory database on a branch office DC replicate to the hub site and to all other DCs in the environment. Therefore, corruption to the branch office DC poses a risk to the integrity of the enterprise directory service. For example, if a branch office administrator performs a restore of the DC from an outdated backup, there can be significant repercussions for the entire domain.

The third concern relates to administration. A branch office domain controller might require maintenance—for example, a new device driver. To perform maintenance on a standard domain controller, you must log on as a member of the Administrators group on the domain controller, which means you are effectively an administrator of the domain. It might not be appropriate to grant that level of capability to a support team at a branch office.

Read-Only Domain Controllers

These concerns—security, directory service integrity, and administration—left many enterprises with a difficult choice to make, and there was no best practice answer. Windows Server 2008 introduced the RODC, which is designed specifically to address the branch office scenario. An RODC is a domain controller, typically placed in the branch office, that maintains a copy of all objects in the domain and all attributes except for secrets such as password-related properties. When a user in the branch office logs on, the RODC receives the request and forwards it to a domain controller in the hub site for authentication.

You can configure a password replication policy (PRP) for the RODC that specifies user accounts the RODC is allowed to cache. If the user logging on is included in the PRP, the RODC caches that user’s credentials, so the next time authentication is requested the RODC can perform the task locally. As users who are included in the PRP log on, the RODC builds its cache of credentials so that it can perform authentication locally for those users. These concepts are illustrated in Figure 8-7.

Because the RODC maintains only a subset of user credentials, if the RODC is compromised or stolen, the effect of the security exposure is limited. Only the user accounts that had been cached on the RODC must have their passwords changed. Writable domain controllers maintain a list of all cached credentials on individual RODCs. When you delete the account of the stolen or compromised RODC from Active Directory, you have the option to reset the passwords of all user accounts that were cached on the RODC. The RODC replicates changes to Active Directory from DCs in the hub site. Replication is one way, from a writable domain controller to the RODC. No changes to the RODC are replicated to any other domain controller. This eliminates the exposure of the directory service to corruption resulting from changes made to a compromised branch office DC. Finally, RODCs, unlike writable DCs, have some local groups, most notably a local Administrators group. You can give one or more local support personnel the ability to maintain an RODC fully, without granting them the equivalence of domain administrators.

Deploying an RODC

The high-level steps to install an RODC are as follows:

• Ensure that the forest functional level is Windows Server 2003 or higher.

• If the forest has any DCs running Microsoft Windows Server 2003, run ADPrep /RODCPrep.

• Ensure that at least one writable DC is running Windows Server 2008 or Windows Server 2008 R2.

• Install the RODC.

Each of these steps is detailed in the following sections.

Verifying and Configuring Forest Functional Level of Windows Server 2003 or Higher

Functional levels enable features unique to specific versions of Windows and are, therefore, dependent on the versions of Windows running on domain controllers. If all domain controllers are Windows Server 2003 or later, the domain functional level can be set to Windows Server 2003. If all domains are at Windows Server 2003 domain functional level, the forest functional level can be set to Windows Server 2003. Domain and forest functional levels are discussed in detail in Chapter 12.

RODCs require that the forest functional level is Windows Server 2003 or higher. That means that all domain controllers in the entire forest are running Windows Server 2003 or later.

To determine the functional level of your forest:

1. Open Active Directory Domains And Trusts.

2. In the console tree, right-click the root node, Active Directory Domains And Trusts [Server Name], and then click Properties.

3. Verify the forest functional level, as shown in Figure 8-8.

Any user can verify the forest functional level in this way. No special administrative credentials are required to view the forest functional level.

If the forest functional level is not at least Windows Server 2003, examine the properties of each domain to identify any domains for which the domain functional level is not at least Windows Server 2003. If you find such a domain, you must ensure that all domain controllers in the domain are running Windows Server 2003. Then, in Active Directory Domains And Trusts, right-click the domain and choose Raise Domain Functional Level. After you have raised each domain functional level to at least Windows Server 2003, right-click the root node of the Active Directory Domains And Trusts snap-in and choose Raise Forest Functional Level. In the Select An Available Forest Functional Level drop-down list, choose Windows Server 2003 and click Raise. You must be an administrator of a domain to raise the domain’s functional level. To raise the forest functional level, you must be either a member of the Domain Admins group in the forest root domain or a member of the Enterprise Admins group.

Running ADPrep /RODCPrep

If you are upgrading an existing forest to include domain controllers running Windows Server 2008 or Windows Server 2008 R2, you must run ADPrep /RODCPrep. This command configures permissions so that RODCs can replicate DNS application directory partitions. DNS application directory partitions are discussed in Chapter 9, “Integrating Domain Name System with AD DS.” If you are creating a new Active Directory forest that will have only domain controllers running Windows Server 2008 or Windows Server 2008 R2, you do not need to run ADPrep /RODCPrep.

The command is found in the \support\adprep folder of the Windows Server 2008 or Windows Server 2008 R2 installation DVD. Copy the folder to the domain controller acting as the schema master. The schema master role is discussed in Chapter 10, “Administering Domain Controllers.” Log on to the schema master as a member of the Enterprise Admins group, open Command Prompt, change directories to the ADPrep folder, and type adprep /rodcprep.

Before running ADPrep /RODCPrep, you must run ADPrep /ForestPrep and ADPrep /DomainPrep. See Chapter 10 for more information about preparing a Windows Server 2003 domain and forest for the first Windows Server 2008 or Windows Server 2008 R2 domain controller.

Placing a Writable Windows Server 2008 or Windows Server 2008 R2 Domain Controller

An RODC must replicate domain updates from a writable domain controller running Windows Server 2008 or Windows Server 2008 R2. It is critical that an RODC can establish a replication connection with a writable Windows Server 2008 or Windows Server 2008 R2 domain controller. Ideally, the writable domain controller should be in the closest site—the hub site. In Chapter 11, “Managing Sites and Active Directory Replication,” you learn about Active Directory replication, sites, and site links. If you want the RODC to act as a DNS server, the writable Windows Server 2008 or Windows Server 2008 R2 domain controller must also host the DNS domain zone.

Installing an RODC

After completing the preparatory steps, you can install an RODC. An RODC can be either a full or Server Core installation of Windows Server 2008 or Windows Server 2008 R2. With a full installation of Windows Server 2008 or Windows Server 2008 R2, you can use the Active Directory Domain Services Installation Wizard to create an RODC. Simply select Read-Only Domain Controller (RODC) on the Additional Domain Controller Options page of the wizard, as shown in Figure 8-9.

Alternately, you can use the dcpromo.exe command with the /unattend switch to create the RODC. On a Server Core installation of Windows Server 2008 or Windows Server 2008 R2, you must use the DCPromo /unattend command.

It is also possible to delegate the installation of the RODC, which allows a user who is not a domain administrator to create the RODC by adding a new server in the branch office and running Dcpromo.exe. To delegate the installation of an RODC, pre-create the computer account for the RODC in the Domain Controllers OU and specify the credentials that will be used to add the RODC to the domain. That user can then promote a server running Windows Server 2008 or Windows Server 2008 R2 as an RODC, using the prestaged RODC account. The server must be a member of a workgroup—not of the domain—when creating an RODC by using delegated installation.

Password Replication Policy

Password Replication Policy (PRP) determines which users’ credentials can be cached on a specific RODC. If PRP allows an RODC to cache a user’s credentials, authentication and service ticket activities of that user can be processed by the RODC. If a user’s credentials cannot be cached on an RODC, authentication and service ticket activities are referred by the RODC to a writable domain controller.

An RODC’s PRP is determined by two multivalued attributes of the RODC’s computer account. These attributes are commonly known as the Allowed List and the Denied List. If a user’s account is on the Allowed List, the user’s credentials are cached. You can include groups on the Allowed List, in which case all users who belong to the group can have their credentials cached on the RODC. If the user is on both the Allowed List and the Denied List, the user’s credentials will not be cached—the Denied List takes precedence.

Configuring Domain-Wide Password Replication Policy

To facilitate the management of PRP, Windows Server 2008 R2 creates two domain local security groups in the Users container of Active Directory. The first group, Allowed RODC Password Replication Group, is added to the Allowed List of each new RODC. By default, the group has no members. Therefore, by default, a new RODC will not cache any user’s credentials. If you have users whose credentials you want to be cached by all domain RODCs, add those users to the Allowed RODC Password Replication Group.

The second group is named Denied RODC Password Replication Group. It is added to the Denied List of each new RODC. If you have users whose credentials you want to ensure are never cached by domain RODCs, add those users to the Denied RODC Password Replication Group. By default, this group contains groups for security-sensitive accounts including Domain Admins, Enterprise Admins, and Group Policy Creator Owners.

Configuring RODC-Specific Password Replication Policy

The two groups described in the previous section provide a method to manage PRP on all RODCs. However, to best support a branch office scenario, you must allow the RODC in each branch office to cache credentials of users and computers in that specific location. Therefore, you must configure the Allowed List and the Denied List of each RODC.

To configure an RODC’s PRP, open the properties of the RODC’s computer account in the Domain Controllers OU. On the Password Replication Policy tab, shown in Figure 8-10, you can view the current PRP settings and add or remove users or groups from the PRP.

Administering RODC Credentials Caching

When you click the Advanced button on the Password Replication Policy tab shown in Figure 8-10, an Advanced Password Replication Policy dialog box appears. An example is shown in Figure 8-11.

In the drop-down list at the top of the Policy Usage tab, you can select one of two reports for the RODC:

• Accounts Whose Passwords Are Stored On This Read-Only Domain Controller Displays the list of user and computer credentials that are currently cached on the RODC. Use this list to determine whether credentials are being cached that you do not want cached on the RODC. Then modify the PRP accordingly.

• Accounts That Have Been Authenticated To This Read-Only Domain Controller Displays the list of user and computer credentials that have been referred to a writable domain controller for authentication or service ticket processing. Use this list to identify users or computers that are attempting to authenticate with the RODC. If any of these accounts are not being cached, consider adding them to the PRP.

In the same dialog box, you can use the Resultant Policy tab to evaluate the effective caching policy for an individual user or computer. Click Add to select a user or computer account for evaluation.

Under normal circumstances, if a user or computer is on the Allowed List of an RODC, the account credentials can be cached on the RODC but will not be cached until the authentication or service ticket events cause the RODC to replicate the credentials from a writable domain controller. However, you can also use the Advanced Password Replication Policy dialog box to prepopulate user and computer credentials in the RODC cache. This ensures that authentication and service ticket activity will be processed locally by the RODC even when the user or computer is authenticating for the first time. To prepopulate credentials, click Prepopulate Passwords and select the appropriate users and computers.

Administrative Role Separation

RODCs in branch offices can require maintenance such as an updated device driver. Additionally, small branch offices might combine the RODC role with the file server role on a single system, in which case it is important to be able to back up the system. RODCs support local administration through a feature called administrative role separation. Each RODC maintains a local database of groups for specific administrative purposes. You can add domain user accounts to these local roles to enable support of a specific RODC.

You can configure administrative role separation by using the Dsmgmt.exe command. To add a user to the Administrators role on an RODC, follow these steps:

1. Open Command Prompt on the RODC.

2. Type dsmgmt and press Enter.

3. Type local roles and press Enter.

   At the Local Roles prompt, you can type ? and press Enter for a list of commands. You can also type list roles and press Enter for a list of local roles.

4. Type add username administrators, where username is the pre–Windows 2000 logon name of a domain user, and press Enter.

You can repeat this process to add other users to the various local roles on an RODC.

PRACTICE: Configuring Read-Only Domain Controllers

In this practice, you implement read-only domain controllers in a simulation of a branch office scenario. You install an RODC, configure password replication policy, monitor credential caching, and prepopulate credentials on the RODC. To perform this practice, you must complete the following preparatory tasks:

• Install a second server running a full installation of Windows Server 2008 R2. Name the server BRANCHSERVER. Do not join the computer to the domain. Set the server’s IP configuration as follows:

  • IP Address: 10.0.0.12

  • Subnet Mask: 255.255.255.0

  • Default Gateway: 10.0.0.1

  • DNS Server: 10.0.0.11 (the address of SERVER01)

• Create the following Active Directory objects:

  • A global security group named Branch Office Users

  • A user named James Fine, who is a member of Branch Office Users

  • A user named Adam Carter, who is a member of Branch Office Users

  • A user named Mike Danseglio, who is not a member of Branch Office Users

In this and other practices in this training kit, you will log on to the domain controller with user accounts that are not a member of Domain Administrators or the domain’s Administrators group. Therefore, you must give all user accounts the right to log on locally to the domain controllers in your practice environment. Follow the steps in the article, “Grant a Member the Right to Logon Locally,” at http://technet.microsoft.com/en-us/library/ee957044(WS.10).aspx to grant the Allow Logon Locally right to the Administrators and Domain Users groups. If you will use Remote Desktop Services to connect to the domain controller—rather than logging on locally—grant the Allow Logon Through Remote Desktop Services right. Reboot the server or otherwise refresh Group Policy. This is for the practice environment only. In a production environment, you should not grant users the right to log on to domain controllers.

EXERCISE 1 Install an RODC

In this exercise, you configure the BRANCHSERVER server as an RODC in the contoso.com domain.

1. Log on to BRANCHSERVER as Administrator.

2. Click Start, and then click Run.

3. Type dcpromo and click OK.

   A window appears, informing you that the Active Directory Domain Services binaries are being installed. When installation is complete, the Active Directory Domain Services Installation Wizard appears.

4. On the first page of the wizard, click Next.

5. On the Operating System Compatibility page, click Next.

6. On the Choose A Deployment Configuration page, click Existing Forest, and then click Add A Domain Controller To An Existing Domain. Click Next.

7. On the Network Credentials page, type contoso.com.

8. Click Set.

9. In the User Name box, type CONTOSO\Administrator.

10. In the Password box, type the password for the domain’s Administrator account. Click OK, and then click Next.

11. On the Select A Domain page, select contoso.com and click Next.

12. On the Select A Site page, select Default-First-Site-Name and click Next.

    In a production environment, you would select the site for the branch office in which the RODC is being installed. Sites are discussed in Chapter 11.

13. On the Additional Domain Controller Options page, select Read-Only Domain Controller (RODC). Also ensure that DNS Server and Global Catalog are selected. Then click Next.

14. On the Delegation Of RODC Installation And Administration page, click Next.

15. On the Location For Database, Log Files, And SYSVOL page, click Next.

16. On the Directory Services Restore Mode Administrator Password page, type a password in the Password and Confirm Password boxes, and then click Next.

17. On the Summary page, click Next.

18. In the progress window, select the Reboot On Completion check box.

EXERCISE 2 Configure Password Replication Policy

In this exercise, you configure PRP at the domain level and for an individual RODC. PRP determines whether the credentials of a user or computer are cached on an RODC.

1. Log on to SERVER01 as Administrator.

2. Open the Active Directory Users And Computers snap-in, expand the domain, and select the Users container.

3. Examine the default membership of the Allowed RODC Password Replication Group.

4. Open the properties of the Denied RODC Password Replication Group.

5. Add the DNSAdmins group as a member of the Denied RODC Password Replication Group. Click OK to close the group Properties dialog box.

6. Select the Domain Controllers OU.

7. Open the properties of BRANCHSERVER.

8. On the Password Replication Policy tab, identify the PRP settings for the two groups: Allowed RODC Password Replication Group and Denied RODC Password Replication Group.

9. Click Add.

10. Select Allow Passwords For The Account To Replicate To This RODC and click OK.

11. In the Select Users, Computers, Or Groups dialog box, type Branch Office Users and click OK, and then click OK again.

EXERCISE 3 Monitor Credential Caching

In this exercise, you simulate the logon of several users to the branch office server and evaluate the credentials caching of the server.

1. Log on to BRANCHSERVER as James Fine, and then log off.

2. Log on to BRANCHSERVER as Mike Danseglio, and then log off.

3. Log on to SERVER01 as Administrator and open the Active Directory Users And Computers snap-in.

4. Open the properties of BRANCHSERVER in the Domain Controllers OU.

5. On the Password Replication Policy tab, click Advanced.

6. On the Policy Usage tab, in the Display Users And Computers That Meet The Following Criteria drop-down list, select Accounts Whose Passwords Are Stored On This Read-Only Domain Controller.

7. Locate the entry for James Fine.

   Because you had configured the PRP to allow caching of credentials for users in the Branch Office Users group, James Fine’s credentials were cached when he logged on in step 1. Mike Danseglio’s credentials are not cached.

8. In the drop-down list, select Accounts That Have Been Authenticated To This Read-Only Domain Controller.

9. Locate the entries for James Fine and Mike Danseglio.

10. Click Close, and then click OK.

EXERCISE 4 Prepopulate Credentials Caching

In this exercise, you prepopulate the cache of the RODC with the credentials of a user.

1. Log on to SERVER01 as Administrator and open the Active Directory Users And Computers snap-in.

2. Open the properties of BRANCHSERVER in the Domain Controllers OU.

3. On the Password Replication Policy tab, click Advanced.

4. Click Prepopulate Passwords.

5. Type Adam Carter and click OK.

6. Click Yes to confirm that you want to send the credentials to the RODC. A dialog box informs you that the action was successful. Click OK.

7. On the Policy Usage tab, select Accounts Whose Passwords Are Stored On This Read-Only Domain Controller.

8. Locate the entry for Adam Carter.

   Adam’s credentials are now cached on the RODC.

9. Click Close, and then click OK.

Lesson Summary

• RODCs contain a read-only copy of the Active Directory database.

• An RODC replicates updates to the domain from a writable domain controller using inbound-only replication.

• Password replication policy defines whether the credentials of the user or computer are cached on an RODC. The Allowed RODC Password Replication Group and Denied RODC Password Replication Group are in the Allowed List and Denied List, respectively, in each new RODC. You can, therefore, use the two groups to manage a domain-wide password replication policy. You can further configure the individual PRP of each domain controller.

• An RODC can be supported by configuring administrator role separation to allow one or more users to perform administrative tasks without granting those users permissions to other domain controllers or to the domain. The DSMgmt command implements administrator role separation.

• An RODC requires a Windows Server 2008 or Windows Server 2008 R2 writable domain controller in the same domain. Additionally, the forest functional level must be at least Windows Server 2003, and the ADPrep /RODCPrep command must be run prior to installing the first RODC.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 3, “Configuring Read-Only Domain Controllers.” The questions are also available on the companion CD if you prefer to review them in electronic form.

1. Your domain consists of five domain controllers, one of which is running Windows Server 2008 R2. All other DCs are running Windows Server 2003. What must you do before installing a read-only domain controller?

   1. Upgrade all domain controllers to Windows Server 2008.

   2. Run ADPrep /RODCPrep.

   3. Run DSMgmt.

   4. Run DCPromo /unattend.

2. During a recent burglary at a branch office of Tailspin Toys, the branch office RODC was stolen. Where can you find out which users’ credentials were stored on the RODC?

   1. The Policy Usage tab

   2. The membership of the Allowed RODC Password Replication Group

   3. The membership of the Denied RODC Password Replication Group

   4. The Resultant Policy tab

3. Next week, five users are relocating to 1 of the 10 overseas branch offices of Litware, Inc. Each branch office contains an RODC. You want to ensure that when the users log on for the first time in the branch office, they do not experience problems authenticating over the WAN link to the data center. Which steps should you perform? (Choose all that apply. Each correct answer is part of the solution.)

   1. Add the five users to the Allowed RODC Password Replication Group.

   2. Add the five users to the Password Replication Policy tab of the branch office RODC.

   3. Add the five users to the Log On Locally security policy of the Default Domain Controllers Policy GPO.

   4. Click Prepopulate Passwords.