Share via

Discovering AD Trust Topology

  • Article

Though many of today’s information technology topics revolve around “the cloud” it’s still very common to be looking at Active Directory trusts.  Active Directory (AD) trusts are the method by which one AD domain can allow access to resources joined to it from identities in other AD domains.  The value in setting up an AD trusts versus setting up “pass through authentication” (identities in both domains with the same name and password) is that you can use the integrated security mechanisms of Kerberos and NTLM when authenticating to resources. The AD trust also provides from single sign on in the traditional sense of not prompting anyone for credentials.

Ultimately AD trusts boil down to-allowing access to resources in an authenticated way. The details of how and what level of access can be configured somewhat on the trust but mostly on the resources themselves once the authentication across the trust has already happened. It’s that “somewhat” configuration of security on the trust and how AD trusts behave that drives any administrator to getting a better understanding of how the trust is configured.

There are several kinds of AD trusts and each may have their own unique properties. These properties can effect authentication and authorization to resources across those trusts. For the most part trust security and configuration hasn’t changed much since Windows Server 2003 days. For that reason the old TechNet reference “Administering Domain and Forest Trusts”is still applicable.

Let’s go over trusts at a high level. There are three categories of trust: Forest, External and Internal.

Forest trusts are explained pretty well in the link above however I will add that a forest trust is the kind where you should expect Kerberos authentication to work. Forest trusts were created and tested explicitly to make sure Kerberos would work (among other things like transitivity). Forest trust configuration can be a major factor in authentication if the trust is optimized for DNS suffix inclusion or exclusion due to overlapping namespaces at source or destination.

External trusts are a lot like Windows NT style trusts. They do not allow for transitivity or customization with respect to namespace routing. They were not created or tested with Kerberos in mind even though it will often work if some details and name resolution is configured correctly.

Internal trusts are trusts within a forest. In forests with more than one domain this can be a ParentChild, CrossLink (also known as a Short Cut Trust) or TreeRoot trust type.

Trust types are confusing in TechNet documentation. The best reference is really MSDN at this link:  https://msdn.microsoft.com/en-us/library/system.directoryservices.activedirectory.trusttype(v=vs.110).aspx 

In addition to the different kinds of trusts, trust security can be configured on the trust itself for Selective Authentication and Quarantine (also known as SIDFiltering). These security settings may restrict access to resources across the trust so having the details of whether they are enabled or not is very helpful. Trust security is a hot topic if you have common migrations or plan to migrate objects from one domain to another and rely on SIDHistory to help maintain a continuity of access of resources for users.   

I’ve written a PowerShell script to help give you a quick understanding of the trust layout in your environment. You can download it from the TechNet Script Center at this link: https://gallery.technet.microsoft.com/scriptcenter/Get-AD-Trust-Topology-f8f2d1d7.

Script Details

  • You do not need to be a domain or enterprise administrator to run this script and get results.
  • You do not need AD PowerShell module or to load any module for that matter
  • Trust type and scope are shown.
  • Trust direction is shown.
  • For forest trusts, DNS suffix inclusions and exclusions are shown as “Trust TopLevelNames (Name Suffix Routing)” and “Trust Excluded TopLevelNames(Name Suffix Routing)”.
  • For forest trusts, transitively trusted domains are listed as “trusted domain info”. This will show the NetBIOS domain name, domain SID and fully qualified DNS name of the domain.
  • Selective Authentication status for the trust is given
  • SIDFiltering (also known as Quarantine) status for the trust is given.
  • To run the script open an elevated PowerShell prompt and enter “.\GetTrustTopology.ps1” (without the prompts).
  • The script will create a file %systemroot%\temp\TrustTopology.txt. All details will go into it.
  • The trust details are contextual. In other words, the trust details are taken from the forest and domain of the computer the script is running the GetTrustTopology.ps1 script on.
  • The script will provide a time estimate for how long the script will take to complete since each trust query takes approximately 1 second to complete.
    • Example:

Trust data collection from the domain is expected to take approximately 1 minute(s) and 53 seconds.

Working...

  • A summary of how many trusts are configured and what kind they are is given.
  • In the text output file the trusts are categorized by Internal, External and Forest.
  • The script uses the .Net methods below:
    • [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
    • [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
    • [System.DirectoryServices.ActiveDirectory.Domain]::GetAllTrustRelationships()

Here’s an example snippet from a trust output (which has been edited for length and content):

Trust topology information obtained from the computer TSPRING1 in the domain na.contoso.com on 03/09/2015 16:04:33.

This text file contains information on all trusts: Forest, External, Shortcut and ParentChild.

There are 41 forest trusts.

There are 8 internal (intra forest) trusts.

There are 64 external trusts.

**********************************************************************************************

Active Directory Trusts for Trusts of Type internal

*********************************

Trust Name : Trust Details for na.contoso.com | af.contoso.com.com

Local Domain (Source) : na.contoso.com

Trusted Domain (Target) : af.contoso.com.com

Trust Direction : Bidirectional

Trust Type : CrossLink

Quarantine (SIDFiltering) : False

Selective Authentication : False

Active Directory Trusts for Trusts of Type forest

*********************************

Trust Name : Trust Details for corp.contoso.com| zeem.contoso.com

Local Domain (Source) : corp.contoso.com

Trusted Domain (Target) : zeem.contoso.com

Trust Direction : Bidirectional

Trust Type : Forest

Trusted Domain Info: ZEEM : DNSName zeem.contoso.com | Domain SID: S-1-5-21-54554650-542264547-849213213

Trusted Domain Info: CORP : DNSName z.corp.contoso.com | Domain SID: S-1-5-21-126545641-121658548-89421321

Trust TopLevelNames (Name Suffix Routing) : {corp.contoso.com}

Trust Excluded TopLevelNames (Name Suffix Routing) : {sub.corp.contoso.com}

Quarantine (SIDFiltering) : True

Selective Authentication : False

Active Directory Trusts for Trusts of Type external

*********************************

Trust Name : Trust Details for na.contoso.com | manuf.tailspintoys.com

Local Domain (Source) : na.contoso.com

Trusted Domain (Target) : manuf.tailspintoys.com

Trust Direction : Bidirectional

Trust Type : External

Quarantine (SIDFiltering) : True

Selective Authentication : True

*****************

I hope this script and blog post helps folks as much as it helps me when I use it to discover a new environments trust topology.

Comments

  • Anonymous
    February 17, 2016
    thanks again
    very useful