Training Guide Configuring Advanced Windows Server 2012 R2 Services(2014)
Chapter 1. Advanced Active Directory infrastructure
If you are the administrator of a medium to large organization, it is likely that you are responsible for managing multiple domains, perhaps even multiple forests, rather than managing a single domain forest. In this chapter you discover how and why you would configure forests with multiple domain trees and the benefits of each functional level. You also find out how to configure and manage different types of trust relationships to ensure users in one forest or domain are granted appropriate access to resources in another forest, domain, or Kerberos realm.
Lessons in this chapter:
Lesson 1: Configuring domains and forests
Lesson 2: Configuring trusts
Before you begin
To complete the practice exercises in this chapter, you need to have deployed computers SYD-DC, MEL-DC, CBR-DC, and ADL-DC as described in the Introduction, using the evaluation edition of Windows Server 2012 R2.
Lesson 1: Configuring domains and forests
As an experienced administrator you’re probably quite familiar with the configuration of single domain Active Directory forests. In this lesson, you find out more about multidomain and multiforest environments. You discover how to upgrade an existing domain and forest so that it uses only Windows Server 2012 R2 domain controllers, and you find out how to configure UPN suffixes.
After this lesson, you will be able to:
Understand multidomain Active Directory environments
Understand multiforest Active Directory environments
Upgrade existing domains and forests
Configure multiple user principal name (UPN) suffixes
Estimated lesson time: 45 minutes
Multidomain Active Directory environments
The majority of current Active Directory de ployments in small-sized and medium-sized enterprises have a single domain. This hasn’t always been the case because earlier versions of the Windows Server operating system, such as Windows NT 4.0, supported far fewer accounts. Supporting a smaller number of accounts often necessitated the use of multiple domains, and it wasn’t unusual to see medium-sized organizations that used complicated domain structures.
Each Windows Server 2012 and Windows Server 2012 R2 domain controller can create approximately 2.15 billion objects during its lifetime, and each domain supports the creation of up to approximately 2.15 billion relative identifiers (RIDs). Given this, however, few administrators implement multiple domain forests because they need to support a large number of users. Of course, in very large organizations, the replication load between sites might make a domain with several hundred thousand user accounts problematic, but site and replication considerations are covered in Chapter 2, “Active Directory Sites and Replication.”
There are many reasons why organizations implement multidomain forests. These can include but are not limited to:
Historical domain structure Even though newer versions of the Windows Server operating system handle large numbers of objects more efficiently, some organizations have retained the forest structure that was established when the organization first adopted Active Directory.
Organizational or political reasons Some organizations are conglomerates, and they might be comprised of separate companies that share a common administrative and management core. An example of this is a university faculty in Europe or Australia, such as a Faculty of Science, that is comprised of different departments or schools, such as the school of physics and the department of botany. For political or organizational reasons it might have been decided that each department or school should have its own domain that is a part of the overall faculty forest. Active Directory gives organizations the ability to create domain namespaces that meet their needs, even if those needs might not directly map to the most efficient way of accomplishing a goal from a strict technical perspective.
Security reasons Domains enable you to create authentication and authorization boundaries. You can also use domains to partition administrative privileges so that you can have one set of administrators who are able to manage computers and users in their own domain, but who are not able to manage computers and users in a separate domain. Although it’s possible to accomplish a similar goal by delegating privileges, many organizations prefer to use separate domains to accomplish this goal.
Real World: Politics trumps technology
It is very important to understand that geeks often see technology as something completely separate from organizational politics, with the most efficient technical solution being the best, but everyone else doesn’t necessarily share this perception. When I worked as a systems administrator at an Australian University, there was a shared room in one building that hosted two different printers used by different departments, even though the departments were part of the same faculty. People in each department felt strongly that the printer should be labeled with a departmental identity on the network and that users from one department should, under no circumstances, be able to print to the printer owned by the other department. Although the machinations of interdepartmental politics are usually of little interest to the geeks in the information technology (IT) department, administrators who ignore unclearly defined boundaries do so at their own peril.
Domain trees
A domain tree is a set of names that share a common root domain name. For example contoso.com can have pacific.contoso.com and atlantic.contoso.com as child domains, and these domains can have child domains themselves. A forest can have multiple domain trees. When you create a new tree in a forest, the root of the new tree is a child domain of the original root domain. In Figure 1-1, adatum.com is the root of new domain tree in the contoso.com forest.
FIGURE 1-1 Contoso.com as the root domain in a two-tree forest
The depth of a domain tree is limited by a domain having maximum fully qualified domain name (FQDN) length for a host of 64 characters.
Intraforest authentication
All domains within the same forest automatically trust one another. This means that in the environment shown in Figure 1-1, you can assign a user in the Australia.pacific.contoso.com permissions to a resource in the arctic.adatum.com domain without performing any extra configuration.
Because of the built-in automatic trust relationships, a single forest implementation is not appropriate for separate organizations, even when they are in partnership with one another. A single forest makes it possible for one or more users to have administrative control. Most organizations aren’t comfortable even with trusted partners having administrative control over their IT environments. When you do need to allow users from partner organizations to have access to resources, you can configure trust relationships or federation. You read more about trust relationships in Lesson 2 of this chapter and more about federation in Chapter 10, “Active Directory Federation Services.”
Domain functional levels
Domain functional levels determine the Active Directory functionality and features that are available. The higher the domain functional level is, the more functionality and features are available.
You can use Windows Server 2012 domain controllers with the following domain functional levels:
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
You can use Windows Server 2012 R2 domain controllers with the following domain functional levels:
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
The limiting factor on a domain functional level is the domain controllers used to host Active Directory. If your organization has Windows Server 2003 domain controllers, you aren’t able to raise the functional level until you replace or upgrade those domain controllers to a more recent version of the Windows Server operating system.
You can alter the domain functional level using the Active Directory Users And Computers console, the Active Directory Domains And Trusts console as shown in Figure 1-2, or the SetADDomainMode Windows PowerShell cmdlet. Your account needs to be a member of the Domain Admins or Enterprise Admins groups to perform this operation.
FIGURE 1-2 Raise or verify the domain functional level
Windows Server 2003 Functional Level
The Windows Server 2003 domain functional level is the lowest level at which you can introduce domain controllers running the Windows Server 2012 or Windows Server 2012 R2 operating system. You can set this functional level if you have domain controllers running the Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 operating systems. The Windows Server 2003 domain functional level includes the following features, which are also available at higher domain functional levels:
The LastLogonTimestamp attribute records a user’s last domain logon.
Constrained delegation enables applications to securely delegate user credentials.
Selective authentication enables you to configure specific resources in the forest so that only certain users and groups can authenticate. The default is to allow all users in the forest to authenticate before permissions to those resources are checked.
Support for storing DNS zones in custom application partitions enables you to selectively replicate DNS zones to specific domain controllers that are enrolled in the custom partitions, rather than requiring that you configure replication to all domain controllers in the domain or the forest.
Attribute-level replication for group and other multivalued attributes. Rather than replicating the whole Active Directory object, only altered attributes will be replicated.
Windows Server 2008 Functional Level
The Windows Server 2008 domain functional level requires that all domain controllers be running the Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 or Windows Server 2012 R2 operating systems. The Windows Server 2008 domain functional level includes all of the features available at the Windows Server 2003 functional level as well as the following:
Improvements in Distributed File System (DFS) replication that make it possible for replication to occur more efficiently
Support for fine-grained password policies, which enables you to apply multiple separate password policies within the same domain
Support for personal virtual desktops through RemoteApp and Remote Desktop when used with Hyper-V
AES (Advanced Encryption Services) 128 and 256 Kerberos support
Windows Server 2008 R2 Functional Level
The Windows Server 2008 R2 domain functional level requires that all domain controllers are running the Windows Server 2008 R2, Windows Server 2012 or Windows Server 2012 R2 operating systems. This functional level supports the features of the Windows Server 2003 and Windows Server 2008 domain functional levels as well as:
Managed service account support, which enables you to automatically manage service account passwords rather than manually managing them
Support for command-line-based Active Directory Recycle Bin if the forest functional level is raised to Windows Server 2008 R2
Windows Server 2012 Functional Level
The Windows Server 2012 domain functional level requires that all domain controllers be running the Windows Server 2012 or Windows Server 2012 R2 operating system. This functional level supports the features of all the lower functional levels as well as:
Group Managed Service Accounts Enables you to install a single managed service account on multiple computers.
Fine-Grained Password Policies Supports the Active Directory Administrative Center rather than by editing them using ADSI Edit.
Active Directory Recycle Bin Supports through Active Directory Administrative Center rather than through command-line utilities if the forest is configured at the Windows Server 2012 forest functional level.
Key Distribution Center (KDC) In addition to support for claims, compound authentication, and Kerberos armoring is set to always provide claims or fail unarmored authentication requests, and they aren’t available unless the domain is raised to the Windows Server 2012 functional level.
Windows Server 2012 R2 Functional Level
The Windows Server 2012 R2 domain functional level requires that all domain controllers be running the Windows Server 2012 R2 operating system. This functional level supports the features of all the lower functional levels as well as:
Domain controller side protection for Protected Users Protected Users authenticating against a Windows Server 2012 R2 domain controller are not able to use NTLM authentication, DES or RC4 cipher suites, cannot be delegated with constrained or unconstrained delegation, and cannot renew user tickets beyond the initial four-hour lifetime.
Authentication policies These are new forest-based policies, which you can apply to accounts in domains that control the member computers that a user or service account can sign-on from. These policies also allow you to apply access control conditions for authentication to services running as an account.
Authentication policy silos These silos allow you to create relationships between user, computer, and managed service accounts for the purposes of applying authentication policies or implementing authentication isolation.
Forest functional levels
A forest can host domains running at different domain functional levels. Forest functional level is dependent on the minimum domain functional level of any domain in your forest. For example, if your organization has one domain running at the Windows Server 2008 functional level and all other domains running at the Windows Server 2012 functional level, you can’t raise the forest functional level beyond Windows Server 2008. After you raise that one domain from the Windows Server 2008 functional level to the Windows Server 2012 domain functional level, you’re also able to raise the forest functional level to Windows Server 2012. When you raise the forest functional level, you limit the domain functional levels that can be added to the forest in the future. For example, if the forest functional level is set to Windows Server 2012 R2, all new domains added to the forest must also be set to the Windows Server 2012 R2 domain functional level. The Windows Server 2012 and Windows Server 2012 R2 forest functional levels don’t introduce any new features beyond those that were available at the Windows Server 2008 R2 functional level. The Windows Server 2008 R2 functional level introduced the ability to implement the Active Directory Recycle Bin, but otherwise has the same features as the Windows Server 2003 and Windows Server 2008 forest functional levels.
More Info: Functional levels
To learn more about functional levels, consult the following article: http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx.
You can raise the forest functional level using the Active Directory Domains and Trusts console, as shown in Figure 1-3, or using the Set-ADForestMode Windows PowerShell cmdlet. You need to use a user account that is a member of the Enterprise Admins group to perform this task. In general you can’t lower the forest functional level after you’ve raised it. The exception to this rule is that you can lower the forest functional level from Windows Server 2012 to Windows Server 2008 R2 if you haven’t enabled Active Directory Recycle Bin.
FIGURE 1-3 Raise the forest functional level
Although Active Directory Recycle Bin becomes available at the Windows Server 2008 R2 forest functional level, you need to have configured your organization’s forest to be running at the Windows Server 2012 or Windows Server 2012 R2 forest functional level to be able to use the Active Directory Administrative Center interface as opposed to the command-line interface.
Quick check
What is the minimum forest functional level that enables you to implement Active Directory Recycle Bin?
Quick check answer
You can implement Active Directory Recycle Bin at the Windows Server 2008 R2 forest functional level.
Multiforest Active Directory environments
Not only do many organizations have more than one domain in their forest, but some organizations have multiple Active Directory forests. Multiple forests often result when organizations merge, during the period before the acquiring organization has subsumed the acquired organization’s infrastructure.
Other reasons for having multiple Active Directory forests within a single organization include:
Security requirements You can ensure that administrators of one part of the organization have no rights over another part of the organization by having each part of the organization in a separate forest.
Incompatible schemas All domains in a forest share a schema. If two separate schemas are required for two different parts of the organization, it is necessary to implement multiple forests.
Political requirements Multinational organizations might have to deal with different jurisdictional requirements. It might be simpler to meet these requirements by having separate forests with trust relationships than it is to attempt to configure domains within the same forest to meet these different compliance benchmarks.
Upgrading existing domains and forests
You can use one of two strategies when upgrading an existing domain so that you can configure it at the Windows Server 2012 R2 functional level:
The first strategy is to upgrade the operating systems on each domain controller to Windows Server 2012 R2. This method can be problematic because many organizations are running Windows Server 2003 on domain controllers, and you can’t directly upgrade Windows Server 2003 to Windows Server 2012 R2. It’s also likely that existing domain controllers are running an x86 version of a Windows Server operating system. Windows operating systems never support direct upgrades from x86 versions to x64 versions.
You can introduce Windows Server 2012 R2 domain controllers into an existing domain and then decommission existing domain controllers running earlier versions of the Windows Server operating system. This method is less complex than performing a direct upgrade. If the hardware supports it, you can repurpose the existing hardware so that the decommissioned domain controllers have a new purpose as Windows Server 2012 R2 domain controllers (although an increasing number of organizations have domain controllers run on virtual machines).
Unlike previous domain controller upgrades, you don’t need to run adprep.exe directly to prepare Active Directory for the introduction of domain controllers running Windows Server 2012 or Windows Server 2012 R2. Instead, if you promote the first Windows Server 2012 or Windows Server 2012 R2 domain controller using an account that is a member of the Schema Admins and Enterprise Admins group, the schema upgrade occurs automatically. You need to run adprep.exe separately only if you are performing an in-place upgrade of a domain controller running an x64 version of Windows Server 2008 or Windows Server 2008 R2 and if this upgraded domain controller will be the first Windows Server 2012 or Windows Server 2012 R2 domain controller in the domain.
Note: Active Directory Migration Tool
The Active Directory Migration Tool can assist you in migrating from an existing Active Directory environment rather than upgrading an existing environment. Version 3.2 of the Active Directory Migration Tool isn’t supported on Windows Server 2012 or Windows Server 2012 R2.
User principal name (UPN) suffixes
User principal name (UPN) suffixes are the part of a user’s UPN that trails the @ symbol. For example, in the UPN don_funk@contoso.com, the UPN suffix is the domain name contoso.com. UPN suffixes enable users to sign on using an account name that includes the name of their domains. Because UPN suffixes look like email addresses, users find them easy to remember. This is useful in complex environments where users might be logging on to computers that are members of domains that are different from the domains that host their accounts. For example, Kim Aker’s user account might be located in the accounts.contoso.com domain, but she needs to sign on to a computer that is a member of the computers.contoso.com domain. Rather than having to sign on as accounts\kim_akers as her user name, or selecting the accounts domain from a list, she can instead sign on using the UPN of kim_akers@contoso.com.
By default, all users use the UPN suffix that is the name of the forest root domain, even if their accounts are in a child domain. You configure UPN suffixes using the Active Directory Domains And Trusts console as shown in Figure 1-4.
FIGURE 1-4 Configure alternative UPN suffixes
You can configure the UPN suffix associated with a specific user account on the Account tab of the user account’s properties through the Active Directory Users And Computers console as shown in Figure 1-5. When you are configuring forest trusts, you can block or allow user authentication based on the UPN suffix.
FIGURE 1-5 Configure a specific UPN suffix
More Info: UPN suffixes
To learn more about UPN suffixes, consult the following article: http://technet.microsoft.com/en-us/library/cc772007.aspx.
Lesson summary
A forest can contain multiple domains. Domain trees build on the same namespace. A forest can contain multiple domain trees.
No hostname in an Active Directory forest can exceed 64 characters.
The domain functional level is dependent on the earliest version of the Windows Server operating system used on a domain controller in a domain.
A domain functional level defines the minimum version of the Windows Server operating system that can be used on domain controllers.
Each domain in a forest can have a different functional level. The forest functional level depends on the lowest domain functional level in the forest.
You can configure custom UPN suffixes to simplify the sign-on process for users in multidomain and multiforest environments.
Lesson review
Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of each answer choice in the “Answers” section at the end of this chapter.
1. You are in the process of designing a new Active Directory implementation for your organization. Two different departments in your organization will be adopting applications that have separate and mutually exclusive Active Directory schema requirements. Which of the following Active Directory structures should you use in your design to accommodate these requirements?
A. A single forest with a single domain tree
B. A single forest with multiple domain trees
C. Multiple forests
D. A single domain forest
2. You are the systems administrator for Tailspin Toys and its subsidiary company Wingtip Toys. You are in the process of designing a new Active Directory structure. You’ve been asked to ensure that employees who work in the Tailspin Toys part of the organization log into a domain named tailspintoys.com and that employees who work in the Wingtip Toys part of the organization log into a domain named wingtiptoys.com. You want to do this in the simplest way possible and minimize the creation of trust relationships. Which of the following Active Directory structures should you use in your design to accommodate these requirements?
A. A single domain forest
B. Multiple forests
C. A single forest with multiple domain trees
D. A single forest with a single domain tree
3. You want to deploy several domain controllers running the Windows Server 2012 R2 operating system. You will eventually decommission existing domain controllers and bring the domain up to the Windows Server 2012 R2 domain functional level. What is the minimum domain functional level required to support the introduction of domain controllers running the Windows Server 2012 R2 operating system?
A. Windows Server 2003 domain functional level
B. Windows Server 2008 domain functional level
C. Windows Server 2012 domain functional level
D. Windows Server 2012 R2 domain functional level
4. At which forest functional levels is the Active Directory Recycle Bin available? (Choose all that apply.)
A. Windows Server 2012 forest functional level
B. Windows Server 2008 R2 forest functional level
C. Windows Server 2008 forest functional level
D. Windows Server 2003 forest functional level
Lesson 2: Configuring trusts
From time to time it’s necessary to connect two different domains so that users who have accounts in one domain are able to access resources in another domain. If those domains are owned by the same organization, the simplest way of doing this is by configuring a trust. In this lesson, you find out how to configure trusts between two different forests, between two separate domains in different forests, and between a domain and a Kerberos realm.
After this lesson, you will be able to:
Configure external, forest, shortcut, and realm trusts.
Configure trust authentication.
Configure SID filtering.
Configure name suffix routing.
Estimated lesson time: 45 minutes
Trusts
Trusts make it possible for users in one domain to be authenticated by domain controllers in a separate domain. For example, if there is a bidirectional trust relationship between the domains contoso.local and adatum.remote, users with accounts in the contoso.local domain are able to authenticate in the adatum.remote domain. By configuring a trust relationship, it’s possible to allow users in one domain to access resources in another, such as being able to use shared folders and printers or being able to sign on locally to machines that are members of a different domain than the one that holds the user’s account.
Some trusts are created automatically. For example, domains in the same forest automatically trust each other. Other trusts, such as external trusts, realm trusts, shortcut trusts, and forest trusts must be created manually. Trusts use the Kerberos V5 authentication protocol by default, and they revert to NTLM if Kerberos V5 is not supported. You configure and manage trusts using the Active Directory Domains And Trusts console or the netdom.exe command-line utility with the /trust switch.
Real World: Understanding trusts
Although trusts themselves are relatively easy to come to terms with, the terminology around trusts tends to confuse many people. It’s important that you understand the difference between a trusting and a trusted domain and how trust direction, incoming or outgoing, relates to which security principals are able to authenticate.
To understand trusts, you need to understand the difference between a trusting domain or forest and a trusted domain or forest. The trusting domain or forest contains the resources to which you want to grant security principals from the trusted domain or forest access. The trusted domain or forest hosts the security principals that you want to allow to access resources in the trusting forest. For example, if you want to grant users in the adatum.remote domain access to resources in the contoso.local domain, the adatum.remote domain is the trusted domain and the contoso.local domain is the trusting domain. In bidirectional trust relationships a domain or forest is both trusting and trusted.
More Info: Trusts
To learn more about the basics of trusts, consult the following article: http://technet.microsoft.com/en-us/library/cc731335.aspx.
Trust transitivity
A transitive trust is one that extends beyond the original trusting domains. For example, if you have a trust between two domain forests and that trust is transitive, all of the domains in each of the forests trust each other. Forest trusts are transitive by default. External trusts are not transitive by default. When you create a trust, keep in mind that there may be domains beyond the one you are establishing the relationship with that may be included. You might trust the administrator of adatum.remote not to allow access by nefarious users, but do you trust the administrator of subdomain.adatum.remote?
More Info: Trust transitivity
To learn more about trust transitivity, consult the following article: http://technet.microsoft.com/en-us/library/cc754612.aspx.
Trust direction
When you create a new trust, you specify a trust direction as shown in Figure 1-6. You can choose a two-way (or bidirectional) trust or a unidirectional trust, which is either one-way incoming or one-way outgoing.
FIGURE 1-6 Specify the trust direction
When you configure a one-way incoming trust, users in the local are authenticated in the remote domain, realm, or forest. Remember that if you are configuring a one-way incoming trust between the single domain forests contoso.local and adatum.remote, users with accounts in contoso.local are able to access resources in adatum.remote. Similarly if you are configuring a one-way outgoing trust between the single domain forests contoso.local and adatum.remote, users with accounts in adatum.remote are able to access resources hosted in contoso.local.
The terminology around trusts can be a little confusing. The key thing to remember is that the direction of trust is the opposite of the direction of access, as shown in Figure 1-7. An outgoing trust allows incoming access, and an incoming trust allows outgoing access.
FIGURE 1-7 The direction of trust and direction of access
More Info: Trust direction
To learn more about trust direction, consult the following article: http://technet.microsoft.com/en-us/library/cc731404.aspx.
Forest trusts
When you configure a forest trust, one Active Directory forest trusts the other one. Forest trusts are transitive. When you configure a forest trust, you can allow any domain in the trusting forest to be accessible to any security principal in the trusted forest. Forest trusts require that each forest be configured to run at the Windows Server 2003 forest functional level or higher. Forest trusts can be bidirectional or unidirectional. You are most likely to configure forest trusts if your organization has two or more Active Directory forests.
You can configure one of two authentications scopes when you configure a forest trust. The type of authentication scope that you configure depends on your security requirements. The options are:
Forest-wide authentication When you choose forest-wide authentication, users from the trusted forest are automatically authenticated for all resources in the local forest. You should use this option when both the trusted and trusting forests are part of the same organization. Figure 1-8 shows a forest trust configured with this type of authentication.
FIGURE 1-8 Configure the authentication type
Selective authentication When you configure this option, Windows does not automatically authenticate users from the trusted forest. You can then configure specific servers and domains within the forest to allow users from the trusted forest to authenticate. Use this option when the two forests are from different organizations, or you have more stringent security requirements.
Configuring selective authentication
Configuring selective authentication means granting specific security principals in the trusted forest the Allowed to authenticate (allow) permission on the computer that hosts the resource to which you want to grant access. For example, assume you had configured a forest trust with selective authentication. You want to grant users in the Research universal group from the trusted forest access to a Remote Desktop Services (RDS) server in the trusting forest. To accomplish this goal, you can configure the properties of the RDS server’s computer account in Active Directory Users and Computers and grant the Research universal group from the trusted forest the Allowed to authenticate permission as shown in Figure 1-9. Doing this only allows users from this group to authenticate; you still have to grant them access to RDS by adding them to the appropriate local group on the RDS server.
FIGURE 1-9 Configure the Allowed To Authenticate permission
External trusts
External trusts enable you to configure one domain in one forest to trust a domain in another forest without enabling a transitive trust. For example, you configure an external trust if you want to allow the auckland.fabrikam.com domain to have a trust relationship with the wellington.adatum.com domain without allowing any other domains in the fabrikam.com or adatum.com forests to have a security relationship with one another.
More Info: External trusts
To learn more about external trusts, consult the following link: http://technet.microsoft.com/en-us/library/cc732859.aspx.
You can use external trusts to configure trust relationships with domains running unsupported Windows Server operating systems, such as Windows 2000 Server and Windows NT 4.0, because these operating systems do not support forest trusts. Even though these operating systems are well beyond their supported lifespan, there are still organizations out there with servers, and even domains, running these operating systems. It’s possible, however unlikely, that you might need to configure a trust relationship between a domain running these operating systems and one running Windows Server 2012 domain controllers.
Quick check
You are the administrator of the single domain contoso.local forest. Users in the adatum.remote single domain forest need to access resources in the contoso.local domain. Users in contoso.local should not have access to resources in adatum.remote. You are configuring an external trust between these two single domain forests from the contoso.local domain. Which trust direction should you configure to support this configuration?
Quick check answer
One-way outgoing. Remember that the direction of trust is opposite to the direction of authentication. To have incoming users authenticated, you configure an outgoing trust.
Shortcut trusts
Shortcut trusts enable you to speed up authentication between domains in a forest that might be in separate branches or even separate trees. For example, in the hypothetical forest shown in Figure 1-10, if a user in the canada.atlantic.contoso.com domain wants to access a resource in the arctic.adatum.com domain, authentication needs to travel up through the atlantic.contoso.com and contoso.com domains before passing across to the adatum.com domain and finally back to the arctic.adatum.com. If you implement a shortcut trust between the canada.atlantic.contoso.com and arctic.adatum.com domains, authentication traffic instead travels directly between these two domains without having to traverse the two domain trees in the forest.
FIGURE 1-10 Shortcut trust
You configure a shortcut trust using the Active Directory Domains And Trusts console by editing the properties of one domain and triggering the New Trust Wizard on the Trusts tab. When the trust is created, it is listed as a shortcut trust as shown in Figure 1-11. Shortcut trusts can be unidirectional or bidirectional. As is the case with the creation of other trusts, ensure that you have name resolution working properly between the trusting and the trusted domains either by having the Domain Name System (DNS) zones propagate through the forest, by configuring conditional forwarders, or by configuring stub zones.
FIGURE 1-11 Trusts tab
Realm trusts
You use a realm trust to create a relationship between an Active Directory Services domain and a Kerberos V5 realm that uses a third-party directory service. Realm trusts can be transitive or nontransitive. They can also be unidirectional or bidirectional. You’re most likely to configure a realm trust when you need to allow users who use a UNIX directory service to access resources in an Active Directory domain or users in an Active Directory domain to access resources in a UNIX Kerberos V5 realm.
You can configure a realm trust from the Active Directory Domains And Trust console. You do this by selecting the Realm trust option as shown in Figure 1-12. When configuring a realm trust, you specify a realm trust password that you use when configuring the other side of the trust in the Kerberos V5 realm.
FIGURE 1-12 Configure the Realm Trust
More Info: Realm trusts
To learn more about realm trusts, consult the following link: http://technet.microsoft.com/en-us/library/cc731297.aspx.
Netdom.exe
You use Netdom.exe with the /trust switch to create and manage trusts from the command line. When using Netdom.exe, you specify the trusting domain name and the trusted domain name. You can use Netdom.exe with the /trust switch to create and manage forest, shortcut, realm, and external trusts.
The syntax of the Netdom.exe command with the trust switch is shown in Figure 1-13.
FIGURE 1-13 The command syntax for Netdom.exe
At release, Windows PowerShell in Windows Server 2012 and Windows Server 2012 R2 does not include much in the way of cmdlets for creating and managing trust relationships beyond the Get-ADTrust cmdlet.
SID filtering
In a trusted domain, it’s possible, though extremely difficult, for you to configure an account in your domain to have SIDs that are identical to those used by privileged accounts in a trusting domain. If you use this configuration, then the accounts from trusted domains gain the privileges of the accounts in the trusting domain. For example, you can configure the SIDs of an account in a trusted domain so that it has domain administrator privileges in the trusting domain.
To block this type of configuration, Windows Server 2012 and Windows Server 2012 R2 enable SID filtering, also known as domain quarantine, on all external trusts. SID filtering blocks users in a trusted forest or domain from being able to grant themselves elevated user rights in the trusting forest domain by discarding all SIDs that do not have the domain SID of the trusting domain.
It’s possible to verify SID filtering settings on a trust using the Get-ADTrust cmdlet in a Windows PowerShell session run by a user with administrative privileges. For example, to verify that SID filtering is enabled on the trust with the margiestravel.com forest, issue the command:
Get-ADTrust margiestravel.com | fl *SID*
To disable SID filtering for the trusting forest, use the netdom trust command with the following option:
/enablesidhistory:Yes
Enabling SID history allows SIDs that don’t have the domain SID of the trusting domain. You enable or disable SID filtering on the trusting side of the trust. For example, if you are an administrator in the contoso.com domain and you want to disable SID filtering, you can issue the following command from an elevated command prompt:
Netdom trust contoso.com /domain:margiestravel.com /enablesidhistory:Yes
In the same scenario, if you want to re-enable SID filtering, you can issue the following command:
Netdom trust contoso.com /domain:margiestravel.com /enablesidhistory:Yes
The default configuration, where SID filtering is enforced by default on trusts, is something that you should probably leave as it is. In the past it was necessary to allow SID history when trusts were created with forests running Windows 2000 Server domain controllers. As Windows 2000 is no longer supported by Microsoft, and SID history is not necessary for trust relationships with Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 or Windows Server 2012 R2 domain controllers, you probably won’t need to disable it.
More Info: SID filter quarantining on external trusts
To learn more about SID filtering, consult the following link: http://technet.microsoft.com/en-us/library/cc794757(v=ws.10).aspx.
Name suffix routing
Name suffix routing enables you to configure how authentication requests are routed when you configure a forest trust between two Active Directory forests. When you create a forest trust, all unique name suffixes are routed. Name suffix routing assists users when they sign on with a UPN, such as don_funk@contoso.com. Depending upon the UPNs that are configured, you might want to allow or disallow the use of specific UPN suffixes. You do this by configuring name suffix routing on the Name Suffix Routing tab of the trust’s properties as shown in Figure 1-14.
FIGURE 1-14 Configure name suffix routing
More Info: Name suffix routing
To learn more about name suffix routing, consult the following link: http://technet.microsoft.com/en-us/library/cc731648.aspx.
Lesson summary
Trusts can be unidirectional or bidirectional. A one-way outgoing trust allows users in the remote domain to access resources in the local domain. A one-way incoming trust allows users in the local domain to access resources in the remote domain.
Trust transitivity allows access to resources in child domains of the trusting domain.
A forest trust allows one forest to trust another forest. This means that all domains in the first forest have a trust relationship with all domains in the second forest.
Selective authentication in a forest trust enables you to limit which users and groups from the trusted domain are able to authenticate.
An external trust is a trust between domains in different forests. External trusts are not transitive. You can configure external trusts to connect to Windows 2000 Server and Windows NT 4 domains.
You use a realm trust when you want to configure a trust between an Active Directory domain and a Kerberos V5 realm.
You can use a shortcut trust between domains in the same forest to speed the authentication process.
SID filtering is enabled by default on all new external and forest trusts.
You can configure name suffix routing to configure which users are able to authenticate in a forest.
Lesson review
Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of each answer choice in the “Answers” section at the end of this chapter.
1. You have a 30-domain Active Directory forest that has contoso.com as its root domain. This forest has five separate domain trees. Users in the Melbourne.australia.pacific.contoso.com domain report that there are substantial authentication delays when they try to access resources in the Auckland.newzealand.adatum.com domain. Both domains are located in the same forest. Which of the following trust types would you configure to resolve this problem?
A. Forest trust
B. External trust
C. Realm trust
D. Shortcut trust
2. You are a systems administrator at a local university. The university has a deployment of Linux servers and workstations that are members of a Kerberos V5 realm. You want to allow users of the Linux workstations to have access to several file shares hosted in one of your organization’s Active Directory domains. Which of the following trust types would you implement to accomplish this goal?
A. Shortcut trust
B. Realm trust
C. Forest trust
D. External trust
3. Your organization recently acquired a subsidiary company. Your organization currently has a 10-domain Active Directory forest running at the Windows Server 2012 R2 functional level. The subsidiary company has a five-domain Active Directory forest running at the Windows Server 2008 functional level. The subsidiary company has implemented a number of schema modifications to support a custom application. You want to allow users in the subsidiary company to be able to access resources hosted in your organization’s forest. Users in your organization’s forest should also be able to access resources in the subsidiary company’s forest. Which of the following trust relationships should you configure to accomplish this goal?
A. External trust
B. Forest trust
C. Realm trust
D. Shortcut trust
4. You are the senior systems administrator of the contoso.com forest. Users in the australia.pacific.contoso.com domain need access to resources hosted in one domain of a partner organization’s Active Directory forest. These users shouldn’t have access to any other domain in the partner organization’s forest. Users from other domains in your organization’s forest should also not have access to resources in the partner organization’s forest. Which of the following trust types would you configure in this scenario?
A. External trust
B. Realm trust
C. Shortcut trust
D. Forest trust
Practice exercises
The goal of this section is to provide you with hands-on practice with the following:
Creating a forest trust
Configuring name suffix routing
Configuring selective authentication
Configuring UPN suffixes
Configuring a shortcut trust
To perform the exercises in this section, you need access to an evaluation version of Windows Server 2012 R2. You should also have access to virtual machines SYD-DC, MEL-DC, CBR-DC, and ADL-DC, the setup instructions for which are described in the Introduction. You should ensure that you have a checkpoint of these virtual machines that you can revert to at the end of the practice exercises.
Exercise 1: Prepare a domain controller to host a child domain with a contiguous namespace
In this exercise, you prepare CBR-DC to function as a domain controller for a child domain of the contoso.com domain. To complete this exercise, perform the following steps:
1. Power on SYD-DC and log in as contoso\don_funk with the password Pa$$w0rd.
2. Click the Tools menu in the Server Manager console, and click DNS.
3. In the DNS Manager console, expand SYD-DC and Forward Lookup Zones.
4. Verify that the following lookup zones are present as shown in Figure 1-15:
_msdcs.contoso.com
contoso.com
FIGURE 1-15 Verify the DNS configuration
5. Power on CBR-DC and sign on as Administrator with the password Pa$$w0rd.
6. In Server Manager, click the Local Server node.
7. In the Properties area, click 10.10.10.30 next to Ethernet.
8. In the Network Connections window, right-click Ethernet and click Properties.
9. In the Ethernet Properties dialog box, click Internet Protocol Version 4 (TCP/IPv4) and click Properties.
10. Verify that the Preferred DNS Server is set to 10.10.10.10, as shown in Figure 1-16, click OK, and then click Close.
FIGURE 1-16 Verify the Internet Protocol (IP) address configuration
11. In the Server Manager console, click Manage and then click Add Roles And Features.
12. On the Before You Begin page of the Add Roles And Features Wizard, click Next three times.
13. On the Select Server Roles page, click the Active Directory Domain Services check box as shown in Figure 1-17.
FIGURE 1-17 Add the AD DS role
14. On the Add Roles And Features Wizard, click Add Features.
15. On the Select Server Roles page, click Next three times and click Install. When the installation completes, click Close.
Exercise 2: Create a child domain with a contiguous namespace
In this exercise, you configure CBR-DC to host the Canberra.contoso.com child domain. To complete this exercise, perform the following steps:
1. In the Server Manager console on CBR-DC, click the Notifications item and then click Promote This Server To A Domain Controller.
2. On the Deployment Configuration page, click Add A New Domain To An Existing Forest.
3. On the Select Domain Type drop-down menu, select Child Domain.
4. Click Select next to Parent Domain Name.
5. In the Windows Security dialog box, type the user name contoso\don_funk, type the password Pa$$w0rd, and click OK.
6. In the Select A Domain From The Forest dialog box, click Contoso.com as shown in Figure 1-18 and then click OK.
FIGURE 1-18 Select the domain in the forest
7. In the New Domain Name text box, type the name Canberra as shown in Figure 1-19 and then click Next.
FIGURE 1-19 Configure the Child Domain
8. On the Domain Controller Options page, set the DSRM password as Pa$$w0rd in both the Password and Confirm Password dialog boxes and click Next.
9. On the DNS Options page, ensure that the settings match those in Figure 1-20 and click Next.
FIGURE 1-20 Configure the delegation credentials
10. On the Additional Options page, verify that the NetBIOS domain name is set to CANBERRA, click Next three times, and click Install.
11. After CBR-DC restarts, sign on as Canberra\Administrator with the password Pa$$w0rd.
12. Switch to SYD-DC. In the DNS console, expand the contoso.com zone and verify the presence of the canberra.contoso.com zone as shown in Figure 1-21.
FIGURE 1-21 Verify the DNS zone
Exercise 3: Prepare domain controller to host the wingtiptoys.com tree in the contoso.com forest
In this exercise, you prepare computer ADL-DC so that it can be promoted to a domain controller. To complete this exercise, perform the following steps:
1. Sign on to ADL-DC as Administrator with the password Pa$$w0rd.
2. In Server Manager, click the Local Server node.
3. In the Properties area, click 10.10.10.20 next to Ethernet.
4. In the Network Connections window, right-click Ethernet and click Properties.
5. In the Ethernet Properties dialog box, click Internet Protocol Version 4 (TCP/IPv4) and click Properties.
6. Verify that the Preferred DNS server is set to 10.10.10.10 and then click OK. Click Close.
7. In the Server Manager console, click Manage and then click Add Roles And Features.
8. On the Before You Begin page of the Add Roles And Features Wizard, click Next three times.
9. On the Select Server Roles page, click the Active Directory Domain Services check box.
10. On the Add Roles And Features Wizard, click Add Features.
11. On the Select Server Roles page, click Next three times and click Install. When the installation completes, click Close.
Exercise 4: Promote domain controller for new tree in contoso.com forest
In this exercise, you promote ADL-DC to domain controller of a new domain tree in an existing Active Directory forest. To complete this exercise, perform the following steps:
1. In the Server Manager console on ADL-DC, click the Notifications item and then click Promote This Server To A Domain Controller.
2. On the Deployment Configuration page, click Add A New Domain To An Existing Forest.
3. On the Select Domain Type drop-down menu, click Tree Domain.
4. In the Forest Name textbox, type contoso.com.
5. In the New Domain Name textbox, type wingtiptoys.com.
6. Next to <No Credentials Provided>, click Change.
7. On the Windows Security dialog box, type the user name as contoso\don_funk, type the password as Pa$$w0rd, and click OK.
8. Verify that the Deployment Configuration page matches Figure 1-22 and then click Next.
FIGURE 1-22 Add a domain tree
9. On the Domain Controller Options page, type the DSRM password Pa$$w0rd in both the Password and Confirm Password text boxes and then click Next.
10. On the DNS Options page, review the warning and click Next.
11. On the Additional Options page, verify that the NetBIOS name is set to WINGTIPTOYS as shown in Figure 1-23. Click Next three times and then click Install.
FIGURE 1-23 Verify the NetBIOS name
12. After the computer restarts, sign in as WINGTIPTOYS\Administrator with the password Pa$$w0rd.
Exercise 5: Prepare a domain controller to host a new forest
In this exercise, you configure MEL-DC so that it is able to host the new forest margiestravel.com. To complete this exercise, perform the following steps:
1. Sign on to MEL-DC as Administrator with the password Pa$$w0rd.
2. In Server Manager, click the Local Server node.
3. In the Properties area, click 10.10.10.40 next to Ethernet.
4. In the Network Connections window, right-click Ethernet and click Properties.
5. In the Ethernet Properties dialog box, click Internet Protocol Version 4 (TCP/IPv4) and click Properties.
6. Verify that the Preferred DNS server is set to 10.10.10.10, click OK, and then click Close.
7. In the Server Manager console, click Manage and then click Add Roles And Features.
8. On the Before You Begin page of the Add Roles And Features Wizard, click Next three times.
9. On the Select Server Roles page, click the Active Directory Domain Services checkbox.
10. On the Add Roles And Features Wizard, click Add Features.
11. On the Select Server Roles page, click Next three times and then click Install. When the installation completes, click Close.
Exercise 6: Create new forest
In this exercise, you configure MEL-DC as the first domain controller in a new forest. To complete this exercise, perform the following steps:
1. In the Server Manager console on MEL-DC, click the Notifications item and then click Promote This Server To A Domain Controller.
2. On the Deployment Configuration page, click Add A New Forest.
3. In the Root Domain Name textbox, type margiestravel.com as shown in Figure 1-24 and click Next.
FIGURE 1-24 Adding a new forest
4. On the Domain Controller Options page, ensure that Domain Name System (DNS) server is selected and that you type the DSRM password of Pa$$word twice as shown in Figure 1-25. Click Next twice.
FIGURE 1-25 The Domain Controller Options page
5. On the Additional Options page, verify that the NetBIOS domain name is set to MARGIESTRAVEL, click Next three times, and then click Install.
6. After the server restarts, sign on as MARGIESTRAVEL\Administrator with the password Pa$$w0rd.
Exercise 7: Prepare to configure a forest trust relationship
In this exercise, you configure a forest trust relationship between the contoso.com forest and the margiestravel.com forest. To complete this exercise, perform the following steps:
1. While logged onto SYD-DC as contoso\don_funk, open the DNS Manager console from the Tools menu in the Server Manager console.
2. Right-click Forward Lookup Zones and click New Zone.
3. On the Welcome To The New Zone Wizard page, click Next.
4. On the Zone Type page, click Stub Zone and ensure that the Store The Zone In Active Directory check box is selected as shown in Figure 1-26. Click Next.
FIGURE 1-26 Configure the zone type
5. On the Active Directory Zone Replication Scope page, click To All DNS Servers Running On Domain Controllers In This Forest: contoso.com and click Next.
6. In the Zone Name text box, type margiestravel.com and click Next.
7. On the Master DNS Servers page, type the IP address 10.10.10.40 in the list of master servers as shown in Figure 1-27, click Next, and then click Finish.
FIGURE 1-27 Configure the stub zone master servers
8. On MEL-DC, ensure that you are signed in as MARGIESTRAVEL\Administrator with the password Pa$$w0rd.
9. Open the DNS Manager console from the Tools menu in the Server Manager console.
10. In the DNS Manager console, right-click on Forward Lookup Zones and click New Zone.
11. On the Welcome To The New Zone Wizard page, click Next.
12. On the Zone Type page, click Stub Zone and ensure that the Store The Zone In Active Directory check box is selected. Click Next.
13. On the Active Directory Zone Replication Scope page, click To All DNS Servers Running On Domain Controllers In This Forest: Margiestravel.com as shown in Figure 1-28. Click Next.
FIGURE 1-28 Configure the zone replication scope
14. On the Zone Name page, type the name contoso.com in the Zone Name textbox and click Next.
15. On the Master DNS Servers page, type the IP address 10.10.10.10 in the Master Servers list as shown in Figure 1-29, click Next, and click Finish.
FIGURE 1-29 Configure the master DNS servers
Exercise 8: Begin creating a forest trust relationship
In this exercise, you configure the contoso.com side of a forest trust relationship between the contoso.com and margiestravel.com forests. To complete this exercise, perform the following steps:
1. On the Tools menu of the Server Manager console on SYD-DC, click Active Directory Domains And Trusts.
2. In the Active Directory Domains And Trusts console, right-click Contoso.com and click Properties.
3. On the Trusts tab of the Contoso.com Properties dialog box, shown in Figure 1-30, click New Trust.
FIGURE 1-30 Create the new trust
4. On the Welcome To The New Trust Wizard page, click Next.
5. On the Trust Name page, type margiestravel.com as shown in Figure 1-31, and click Next.
FIGURE 1-31 Set the trust name
6. On the Trust Type page, select the Forest Trust option as shown in Figure 1-32 and click Next.
FIGURE 1-32 Configure the trust type
7. On the Direction Of Trust page, click Two-Way and click Next.
8. On the Sides Of Trust page, click This Domain Only and then click Next.
9. On the Outgoing Trust Authentication Level page, click the Forest-Wide Authentication option as shown in Figure 1-33 and click Next.
FIGURE 1-33 Configure the trust authentication level
10. On the Trust Password page, type Pa$$w0rd in the Trust Password and Confirm Trust Password text boxes. Click Next three times.
11. On the Confirm Outgoing Trust page, click No, Do Not Confirm The Outgoing Trust and click Next.
12. On the Confirm Incoming Trust page, click No, Do Not Confirm The Incoming Trust, click Next, and click Finish.
Exercise 9: Complete the creation of the forest trust relationship between contoso.com and margiestravel.com
In this exercise, you configure the margiestravel.com side of a forest trust relationship between the contoso.com and margiestravel.com forests. To complete this exercise, perform the following steps:
1. In the Tools menu of the Server Manager console on MEL-DC, click Active Directory Domains And Trusts.
2. In the Active Directory Domains And Trusts console, right-click Margiestravel.com and click Properties.
3. On the Trusts tab of the Margiestravel.com Properties dialog box, shown in Figure 1-34, click New Trust.
FIGURE 1-34 View the current trusts
4. On the Welcome To The New Trust Wizard page, click Next.
5. On the Trust Name page of the New Trust Wizard, type contoso.com in the Name text box and click Next.
6. On the Trust Type page, click Forest Trust and click Next.
7. On the Direction Of Trust page, click Two-Way as shown in Figure 1-35 and click Next.
FIGURE 1-35 Configure the direction of the trust
8. On the Sides Of Trust page, click This Domain Only and click Next.
9. On the Outgoing Trust Authentication Level page, click Forest-Wide Authentication and click Next.
10. On the Trust Password page, type Pa$$w0rd in the Trust Password and Confirm Trust Password text boxes. Click Next three times.
11. On the Confirm Outgoing Trust page, click Yes, Confirm the Outgoing Trust as shown in Figure 1-36, and click Next.
FIGURE 1-36 Confirm the outgoing trust
12. On the Confirm Incoming Trust page, click Yes, Confirm The Incoming Trust. In the User Name text box, type contoso\don_funk and in the Password text box type Pa$$w0rd as shown in Figure 1-37. Click Next.
FIGURE 1-37 Confirm the incoming trust
13. On the Completing The New Trust Wizard page verify that the trust is successfully created as shown in Figure 1-38 and click Finish. Click OK to close the Margiestravel.com Properties dialog box.
FIGURE 1-38 Confirm the trust creation
Exercise 10: Configure name suffix routing
In this exercise, you configure the forest trust between the margiestravel.com forest and the contoso.com forest so that name suffix routing is supported for the wingtiptoys.com domain tree. To complete this exercise, perform the following steps:
1. In the Active Directory Domains and Trusts console on MEL-DC, right-click Margiestravel.com and click Properties.
2. On the Trusts tab of the Margiestravel.com Properties dialog box, click Contoso.com in the Domains Trusted By This Domain (Outgoing Trusts) area, as shown in Figure 1-39, and then click Properties.
FIGURE 1-39 Editing the properties of trusts
3. On the Name Suffix Routing tab of the Contoso.com Properties dialog box, click *.wingtiptoys.com and then click Enable as shown in Figure 1-40.
FIGURE 1-40 Configure the Name Suffix Routing
4. On the General tab of the Contoso.com Properties dialog box, click Validate.
5. On the Active Directory Domain Services dialog box, click Yes, Validate The Incoming Trust by entering the user name contoso\don_funk and the password Pa$$w0rd, and click OK.
6. Click OK on the Active Directory Domain Services dialog box and then click Yes on the second Active Directory Domain Services dialog box.
7. Click OK to close the Contoso.com Properties dialog box.
8. Click Contoso.com on the list of Domains That Trust This Domain (Incoming Trusts) dialog box as shown in Figure 1-41 and then click Properties.
FIGURE 1-41 Trusts for the margiestravel.com domain
9. On the Name Suffix Routing tab of the Contoso.com Properties dialog box verify that both *.contoso.com and *.wingtiptoys.com are enabled and then click OK.
10. Click OK to close the Margiestravel.com Properties dialog box.
Exercise 11: Configure selective authentication
In this exercise, you configure selective authentication. You configure the trust to use selective authentication, create a user group in one forest, and create a computer account in the other forest. You then configure the computer account so that members of the user group in the trusted forest can authenticate when connecting to that computer. To complete this exercise, perform the following steps:
1. When signed on to SYD-DC as contoso\don_funk, click Active Directory Users And Computers on the Tools menu of the Server Manager console.
2. In Active Directory Users And Computers, right-click the Users container, click New, and click Group.
3. On the New Object – Group dialog box, type the group name as Research, set the group scope to Universal as shown in Figure 1-42, and click OK.
FIGURE 1-42 Create a new universal group
4. On MEL-DC, right-click Margiestravel.com in the Active Directory Domains And Trust console and click Properties.
5. On the Trusts tab of the Margiestravel.com Properties dialog box, click Contoso.com in the Domains That Trust This Domain (Incoming Trusts) list and click Properties.
6. On the Authentication tab of the Contoso.com Properties dialog box, click Selective Authentication as shown in Figure 1-43.
FIGURE 1-43 Configure selective authentication
7. On the General tab of the Contoso.com Properties dialog box, shown in Figure 1-44, click Validate.
FIGURE 1-44 Validate authentication
8. On the Active Directory Domain Services dialog box, click Yes to validate the incoming trust. Enter the user name as contoso\don_funk, type the password as Pa$$w0rd, and then click OK twice.
9. Click Yes on the Active Directory Domain Services dialog box and then click OK twice to close the Contoso.com Properties and Margiestravel.com Properties dialog boxes.
10. Click Active Directory Users And Computers in the Tools menu of the Server Manager console.
11. Right-click the Computers node and click New and then click Computer.
12. In the New Object – Computer dialog box, type the name SelectiveAuthRDP as shown in Figure 1-45 and click OK.
FIGURE 1-45 Create new computer object
13. Enabled Advanced Features on the View menu of the Active Directory Users And Computers console.
14. Right-click the SelectiveAuthRDP computer object and click Properties.
15. On the Security tab of the SelectiveAuthRDP Properties dialog box, shown in Figure 1-46, click Add.
FIGURE 1-46 Add a user
16. On the Select Users, Computers, Service Accounts, Or Groups dialog box, click Locations.
17. On the Locations dialog box, click Contoso.com as shown in Figure 1-47 and then click OK.
FIGURE 1-47 The Locations dialog box
18. In the Select Users, Computers, Service Accounts, Or Groups dialog box, type Research, click Check Names, and click OK.
19. On the SelectiveAuthRDP Properties dialog box, click Research (Contoso\Research) and click the Allow check box next to the Allowed To Authenticatepermission as shown in Figure 1-48. Click OK.
FIGURE 1-48 Configure Allowed to authenticate permission
Exercise 12: Configure additional UPN suffixes
In this exercise, you configure additional UPN suffixes. To complete this exercise, perform the following steps:
1. When signed on to SYD-DC as contoso\don_funk, switch to the Active Directory Domains And Trusts console.
2. In the Active Directory Domains And Trusts console, right-click Active Directory Domains And Trusts and click Properties.
3. On the UPN Suffixes tab of the Active Directory Domains And Trusts dialog box, type contoso.internal in the Alternative UPN suffixes dialog box and then click Add as shown in Figure 1-49. Click OK.
FIGURE 1-49 Configure a UPN suffix
Exercise 13: Configure a shortcut trust
In this exercise, you configure a shortcut trust between the Canberra.contoso.com domain and the wingtiptoys.com domain. To complete this exercise, perform the following steps:
1. Sign on to CBR-DC as canberra\administrator.
2. In the Server Manager console, click the Tools menu and then click DNS.
3. In the DNS Manager console, expand CBR-DC, right-click Forward Lookup Zones, and click New Zone.
4. On the Welcome To The New Zone Wizard page, click Next.
5. On the Zone Type page of the New Zone Wizard, click Stub Zone and ensure that the Store The Zone In Active Directory (Available Only If The DNS server Is A Writable Domain Controller) check box is selected as shown in Figure 1-50 and click Next twice.
FIGURE 1-50 Create a stub zone
6. On the Zone name page, type wingtiptoys.com and click Next.
7. On the Master DNS Servers page, type 10.10.10.20 in the list of master DNS servers and press Enter as shown in Figure 1-51. Click Next and then click Finish.
FIGURE 1-51 Configure a master DNS server
8. In the Server Manager console, click the Tools menu and then click Active Directory Domains And Trusts.
9. In the Active Directory Domains And Trusts console, expand the Contoso.com node, right-click Canberra.contoso.com, and click Properties.
10. On the Trusts tab of the Canberra.contoso.com Properties dialog box, show in Figure 1-52, click New Trust.
FIGURE 1-52 Create a new trust
11. On the Welcome To The New Trust Wizard page, click Next.
12. On the Trust Name page of the New Trust Wizard, type wingtiptoys.com and click Next.
13. On the Direction Of Trust page, click Two-Way and click Next.
14. On the Sides Of Trust page, click Both This Domain And The Specified Domain as shown in Figure 1-53 and click Next.
FIGURE 1-53 Configure trust sides
15. On the User Name And Password page, type wingtiptoys\administrator in the user name text box, type Pa$$w0rd in the password text box, and click Next three times.
16. On the Confirm Outgoing Trust page, click Yes, Confirm The Outgoing Trust as shown in Figure 1-54, and click Next.
FIGURE 1-54 Confirm the trust
17. On the Confirm Incoming Trust page, click Yes, Confirm The Incoming Trust and click Next.
18. Verify that the trust relationship was successfully created and click Finish.
19. Verify that the Wingtiptoys.com trust is listed as a shortcut trust as shown in Figure 1-55 and then click OK.
FIGURE 1-55 Verify the trust type
Suggested practice exercises
The following additional practice exercises are designed to give you more opportunities to practice what you’ve learned and to help you successfully master the lessons presented in this chapter.
Exercise 1: Configure additional UPN suffixes for the margiestravel.com forest.
Exercise 2: Use Netdom.exe to disable and then re-enable SID filtering on the margiestravel.com forest.
Answers
This section contains the answers to the lesson review questions in this chapter.
Lesson 1
1. Correct answer: C
A. Incorrect. This structure does not support the two different departments that have mutually exclusive Active Directory schema requirements. This structure supports only one Active Directory schema.
B. Incorrect. This structure does not support the two different departments that have mutually exclusive Active Directory schema requirements. This structure supports only one Active Directory schema.
C. Correct. This structure supports the two different departments that have mutually exclusive Active Directory schema requirements because each forest has a separate schema.
D. Incorrect. This structure does not support the two different departments that have mutually exclusive Active Directory schema requirements. This structure supports only one Active Directory schema.
2. Correct answer: C
A. Incorrect. You need more than one domain to support the two separate domain names.
B. Incorrect. Implementing this solution requires the creation of additional trust relationships when compared to using a single forest with multiple domain trees.
C. Correct. You can accomplish this objective with a design that uses two domain trees, one for wingtiptoys.com and one for tailspintoys.com.
D. Incorrect. With a single domain tree, a child domain of the root domain needs to use a contiguous namespace. The requirements are that two domains with noncontiguous namespaces be available, which means at least two domain trees.
3. Correct answer: A
A. Correct. You can add domain controllers running the Windows Server 2012 R2 operating system to a domain running at the Windows Server 2003 functional level.
B. Incorrect. You can add domain controllers running the Windows Server 2012 R2 operating system to a domain running at the Windows Server 2003 functional level.
C. Incorrect. You can add domain controllers running the Windows Server 2012 R2 operating system to a domain running at the Windows Server 2003 functional level.
D. Incorrect. You can add domain controllers running the Windows Server 2012 R2 operating system to a domain running at the Windows Server 2003 functional level.
4. Correct answers: A and B
A. Correct. The Active Directory Recycle Bin is available at the Windows Server 2008 R2 and Windows Server 2012 forest functional levels.
B. Correct. The Active Directory Recycle Bin is available at the Windows Server 2008 R2 and Windows Server 2012 forest functional levels.
C. Incorrect. The Active Directory Recycle Bin is available at the Windows Server 2008 R2 and Windows Server 2012 forest functional levels.
D. Incorrect. The Active Directory Recycle Bin is available at the Windows Server 2008 R2 and Windows Server 2012 forest functional levels.
Lesson 2
1. Correct answer: D
A. Incorrect. A forest trust is created between two forests when you want users in each forest to access resources in the counterpart forest. In this instance you need to create a shortcut trust between two domains in the same forest.
B. Incorrect. You configure an external trust between two domains in different forests, often when you don’t want to allow the trust to be transitive. In this instance you need to create a shortcut trust between two domains in the same forest.
C. Incorrect. You configure a realm trust between an Active Directory domain and a Kerberos V5 realm. In this instance you need to create a shortcut trust between two domains in the same forest.
D. Correct. In this instance you need to create a shortcut trust between two domains in the same forest.
2. Correct answer: B
A. Incorrect. In this instance you need to create a shortcut trust between two domains in the same forest. You configure a realm trust between an Active Directory domain and a Kerberos V5 realm.
B. Correct. You configure a realm trust between an Active Directory domain and a Kerberos V5 realm.
C. Incorrect. A forest trust is created between two forests when you want users in each forest to access resources in the counterpart forest. You configure a realm trust between an Active Directory domain and a Kerberos V5 realm.
D. Incorrect. You configure an external trust between two domains in different forests, often when you don’t want to allow the trust to be transitive. You configure a realm trust between an Active Directory domain and a Kerberos V5 realm.
3. Correct answer: B
A. Incorrect. You configure an external trust between two domains in different forests, often when you don’t want to allow the trust to be transitive.
B. Correct. A forest trust is created between two forests when you want users in each forest to access resources in the counterpart forest.
C. Incorrect. You configure a realm trust between an Active Directory domain and a Kerberos V5 realm.
D. Incorrect. In this instance you need to create a shortcut trust between two domains in the same forest.
4. Correct answer: A
A. Correct. You configure an external trust between two domains in different forests, often when you don’t want to allow the trust to be transitive.
B. Incorrect. You configure a realm trust between an Active Directory domain and a Kerberos V5 realm.
C. Incorrect. In this instance you need to create a shortcut trust between two domains in the same forest.
D. Incorrect. A forest trust is created between two forests when you want users in each forest to access resources in the counterpart forest.