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.
