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 R2 domain controllers, and you find out how to configure UPN suffixes.

After this lesson, you will be able to:

Understand multidomain Active Directory environments

Understand multiforest Active Directory environments

Upgrade existing domains and forests

Configure multiple user principal name (UPN) suffixes

Estimated lesson time: 45 minutes

Multidomain Active Directory environments

The majority of current Active Directory de ployments in small-sized 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 NT 4.0, supported far fewer 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 and Windows Server 2012 R2 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 this, however, 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 comprised 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 comprised 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 authentication and authorization boundaries. You can also use domains to partition administrative privileges 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.

Real World: Politics trumps technology

It is very important to understand that geeks often see technology as something completely separate from organizational politics, with the most efficient technical solution being the best, but everyone else doesn’t necessarily share this perception. When I worked as a systems administrator at an Australian University, there was a shared room in one building that hosted two different printers used by different departments, even though the departments were part of the same faculty. People in each department felt strongly that the printer should be labeled with a departmental identity on the network and that users from one department should, under no circumstances, be able to print to the printer owned by the other department. Although the machinations of interdepartmental politics are usually of little interest to the geeks in the information technology (IT) department, administrators who ignore unclearly defined boundaries do so at their own peril.

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.

The depth of a domain tree is limited by a domain having maximum fully qualified domain name (FQDN) length for a host of 64 characters.

Intraforest 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.”

Domain functional levels

Domain functional levels determine the Active Directory functionality and features that are available. The higher the domain functional level is, the more functionality and features are available.

You can use Windows Server 2012 domain controllers with the following domain functional levels:

Windows Server 2003

Windows Server 2008

Windows Server 2008 R2

Windows Server 2012

You can use Windows Server 2012 R2 domain controllers with the following domain functional levels:

Windows Server 2003

Windows Server 2008

Windows Server 2008 R2

Windows Server 2012

Windows Server 2012 R2

The limiting factor on a domain functional level is the domain controllers used to host Active Directory. If your organization has Windows Server 2003 domain controllers, you aren’t able to raise the functional level until you replace or upgrade those domain controllers to a more recent version of the Windows Server operating system.

You can alter the domain functional level using the Active Directory Users And Computers console, the Active Directory Domains And Trusts console as shown in Figure 1-2, or the SetADDomainMode Windows PowerShell cmdlet. Your account needs to be a member of the Domain Admins or Enterprise Admins groups to perform this operation.

FIGURE 1-2 Raise or verify the domain functional level

Windows Server 2003 Functional Level

The Windows Server 2003 domain functional level is the lowest level at which you can introduce domain controllers running the Windows Server 2012 or Windows Server 2012 R2 operating system. You can set this functional level if you have domain controllers running the Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 operating systems. The Windows Server 2003 domain functional level includes the following features, which are also available at higher domain functional levels:

Selective authentication enables you to configure specific resources in the forest so that only certain users and groups can authenticate. The default is to allow all users in the forest to authenticate before permissions to those resources are checked.

Support for storing DNS zones in custom application partitions enables you to selectively replicate DNS zones to specific domain controllers that are enrolled in the custom partitions, rather than requiring that you configure replication to all domain controllers in the domain or the forest.

Attribute-level replication for group and other multivalued attributes. Rather than replicating the whole Active Directory object, only altered attributes will be replicated.

Windows Server 2008 Functional Level

The Windows Server 2008 domain functional level requires that all domain controllers be running the Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 or Windows Server 2012 R2 operating systems. The Windows Server 2008 domain functional level includes all of the features available at the Windows Server 2003 functional level as well as the following:

Improvements in Distributed File System (DFS) replication that make it possible for replication to occur more efficiently

Support for fine-grained password policies, which enables you to apply multiple separate password policies within the same domain

Support for personal virtual desktops through RemoteApp and Remote Desktop when used with Hyper-V

Managed service account support, which enables you to automatically manage service account passwords rather than manually managing them

Support for command-line-based Active Directory Recycle Bin if the forest functional level is raised to Windows Server 2008 R2

Windows Server 2012 Functional Level

The Windows Server 2012 domain functional level requires that all domain controllers be running the Windows Server 2012 or Windows Server 2012 R2 operating system. This functional level supports the features of all the lower functional levels as well as:

Group Managed Service Accounts Enables you to install a single managed service account on multiple computers.

Fine-Grained Password Policies Supports the Active Directory Administrative Center rather than by editing them using ADSI Edit.

Active Directory Recycle Bin Supports through Active Directory Administrative Center rather than through command-line utilities if the forest is configured at the Windows Server 2012 forest functional level.

Key Distribution Center (KDC) In addition to support for claims, compound authentication, and Kerberos armoring is set to always provide claims or fail unarmored authentication requests, and they aren’t available unless the domain is raised to the Windows Server 2012 functional level.

Windows Server 2012 R2 Functional Level

The Windows Server 2012 R2 domain functional level requires that all domain controllers be running the Windows Server 2012 R2 operating system. This functional level supports the features of all the lower functional levels as well as:

Domain controller side protection for Protected Users Protected Users authenticating against a Windows Server 2012 R2 domain controller are not able to use NTLM authentication, DES or RC4 cipher suites, cannot be delegated with constrained or unconstrained delegation, and cannot renew user tickets beyond the initial four-hour lifetime.

Authentication policies These are new forest-based policies, which you can apply to accounts in domains that control the member computers that a user or service account can sign-on from. These policies also allow you to apply access control conditions for authentication to services running as an account.

Authentication policy silos These silos allow you to create relationships between user, computer, and managed service accounts for the purposes of applying authentication policies or implementing authentication isolation.

Forest functional levels

A forest can host domains running at different domain functional levels. Forest functional level is dependent on the minimum domain functional level of any domain in your forest. For example, if your organization has one domain running at the Windows Server 2008 functional level and all other domains running at the Windows Server 2012 functional level, you can’t raise the forest functional level beyond Windows Server 2008. After you raise that one domain from the Windows Server 2008 functional level to the Windows Server 2012 domain functional level, you’re also able to raise the forest functional level to Windows Server 2012. When you raise the forest functional level, you limit the domain functional levels that can be added to the forest in the future. For example, if the forest functional level is set to Windows Server 2012 R2, all new domains added to the forest must also be set to the Windows Server 2012 R2 domain functional level. The Windows Server 2012 and Windows Server 2012 R2 forest functional levels don’t introduce any new features beyond those that were available at the Windows Server 2008 R2 functional level. The Windows Server 2008 R2 functional level introduced the ability to implement the Active Directory Recycle Bin, but otherwise has the same features as the Windows Server 2003 and Windows Server 2008 forest functional levels.

You can raise the forest functional level using the Active Directory Domains and Trusts console, as shown in Figure 1-3, or using the Set-ADForestMode Windows PowerShell cmdlet. You need to use a user account that is a member of the Enterprise Admins group to perform this task. In general you can’t lower the forest functional level after you’ve raised it. The exception to this rule is that you can lower the forest functional level from Windows Server 2012 to Windows Server 2008 R2 if you haven’t enabled Active Directory Recycle Bin.

FIGURE 1-3 Raise the forest functional level

Although Active Directory Recycle Bin becomes available at the Windows Server 2008 R2 forest functional level, you need to have configured your organization’s forest to be running at the Windows Server 2012 or Windows Server 2012 R2 forest functional level to be able to use the Active Directory Administrative Center interface as opposed to the command-line interface.

Quick check

What is the minimum forest functional level that enables you to implement Active Directory Recycle Bin?

Multiforest Active Directory environments

Not only do many organizations have more than one domain in their forest, but some organizations have multiple Active Directory forests. Multiple forests often result when organizations merge, during the period before the acquiring organization has subsumed the acquired organization’s infrastructure.

Other reasons for having multiple Active Directory forests within a single organization include:

Security requirements You can ensure that administrators of one part of the organization have no rights over another part of the organization by having each part of the organization in a separate forest.

Incompatible schemas All domains in a forest share a schema. If two separate schemas are required for two different parts of the organization, it is necessary to implement multiple forests.

Political requirements Multinational organizations might have to deal with different jurisdictional requirements. It might be simpler to meet these requirements by having separate forests with trust relationships than it is to attempt to configure domains within the same forest to meet these different compliance benchmarks.

Upgrading existing domains and forests

You can use one of two strategies when upgrading an existing domain so that you can configure it at the Windows Server 2012 R2 functional level:

The first strategy is to upgrade the operating systems on each domain controller to Windows Server 2012 R2. This method can be problematic because many organizations are running Windows Server 2003 on domain controllers, and you can’t directly upgrade Windows Server 2003 to Windows Server 2012 R2. It’s also likely that existing domain controllers are running an x86 version of a Windows Server operating system. Windows operating systems never support direct upgrades from x86 versions to x64 versions.

You can introduce Windows Server 2012 R2 domain controllers into an existing domain and then decommission existing domain controllers running earlier versions of the Windows Server operating system. This method is less complex than performing a direct upgrade. If the hardware supports it, you can repurpose the existing hardware so that the decommissioned domain controllers have a new purpose as Windows Server 2012 R2 domain controllers (although an increasing number of organizations have domain controllers run on virtual machines).

Unlike previous domain controller upgrades, you don’t need to run adprep.exe directly to prepare Active Directory for the introduction of domain controllers running Windows Server 2012 or Windows Server 2012 R2. Instead, if you promote the first Windows Server 2012 or Windows Server 2012 R2 domain controller using an account that is a member of the Schema Admins and Enterprise Admins group, the schema upgrade occurs automatically. You need to run adprep.exe separately only if you are performing an in-place upgrade of a domain controller running an x64 version of Windows Server 2008 or Windows Server 2008 R2 and if this upgraded domain controller will be the first Windows Server 2012 or Windows Server 2012 R2 domain controller in the domain.

NOTE: Active Directory Migration Tool

The Active Directory Migration Tool can assist you in migrating from an existing Active Directory environment rather than upgrading an existing environment. Version 3.2 of the Active Directory Migration Tool isn’t supported on Windows Server 2012 or Windows Server 2012 R2.

User principal name (UPN) suffixes

User principal name (UPN) suffixes are the part of a user’s UPN that trails the @ symbol. For example, in the UPN don_funk@contoso.com, the UPN suffix is the domain name contoso.com. UPN suffixes enable users to sign on using an account name that includes the name of their domains. Because UPN suffixes look like email addresses, users find them easy to remember. This is useful in complex environments where users might be logging on to computers that are members of domains that are different from the domains that host their accounts. For example, Kim Aker’s user account might be located in the accounts.contoso.com domain, but she needs to sign on to a computer that is a member of the computers.contoso.com domain. Rather than having to sign on as accounts\kim_akers as her user name, or selecting the accounts domain from a list, she can instead sign on using the UPN of kim_akers@contoso.com.

By default, all users use the UPN suffix that is the name of the forest root domain, even if their accounts are in a child domain. You configure UPN suffixes using the Active Directory Domains And Trusts console as shown in Figure 1-4.

FIGURE 1-4 Configure alternative UPN suffixes

You can configure the UPN suffix associated with a specific user account on the Account tab of the user account’s properties through the Active Directory Users And Computers console as shown in Figure 1-5. When you are configuring forest trusts, you can block or allow user authentication based on the UPN suffix.

Lesson summary

A forest can contain multiple domains. Domain trees build on the same namespace. A forest can contain multiple domain trees.

No hostname in an Active Directory forest can exceed 64 characters.

The domain functional level is dependent on the earliest version of the Windows Server operating system used on a domain controller in a domain.

A domain functional level defines the minimum version of the Windows Server operating system that can be used on domain controllers.

Each domain in a forest can have a different functional level. The forest functional level depends on the lowest domain functional level in the forest.

You can configure custom UPN suffixes to simplify the sign-on process for users in multidomain and multiforest environments.

Lesson review

Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of each answer choice in the “Answers” section at the end of this chapter.

You are in the process of designing a new Active Directory implementation for your organization. Two different departments in your organization will be adopting applications that have separate and mutually exclusive Active Directory schema requirements. Which of the following Active Directory structures should you use in your design to accommodate these requirements?

A single forest with a single domain tree

A single forest with multiple domain trees

Multiple forests

A single domain forest

You are the systems administrator for Tailspin Toys and its subsidiary company Wingtip Toys. You are in the process of designing a new Active Directory structure. You’ve been asked to ensure that employees who work in the Tailspin Toys part of the organization log into a domain named tailspintoys.com and that employees who work in the Wingtip Toys part of the organization log into a domain named wingtiptoys.com. You want to do this in the simplest way possible and minimize the creation of trust relationships. Which of the following Active Directory structures should you use in your design to accommodate these requirements?

A single domain forest

Multiple forests

A single forest with multiple domain trees

A single forest with a single domain tree

You want to deploy several domain controllers running the Windows Server 2012 R2 operating system. You will eventually decommission existing domain controllers and bring the domain up to the Windows Server 2012 R2 domain functional level. What is the minimum domain functional level required to support the introduction of domain controllers running the Windows Server 2012 R2 operating system?

Windows Server 2003 domain functional level

Windows Server 2008 domain functional level

Windows Server 2012 domain functional level

Windows Server 2012 R2 domain functional level

At which forest functional levels is the Active Directory Recycle Bin available? (Choose all that apply.)