Advanced Active Directory Infrastructure for Windows Server 2012 R2 Services

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

   1. Forest trust
   2. External trust
   3. Realm trust
   4. 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?

   1. Shortcut trust
   2. Realm trust
   3. Forest trust
   4. 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?

   1. External trust
   2. Forest trust
   3. Realm trust
   4. 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?

   1. External trust
   2. Realm trust
   3. Shortcut trust
   4. Forest trust