Active Directory Insights (Part 2): Digging into Trusts

If you would like to read the other parts in this article series please go to:


Trusts are a feature of Active Directory that make multi-domain environments possible by enabling users in one domain to be authenticated by a domain controller in a different domain. The basic facts concerning trusts are well-known by any Active Directory administrator, namely:

  • Trusts between domains within an Active Directory forest are always two-way and transitive.
  • Trusts between forest root domains (i.e. forest trusts) can be either one-way or two way but are always transitive and establish a trust relationship between every domain in each forest.
  • Trusts between one forest and a specific domain in another forest (i.e. external trusts) can be either one-way or two way but are always nontransitive.
  • Trusts between an Active Directory domain and a non-Windows Kerberos realm (i.e. realm trusts) can be either one-way or two way, and they can also be either transitive or nontransitive.
  • Shortcut trusts can be created between two domains to improve user logon times between the domains, for example between a domain in one domain tree and a domain in a different domain tree in the same forest. Shortcut trusts can be either one-way or two way and are always transitive.

Given all of the above, what else do we need to know about trusts?

Scripting trust relationships

Trusts can be created using the New Trust Wizard, the Netdom command-line tool, or Windows PowerShell. However, there are some caveats. For example, the TechNet page for the Netdom trust command indicates that you can’t use this command to create a forest trust between two forests. However, as this article in the TechNet Wiki indicates you can use a Windows PowerShell script to accomplish this. You can also find more information about this in this post on Spat’s WebLog, and there’s a script called AD Trust in the TechNet Script Repository that you can use to create one- or two-way trusts between two domains or forests.

Trusts under the hood

Trust relationships are represented within the Active Directory directory database as a type of object called trusted domain objects (TDOs). Each trust relationship that is created is associated with a unique TDO that is stored in the System container of its domain. The attributes of the TDO enumerate the names of the domains involved, the type of trust created, and whether the trust is transitive or not. Forest trusts also have some additional attributes. This archived TechNet blog post from 2009 shows how to view the properties of TDOs.

You can also use the Get-ADTrust cmdlet of Windows PowerShell in Windows Server 2012 R2 to display all trusted domain objects in a forest or having specific characteristics such as TDOs having a specified trust partner. There is also a version of this cmdlet called Get-ADTrusts.ps1 (note the plural) that you can download as a script from the TechNet Script Repository which you can use on Active Directory environments running on earlier versions of Windows Server. Carl “The Accidental Citrix Admin” Webster says however that he has identified some issues with the Get-ADTrusts.ps1 script in the TechNet Script Repository, and in this post on his blog he has created his own version of the script to address these issues.

Trusts and Kerberos authentication

Kerberos v5 is a mutual authentication protocol used by Active Directory to verify the identity of users and network services. Trust relationships make it possible for Kerberos authentication to be extended beyond the domain to other domains in the forest. But what about authentication beyond your forest? Jorge de Almeida Pinto has an excellent series of posts that explain how you can extend Kerberos authentication so it works across an external trust i.e. a trust between your forest and a specific domain in a different forest. You can find the final part of his six-part article here and it contains links to the earlier articles in the series. Note that Jorge’s method only works when the two forests both have domain controllers running at least Windows Server 2008 R2. Also note that as far as I know his approach is not officially supported by Microsoft, so use it at your own risk.

Here are a couple of other helpful resources that may be of use if you want to use Kerberos over an external trust:

Trusts between organizational units (OUs)

In Active Directory a trust is basically a relationship between two domains, or two forests, a forest and a domain in another forest, and so on. But forests and domains aren’t the only “structural” elements of your Active Directory environment, there are also elements called organizational units (OUs). You can create hierarchical structures of OUs within each domain to organize the user and computer accounts and other Active Directory objects in the domain. You can then link Group Policy Objects (GPOs) to each OU to manage, control or lock down what those accounts can do or not do.

So what about trusts? Can you create a trust relationship between, say, an OU in a domain of one forest and an OU of a domain in a different forest? Unfortunately trusts can’t be created for OUs, but there is a kind of workaround available called selective authentication that provides a way to control which groups of users in a trusted forest can access shared resources in the trusting forest. Basically as this TechNet article explains, selective authentication allows you to limit the scope of a trust relationship so it applies only to the Active Directory objects you explicitly specify.

But should you trust another forest?

Trusts between forests are usually implemented in situations like where one company acquires another or merges with another. Are there any risks involved in creating trusts between two forests? Of course there are, because you’re basically giving the other company the keys to your kingdom. Even if you’ve legally acquired the other business, it doesn’t mean you should automatically fully trust their IT staff! So before you attempt to create an inter-forest trust or implement something like selective authentication between two forests, be sure to read the TechNet article Security Considerations for Trusts.

Trusts between geographically separated forests

Let’s say you have two forests, one in North America and the other in Asia, and you want to establish a forest trust between them. It would be nice if you had a high-speed dedicated leased WAN link connecting the two networks, but you don’t have that because it would be too expensive. What can you do?

Your best solution would probably be to create a point-to-point VPN between the DMZ of one forest with the DMZ of the other forest. You should be able to do that easily if your DMZ in each forest is using an enterprise-grade firewall appliance. Once you’ve done this, you should be able to create the trust between the two forests.

Remote Desktop Gateway and trusts

RD Gateway is basically a server used as a gateway between your corporate network (corpnet) and the Internet. RD Gateway is designed to allow authorized remote users to connect to computers on your corporate network from any computer that has an Internet connection. RD Gateway does this using Remote Desktop Protocol (RDP) and Secure HTTP (HTTPS). An important consideration concerning trusts is that RD Gateway doesn’t support accessing resources from non-trusted domains; they should at least have a one way trust between two domain controllers configured. And if you want to extend your domain into your DMZ in a way that supports RD Gateway, you should read through this article from Windows IT Pro.

System Center Configuration Manager and trusts

Say you are using ConfigMgr in Forest A to manage the servers and virtual machines and other systems in Forest A. You then create a trust between Forest A and a second forest named Forest B. Can you use ConfigMgr to manage systems in Forest B? Yes you can, with the following caveats:

  • You’ll need to create a new client push account in Forest B and add it to the local admins group of the systems in Forest B.
  • You may need to open additional firewall ports in the DMZ of both forests.

There’s more to it than that however, so you should also read through the four blog posts by Neil Peterson who is a Microsoft Premier Field Engineer (PFE).

Got questions about trusts?

If you have any questions about trusts, the best place to ask them is the Active Directory Domain Services forum on TechNet.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top