Creating the right trust

In an Active Directory environment with multiple domains, you're bound to have trusts. Trusts allow people to access resources in a domain or forest other than the domain or forest where their user accounts reside.

When Active Directory domains are added to an existing Active Directory domain, two-way transitive trusts are automatically created. However, in other situations, trusts have to be created manually. With many different types of trusts, two trust directions, and a choice in transitivity, which trust is the right trust for which situation?

Let's take a look at the six types of trusts first:

• Parent-child trust: The parent-child trust is a trust type that is automatically created when you add a domain to a tree root. For example, a parent-child trust is automatically created between adatum.com and sub.adatum.com. You cannot manually create a parent-child trust.
• Tree-root trust: The tree-root trust is a trust type that is also automatically created, just like the parent-child trust. However, the tree-root trust is created when you add a new domain tree to an Active Directory forest. For example, when you add the domain to a forest that contains only the adatum.com domain. The difference between the tree-root trust and the parent-child trust is that with the former, you break the domain tree, whereas with the latter, you expand on it. You cannot manually create a tree-root trust.
• Forest trust: A forest trust is a trust type that you will have to create manually. When accounts in two separate Active Directory forests want to work together on each other's resources, then this is the right trust type to create between the two forest root domains. Creating a forest trust is highly preferable over creating an external trust, because the latter only supports older authentication schemes, whereas a forest trust supports Kerberos authentication.
• Realm trust: The realm trust type exists to help you connect with non-Active Directory environments, such as Samba-based environments and Novell eDirectory-based environments. The requirement for the other side of the trust is that it needs to support the Kerberos version.
• External trust: An external trust is a trust type that you will have to create manually. This trust type is truly versatile, as you can create a trust with any other environment, including Windows NT 4.0 Server-based environments. The downside is that it leverages NTLM as its authentication protocol; this is considered an outdated and weak protocol.
• Shortcut trust: In large Active Directory environments, authentication to access a resource may take a long time. As a user traverses trusts within an Active Directory forest, they have to perform Kerberos authentication up and down trees until they reach the domain with the resource they want to access. The rule of thumb is to create a shortcut trust when users in one domain regularly use resources in another domain (but within the same forest), and they have to traverse five, or more, trusts to get from the domain where their user accounts reside to the domain where the resources reside.

This creates the following flowchart:

Trust direction

The right direction of a trust can be simply explained with an analogy. Suppose that a friend wants to borrow your car; you share your keys to the car with them and then you give them permission to use the car.

In terms of the Active Directory trust, the friend will map to the user account, the car to a resource, and you will be the resource owner. The trust flows from the resource to the user. The admin of the resource has to create the trust.

Trust transitivity

The same analogy also works for transitivity. Suppose that you want to lend your car to a friend, but they also want to lend the car to their friends. If you trust the friend enough, you will probably allow them to do so. If you don't have this level of trust in your friend, or you know some of their friends and you don't trust them with your car, then it's a bad idea.

In terms of Active Directory trusts, the trust type where you trust all the user accounts in all the domains to access the resource, is a transitive trust; parent-child trusts, tree-root trusts, and forest trusts are transitive, by default.

The trust type where you only trust your friend and not all of their friends to access the resource is a non-transitive trust. Realm trusts and external trusts are non-transitive, by default.

One-way or two-way trust

Essentially, every trust is a one-way trust. All the trusts that you create manually are one-way trusts, by default. However, you can combine two one-way trusts in opposite directions to create a two-way trust. In the scope of a two-way trust, people on both sides of the trust can access resources on both sides of the trust using their user accounts.

Microsoft recommends creating a two-way trust when your goal is to migrate accounts and resources using the Active Directory Migration Tool (ADMT). After migrating everything over, the two-way trust can be torn down.

Getting ready

To create a trust between two environments, make sure that the two environments know how to find each other. In DNS, create any necessary (conditional) forwarders or stub zones to point domain controllers from one environment to the domain controllers or Kerberos Key Distribution Centers (KDCs) of the other environment.

Additionally, take care of proper networking; the domain controller holding the PDCe FSMO role and at least one global catalog for each domain on the route of the trust should be reachable from the device that someone uses to access the resource. The following firewall ports should be opened:

Service	Protocol	Port
Kerberos authentication	TCP and UDP	88
RPC endpoint mapper	TCP	135
NetBIOS name service	TCP and UDP	137
File Replication Service (FRS) between domain controllers	UDP	138
Distributed File System Replication (DFSR), NetBIOS session service	TCP	139
Lightweight Directory Access Protocol (LDAP)	TCP and UDP	389
Server Message Block (SMB)	TCP and UDP	445
Kerberos password change	TCP and UDP	464
Lightweight Directory Access Protocol over SSL (LDAPS)	TCP and UDP	636
LDAP to global catalogs	TCP	3269
LDAPs to global catalogs	TCP	3269

Preferably, you should sign in to the domain controller that is running the Domain Naming Master FSMO role, or connect the Active Directory Domains and Trusts console to this specific domain controller.

To find this domain controller, right-click the Active Directory Domains and Trusts node and select Operations Master... from the menu. Alternatively, run the following command from any domain-joined device, member server, or domain controller:

netdom.exe query fsmo

Otherwise, you can use the following PowerShell commands on a domain-joined system that has the Active Directory module for Windows PowerShell installed:

Import-Module ActiveDirectory

Get-ADForest | Format-List DomainNamingMaster

Required permissions

For shortcut trusts, sign in with the credentials of an admin account that is a member of the Domain Admins group. For all other accounts, sign in with the credentials of an admin account that is a member of the Enterprise Admins group.

How to do it...

To create a trust on Windows devices or Windows Servers with the Desktop Experience use the Active Directory Domains and Trusts tool for the domain you (as a resource owner) want to give access to:

1. Open Active Directory Domains and Trusts (domain.msc).
2. In the console tree, right-click the domain that you want to allow access to, and then click Properties....
3. Navigate to the Trusts tab, as follows:

4. Click the New Trust… button.
5. Run through the New Trust Wizard.
6. In the Welcome to the New Trust Wizard screen, click Next >.
7. In the Trust Name screen, type a name for the trust in the Name: field. Then, click Next > when done.
8. In the Trust Type screen, choose between a Realm trust or a Trust with a Windows domain. For the latter, type the name of the domain, in case it's different to the trust name. Click Next >.
9. In the Trust Type screen, choose between an External trust or a Forest trust. Click Next >.
10. In the Direction of Trust screen, choose between a Two-way, One-way: incoming, or One-way: outgoing trust. Click Next >.
11. In the Sides of Trust screen, choose between creating the trust for this domain only, or both this domain and the specified domain. Click Next >.
12. In the User Name and Password screen, provide the credentials of an account that has administrative privileges in the Active Directory domain on the other side of the trust. Click Next >.
13. In the Outgoing Trust Authentication Level-Local Forest and/or Outgoing Trust Authentication Level - Specified Forest screens, choose between Forest-wide authentication and Selective authentication. Click Next >.
14. In the Trust Selections Complete screen, review the settings, and click Next > to create the trust.

15. In the Trust Creation Complete screen, click Next >:

16. In the Confirm Outgoing Trust and/or Confirm Incoming Trust screens, choose between No, do not confirm the outgoing trust and Yes, confirm the outgoing trust. Click Next >.
17. In the Completing the New Trust Wizard screen, click Finish.

Alternatively, you can use the following commands:

netdom.exe trust TrustingDomain.tld /Domain:TrustedDomain.tld /TwoWay /Add

Replace TrustingDomain.tld with the DNS domain name of the Active Directory environment that gives access to its resources, and then replace TrustedDomain.tld with the DNS domain name of the Active Directory environment that gains access to the resources.

In the preceding example, a two-way trust is created where both Active Directory environments give and gain access to the other Active Directory environment.

It's a recommended practice in Active Directory to remove objects and settings that have no use.

When a trust is no longer needed, it can be deleted. To do so, follow these steps:

1. Open Active Directory Domains and Trusts.
2. In the console tree, right-click the domain that you want to allow access to, and then click Properties.
3. Navigate to the Trusts tab.
4. From the list of Domains trusts by this domain (outgoing trusts):, or from the list of Domains that trust this domain (incoming trusts): select the trust that you want to remove.
5. Click the Remove button next to the corresponding list.