Advanced Active Directory infrastructure

f you are the administrator of a medium to large organization, it is likely that you are responsible for managing multiple domains, perhaps even multiple forests, rather than managing a single domain forest. In this chapter you discover how and why you would configure forests with multiple domain trees and the benefits of each functional level. You also find out how to configure and manage different types of trust relationships to ensure users in one forest or domain are granted appropriate access to resources in another forest, domain, or Kerberos realm.

Lessons in this chapter:

• Lesson 1: Configure domains and forests
• Lesson 2: Configure trusts

Before you begin

To complete the practice exercises in this chapter, you need to have deployed computers SYD-DC, MEL-DC, CBR-DC, and ADL-DC as described in the Introduction, using the evaluation edition of Windows Server 2012.

Lesson 1: Configuring domains and forests

As an experienced administrator you’re probably quite familiar with the configuration of single domain Active Directory forests. In this lesson, you find out more about multidomain and multiforest environments. You discover how to upgrade an existing domain and forest so that it uses only Windows Server 2012 domain controllers, and you find out how to configure UPN suffixes.

Multidomain Active Directory environments

The majority of current Active Directory deployments in small- and medium-sized enterprises have a single domain. This hasn’t always been the case because earlier versions of the Windows Server operating system, such as Windows NT4, supported far fewer user accounts. Supporting a smaller number of accounts often necessitated the use of multiple domains, and it wasn’t unusual to see medium-sized organizations that used complicated domain structures.

Each Windows Server 2012 domain controller can create approximately 2.15 billion objects during its lifetime, and each domain supports the creation of up to approximately 2.15 billion relative identifiers (RIDs). Given these statistics, few administrators implement multiple domain forests because they need to support a large number of users. Of course, in very large organizations, the replication load between sites might make a domain with several hundred thousand user accounts problematic, but site and replication considerations are covered in Chapter 2, “Active Directory sites and replication.”

There are many reasons why organizations implement multidomain forests. These can include but are not limited to:

• Historical domain structure Even though newer versions of the Windows Server operating system handle large numbers of objects more efficiently, some organizations have retained the forest structure that was established when the organization first adopted Active Directory.
• Organizational or political reasons Some organizations are conglomerates, and they might be composed of separate companies that share a common administrative and management core. An example of this is a university faculty in Europe or Australia, such as a Faculty of Science, that is composed of different departments or schools, such as the school of physics and the department of botany. For political or organizational reasons it might have been decided that each department or school should have its own domain that is a part of the overall faculty forest. Active Directory gives organizations the ability to create domain namespaces that meet their needs, even if those needs might not directly map to the most efficient way of accomplishing a goal from a strict technical perspective.
• Security reasons Domains enable you to create security boundaries so that you can have one set of administrators who are able to manage computers and users in their own domain, but who are not able to manage computers and users in a separate domain. Although it’s possible to accomplish a similar goal by delegating privileges, many organizations prefer to use separate domains to accomplish this goal.

Domain trees

A domain tree is a set of names that share a common root domain name. For example contoso.com can have pacific.contoso.com and atlantic.contoso.com as child domains, and these domains can have child domains themselves. A forest can have multiple domain trees. When you create a new tree in a forest, the root of the new tree is a child domain of the original root domain. In Figure 1-1, adatum.com is the root of new domain tree in the contoso.com forest.

FIGURE 1-1 Contoso.com as the root domain in a two-tree forest

The depth of a domain tree is limited by a maximum fully qualified domain name (FQDN) length for a host of 64 characters. This means that the host name and the domain name combined cannot exceed 64 characters, including the periods that separate each component of the name. For example, the name 3rd-floor-printer could not be used in the melbourne. victoria.australia.pacific.contoso.com domain because it cannot be used as a hostname in an Active Directory forest as the hostname exceeds the 64-character limit.

Intra-forest authentication

All domains within the same forest automatically trust one another. This means that in the environment shown in Figure 1-1, you can assign a user in the Australia.pacific.contoso.com permissions to a resource in the arctic.adatum.com domain without performing any extra configuration.

Because of the built-in automatic trust relationships, a single forest implementation is not appropriate for separate organizations, even when they are in partnership with one another. A single forest makes it possible for one or more users to have administrative control. Most organizations aren’t comfortable even with trusted partners having administrative control over their IT environments. When you do need to allow users from partner organizations to have access to resources, you can configure trust relationships or federation. You read more about trust relationships in Lesson 2 of this chapter and more about federation in Chapter 10, “Active Directory Federation Services.”