Exam Ref 70-413 Designing and Implementing a Server Infrastructure, Second Edition (2014)
Chapter 4. Design and implement an Active Directory infrastructure (logical)
Active Directory, which is a critical piece of most modern corporate networks, provides authentication and authorization for every aspect of your network, including email, file shares, and corporate websites. Active Directory is also one of those services that people notice only when something malfunctions. One observation that can be made regarding Active Directory in Windows Server 2012 is that several of the processes that used to be critical skills for certification candidates can now be handled automatically. Preparing the Active Directory schema used to be a required first step performed when introducing a domain controller with a newer version of Windows Server. This step is handled automatically if not accomplished before adding a Windows Server 2012 domain controller to an Active Directory Forest.
This chapter focuses on the objects in Active Directory that define the logical structure, including forests and domains, as well as management tools such as Group Policy and controlling permissions on Active Directory objects. A consistent theme throughout this chapter is making design decisions consistent with the corporate structure and using this organizational hierarchy within Active Directory to simplify management of users and computers. These concepts hold true throughout the logical structure of Active Directory as forests, domains, and even the use of organizational units (OUs) facilitate deployment of Group Policy and provide a basis for an administrative permission model and delegation of control.
Objectives in this chapter:
Objective 4.1: Design a forest and domain infrastructure
Objective 4.2: Implement a forest and domain infrastructure
Objective 4.3: Design a Group Policy strategy
Objective 4.4: Design an Active Directory permission model
Objective 4.1: Design a forest and domain infrastructure
Unlike some other services discussed in this book, Active Directory Forests often maintain their logical structure for years with minimal changes due to the dependence that other services and applications have on the directory structure. Although the tools and process for altering the logical structure within Active Directory have improved greatly in Windows Server 2012, the design process is critical to the long-term success of your corporate infrastructure.
When you think of a design phase, you typically think of building something that does not yet exist. As you progress through this section of the book, you learn that this is not always true. Although it is certainly true that new Active Directory Forests should be carefully planned prior to implementation, most of this topic is dedicated to altering the existing structure of one or more forests into something that matches the needs of a corporation. The lesson to be learned is that any changes to the structure of Active Directory should be carefully planned to prevent degradation or complete loss of service.
This objective covers how to:
Build a multiforest architecture and manage trust relationships
Manage functional levels and domain upgrades
Perform domain migration and alter the forest structure
Implement hybrid cloud services, including Microsoft Azure Active Directory and DirSync
Building multiforest structures and trust relationships
Many Active Directory implementations are configured using a single forest because it is most efficient for authentication, replication, and management. Occasionally, a multiforest architecture is used either out of necessity, such as when two companies merge; or by design, such as when dealing with regulatory requirements or business needs. Some enterprises might even make a design decision to implement Active Directory in multiple forests for reasons of scope. Although Active Directory can handle the requirements of a large organization in a single forest, breaking large corporate branches into separate forests can often make them easier to manage. The most common reason for multiple forests within an organization is to create a test forest, providing a safe environment for testing changes to the enterprise prior to implementing them in the production forest. Test forests are highly recommended for any operation that has the potential to affect a large number of users, particularly those without a clean rollback capability. You learn more about test forests in Objective 4.2.
When multiple forests are implemented as a design choice or out of necessity, trust relationships can be used to retain a level of cohesion between the two forests, or even between specific domains within these forests. Trusts enable you to provide for authentication and authorization between forests while maintaining separate organizational and management structures. Without trust relationships, organizations using multiple forests cannot perform authentication or share resources without users having accounts in both forests (which can be the desired effect in some cases).
Multiforest architecture
An Active Directory forest refers to all domains within a contiguous namespace, such as microsoft.com; a multiforest architecture refers to an implementation using noncontiguous namespaces such as contoso.com and contosowest.com, as shown in Figure 4-1. These two forests have separate domain controllers, groups, and users. Although this level of segregation seems counterintuitive for a system typically used to provide enterprise-wide authentication and authorization, it can be useful for corporations requiring this level of separation. Although the words “separation” and “segregation” are often used to describe a multiforest architecture, this separation is often logical, not physical. Many scenarios of multiforest implementation feature forests operating side-by-side, even on the same physical network segment.
FIGURE 4-1 A simple multiforest implementation
In a single-forest Active Directory architecture, members of certain administrative groups have control over aspects of the entire forest. A multiforest architecture enables you to limit control over a portion of your infrastructure to only administrators within that segment of your organization. Although Active Directory provides numerous methods and techniques for managing group membership and restricting control over different domains or OUs, a single-forest architecture does not provide the same level of administrative segregation that can be achieved by implementing multiple forests.
Another reason to deploy multiple Active Directory forests involves the use of applications that extend the default Active Directory schema. For performance or security reasons, a decision can be made to create a separate forest to contain one or more of these applications, limiting these schema changes to the forest that is custom-built for this purpose.
To further understand how a multiforest implementation of Active Directory can be used in a corporate environment, consider the following scenario. Hospitals and other medical facilities must meet regulatory requirements specific to the health and medical industry. These same organizations have both traditional computing requirements, such as email and productivity tools, and expensive and sensitive equipment that can be computer operated. To facilitate the potentially drastic management needs for these two types of systems, separate forests could be implemented. These two forests would have separate administrative groups, different policies and security requirements, and even separate sets of users.
Another organization that can benefit from separate forests is a university. Most college campuses have a corporate network for faculty to communicate, track grades, or perform research. Allowing students to access this university network (or, more specifically, the faculty forest) could prove problematic from a security standpoint. Multiple Active Directory forests could provide a solution that would allow students to access network and university resources without introducing security weaknesses into the faculty forest.
A multiforest architecture relies heavily on a Domain Name System (DNS). Because authentication requests are routed to domain controllers using SRV records in DNS zones, DNS must be properly configured for users to be properly authenticated. Multiple Active Directory forests increase the level of complexity required to provide for authentication to both domains. Although multiforest architecture is possible even on the same physical network segment, the DNS complexities required for this configuration should be part of the Active Directory design process.
Trust relationships
Active Directory forests contain built-in relationships between domains that enable authentication and authorization to be handled automatically throughout the forest. In a multiforest architecture, these relationships must be created manually through the use of trusts. After a trust is established between two forests, authentication traffic is passed between domain controllers to enable users to log on to a trusting domain. After authentication, a user receives access to resources based on their group membership and established permissions.
Trust relationships are created using Active Directory domains and trusts within the domain properties. Several types of trusts are available, and each provides a different function (see Table 4-1). A key aspect of a trust is its transitivity, which determines whether the trust relationship is extended to other domains within the same forest as the trusted domain.
TABLE 4-1 Trust types
Although this table provides a solid description of each of the available trust types, sometimes use cases or examples are a better way to understand when a particular option should be implemented or used. Each of the different trust types is designed to meet specific organizational or technological needs, and understanding these differences simplifies the process of determining which is best for a specific situation.
External trusts are used to create a trust relationship between individual domains in separate forests, as shown in Figure 4-2. Because external trusts are nontransitive, the trust relationship does not extend to users or groups from other domains in either forest. Because they are limited to a single domain in each forest, external trusts are best used in scenarios in which restricting the scope of the trust is required. One example of an external trust that meets needs is a partnership between two universities collaborating on a shared resource project. Suppose that one or both universities want to restrict the scope of this trust to a specific department or office. If each department had its own domain, an external trust could be used to prevent resources from other domains in the forest being made available to the trusted domain.
FIGURE 4-2 External trusts involve two domains in separate forests
Forest trusts, such as the one illustrated in Figure 4-3, encompass the entire scope of an Active Directory forest. Although this level of trust can be disconcerting, it is also a convenient way for two organizations to enable their users to authenticate while on the other’s network and access resources from a partner. Use cases for forest trusts include corporate mergers, acquisitions, spinoffs, and any other corporate event that involves aspects of one company moving to another. In many cases, a forest trust is a temporary solution until the two forests (and the organizations they support) can be fully merged.
FIGURE 4-3 Forest trusts are transitive, encompassing the entirety of both forests
Realm trusts have a specific function, which is to facilitate trust relationships between an Active Directory forest and a Kerberos realm, typically in UNIX environments. Use cases for realm trusts are straightforward because they are used only when communication with a Kerberos realm is required.
Shortcut trusts differ slightly from other trust types in that they create trust relationships between two domains on a single forest, such as the one shown in Figure 4-4. Users in different domains in a single Active Directory forest can authenticate and receive authorization by default without the need for trust relationships. In large forests, performance can suffer for these authentication requests due to the amount of time required to route the traffic through the forest. Shortcut trusts can link domains to bypass much of the authentication routing process, thus improving performance.
FIGURE 4-4 A shortcut trust is created between two domains in the same forest to improve authentication between the two domains
Each of these trust types can be one- or two-way trusts. Two-way trusts refer to those in which each side of the trust relationship trusts the other. A one-way trust is used when only one entity trusts the other. Terminology is key to understanding trust direction. A trusting domain enables users from another (trusted) domain to access its resources. Trust relationships are often defined or diagrammed using the trust direction, which goes from the trusting domain to the trusted domain.
In addition to enabling cross-forest authentication and authorization, trusts are also used extensively when the structure of a forest is altered through domain migration or domain rename (both topics are discussed later in this chapter).
Managing functional levels and domain upgrades
Domain and forest functional levels directly affect the feature set available in Active Directory. It is important to know which features become available at different domain and forest functional levels and what limitations you might encounter when moving between functional levels.
Functional levels
Each generation of Windows Server introduces new domain and forest functional levels, which typically bring new features. Domain functional levels are limited by the domain controllers within the domain because the minimum domain controller operating system determines the maximum functional level of which the domain is capable. Likewise, forest functional levels are dependent on domain functional levels. A forest functional level cannot be raised until each of the domains within the forest is raised to the corresponding level. The example shown in Figure 4-5 can support a Windows Server 2008 forest functional level because the east.contoso.com domain is still at the Windows Server 2008 domain functional level.
FIGURE 4-5 A forest shows domain functional levels; the forest functional level is limited to the lowest domain functional level (in this case, Windows Server 2008)
A Windows Server 2003 forest functional level must be achieved before a Windows Server 2012 domain controller can be used. So each domain controller in the forest must use Windows Server 2003 at a minimum, and each domain within the forest must be up to the Windows Server 2003 domain functional level.
The Windows Server 2008 domain functional level added Distributed File System Replication (DFSR) support for SYSVOL, adds information about a user’s last interactive logon, and enables fine-grained password policies. Additionally, Advanced Encryption Standard (AES) support was added to the Kerberos protocol. No new features are added at the Windows Server 2008 forest functional level, but any additional domains added to the forest are automatically introduced at the Windows Server 2008 domain functional level.
Windows Server 2008 R2 domains add authentication mechanism assurance to a user’s Kerberos token, providing support for Active Directory Federation Services (AD FS)–enabled applications and the ability to authorize user access attempts based on logon method (user name and password or smart card). Automated service principal name (SPN) management for services is provided when operating using Managed Service Accounts (MSAs), enabling name changes to be handled automatically when the host name or DNS name of the computer is altered. At the forest, the Windows Server 2008 R2 functional level adds support for the Active Directory Recycle Bin.
The Windows Server 2012 domain functional level provides additional features for Kerberos authentication, specifically Key Distribution Center (KDC) support for claims, compound authentication, and Kerberos armoring. Forests using the Windows Server 2012 functional level receive no additional features over the Windows Server 2008 R2 level.
Windows Server 2012 R2 domains now support additional security for Active Directory objects with membership in Protected Users, a new domain-level security group introduced in Windows Server 2012 R2. Members of this group are prevented from using NTLM authentication, DES or RC4 ciphers in Kerberos preauthentication, delegation, or user ticket renewal beyond the four-hour lifetime. These restrictions for members of the Protected Users group are applied only if a Windows 8.1 client authenticates to a Windows Server 2012 R2 domain controller. Authentication policies are introduced in Windows Server 2012 R2 domains, providing control over the hosts an account can use to sign on and to provide additional access control for authenticating to services running as an account. No additional features are gained by using the Windows Server 2012 R2 forest functional level.
Exam Tip
You will probably get a question or two about domain and forest functional levels on the exam. Have a solid understanding of the requirements necessary to raise functional levels. Also try to commit to memory the different features enabled at each domain and forest functional level.
Domain upgrades
Because domain and forest functional levels are dependent on which Windows Server version the domain controllers are running, it is critical to take these limitations into account when you plan and design changes to an Active Directory implementation. For example, if you want to implement Windows Server 2012 domain controllers in your forest, you must first upgrade or replace any remaining Windows Server 2000 domain controllers, raise the functional level of all domains to at least the Windows Server 2003 level, and then raise the forest functional level.
The domain upgrade process occurs prior to the functional level being raised. When the first domain controller running a newer version of Windows Server is introduced, whether it is an in-place upgrade of an existing domain controller or the addition of a new domain controller, the Active Directory schema is modified, adding new object types and attributes. This process is illustrated in Figure 4-6. Windows Server 2012 makes this a more seamless process than previous versions by bringing the Active Directory preparation step into the domain controller deployment process. Rather than running adprep manually, the wizard automatically performs the preparation step (discussed in more detail in Objective 4.2).
FIGURE 4-6 When a domain controller with a new version of Windows Server is introduced, the domain, forest, and schema go through an upgrade process
Altering the forest structure
In the past, modifying an existing Active Directory forest was almost impossible. Over the years, however, Microsoft has added support for altering a forest and even moving objects between forests or domains. As tasks that were previously considered to be critical skills for enterprise administrators working with Active Directory become simplified through wizards and integral system capabilities, administrators must become comfortable with making alterations to the shape and structure of Active Directory.
Domain migration
The Active Directory Migration Tool (ADMT) enables you to migrate objects between domains or restructure your forest by moving a domain within the forest—or even into a new forest. Domain migrations are commonly used to integrate two corporations into one, as shown in Figure 4-7, or divide one business into two. Objects being moved between domains retain a security identifier (SID) history that can be used to maintain existing permissions throughout the migration process. The ADMT can be used through the ADMT console by using command-line options or within a script.
FIGURE 4-7 A domain migration can be used to move group, computer, and user objects between domains or forests
A big benefit of incorporating ADMT when you alter your forest structure is that it enables you to take a phased approach. Although certain steps in the domain rename process require mass changes to Active Directory in a single step, domain migration enables you to deploy a new domain and then migrate objects when convenient. Through SID history, existing permissions to corporate resources are retained throughout the migration process. Finally, most object types are retained in the source domain during migration, making recovery from a failed domain migration relatively painless.
Forest restructure
An Active Directory forest gains its structure from the hierarchy within the namespace. By renaming domains within your forest with the domain rename tool (rendom.exe), you can alter the structure of your Active Directory forest. Domains can even be moved to their own forest by using domain rename, as shown in Figure 4-8.
FIGURE 4-8 A forest restructure using domain rename
Although restructuring an Active Directory forest is possible using domain rename, it is a complex, multistep process that should not be undertaken lightly. To perform a domain rename, the forest must be frozen, prepped, and renamed; then cleanup efforts can begin. During the domain rename process, each domain controller in the forest must be reconfigured with the new structure of the forest. Remember that each computer within a domain is configured to specifically use that domain; during a domain rename, this configuration must be altered on each computer associated with that domain. The cleanup process includes removing obsolete domain names and restoring GPOs.
Implementing hybrid cloud services, including Microsoft Azure Active Directory and DirSync
Many businesses are considering services in the cloud as a way to gain efficiency and agility. Active Directory can be used in conjunction with cloud-based applications such as Microsoft Office 365 to provide password synchronization and Single Sign-On (SSO) capabilities. When you design an Active Directory implementation, remember the benefits offered by a hybrid cloud solution.
The number of scenarios in which a hybrid cloud approach can benefit a business are far too numerous to list here, but businesses need to make their own decisions on what areas make sense being moved to the cloud and what areas need to remain on-premises. For many businesses, hybrid scenarios make a lot of sense because they offer many of the benefits of using the cloud without loss of control over critical enterprise systems. As you evaluate use cases for the cloud, consider factors such as scalability, reliability, security, cost, maintenance, and user impact.
Azure Active Directory
Azure encompasses a large portion of the Microsoft cloud offerings for business. Part of this family of services is Azure Active Directory (Azure AD). Intended to serve as a bridge between on-premises Active Directory implementations and Microsoft cloud services such as Office 365 and Windows Intune, Azure AD also enables SSO with third-party cloud applications that support this feature.
Azure AD is available in two editions: Active Directory Free (AD Free) and Active Directory Premium (AD Premium). Azure AD Free supports up to 500,000 objects and supports synchronization with your on-premises Active Directory instance. Azure AD Premium allows for an unlimited number of objects and supports Forefront Identity Manager (FIM) for more robust synchronization between Azure AD and your on-premises Active Directory forest. Additional features in Azure AD Premium include high availability backed by a Service Level Agreement (SLA), group-based management for access to applications, custom branding with corporate logos and colors, and more robust self-service and reporting tools.
DirSync
The Azure AD directory synchronization (DirSync) tool, shown in Figure 4-9, enables synchronization of appropriate objects from within your corporate Active Directory to Azure AD. DirSync enables you to perform object synchronization on a schedule, mirroring objects contained in youron-premises Active Directory environment in Azure AD. Synchronized objects are used not only to provide users the ability to authenticate to cloud services but also for applications such as Office 365 to enable integration with an existing on-premises Microsoft Exchange Server environment, including mail-enabled groups and the global address list (GAL). DirSync and Azure AD offer two methods of handling authentication: password synchronization and SSO.
FIGURE 4-9 DirSync enables you to synchronize objects between the corporate Active Directory forest and Azure AD
Password synchronization is supported in DirSync version 6382.0000 and later, enabling users to authenticate to cloud services using the same user name and password as their on-premises Active Directory account. Passwords are synchronized in their hash form, maintaining security in transit, and ensuring that your corporate Active Directory will not be compromised in the event that synchronization traffic is somehow captured. If password synchronization is enabled after the initial implementation of Azure AD the initial synchronization process will overwrite existing cloud password, the cloud-based password will be set to never expire, and the corporate complexity policy will be enforced.
SSO support also uses DirSync, but it requires the use of a security token service (STS) such as AD FS, Shibboleth Identity Provider, or another third-party identity provider. Through the Azure AD authentication system and the STS, users are authenticated automatically to third-party cloud services without being required to provide credentials, a process that is shown in Figure 4-10. In addition to simplifying authentication for users, SSO provides several other benefits to your organization. All policies remain controlled through Active Directory, removing the need to manage security controls in the cloud. Access control can be managed within the STS, providing control over how users are authenticated through AD FS. Finally, SSO through AD FS enables you to use two-factor authentication such as smart cards.
FIGURE 4-10 With DirSync and AD FS, users can authenticate to cloud applications without providing credentials a second time
More Info: Azure AD
Because it is a relatively new offering, Azure AD will likely see numerous improvements and changes as the platform matures. More information can be found here: http://technet.microsoft.com/en-us/library/hh967611.aspx.
Thought experiment: Planning for corporate changes in Active Directory
In this thought experiment, apply what you’ve learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter.
You are the lead network engineer for your corporation, and one of your primary jobs is to ensure that changes to the network structure are seamless and transparent to users.
Your forest currently matches the geographical structure of your company, with the forest root domain hosted at the corporate headquarters and domains representing each of the cities in which a corporate presence exists. Each of your domain controllers has already been upgraded to Windows Server 2012, as have the domain and forest functional levels.
Your company recently acquired a competitor that also has a presence in cities across the country/region. By coincidence, the Active Directory structure used by this competitor is remarkably similar to your own because its domains are determined by the cities in which its corporate branches are located.
Given this scenario, answer the following questions:
1. How could you quickly enable resource sharing between the two corporate entities?
2. What method could you use to incorporate users from cities in which both companies have an existing presence?
3. What steps should you take to integrate the domains in cities in which your company did not previously have a branch?
4. While planning to bring these existing domains into your forest, you discover that domain controllers within your competitor’s forest are using everything from Windows Server 2003 to Windows Server 2012. How could this affect your plan to incorporate these domains into your forest?
Objective summary
Forests enable your Active Directory infrastructure to match that of your business.
Many corporate Active Directory implementations use a single forest, but multiple forests can also be used for design reasons.
Trusts can be used to enable authentication and authorization between domains or forests.
A trust’s transitivity refers to whether the trust extends to other domains in the forest.
Domain and forest functional levels provide additional features as the domain or forest is upgraded.
A domain functional level can be only as high as its oldest domain controller.
A forest functional level is limited by those of the domains it contains.
Active Directory objects can be moved between domains and forests with the ADMT.
Forest structures can be modified by renaming domains so they fit in an alternate location in the namespace.
Active Directory can be integrated with cloud-based services in a hybrid cloud scenario, offering features such as SSO to popular web services such as Office 365.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which business needs would cause you to consider a multiple forest architecture for your Active Directory design? (Choose all that apply.)
A. Required segregation of administration responsibilities
B. Corporate merger
C. Third-party applications that modify the Active Directory schema
D. Corporate locations in different parts of the country/region
2. What type of trust should be used to enable users between two forests to authenticate and access resources within the other forest?
A. Forest trust
B. Realm trust
C. External trust
D. Shortcut trust
3. What is the minimum forest functional level that supports the Active Directory Recycle Bin?
A. Windows Server 2003
B. Windows Server 2008
C. Windows Server 2008 R2
D. Windows Server 2012
4. Which domain functional levels cannot be used with a Windows Server 2012 forest functional level? (Choose all that apply.)
A. Windows Server 2003
B. Windows Server 2008
C. Windows Server 2008 R2
D. Windows Server 2012
5. What are the minimum requirements for users with membership in the Protected Users group to have their authentication traffic protected? (Choose all that apply.)
A. Windows 8 client
B. Windows 8.1 client
C. Windows Server 2012 domain controller
D. Windows Server 2012 R2 domain controller
6. A recent corporate merger has necessitated the incorporation of users, groups, and computers from another Active Directory forest. What tool enables you to bring these objects into your forest while maintaining existing access to resources?
A. Domain migration
B. Forest trust
C. External trust
D. Domain rename
7. Your organization is undergoing a major restructure, requiring changes to your forest and domain design. What action enables you to move domains within a forest?
A. Domain upgrade
B. Domain migration
C. Forest trust
D. Domain rename
8. You need to provide access to web services without the need to manage additional credentials for your users. What tool enables this process?
A. Windows Server 2012 forest functional level
B. Forest trust
C. Realm trust
D. Hybrid cloud
9. Which of the following is not a feature of Azure AD Premium?
A. Support for two-factor authentication
B. Unlimited Active Directory objects
C. Support for FIM
D. SLA-backed high availability
10. What requirements must be met to provide SSO capability for cloud applications? (Choose all that apply.)
A. Azure AD Premium
B. Security token service
C. Azure AD DirSync tool
D. Windows Server 2012 forest functional level
Objective 4.2: Implement a forest and domain infrastructure
After your forest and domain implementation has been carefully planned and designed, the implementation phase begins. Creating or restructuring an Active Directory forest and creating trust relationships are among the more complex tasks of managing Active Directory. It is important to have an understanding of the processes used to make these sorts of changes and to be able to predict any potential problems you might encounter during these tasks.
Domain rename is used not only for managing the Active Directory namespace but it also enables you to significantly alter the structure of your Active Directory forest. Although comprehensive changes can be made using domain rename, it is an extremely complex, multistep process. Changes to DNS, Certificate Authorities (CAs), Group Policy, and several other aspects of your infrastructure are required when performing a domain rename.
Windows Server 2012 simplifies the domain upgrade process by removing the manual Active Directory preparation process entirely. When the first Windows Server 2012 domain controller is introduced to the forest, either through an operating system upgrade or installation of the Active Directory Domain Services (AD DS) role, schema preparation occurs, and the domain is upgraded.
Domain migration provides a means to move Active Directory objects between domains in a forest or between forests, even without causing problems with users accessing network resources. Performing domain migrations are somewhat less intensive than domain rename because the structure of the forest is not directly affected by the migration. The domain migration process is often used in conjunction with the deployment of new domains in the forest to effect changes to the overall forest structure.
This objective covers how to:
Configure domain rename
Configure Kerberos realm trusts
Implement a domain upgrade
Implement a domain migration
Implement a forest restructure
Deploy and manage a test forest, including synchronization with production forests
Configuring domain rename
Performing a domain rename requires a series of multistep processes, each of which requires prior planning for both the implementation and recovery if the process fails. Because of the complexity involved, domain rename is intended to be used as a last option and is no substitute for a well-designed Active Directory architecture.
Caveats aside, sometimes performing a domain rename is the only option to preserve the objects, configuration, and security associated with an Active Directory domain. Corporate reorganization is a fact of life in large organizations, and often cannot be planned for ahead of time. For this reason, it is important to know the steps to perform a domain rename, the tools and components involved, and the requirements for each step to be successful.
Preparing for domain rename
There are several preparation steps that must be completed before you begin a domain rename. The first step is fairly straightforward because a domain rename requires a forest functional level of Windows Server 2003 and above. If your forest does not meet this requirement, you need to upgrade your domains and forest, or else you simply cannot continue with the domain rename.
The second step deals with situations in which you are restructuring your forest by using this process. If a domain is being moved in the forest, specifically if it will have a different parent domain after the domain rename, you must first create a shortcut trust between the domain being renamed and its future parent domain, as shown in Figure 4-11. During the domain rename process, this shortcut trust becomes a parent-child trust relationship that preserves the transitive trust relationship among all domains in the forest. This step is critical for maintaining users’ ability to authenticate and receive access to domain resources.
FIGURE 4-11 The shortcut trust being created in preparation for domain rename
Step 3 of preparing for a domain rename involves configuring a DNS zone for your renamed domain. Each of the SRV records and structure needed to support the current Active Directory domain must be duplicated in a new DNS zone that matches the new namespace. Because DNS is critical to the ability of clients to perform authentication to Active Directory, it must be properly configured prior to a domain rename. Additionally, the domain rename process alters the fully qualified domain name (FQDN) of all domain controllers, servers, and computers within the affected domains. For the domain rename process to complete properly, DNS must be properly configured for both the source and target domains.
The fourth preparation step for a domain rename is to relocate folder redirection or roaming user profiles. If you use either of these methods to centralize user data, changing the domain name might invalidate the path to these files. Distributed File System (DFS) is often used to handle folder redirection and roaming user profiles. When domain-based DFS namespaces are used, the domain rename process might invalidate these folder paths, resulting in users being unable to log on until the paths are resolved. Domain-based DFS namespaces support both NetBIOS and FQDNs for name resolution. If the NetBIOS name is used and remains unchanged throughout the domain rename process, users should be unaffected. If the DFS namespace becomes invalid during domain rename, steps must be taken to ensure that users can access the appropriate folders. Migrating to a new domain–based DFS namespace is the recommended solution, and Group Policy can be used to configure the new network paths.
Configuring member computers for the domain name change is step 5. Although member computers can be configured to automatically handle the DNS name change by modifying their DNS suffix, it could potentially result in excessive network traffic due to Active Directory and DNS replication as computers are moved to the new domain. Group Policy can be used to ensure that the proper domain name is applied to each computer by configuring the Primary DNS Suffix prior to executing the domain rename. To limit concurrent network traffic, it is recommended to perform Primary DNS Suffix changes using Group Policy in stages.
Configuration of CAs is step 6. This step involves ensuring that your CAs are not also domain controllers because that will cause issues after the domain rename. Prior to the domain rename, ensure that the Certificate Revocation Lists (CRLs) and CA certificates will not expire soon. Some certificates might need to be reissued following the domain rename.
The final preparation step involves domains that use Microsoft Exchange Server 2003 SP1. There is an Exchange Domain Rename Fix-up Tool that must be used to prepare these servers for the rename.
More Info: Domain Rename Preparation
Proper planning and preparation for domain rename is absolutely critical. For more detailed instructions, visit http://technet.microsoft.com/en-us/library/cc794919.aspx.
Performing domain rename
After you are properly prepared, you can begin the domain rename process. The first step is to set up a control station, which should be a member server within the domain being renamed. This control station should not be a domain controller and should have the domain rename tools installed as part of the Remote Server Administration Tools (RSAT). In Windows Server 2012 and Windows Server 2012 R2, the tools used for domain rename (Rendom.exe, Repadmin.exe, Dfsutil.exe, and Gpfixup.exe) are located in the System32 directory. Best practice dictates that you copy these files to their own directory (something like C:\domren) for the duration of this process (see Figure 4-12).
FIGURE 4-12 An example of the working folder to be created during a domain rename
Next, you must freeze the forest configuration, which prevents the addition or removal of other domains in the forest, application directory partitions, or shortcut trusts. It also prevents changes to the partial attribute set, which is the set of attributes that replicates to the global catalog. The forest configuration will be unfrozen at a later step. Due to the limitations placed on Active Directory by a frozen configuration, it is important to complete the remainder of this process in a timely manner.
The third step is to back up each domain controller in the forest by using a full system state backup. This is a critical step for being able to recover if something catastrophic happens.
Step 4 uses the domain rename tools, specifically rendom.exe, to generate a forest description file using the following command:
rendom /list
This command creates a Domainlist.xml file to contain a description of the current forest structure. You should create a backup copy of this file prior to proceeding to the next step. A sample of a domain entry from the Domainlist.xml file is shown here:
<Domain>
<Guid>89cf8ae3-f4a3-453b-ac5c-cb05a76bfa40</Guid>
<DNSname>research.contoso.com</DNSname>
<NetBiosName>RESEARCH</NetBiosName>
<DcName></DcName>
</Domain>
The fifth step is to edit the Domainlist.xml file, modifying the DNSname attribute, the NetBiosName attribute, or both. These names should match the location within the domain infrastructure in which you want this domain to be moved, as shown in the following example, which changes the research.contoso.com domain into the contosoresearch.com forest root domain. The Guid is used to identify each domain in the forest and cannot be altered. Application partitions also appear as unique domain entries, and their naming should be edited to match the rest of the forest.
<Domain>
<Guid>89cf8ae3-f4a3-453b-ac5c-cb05a76bfa40</Guid>
<DNSname>contosoresearch.com</DNSname>
<NetBiosName>CONTOSORESEARCH</NetBiosName>
<DcName></DcName>
</Domain>
After the domain description file has been modified, you must generate domain rename instructions and upload them to the domain controller operating as the domain-naming master by using the following command:
rendom /upload
This command creates a Dclist.xml file that contains a listing of each domain controller in the forest.
Finally, you can push the instruction set to each domain controller in the forest by using the following repadmin command:
repadmin /syncall /d /e /P /q DomainNamingMaster
In most forests, these instructions are not immediately synchronized to all domain controllers, so you can use the following command to check the readiness of domain controllers throughout the forest:
rendom /prepare
This command updates the Dclist.xml file that was created earlier, so you can track the status of the preparation step and monitor the process for errors. This XML file can be analyzed to determine domain controller readiness. When each domain controller achieves the Prepared state, you are ready to move to the next step.
After each domain controller is prepared for the domain rename, you can issue the rename using this command:
rendom /execute
Examine the Dclist.xml file again; if any domain controllers still show a status of Prepared, you must repeat the command. Repeat executing the domain rename until each domain controller shows a state of Done or Error. You can force the command to make another attempt on domain controllers showing an Error state by placing the word yes inside the Retry attribute under that domain controller and then rerunning the execute command.
After the domain rename execution is complete, there is an additional step for domains containing Exchange servers. The Exchange Domain Rename Fix-up Tool must be used to make necessary changes to your Exchange servers, after which you must restart each Exchange server twice.
At this point, you can unfreeze the forest configuration with this command:
rendom /end
After the forest configuration is unfrozen, reestablish any forest or external trusts. The domain rename process invalidates these trusts.
Finally, you must repair the GPOs within the domain by using the following:
gpfixup /olddns:OldDomainDnsName
/newdns:NewDomainDNSName
/oldnb:OldDomainNetBIOSName
/newnb:NewDomainNetBIOSName
/dc:DcDnsName 2>&1 >gpfixup.log
This command should appear on one line, and the oldnb and newnb parameters are needed only if the NetBIOS name of the domain has changed. These changes need to be replicated to other domain controllers within the domain by using this command:
repadmin /syncall /d /e /P /q DcDnsName NewDomainDN
Each renamed domain must have its GPOs repaired by using these steps.
More Info: Performing Domain Rename
Executing a domain rename is a complex process; for complete details on each of the steps involved, visit http://technet.microsoft.com/en-us/library/cc794793.aspx.
Completing a domain rename
After the domain rename is issued on each of your domain controllers, several more steps must be completed to ensure that all the parts of your directory function properly.
For CRLs to function properly after a domain rename, CNAME records should be created in DNS for the original FQDN of the certificate authority to resolve to the new FQDN. This CNAME record should be retained until all existing certificates have been renewed. If the URLs in your certificates use Lightweight Directory Access Protocol (LDAP) exclusively, this process does not work, and the entire certificate hierarchy has to be renewed.
Several miscellaneous cleanup steps should occur after a domain rename, some of which are applicable only if certain steps were taken in preparation for the domain rename:
After the domain rename process, in which the structure of the forest has changed, redundant shortcut trusts can be safely removed using Active Directory Domains And Trusts.
If Group Policy was used to configure the primary DNS suffix of member computers, the applicable GPO can be reconfigured or removed.
DNS zones that no longer match the directory structure are now extraneous and can be removed.
Member computers should be restarted twice to ensure that the computer and its applications and services are all made aware of the domain change.
After the domain rename is complete, a system state backup of all domain controllers should be performed one final time because restoring to a previous backup would result in the domain rename process having to be run again. If GPOs were backed up using the Group Policy Management Console (GPMC), these backups will be invalid due to the domain rename. It is recommended that you do a fresh backup of your GPOs as well.
Certain attributes within Active Directory, specifically the nsDS-DnsRootAlias and msDS-UpdateScript attributes, must be altered after the domain rename is complete. This step can be accomplished using rendom.exe with the /clean switch.
Finally, domain controllers must be renamed to match the new domain structure. Domain controllers are not automatically renamed during the domain rename process, so they must be reconfigured after the domain rename process has completed. Domain controllers can be renamed through the system properties, as shown in Figure 4-13.
FIGURE 4-13 Renaming a domain controller
The host name of a domain controller can also be configured from the command line using the following process.
1. Add a new computer name:
netdom computername <CurrentComputerName> /add:<NewComputerName>
2. Specify the new computer name as the primary name:
netdom computername <CurrentComputerName> /makeprimary:<NewComputerName>
3. Restart the domain controller.
4. Remove the old computer name:
netdom computername <NewComputerName> /remove:<OldComputerName>
More Info: Completing a Domain Rename
For complete details on the steps involved in completing a domain rename, visit http://technet.microsoft.com/en-us/library/cc794825.aspx.
Exam Tip
Domain rename will probably be included in the exam. Be confident in your understanding of the general process steps as well as the command-line tools and switches used to initiate each step.
Configuring Kerberos realm trusts
Kerberos realm trusts are used to create a trust relationship between an Active Directory domain and a Kerberos realm running UNIX. Realm trusts are created with the New Trust Wizard found in Active Directory Domains And Trusts (see Figure 4-14). Using the New Trust Wizard, you can configure the transitivity and direction of the trust, the name of the Kerberos realm, and the trust password. You can also configure the realm trust to use AES encryption.
FIGURE 4-14 The New Trust Wizard is used to create a Kerberos realm trust
Implementing a domain upgrade
In previous versions of Windows Server, the domain-upgrade process had to be completed using adprep. Windows Server 2012 integrates the domain upgrade process into the Active Directory Domain Services Configuration Wizard when domain and forest preparation have not yet been performed.
When you add the first Windows Server 2012 domain controller to an existing forest, an additional step appears in the wizard, notifying you that the forest, schema, and domain must be prepped for the domain controller. An example of this preparation step is shown in Figure 4-15.
FIGURE 4-15 Upgrading a forest and domain during a domain controller deployment
Although the domain and forest preparation steps have been integrated into the Active Directory Domain Services Configuration Wizard, in many cases this step is best performed manually in advance of deploying the first domain controller. By manually extending the schema prior to deploying your first Windows Server 2012 or Windows Server 2012 R2 domain controller, you allow time for schema replication to occur throughout the forest.
In Windows Server 2012 and Windows Server 2012 R2, adprep is contained in the \Support\Adprep folder of the installation media.
Manual forest preparation is performed using the adprep /forestprep command. This step should be accomplished by a member of the Enterprise Admins, Schema Admins, and Domain Admins groups on the domain controller running the schema master Flexible Single Master Operations (FSMO) role. Forest preparation is performed once for the entire forest.
Preparation of each domain is accomplished using the adprep /domainprep command. Domain preparation should be performed on the domain controller performing the infrastructure master role by a member of the Domain Admins group.
Implementing a domain migration
Besides renaming domains and altering a forest structure, the migration of objects between domains and forests can also assist with modifying Active Directory to meet the changing needs of your business. The process of moving objects and performing the security translation associated with the movement of these objects is known as domain migration.
The ADMT is provided as a means to assist with domain migrations. There are several versions of the ADMT, each corresponding to a specific version of Windows Server. At the time of this writing, the latest version of the ADMT is 3.2, which must be installed on a Windows Server 2008 R2 server. The ADMT is a flexible tool in that it supports both wizard-based and scripted usage, making it simple to migrate a small number of objects—or even entire domains.
An intraforest domain migration is one in which the source and target domains are within the same forest. Some characteristics of an intraforest domain migration are important to understand because they differ from an interforest migration, which is discussed in the next section. Specifically, user and group objects are moved in an intraforest migration, whereas computers and MSAs are copied and the originals remain enabled in the source domain. Passwords are always retained in an intraforest migration. SID history is required for user, group, and computer accounts, although not so for MSAs.
Prior to running the ADMT to perform your migration, you must enable the File And Printer Sharing exception in Windows Firewall on member computers or servers. You should also have a rollback plan for disaster recovery, including periodic backups of domain controllers in both target and source domains. Testing the domain migration process is highly recommended, not only for familiarization with the process but also to find potential trouble areas prior to performing the migration on production Active Directory domains.
As with any complex process, there are several best practices concerning domain migration:
Users who have encrypted files using Encrypting File System (EFS) cannot decrypt this data after a domain migration. Ensure that users decrypt these files prior to the migration.
Performing regular backups of domain controllers throughout the domain migration process is recommended.
Migrating objects in batches of 100 is recommended to better manage the process.
Administration of user and group objects should occur in the source domain throughout the migration for changes to be reflected in both domains.
User profiles must be managed differently depending on the type of user profiles being used.
Roaming profiles can be translated using the Translate Roaming Profiles option in the User Options page of the User Account Migration Wizard.
Local profiles should be translated in a separate step after user migration occurs. The Security Translation Wizard can be used to perform local profile translation using the User profiles option on the Translate Objects page.
Member computers should be restarted after migration.
Unlike the domain rename process, a domain migration is selective, so you must specifically migrate objects individually or in groups. A key aspect of the process is to migrate objects in the proper order. For example, groups should be migrated prior to the users they contain. Likewise, service accounts and MSAs should be migrated before the workstations or member servers with which they are associated.
Each phase of a domain migration can be initiated by using the appropriate ADMT wizard or by using a command-line version such as admt group, admt computer, or admt user. The admt security option corresponds to the Security Translation Wizard, which enables the translation of local user profiles from the old user object to the new user object in the target domain.
More Info: Intraforest Domain Migration
The intraforest domain migration process is discussed more extensively here: http://technet.microsoft.com/en-us/library/cc974371.aspx.
Implementing a forest restructure
Between domain rename and domain migration, you are given a lot of flexibility in reshaping the structure of your forest, and many scenarios can make use of either tool. When ADMT is to be used as a strategy for restructuring an Active Directory forest, the domain structure must first be modified, typically by deploying new domains in the forest (see Figure 4-16). This process places less stress on the forest because a phased approach can be taken to incorporate changes to the domain structure, and mass changes that must be replicated to all domain controllers and member computers are avoided.
FIGURE 4-16 A forest restructure using domain migration
The domain rename process does not change drastically between a simple rename and a forest restructure with the domain moving somewhere else within the forest. There are some significant changes, though, with an Active Directory domain migration between forests—also called an interforest migration.
In an interforest domain migration, objects are cloned rather than moved; the original objects remain in the source domain. Although SID history and passwords can be retained, these settings are optional in an interforest migration.
A trust relationship, either external or forest, one- or two-way, should be used to create an initial relationship between Active Directory domains prior to attempting an interforest migration. This trust relationship can be removed after the migration is complete.
More Info: Forest Restructure Using Domain Migration
More information on interforest Active Directory domain restructuring can be found at http://technet.microsoft.com/en-us/library/cc974335.aspx.
Deploying and managing a test forest
For many scenarios, it is beneficial to have a test instance of the Active Directory forest. Being able to validate changes to Group Policy and ensure proper policy application, test new automation methods such as scripts, or test third-party applications that integrate with Active Directory are critical steps that should be accomplished prior to implementation in a production forest. Any task with the potential to significantly affect the forest—such as domain upgrades, domain controller operating system upgrades, functional level changes, domain rename, and domain migration—should be tested prior to implementation in production.
Ideally, a test forest is a close match to your production forest to most effectively simulate the actions you are testing and identify any problems prior to the production implementation. As shown in Figure 4-17, synchronization of objects from your production forest to your test forest should be part of the test scenario.
FIGURE 4-17 Synchronizing objects from a production Active Directory forest to a test forest
Microsoft Forefront Identity Manager 2012 R2 (FIM 2012 R2) provides a new level of user management for the enterprise. FIM offers self-service management for users such as password resets, enforcement of security policies, and increased audit capabilities and reporting. FIM also provides the tools needed to synchronize user identities between forests or to Azure AD, as mentioned previously.
FIM supports both inbound and outbound synchronization, workflows, and rule-based synchronization. Rules can be used to synchronize users from certain domains within the forest, users within certain groups, or users that meet a defined set of criteria. In some testing scenarios, it can be useful to reintegrate users from the test environment at some point; this can be accomplished by using inbound synchronization.
Thought experiment: Restructuring Active Directory
In this thought experiment, apply what you’ve learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter.
Your company has been hired to consult for an international corporation. Your client currently uses a single Active Directory forest with child domains representing each country/region in which the corporation has a presence.
Rather than continue to operate in a single forest, your client wants to move to a multiple forest architecture. Each domain representing a country/region has to be transitioned into its own forest root domain. Some large countries/regions will be further broken down to represent geographical areas of the countries/regions they represent.
Given this scenario, answer the following questions:
1. What process should you use to convert the current domains to their own forest root domains?
2. How can you create and populate regional domains within the large countries/regions?
3. What features will be lost by moving to the multiforest architecture? Is there anything that can be done to mitigate or restore these lost features?
Objective summary
Domain rename enables you to restructure an Active Directory forest by altering the structure of the namespace.
Windows Server 2012 simplifies the process of upgrading a domain by performing schema extension within the Active Directory Domain Services Configuration Wizard.
Domain migration enables you to move objects between domains or forests while preserving passwords and SID history.
The ADMT enables you to perform domain migration using a wizard-based interface or the command line.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which files are used to perform a domain rename? (Choose all that apply.)
A. Rendom.exe
B. Admt.exe
C. Repadmin.exe
D. Gpfixup.exe
2. What command is used to provide the domain rename script to each domain controller in the forest?
A. rendom /upload
B. rendom /prepare
C. rendom /execute
D. repadmin /syncall
3. Which fields in the Domainlist.xml should be modified to effect a domain rename? (Choose two.)
A. Guid
B. DNSname
C. NetBiosName
D. DcName
4. What steps should be taken after a domain is renamed? (Choose all that apply.)
A. Delete redundant shortcut trusts
B. Force user password resets
C. Migrate user and computer objects
D. Rename domain controllers
5. What aspects of a domain upgrade are integrated into the Active Directory Domain Services Configuration Wizard and automatically handled? (Choose all that apply.)
A. Domain preparation
B. Forest preparation
C. Domain functional level upgrade
D. Forest functional level upgrade
6. How do migrated Active Directory objects retain their existing permissions when changing domains?
A. Shortcut trusts
B. Forest trusts
C. SID history
D. Password retention
7. What objects are moved (not copied) in an intraforest domain migration? (Choose all that apply.)
A. MSAs
B. Users
C. Computers
D. Groups
8. Which ADMT option configures local user profiles to work with migrated user accounts?
A. admt user
B. admt computer
C. admt security
D. admt profile
9. What should be used to synchronize user objects with a test Active Directory forest?
A. Domain migration
B. FIM
C. Domain rename
D. Active Directory replication
10. What options are available when using FIM to synchronize objects between forests? (Choose all that apply.)
A. Inbound synchronization
B. Outbound synchronization
C. User profile migration
D. Rule-based configuration
Objective 4.3: Design a Group Policy strategy
Group Policy, which is one of the most powerful aspects of Active Directory, is often a factor in the design strategy of the entire domain structure. The capability to apply a standard configuration to literally millions of computers across the globe is a major reason why so many large corporations use Active Directory and Windows Server.
Designing a Group Policy implementation involves applying the proper policies to users and computers in the most efficient way possible. Performance issues due to the application of a large number of policies must be balanced against the need to apply different policies to different sets of users or computers. Precedence is a key aspect of controlling the application of GPOs, as are the filtering methods available through Windows Management Instrumentation (WMI) and security groups.
Your Group Policy strategy should include the process for testing GPO application to ensure that clients are properly configured and for troubleshooting problems related to misconfiguration. Several tools are available to determine what policies are applied to a client or what policies would be applied to clients meeting certain criteria. Other tools facilitate advanced management of Group Policy, including staging, reporting, and backup capabilities. You should know what tools are available to manage and troubleshoot Group Policy and how they are used throughout the Group Policy life cycle.
This objective covers how to:
Control GPO application through inheritance blocking, enforced policies, loopback processing, security filtering, and Windows Management Instrumentation (WMI) filtering
Manage GPO assignment, including site-linked GPOs, slow-link processing, group strategies, and organizational unit (OU) hierarchies
Use Advanced Group Policy Management (AGPM)
Cache Group Policy
Controlling GPO application
The most complex aspect of dealing with Group Policy is managing precedence and ensuring that the correct policies are applied to computers without accidentally applying something to the wrong computers. Understanding the different options available to alter the priority in which GPOs get applied is the most important part of understanding how Group Policy works. A properly configured Group Policy design enables you to configure the computers in your network without experiencing performance issues that result from the use of dozens of GPOs at each level of the domain. In some scenarios, GPO application can be as simple as linking a GPO to one or more OUs; in others, blocked inheritance and enforced policies are needed.
Minimizing the number of GPOs in use within your domain is beneficial for performance reasons, but sometimes additional policies must be created to target the necessary users or computers. Finding this balance should be a priority for the Group Policy design process and is a critical skill for you to develop.
Exam Tip
Although it isn’t called out specifically in the exam objectives, be sure you understand what tools are available to troubleshoot the application of GPOs and how they differ. Group Policy Modeling (GPM) and Gpresult.exe are critical tools to know and understand.
Inheritance blocking
By default, GPOs applied to an object in Active Directory are automatically inherited and applied to all objects below that object in the hierarchy. This default behavior can be modified by configuring a child OU to block inheritance, as shown in Figure 4-18.
FIGURE 4-18 Inheritance blocking on the Domain Controllers OU
OUs that are specifically for servers often use inheritance blocking. Although you might want to use Group Policy to configure your servers, it is often a good idea to prevent unexpected changes to critical systems by blocking inheritance and applying GPOs directly to the OU.
In many cases, inheritance blocking is unnecessary because of the order in which GPOs are applied. By default, GPOs applied at a higher level in the hierarchy are processed first. When GPOs have conflicting settings, the GPO being applied at a lower level receives precedence.
Enforced policies
Although inheritance blocking changes the default inheritance in Group Policy, it can be overridden by an administrator choosing to enforce a GPO at a higher level in the OU hierarchy. Enforced GPOs are typically used to configure policies that are required regardless of a system’s purpose or criticality. They are indicated by a padlock icon added to the linked GPO, as shown in Figure 4-19.
FIGURE 4-19 The GPO enforcement of the Default Domain Policy
Not only do enforced GPOs override inheritance blocking but they are also applied in reverse order. A GPO enforced at a lower level is applied before one at a higher level, resulting in conflicting settings being configured using the GPO at the higher level.
Because enforced GPOs at higher levels of the OU hierarchy receive precedence over all GPOs applied below them, these GPOs should be handled with extreme care because they can affect computers and users throughout the domain. The importance of testing GPO application corresponds directly to the number of users and computers that might be affected.
Loopback processing
When a computer retrieves GPOs from Active Directory, it typically does so for itself and the current user. A computer sometimes needs to receive a specific configuration regardless of the user (a computer left in a public area or used as a kiosk is a common example).
Unlike the other methods discussed in this section, loopback processing is configured within a GPO under Computer Configuration\Policies\Administrative Templates\System\Group Policy. Two modes are offered for loopback processing: merge mode and replace mode. Merge mode uses both the user and computer configuration, but any conflicting settings are configured with the computer setting. Replace mode ignores the user’s configuration completely, using only those settings gathered for the computer.
Security filtering
One of the most common ways to fine-tune GPO application is to use security group filters. Each GPO is configured by default to target the Authenticated Users group, which results in the GPO always being applied. By removing the Authenticated Users group and specifying a more restrictive group, you can apply the GPO to only those users or computers that are members of that group. This technique enables you to provide a specific configuration to different classes of users, such as system administrators or corporate executives. Likewise, if a GPO should target only a certain group of computers, such as servers, security filtering can be used.
Security filtering can become increasingly powerful when used in conjunction with other GPO application strategies such as enforcement or loopback processing. By using multiple application methods, you can more strategically target specific groups of computers or users for GPO application.
Windows Management Instrumentation (WMI) filtering
The second type of filter that can be applied to a GPO uses WMI, a system that enables you to query for detailed information about a computer—such as manufacturer, processor architecture, or installed applications. WMI filters can be used to apply firewall settings to computers with a specific application installed or to enable certain services based on the hardware available to a computer. The example shown in Figure 4-20 even enables you to target Hyper-V virtual machines (VMs) with a GPO.
FIGURE 4-20 Using a WMI filter to apply a specific GPO to Hyper-V VMs
Managing GPO assignment
GPOs are assigned to a domain or OU because they typically have the most flexibility in applying specific policies and configurations based on the logical organizational structure of the company. Several other techniques and strategies can be used to assign GPOs for scenarios that don’t necessarily fit the rigid structure built in to many Active Directory domains.
Many organizations have no need for GPO assignment methods other than directly to a domain or OU. However, knowing that these options are available can be particularly helpful for managing GPO assignment to specific sites or to mobile users.
Site-linked GPOs
As with domains and OUs, GPOs can be linked to Active Directory sites, part of the physical structure of Active Directory (discussed in more detail in Chapter 5, “Design and implement an active directory infrastructure [physical]”). Site-linked GPOs can be used in several scenarios, including the use of a local Windows Server Update Services (WSUS) server, a proxy server, or anything specific to the client’s physical location. Figure 4-21 shows a GPO linked to the LosAngeles site.
FIGURE 4-21 Site-linked GPOs enable you to assign location-specific settings based on a user’s current site
Slow-link processing
The application of GPOs can take a toll on performance, particularly on networks with slow connectivity to a domain controller. When a slow link is detected, only certain aspects of a GPO are applied to a client computer. By default, the threshold by which a slow link is judged is 500 kilobits per second (Kbps), but it can be modified by editing the Group Policy Slow Link Detection setting in Policies\Administrative Templates\System\Group Policy under both the User Configuration and Computer Configuration sections. You can also disable slow-link processing by configuring the Do Not Detect Slow Network Connections setting.
The default setting categories processed over slow links are listed in Table 4-2. Many of these settings can be modified using the Allow Processing Across A Slow Network Connection setting, although Administrative Templates And Security is always processed.
TABLE 4-2 Settings processed over slow links
Group strategies
Security filtering adds quite a bit of flexibility to Group Policy. Rather than having to manage GPOs at multiple levels in a domain, you can assign them at the domain root and filter the GPO to one or more groups of users or computers. These groups could then be managed by lower-level administrators, a help desk, or even by script or other forms of automation. This technique provides some level of control over GPO application to administrators who do not have direct control over Group Policy.
Using security filtering exclusively to target users or computers for policy application can have a negative effect on performance. When Group Policy is applied, both the user and computer must go through an evaluation process to determine which GPOs should be applied and in what order. If GPOs are assigned in the OU hierarchy, they are evaluated to determine whether they should be applied. This evaluation process becomes more complex and intensive as more GPOs are added in the OU hierarchy.
Organizational unit (OU) hierarchies
Many of the strategies discussed earlier, such as inheritance and enforcement, are typically implemented against the OU hierarchy. Understanding how GPOs are applied and managed should have an impact on the OU structure and where certain objects fall within that structure. Precedence, the order in which GPOs are applied, determines which settings are applied to a computer when the GPO application process is completed.
By default, precedence occurs from top to bottom, so GPOs applied to the OU containing the user or computer are used to apply settings that conflicted with GPOs linked directly to the domain. Besides bypassing blocked inheritance, enforced GPOs also alter precedence. If two enforced GPOs are applied, one to an OU and the other to the domain, the GPO applied higher in the OU structure receives precedence.
Figure 4-22 shows an example of how GPOs could be applied to an OU structure. Two GPOs are assigned to the domain level, but only one is enforced to enable settings configured in the Contoso Corporate Standard GPO to be blocked at the Domain Controllers, Servers, and Admin OUs.
FIGURE 4-22 An example of how GPOs can be applied to an OU structure
GPO enforcement is sometimes unnecessary to achieve the desired result. A single GPO can be linked to more than one location in the OU structure. If a policy is being overridden within an OU, consider applying the GPO directly to the OU.
Applying GPOs properly and efficiently can become quite complex. Using the Group Policy Modeling Wizard can help to determine precedence and troubleshooting issues related to GPO application.
Using Advanced Group Policy Management (AGPM)
A Group Policy tool that is not provided by default is Advanced Group Policy Management (AGPM). Part of the Microsoft Desktop Optimization Pack (MDOP), which is available to Software Assurance customers, AGPM provides numerous benefits to Group Policy administrators. AGPM integrates directly with the GPMC, adding new features and capabilities (see Figure 4-23).
FIGURE 4-23 AGPM is integrated directly into the GPMC
Offline development and editing of GPOs is offered through the use of the AGPM archive. Administrators can design and build GPOs in an environment safe from accidental deployment by deploying the GPOs only when fully configured. If a problem occurs after a GPO is deployed, the GPO and its associated configuration can be quickly rolled back to the previous state.
Change control enables you to track GPOs as they go through the design and development process. Combined with role-based delegation, change control enables you to enable lower-level administrators to design and create GPOs without allowing them to deploy the GPO to production. After the GPO has been reviewed and approved for deployment, an administrator with the appropriate permissions can perform the deployment step. An example of the change control and role delegation process is shown in Figure 4-24.
FIGURE 4-24 The change control and role delegation in AGPM
Organizations with complex Group Policy implementations make heavy use of the search and filter capabilities provided in AGPM. The search functionality enables you to look for GPOs edited by a specific user, saved on a certain date, using a filter, or numerous other criteria.
Finally, AGPM enables you to manage Group Policy across multiple forests by importing and exporting GPOs, as shown in Figure 4-25. Cross-forest management can be used for multiple production forests and for moving GPOs between test and production environments.
FIGURE 4-25 AGPM provides a means for GPOs to be exported and migrated to another forest
Group Policy caching
A new feature in Windows Server 2012 R2 and Windows 8.1, Group Policy caching enables faster processing of GPOs running in synchronous mode (in which policies are being enforced prior to the user seeing a logon screen). By default, caching is disabled in Windows Server 2012 R2, but it can be enabled by editing the Computer Configuration\Policies\Administrative Templates\System\Group Policy\Enable Group Policy Caching For Servers setting.
Group Policy caching is particularly useful for branch office scenarios in which network connectivity to domain controllers might not be optimal. Instead of the computer’s boot process being delayed while GPOs are downloaded, a cached copy can be used to apply policies.
Thought experiment: Optimizing Group Policy
In this thought experiment, apply what you’ve learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter.
You have been tasked with improving the performance and efficiency of the Group Policy implementation used by your company. The organization has multiple Active Directory sites in a single domain. Each site has Active Directory users and computers in its own OUs to facilitate delegated administration by local administrators.
Given this scenario, answer the following questions:
1. You want to ensure that a set of default configuration settings is applied to computers throughout the organization without the possibility of being overridden. What is the most efficient way to accomplish this?
2. Each location has certain configuration requirements that differ from any other location. Also, users moving between locations should receive the configuration for the location in which they connect their computer. What is the best way to manage this requirement?
3. Some locations occasionally have connectivity issues that result in performance issues. What causes this and how could you mitigate this issue?
4. You have configured a GPO for server configuration that is applied synchronously. It is causing performance issues for servers at remote locations due to network latency. How could you remedy this problem?
5. Local administrators at each corporate location have requested the ability to create GPOs to be applied to their local sites. How might you facilitate this request while still maintaining control over what GPOs are actually applied to Active Directory?
Objective summary
GPO precedence can be altered using inheritance blocking and enforced policies.
Loopback processing can be used to enforce the computer configuration over that of the user.
Security filtering can be used to target specific groups of users or computers, whereas WMI filtering can focus on computers with certain attributes or configurations.
GPOs linked to an Active Directory site can be helpful for location-specific settings such as WSUS or web proxy servers.
Slow-link processing configures how GPOs are applied over links to a domain controller without the required bandwidth.
AGPM, which is part of the MDOP, adds several features to Group Policy such as role-based access control, GPO staging, and change management.
Group Policy caching is a new feature in Windows Server 2012 R2 that enables cached GPOs to be used when running in synchronous mode.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. What technique can be used to prevent GPOs from higher levels in the domain hierarchy from being applied to computers within an OU?
A. Inheritance blocking
B. Enforced policies
C. Security filtering
D. WMI filtering
2. Which option enables you to ensure that a GPO is applied to lower levels of the domain hierarchy?
A. Inheritance blocking
B. Enforced policies
C. Security filtering
D. WMI filtering
3. Which GPO would receive precedence and be applied to computers in an OU with blocked inheritance?
A. GPO applied to domain level
B. GPO applied to OU
C. Enforced GPO applied to domain level
D. Enforced GPO applied to OU
4. How can you ensure that a specific configuration is applied to a computer, regardless of the current user?
A. Enforced policies
B. Loopback processing
C. WMI filtering
D. Security filtering
5. What feature enables you to target a GPO for computers with a specific processor type?
A. Loopback processing
B. Enforced policies
C. WMI filtering
D. Security filtering
6. What is the best way to target a GPO for users or computers in a specific location?
A. Security filtering
B. Enforced policies
C. Site-linked GPOs
D. Loopback processing
7. What features are provided by AGPM? (Choose all that apply.)
A. Role-based delegation
B. Group Policy caching
C. Change control
D. Policy rollback
8. Which AGPM feature allows for policy rollback?
A. AGPM archive
B. Change control
C. Role-based delegation
D. Import and export
9. What features does Group Policy offer to improve performance over slow network connections? (Choose all that apply.)
A. Site-linked GPOs
B. Slow-link processing
C. Loopback processing
D. Group Policy caching
10. When are cached GPOs used?
A. Loopback processing
B. Slow-link processing
C. Synchronous mode
D. Enforced policies
Objective 4.4: Design an Active Directory permission model
For many reasons, delegating permissions is critical in a modern corporate environment. Many industries require a separation of duties to prevent unauthorized use and provide checks and balances. Others require the workload to be distributed for the system to be managed efficiently. Whatever the reason, Active Directory is fully capable of providing the appropriate level of access to administrators throughout an organization.
In addition to GPO application, planning for permissions delegation should determine the structure of your OU hierarchy. Permissions in Active Directory are applied to domains or OUs and their children: objects or additional OUs. To be properly restrictive, administrators should be delegated access to perform only the functions within the scope of their job and only over the areas they manage.
In addition to controlling delegation and permissions, areas of administrative control can be used to monitor administrative users and ensure that their privileges are not being abused. Active Directory quotas can be configured to prevent individual users from creating large numbers of objects. The adminSDHolder attribute and the Protected Users security group can also be used to provide additional protections for administrative users and other sensitive accounts in Active Directory.
This objective covers how to:
Design and implement Active Directory object security
Manage quotas in Active Directory
Add custom items to the Delegation 0f Control Wizard
Deploy administration tools
Delegate permissions on administrative users (AdminSDHolder)
Plan for Kerberos delegation
Designing and implementing Active Directory object security
Similar to files or registry keys, objects within Active Directory have access control lists (ACLs) that determine which users or groups can read or make changes. Managing an object’s ACL is done through the Security tab in the object’s properties (see Figure 4-26).
FIGURE 4-26 The Security tab for a user object
Active Directory permissions do not always have to be configured manually with the Security tab; the Delegation of Control Wizard can be used as well. Launched through the context menu for an Active Directory container or OU, the Delegation of Control Wizard enables you to choose one or more user or security group objects and select tasks to delegate (see Figure 4-27). Custom tasks can also be managed using the Delegation of Control Wizard, including the ability to specify specific object types to manage and the level of control given over those objects.
FIGURE 4-27 Choosing tasks to delegate using the Delegation of Control Wizard
As with files and folders, Active Directory object security can be inherited. For this reason, it is common for security to be managed at an OU and be applied to all objects within the scope of that OU. After an object’s ACL has been configured, either through the Delegation of Control Wizard or the Security tab, removal of these permissions is accomplished through the Security tab.
PowerShell offers several methods to analyze and modify Active Directory object security. The following two lines of PowerShell code are functionally identical—retrieving a list of objects from the Computers container and then retrieving the ACL for each object using the DistinguishedName from the original query:
Get-ChildItem 'AD:\CN=Computers,DC=contoso,DC=com' | % {Get-ACL ("AD:\" +
$_.DistinguishedName)}
Get-ADObject -SearchBase 'CN=Computers,DC=contoso,DC=com' -SearchScope OneLevel -Filter
* | % {Get-ACL ("AD:\" + $_.DistinguishedName)}
With some simple modifications, these bits of code can be changed into powerful scripts. The flexibility offered by PowerShell enables you to create automated processes to perform deep analysis, even to the point of monitoring administrative user objects to ensure that administrators cannot make changes to their own user accounts.
Managing Active Directory quotas
Quotas manage the number of objects in Active Directory that are owned by a user, preventing the creation of more objects than a user is allowed. Setting a low quota for administrative users in a less-trusted position prevents them from creating large numbers of Active Directory objects, protecting against potential denial. Active Directory quotas are managed in two ways: default quotas and quotas assigned to a security principal.
Default quotas can be set for all users in the domain by configuring the msDS-DefaultQuota attribute on the NTDS Quotas container in ADSI Edit (see Figure 4-28). If the msDS-DefaultQuota attribute is not set (the default configuration) or if it has a value of -1, no default quotas are enforced, and users with the proper permissions can create an unlimited number of objects.
FIGURE 4-28 Configuring the msDS-DefaultQuota attribute enables you to define the default quota for the partition
Quotas can be created and assigned to security principals by using the dsadd command-line tool. The following example can be used to add a quota of 500 to the HelpDesk security group in the contoso.com domain:
dsadd quota -part dc=contoso,dc=com -qlimit 500 -acct
cn=HelpDesk,ou=Users,dc=contoso,dc=com
Sometimes multiple quotas can be assigned to a user based on his membership in multiple groups with quotas assigned. If a user has multiple quota assignments based on group membership, the maximum quota value is the effective quota. To find the effective quota for a user, the following command can be used:
dsget user cn=johnmith,ou=Users,dc=contoso,dc=com –part dc=contoso,dc=com –qlimit –qused
A couple of aspects of quota management can cause issues for legitimate administrative actions. When performing an automated administrative process such as a domain migration or when creating objects using a script, large numbers of objects can be attributed to a single user. Be especially wary of quotas when you perform mass object creation using automated methods.
Also interesting is the impact that deleted objects, also known as tombstone objects, have on quotas. By default, a deleted object counts fully against a user’s quota, which can be managed by editing the msDS-TombstoneQuotaFactor attribute on the NTDS Quotas container. This attribute is configured as a percentage, which means that the default value of 100 results in a deleted object that counts the same as one that hasn’t been deleted.
Creating custom tasks using the Delegation of Control Wizard
The Delegation of Control Wizard enables you to quickly assign permissions to a user or group by using a predefined set of common access levels, several of which are shown in Figure 4-29. When common access levels do not meet the requirements of the tasks to be delegated, you can choose the Create A Custom Task To Delegate option that enables you to customize the types of objects, attributes, and actions that can be viewed and modified by the assigned users.
FIGURE 4-29 Choosing Active Directory object types to delegate using the Delegation of Control Wizard
Creating a custom task with the Delegation of Control Wizard involves two steps. The first step is to choose the types of Active Directory objects to be delegated. Although the typical object types (users, groups, and computers) are listed here, so are more than 100 other object types. The object type screen also enables you to choose whether to allow delegated users to create or delete objects of the selected types in the folder.
The second step of delegating custom tasks is to choose the action types to be delegated (see Figure 4-30). Three permission types are provided. General permissions include a list of permission types that are familiar to most administrators: Full Control; Read; Write; and several others, such as Change Password and Reset Password. With property-specific permissions, you can perform fine-grained delegation to enable administration of specific object attributes. Finally, creating and deleting specific child objects can be managed, although these options are rarely used.
FIGURE 4-30 Configuring permissions to delegate using the Delegation of Control Wizard
Deploying administration tools
The tools used to manage Windows Server 2012 from a Windows 8 or Windows 8.1 computer are contained in the RSAT provided as a free download. The RSAT downloads for Windows 8 and Windows 8.1 are distinct and work only on the designated platform. PowerShell cmdlets and modules that correspond to the RSAT tools are also part of this installation. These tools do not need to be downloaded on Windows Server 2012 because the RSAT tools can be enabled by using the Add Roles and Features Wizard.
Unlike previous versions of RSAT, the installation consists of running the Windows Update Standalone Installer file; there is no need to enable features following installation.
Delegating permissions on administrative users (AdminSDHolder)
Active Directory has a special process for protecting certain objects that are considered critical, such as the Enterprise Admins group. Rather than allowing permissions on these objects to be configured directly, Active Directory resets the object permissions once per hour (by default) to those assigned to the AdminSDHolder object. To permanently configure permissions on these objects, you must edit the permissions on the AdminSDHolder object.
To configure permissions on the AdminSDHolder object, open ADSI Edit, choose the Default naming context, and navigate to the CN=System node under the domain in which you should find CN=AdminSDHolder. The Security tab in the object’s properties, shown in Figure 4-31, shows that few groups within the domain have permissions to edit administrative objects.
FIGURE 4-31 Configuring permissions on the AdminSDHolder object
Planning for Kerberos delegation
Kerberos constrained delegation is a function in Active Directory that enables a computer, typically a server, to authenticate with a user’s credentials. This functionality was introduced in Windows Server 2003 as a way for services to perform authentication on behalf of users. Prior to Windows Server 2012, this action required a high level of trust for the server being delegated because the delegation could not easily be limited to specific actions. Beginning with Windows Server 2012 and Windows Server 2012 R2, service administrators can limit Kerberos constrained delegation to individual front-end services by allowing the domain accounts for those services to authenticate (see Figure 4-32).
FIGURE 4-32 Kerberos constrained delegation supports limiting delegated authentication to specific services
To view a list of security principals allowed to perform delegated authentication, use the Get-ADComputer, Get-ADServiceAccount, or Get-ADUser cmdlets with the -Properties parameter set to PrincipalsAllowedToDelegateToAccount. To configure a service to enable specific security principals to perform delegated authentication, use New-ADComputer, New-ADServiceAccount, New-ADUser, Set-ADComputer, Set-ADServiceAccount, or Set-ADUser cmdlets with the -PrincipalsAllowedToDelegateToAccount parameter.
Thought experiment: Creating a delegation strategy for Active Directory
In this thought experiment, apply what you’ve learned about this objective. You can find answers to these questions in the “Answers” section at the end of this chapter.
Your office is responsible for Active Directory implementation for a large enterprise. The company has multiple domains, each serving a regional office dispersed across the country/region.
Up to this point, your corporate strategy regarding Active Directory object permissions has been to allow autonomy at the domain level, with little to no management at the enterprise level. Recent events have led you to limit the access provided to administrators at the domain level.
Each domain has hundreds of users who are to be classified in three separate categories, and administrators should have restrictions on the actions they can perform on each user type:
Corporate executives will have access to sensitive files and can use encryption on their laptops. Therefore, local administrators should not be able to reset their passwords.
Local administrators should not be able to manage their own accounts or those of other local administrators.
All other user objects should be managed wholly by local administrators, including group membership and password resets.
Given this scenario, answer the following questions:
1. How could you meet the requirement of restricting access to user objects based on the type of user?
2. Local administrators should be able to create new objects within their domain, but the number of objects they create should be closely monitored. With what method could you accomplish this goal?
3. A very select group of corporate administrators should be able to manage membership of highly restricted groups throughout the forest, including the Enterprise Admins group. How would you allow access to this group to perform these duties?
4. A local administrator cannot create any new objects in his domain due to the number he has already created. How could you allow this user to continue creating new objects?
Objective summary
Active Directory objects have ACLs that can be configured to allow permission levels based on administrative requirements.
Quotas are used to prevent an administrator from creating an excessive number of objects in Active Directory.
The Delegation of Control Wizard enables you to quickly assign permissions from predefined selections or a custom selection.
The RSAT for Windows 8 and Windows 8.1 are available as a free download.
High-level administrator groups are protected by having their permissions reset automatically every hour by Active Directory. Permissions on these groups should be modified by configuring the ACL on the AdminSDHolder object using ADSI Edit.
Kerberos delegation enables a computer to perform authentication on behalf of a user.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. What methods can you use to configure permissions on an object in Active Directory? (Choose all that apply.)
A. Edit the Security tab in the object’s properties
B. Add the object to the Enterprise Admins group
C. Use the Delegation of Control Wizard
D. Edit the AdminSDHolder object
2. Which of the following determines a user’s quota when all apply?
A. Default quota of 100
B. Group-assigned quota of 200
C. Group-assigned quota of 1000
D. User-assigned quota of 500
3. Which command sets the quota for members of the HelpDesk group to 100 objects?
A. dsadd quota -part dc=contoso,dc=com -qlimit 100
-acct cn=HelpDesk,ou=Users,dc=contoso,dc=com
B. dsget group cn=HelpDesk,ou=Users,dc=contoso,dc=com
-part dc=contoso,dc=com –qlimit –qused
C. New-ADQuota -Part dc=contoso,dc=com -Quota 100
-Acct cn=HelpDesk,ou=Users,dc=contoso,dc=com
D. Set-ADQuota -Part dc=contoso,dc=com -Quota 100
-Acct cn=HelpDesk,ou=Users,dc=contoso,dc=com
4. What actions might fail due to quota limitations? (Choose all that apply.)
A. Domain rename
B. Domain migration
C. DirSync to Azure AD
D. Mass user creation
5. What additional step must be taken after installing RSAT for Windows 8.1 to make the admin tools available?
A. Reboot
B. Enable the admin tools in Windows features
C. Run gpupdate /force
D. Nothing
6. How can you assign permissions to a protected admin group in Active Directory such as Enterprise Admins?
A. Edit the Security tab in the object’s properties
B. Edit the ACL on the AdminSDHolder object
C. Use the Delegation Of Control Wizard
D. Use the Run As Administrator option
7. With what tool do you configure permissions on the AdminSDHolder object?
A. Active Directory Users and Computers
B. Active Directory Administrative Center
C. Delegation of Control Wizard
D. ADSI Edit
8. Why would you need to create or manage a Kerberos delegation?
A. To provide administrative privileges to a user in Active Directory
B. To give access to a Kerberos realm trust
C. To enable a service to perform authentication on behalf of a user
D. To authenticate users from UNIX systems
9. What capability in Kerberos constrained delegation is available beginning in Windows Server 2012?
A. Limiting delegation to individual computers
B. Limiting delegation to individual services
C. Configuring delegation with PowerShell cmdlets
D. Supporting delegation between domains
Answers
This section contains the solutions to the thought experiments and answers to the lesson review questions in this chapter.
Objective 4.1: Thought experiment
1. A two-way forest trust is the quickest way to enable the two corporations to begin sharing resources.
2. For the cities in which both companies have an existing presence, a domain migration enables users, computers, and groups to be brought into the existing domain while maintaining existing permissions.
3. Locations in which an existing domain does not already exist can be most easily incorporated using domain rename to bring the competitor’s domain into the corporate forest.
4. Because your corporation uses the Windows Server 2012 forest functional level, you cannot bring in domains using an older domain functional level. One option is to upgrade existing domain controllers and domain functional levels. Alternatively, you can create new domains in the existing forest and then perform a domain migration, bringing over only the Active Directory objects.
Objective 4.1: Review
1. Correct answers: A, C
A. Correct: Creating multiple Active Directory forests enables you to segregate administrative responsibilities when required for regulatory or other business reasons.
B. Incorrect: A corporate merger is not reason enough to operate multiple forests, although a multiforest architecture can be used while the two corporations are fully integrated.
C. Correct: When third-party applications modify the Active Directory schema, these changes affect the entire forest. Using multiple forests enables you to limit the scope of these changes.
D. Incorrect: Having multiple corporate locations is easily handled with a single forest.
2. Correct answer: A
A. Correct: Forest trusts are transitive and encompass each domain in the two forests.
B. Incorrect: A realm trust is used in conjunction with Kerberos realms.
C. Incorrect: An external trust is nontransitive and creates a trust between only two domains.
D. Incorrect: A shortcut trust is implemented between two domains in the same forest to improve authentication performance.
3. Correct answer: C
A. Incorrect: Windows Server 2003 does not support the Active Directory Recycle Bin.
B. Incorrect: The Active Directory Recycle Bin was not introduced in the Windows Server 2008 forest functional level.
C. Correct: Windows Server 2008 R2 forest functional levels were the first to support the Active Directory Recycle Bin.
D. Incorrect: Although Windows Server 2012 forest functional levels support the Active Directory Recycle Bin, they were not the first.
4. Correct answers: A, B, C
A. Correct: The Windows Server 2003 forest functional level supports Windows Server 2012 domain controllers, but the Windows Server 2012 domain and forest functional levels require Windows Server 2012 domain controllers.
B. Correct: Windows Server 2008 domain controllers cannot be used in a domain or forest at the Windows Server 2012 functional level.
C. Correct: The Windows Server 2012 domain and forest functional levels do not support domain controllers running Windows Server 2008 R2.
D. Incorrect: Windows Server 2012 domain controllers must be used in Windows Server 2012 forests.
5. Correct answers: B, D
A. Incorrect: Windows 8 clients do not support the authentication constraints placed on members of the Protected Users group in a Windows Server 2012 R2 domain.
B. Correct: Windows 8.1 clients support the authentication constraints added in the Windows Server 2012 R2 domain functional level when the user is a member of the Protected Users group.
C. Incorrect: The authentication protections employed for members of the Protected Users group require a Windows Server 2012 R2 domain functional level, which is not supported in a domain with Windows Server 2012 domain controllers.
D. Correct: For the Protected Users group to have its authentication protected, a Windows Server 2012 R2 domain functional level must be reached, requiring Windows Server 2012 R2 domain controllers.
6. Correct answer: A
A. Correct: The domain migration tool enables you to move users, computers, and groups between domains. These objects can retain access to resources in the old domain by using SID history.
B. Incorrect: A forest trust enables two forests to share resources, but does not move objects between forests.
C. Incorrect: Although an external trust is used between two domains in different forests, it is used to share resources and not move objects between forests.
D. Incorrect: Domain rename can be used to relocate domains within forests and relocate the objects, but it cannot be used to move Active Directory objects to another domain.
7. Correct answer: D
A. Incorrect: A domain upgrade brings your domain functional level up, but it does not change the domain’s location in the forest.
B. Incorrect: Domain migrations move objects between domains, not the actual domain.
C. Incorrect: A forest trust enables sharing of resources between forests; it does not change your forest structure.
D. Correct: The domain rename tool enables you to change your forest structure by changing a domain’s location in the domain namespace.
8. Correct answer: D
A. Incorrect: The Windows Server 2012 forest functional level does not enable authentication to cloud services by itself.
B. Incorrect: Forest trusts enable shared resources and authentication between forests, but do not enable authentication to cloud services.
C. Incorrect: Realm trusts are used to share resources with a Kerberos realm, not cloud services.
D. Correct: A hybrid cloud infrastructure enables you to provide SSO capabilities to cloud services for your users.
9. Correct answer: A
A. Correct: Two-factor authentication is supported for Azure AD Free, not only Azure AD Premium.
B. Incorrect: Azure AD Free supports only 500,000 objects.
C. Incorrect: FIM support is not provided in Azure AD Free; only DirSync is supported for synchronizing objects from your on-premises Active Directory forest.
D. Incorrect: Although Azure AD Free is reliable, SLA-backed high availability is supported only in Azure AD Premium.
10. Correct answers: B, C
A. Incorrect: Azure AD Free supports SSO.
B. Correct: An STS such as AD FS is required to support SSO to cloud applications such as Office 365.
C. Correct: DirSync is required to synchronize security principals to Azure AD.
D. Incorrect: The Windows Server 2012 forest functional level is not required to support SSO.
Objective 4.2: Thought experiment
1. Domain rename enables you to break down each domain into its own forest root domain.
2. Regional domains within large countries/regions need to be built manually, but objects can be migrated to these domains using the ADMT.
3. There would be a loss of global administration and users would not be able to log on to domains in other countries/regions. Using forest trusts enables cross-forest authentication.
Objective 4.2: Review
1. Correct answers: A, C, D
A. Correct: Rendom.exe is the executable that actually performs the domain rename operation.
B. Incorrect: Admt.exe is the ADMT, which is used for domain migrations, not domain rename.
C. Correct: Repadmin.exe enables you to manage replication between domain controllers, which helps the domain rename process.
D. Correct: Gpfixup.exe is used to repair GPOs after a domain rename, changing their domain association from the old name to the new.
2. Correct answer: D
A. Incorrect: The rendom /upload command provides the domain rename script to the domain naming master.
B. Incorrect: The rendom /prepare command can be used to check the readiness of domain controllers throughout the forest to run the execute command.
C. Incorrect: The domain rename begins when the rendom /execute command is given.
D. Correct: The repadmin /syncall command enables you to force replication to the domain controllers in your forest.
3. Correct answers: B, C
A. Incorrect: The Guid contains the unique identifier for the domain and cannot be changed.
B. Correct: The DNSname determines the FQDN for the domain and should be changed if the domain is to be renamed.
C. Correct: The NetBiosName contains the NetBios name for the domain and can be changed.
D. Incorrect: The DcName does not need to be changed during the domain rename. Domain controllers are renamed after the domain rename process is complete.
4. Correct answers: A, D
A. Correct: After a forest structure is changed, redundant shortcut trusts can remain. These shortcut trusts can be safely deleted.
B. Incorrect: User password resets are unnecessary after a domain rename.
C. Incorrect: No migration of objects is required after a domain rename. Existing objects remain in their domain throughout the process.
D. Correct: Domain controllers must be renamed if their FQDNs have changed.
5. Correct answers: A, B
A. Correct: Domain preparation occurs as part of the Active Directory Domain Services Configuration Wizard.
B. Correct: The forest preparation step is handled automatically by the Active Directory Domain Services Configuration Wizard.
C. Incorrect: Domain functional level upgrades do not occur during domain controller deployment and must be triggered manually.
D. Incorrect: Forest functional level changes must be handled manually.
6. Correct answer: C
A. Incorrect: Shortcut trusts are used exclusively to provide improved authentication performance between two domains in the same forest.
B. Incorrect: Forest trusts enable authentication across forests.
C. Correct: An object’s SID history enables it to retain access to resources throughout a domain migration.
D. Incorrect: Password retention enables users to continue to authenticate to the network, but it does not affect their authorization to resources.
7. Correct answers: B, D
A. Incorrect: MSAs are copied between domains, not moved.
B. Correct: User accounts are moved in an intraforest domain migration.
C. Incorrect: Computer objects are copied in an intraforest domain migration.
D. Correct: Group objects are moved between domains in an intraforest migration.
8. Correct answer: C
A. Incorrect: The admt user option migrates the user object, but does not modify the security on local user profiles.
B. Incorrect: The admt computer command moves computer objects without configuring local user profiles.
C. Correct: Running admt security alters the permissions and configures local user profiles.
D. Incorrect: The admt profile command is invalid.
9. Correct answer: B
A. Incorrect: Domain migration is not the best solution for synchronizing objects with a test forest.
B. Correct: FIM provides the flexibility needed to synchronize objects with Active Directory test forests.
C. Incorrect: Domain rename cannot be used to synchronize objects between domains or forests.
D. Incorrect: Active Directory replication synchronizes the Active Directory database between domain controllers and does not copy objects into other domains or forests.
10. Correct answers: A, B, D
A. Correct: Inbound synchronization is supported by FIM and enables objects to be brought into the forest from another source.
B. Correct: Outbound synchronization is supported by FIM and can be used to move objects from a production forest to a test forest.
C. Incorrect: User profile migration is a feature of ADMT, not FIM.
D. Correct: FIM enables you to synchronize users based on rule conditions.
Objective 4.3: Thought experiment
1. Creating a GPO with the required configuration, linking it to the domain, and setting the GPO to enforced ensure that the settings in the GPO are applied to all computers within the domain.
2. Using site-linked GPOs is the perfect solution for this problem. Users moving between sites receive the configuration for their current location.
3. Slow-link processing enables you to manage the way GPOs are applied over slow links.
4. Group Policy caching, a new feature in Windows Server 2012 R2, enables your servers to apply the cached copy of the GPO in this scenario.
5. AGPM (with its role-based access control) enables local administrators to create GPOs and also enables you to stage and test the policies prior to implementation.
Objective 4.3: Review
1. Correct answer: A
A. Correct: Inheritance blocking prevents GPOs applied at higher levels of the domain from being applied to the OU unless those GPOs are enforced.
B. Incorrect: Enforced GPOs bypass blocked inheritance; they do not block inheritance.
C. Incorrect: Security filtering enables you to restrict a GPO to a list of users, computers, or groups; it does not alter inheritance.
D. Incorrect: WMI filtering is used to target specific computers meeting certain criteria, such as processor type and computer manufacturer.
2. Correct answer: B
A. Incorrect: Inheritance blocking prevents GPOs from higher levels of the domain to be applied to an OU.
B. Correct: Enforced policies bypass inheritance blocking and receive precedence over other GPOs that might apply to an OU.
C. Incorrect: Security filtering does not bypass inheritance blocking.
D. Incorrect: WMI filters are blocked by inheritance blocking.
3. Correct answer: C
A. Incorrect: GPOs applied at the domain level are placed below a GPO applied to the OU or any enforced GPO.
B. Incorrect: A GPO applied to an OU has a lower precedence than any enforced GPO.
C. Correct: Enforced GPOs at the domain level have higher precedence over those applied to an OU.
D. Incorrect: GPOs enforced at the OU level have a lower precedence than those applied above them in the domain.
4. Correct answer: B
A. Incorrect: Enforced GPOs surpass other GPOs that might be applied at a lower level, but not those of the user.
B. Correct: Loopback processing enables the computer configuration to be applied last, thus ensuring that it receives precedence.
C. Incorrect: WMI filtering is used to apply a configuration to a computer, but it does not alter the order in which the configurations are applied.
D. Incorrect: Security filtering does not accomplish the goal of applying the computer configuration, regardless of the user.
5. Correct answer: C
A. Incorrect: Loopback processing prioritizes the computer configuration over the user, but you cannot target computers meeting specific criteria.
B. Incorrect: Enforced policies do not allow you to target computers in this way.
C. Correct: WMI filters allow you to target computers with this level of specificity.
D. Incorrect: Security filtering is not the best fit for this scenario.
6. Correct answer: C
A. Incorrect: Security filters can be used in this scenario, but they are not the best solution.
B. Incorrect: Enforced policies do not meet this need.
C. Correct: Site-linked GPOs enable you to target users or computers connecting at a specific Active Directory site.
D. Incorrect: Loopback processing does not help in this scenario.
7. Correct answers: A, C, D
A. Correct: Role-based access control is included in AGPM and allows more control over what individual users can do with GPOs.
B. Incorrect: Group Policy caching is a new feature in Windows Server 2012 R2; it is not tied to AGPM.
C. Correct: Change tracking support in AGPM enables you to manage changes to GPOs and provides improved troubleshooting capability.
D. Correct: Individual GPOs can be rolled back using AGPM, giving you an easy way to quickly resolve problems caused by newly implemented GPOs.
8. Correct answer: A
A. Correct: Deployed GPOs can be rolled back because of the AGPM archive.
B. Incorrect: Although change control enables creating, reviewing, and deploying GPOs, GPO rollback is a function of the AGPM archive.
C. Incorrect: Role-based delegation is used to configure what tasks an administrator can perform.
D. Incorrect: The import and export features of AGPM do not affect GPO rollback.
9. Correct answers: B, D
A. Incorrect: Site-linked GPOs do not improve performance over slow network connections.
B. Correct: Slow-link processing enables you to configure which aspects of a GPO are processed over slow network connections.
C. Incorrect: Loopback processing is used to give the Computer Configuration precedence over the User Configuration; it does not improve performance over slow links.
D. Correct: Group Policy caching improves performance over slow network connections for GPOs applied in synchronous mode.
10. Correct answer: C
A. Correct: Loopback processing does not determine whether cached GPOs are used.
B. Incorrect: Slow-link processing does not enable GPO caching.
C. Correct: GPOs processed in synchronous mode can use cached GPOs to improve performance over slow network connections.
D. Incorrect: Enforced GPOs have no impact on cached GPOs.
Objective 4.4: Thought experiment
1. By placing each user class in its own OU, you can delegate different permissions to each type of user.
2. Active Directory quotas meet this requirement perfectly.
3. Creating a security group containing these corporate administrators and giving them permissions over the AdminSDHolder gives the appropriate permissions over these restricted groups.
4. There are two solutions: You can either increase the user’s quota or change the owner of the objects that were created by the user, ideally through an automated method such as a script.
Objective 4.4: Review
1. Correct answers: A, C
A. Correct: Editing the Security tab directly enables you to configure Active Directory object permissions.
B. Incorrect: Adding a user to a group does not change the permissions on the object.
C. Correct: The Delegation of Control Wizard provides quick and easy access to set permissions on an object in Active Directory.
D. Incorrect: The AdminSDHolder object is used to manage the permissions only on sensitive administrative objects such as Enterprise Admins.
2. Correct answer: C
A. Incorrect: When quotas are assigned to a user through other means, the default quota is not used.
B. Incorrect: When multiple quotas are assigned to a user, the highest quota value is used.
C. Correct: This quota assignment is the highest total of the three assigned to the user, so it is used.
D. Incorrect: When Active Directory quotas are assigned to a user through group membership or directly to the user object, the quota assignation has no bearing on the resulting quota limitations.
3. Correct answer: A
A. Correct: The dsadd quota command is used to assign a quota to a security principal, either a user or a security group.
B. Incorrect: The dsget command can be used to determine the quota assigned to a security principal.
C. Incorrect: PowerShell cmdlets for managing Active Directory quotas are not yet available; dsadd quota should be used.
D. Incorrect: PowerShell cmdlets for managing Active Directory quotas are not yet available; dsadd quota should be used.
4. Correct answers: B, D
A. Incorrect: Renaming a domain does not create new objects within a domain or change object ownership. Quotas should have no bearing on this action.
B. Correct: Domain migrations create or update large numbers of objects in the target domain. The user performing the migration should not be constrained by quotas.
C. Incorrect: DirSync to Azure AD has no impact on user quotas.
D. Correct: Mass user creation through automation such as PowerShell scripts will encounter problems if quotas are reached.
5. Correct answer: D
A. Incorrect: A reboot is not needed to make the admin tools available.
B. Incorrect: The RSAT for Windows 8 and Windows 8.1 do not require you to enable the tools after installation.
C. Incorrect: You do not need to update Group Policy after installing RSAT.
D. Correct: Installing RSAT should be the only step needed to gain access to the tools.
6. Correct answer: B
A. Incorrect: Changing the object’s ACL directly results in it being overwritten within an hour.
B. Correct: Modifying the ACL on the AdminSDHolder object results in the object’s ACL being configured correctly.
C. Incorrect: The Delegation of Control Wizard edits only the ACL of the object, resulting in the ACL reverting to its prior state.
D. Incorrect: The Run As Administrator option does not have any result on the object’s ACL.
7. Correct answer: D
A. Incorrect: Active Directory Users And Computers cannot be used to define permissions on the AdminSDHolder object.
B. Incorrect: You cannot use the Active Directory Administrative Center (ADAC) to configure the ACL of the AdminSDHolder object.
C. Incorrect: Permissions on the AdminSDHolder object cannot be configured using the Delegation of Control Wizard.
D. Correct: ADSI Edit should be used to configure permissions on the AdminSDHolder object.
8. Correct answer: C
A. Incorrect: Kerberos delegations do not affect object permissions in Active Directory.
B. Incorrect: Kerberos delegations are not used in conjunction with realm trusts.
C. Correct: Delegations enable a computer to authenticate as a user.
D. Incorrect: Kerberos delegations do not provide authentication to UNIX users.
9. Correct answer: B
A. Incorrect: Kerberos constrained delegation to individual computers has been supported since Windows Server 2003.
B. Correct: Limiting Kerberos constrained delegation to individual services is a new feature in Windows Server 2012.
C. Incorrect: Configuring delegation with PowerShell is not a new feature in Windows Server 2012.
D. Incorrect: Cross-domain Kerberos constrained delegation has been supported since Windows Server 2003.