Trusts in Active Directory

IT administrators have been working with and around Active Directory since the introduction of the technology in Windows 2000 Server. Windows 2000 Server was released on February 17, 2000 but many administrators began working with Active Directory in late 1999 when it was released to manufacturing (RTM) on December 15, 1999.

What is Trust in AD?

A trust is a relationship between forest and/or domains.

In a AD forest, all of the domains trust each because a two way transitive trust is created when each domain is added. This allows authentication to pass through from one domain to any other domain in the same forest.

You can create trusts outside of the forest too with other AD DS forests and domains or Kerberos v5 realms.

Back in the days of Windows NT 4.0, there wasn’t a forest or a hierarchical structure. If you had multiple domains, you had to manually create trusts between them. With Active Directory, you automatically have two-way transitive trusts between domains in the same forest. Back with Windows NT 4.0, you had to use NetBIOS to establish trusts too!

Luckily, things have come a long way and now we’ve got additional trust functionality, especially around securing trusts with selective authentication and SID filtering.

Each trust in a domain is stored as a trustedDomain object (TDO) in the System container. Thus, to find and list all of the trusts and trust types in a domain named contoso.com, run the Get-ADObject –SearchBase “cn=system,dc=contoso,dc=com” –Filter * -Properties trustType | where {$_.objectClass –eq “trustedDomain”} | select Name,trustType Windows PowerShell command.

There are 4 valid values for the trustType attribute. However, only the value 1 (indicating a trust with an NT domain) and the value 2 (indicating a trust with an Active Directory domain) are common. There is a lot of other good information about trusts stored in the trustedDomain object.

In a domain named contoso.com, run the Get-ADObject –SearchBase “cn=system,dc=contoso,dc=com” –Filter * -Properties * | where {$_.objectClass –eq “trustedDomain”} | FL Windows PowerShell command to look at all of the trust properties.

You can also view many of the core properties of a trust by running the Get-ADTrust –Filter * command.

Trust properties

The table below shows the trust properties and a description of each property.

Trust property Property description
Direction Valid values are bidirectional, inbound, or outbound. Note that the direction is relative to the domain in which you are running the query.
DisallowTransivity I think this is a Microsoft typo as it really should be “DisallowTransitivity”. This can be set to True or False based on whether the trust disallows tranitivity.
DistinguishedName The DN of the trusted domain object.
ForestTransitive This is set to True when a forest trust is transitive and False when a forest trust is non-transitive.
IntraForest This is set to True when a trust is between domains in the same forest or set to False when a trust is between domains in different forests.
IsTreeParent Valid values are True and False.
IsTreeRoot Valid values are True and False.
Name The name of the domain that is part of the trust, not the domain where the query is run.
ObjectClass This is set to trustedDomain for trusts.
ObjectGUID Globally unique identifier for the trust. An example is de207451-51ed-44cd-4248-85ad9fcb2d50.
SelectiveAuthentication Set to True if the trust is configured for selective authentication or False if it isn’t.
SIDFilteringForestAware Set to True if a forest trust is configured for selective authentication
SIDFilteringQuarantined Set to True when SID filtering with quarantining is used for a trust. Used for external trusts only.
Source Set to the DN of the trust root. In a forest trust, the DN of the root domain of the forest is the source.
Target Set to the domain name of the other side of the trust.
TGTDelegation Set to True if Kerberos full delegation is enabled on outbound forest trusts. Default is False.
TrustAttributes Set to a numerical value indicating the trust configuration. For example
TrustedPolicy Undocumented
TrustingPolicy Undocumented
TrustType Set to Uplevel for trusts with Active Directory forests and domains, DownLevel for trusts pre-Active Directory domains such as NT 4 domains, Kerberos realm for trusts with Unix/Linux realms.
UplevelOnly Set to True if only Windows 2000 and later operating systems can use the trust link.
UsesAESKeys Set to True for realm trusts that use AES encryption keys.
UsesRC4Encryption Set to True for realm trusts that use RC4 encryption keys.


From a scalability perspective, there are a couple of things about trusts that you should be aware of:

  • Maximum number of trusts for Kerberos authentication.

If a client in a trusted domain attempts to access a resource in a trusting domain, the client can’t authenticate if the truth path has more than 10 trust links. In environments with a large number of trusts and long trust paths, you should implement shortcut trusts to improve performance and ensure Kerberos authentication functionality.

  • Performance deteriorates after 2,400 trusts.

In really large and complex environments, you may have an enormous number of trusts. After you reach 2,400 trusts, any additional trusts added to your environment could significantly impact performance over the trusts, especially related to authentication.

More information about Active Directory basisc you will find in our AD tutorial for begginners.

Expert in Microsoft infrastructure and cloud-based solutions built around Windows, Active Directory, Azure, Microsoft Exchange, System Center, virtualization, and MDOP. In addition to authoring books, Brian writes training content, white papers, and is a technical reviewer on a large number of books and publications.