Microsoft Active Directory uses the concepts of “domains”, a domain is the outer edge of a security compartment; within a domain, user accounts, computer accounts and resources are authenticated and share a common authentication source. There is also the concept of a “forest”, a forest is a collection of domains, in the most basic configuration there is a single forest containing a single “root” domain and the forest is the outer edge of a security compartment of multiple domains.
For many organisations a single forest, single domain configuration is adequate (keep it simple) however what happens when perhaps there is a merger or acquisition and you need the two organisations to either co-exist and share resources, or start along the process of merging one forest and its child domain(s) into another?
The domains (root and child) within a forest all trust each other implicitly, however outside of the forest (the outer edge of the security compartment) there is no implicit trust, if you need to trust and external forest or domain, you as the administrator need to configure it, and that is where Active Directory trust types, directions and transitivity comes in.
To explain the concepts we’ll use a simple case study, in this scenario, the Megacorp organisation has a forest and a single root domain “megacorp.com”. The Cashcow Plc. organisation has a forest with three domains; it also has a Unix domain where it hosts a small number of services from a previous acquisition. The diagram below illustrates this, the forests are the outer lighter blue triangles, the domains are the darker blue triangles within.
Bear in mind that domains within a forest already implicitly trust each other with “transitive” and “two-directional” trusts, of course you are wondering what these mean?
Transitive or Non-Transitive
First transitive and non-transitive trust. Transitivity is a concept that is used throughout Microsoft’s Active Directory, in this case it means the ability for trust to flow through from one object to another and then on to any other objects.
So in relation to forests and domains, a transitive trust is one that extends not only to the target of the trust, but also to the children of the target of the trust.
So let’s use an example, let’s say there is a trust relationship setup between Megacorp’s forest and Cashcow Plc.’s forest, (a forest trust – more on this later) it is a transitive trust, so this means the root megacorp.com domain trusts the root cashcow.co.uk domain, but this trust flows through so that the megacorp.com domain also trusts the uk.cashcow.co.uk and us.cashcow.co.uk child domains too; and vice -versa (its a forest trust we’ll explain this shortly).
So what about non-transitive trust, well this is the opposite, a non-transitive trust is one that extends only to the target of the trust i.e. not to any child objects.
In our case study, megacorp.com trusts cashcow.co.uk, but that flow of trust stops there, it does not flow down to the child domains within Cashcow Plc.’s forest.
Direction of Trust
The direction of trust is also a very important concept. Remember that within a forest all the domains implicitly trust each other, these are “parent-child” trusts (or “tree-root” trusts depending on how you look at it) and its two way (and transitive).
The root trusts the child, the child trusts the root; the root trusts the children of the child and the child of the child trusts the root and so on.
So what does this have to do with the direction of trust? Well, trust can be one-way or two-way, but first we need to quickly talk about the flow of access to make it clear.
Trust flows in one direction, the access (granted by that trust) flows in the opposite direction to the trust, wait, what?
Let’s examine that for a moment using our case study, let’s say Megacorp has purchased Cashcow Plc. and is going to bring it into the Megacorp brand, however as part of that the Cashcow Plc. will use Megacorp’s resources to bring that organisation into the brand.
In this case there is only a need for a one-way trust, i.e. Megacorp is going to trust Cashcow Plc, which allows Cashcow Plc. to access Megacorp’s resources; remember the access flows in the opposite direction to the trust.
So that is one-way trust, the two-way trust is the same thing reversed. So Megacorp trusts Cashcow Plc. and Cashcow Plc. trusts Megacorp; essentially both trust each other and both can access each other’s resources (with the necessary security configuration of course), the two-way trust.
Types of Trust
The transitivity and the one-way/two-way trusts now leads us to the various types of Active Directory trusts, these have their own use cases and their own characteristics of transitivity and direction. You may or may not ever use these as an Active Directory administrator, but it is worth understanding they exist, just in case you come across the situation where you need to!
Forest Trusts
A forest trust is transitive (i.e. the trust flows down through all child domains), this is not configurable, however it can be made a one-way or two-way trust; and is manually created.
In our example a forest trust is setup, cashcow.co.uk domain users can access any of the megacorp.com resources and if it is a two-way trust, they (megacorp.com domain user’s) can access any resources in any of the cashcow.co.uk domains.
External Trust
A much more specific trust, these are always non-transitive, one-way (although you could create another in the reverse manually) and are manually created; they are also always to enable trust to a single domain outside of the source forest.
So in our example megacorp.com needs to allow only those at cashcow.co.uk head-office to access its resources (not the child domain), so in this case there is an external trust created from megacorp.com to cashcow.co.uk. It being one-way and non-transitive, no access is granted to the us.cashcow.co.uk or uk.cashcow.co.uk child domains to get to resources in the megacorp.com domain/forest.
Shortcut Trust
Now this is a bit of a weird one in way, a shortcut trust is always one-way (unless you create the reverse manually) and is always transitive. It is used within domains within the same forest only. Of course the question is why you’d want this? Surely all the domains within the forest already trust each other (because of the parent-child implicit trust) and yes they do, but the shortcut trust is there to speed up the “trust path” between two domains that’s don’t directly trust each other.
So although its not on the example (or diagram), if the uk.cashcow.co.uk had a child domain called, secret.uk.cashcow.co.uk and those in the us.cashcow.co.uk needed to access resources in it, a shortcut trust could be setup from secret.uk.cashcow.co.uk to us.cashcow.co.uk (remember the access flows in the opposite direction of the trust), so us.cashcow.co.uk user’s could get access to resources in secret.uk.cashcow.co.uk but without having a trust path via first the cashcow.co.uk root domain and then uk.cashcow.co.uk child domain first.
I’ve personally never used a shortcut trust, but in very large Active Directory forest and domain infrastructures they can be helpful to improve the user (logon) experience.
Realm Trust
And finally, a realm trust is a specific type of trust that is used to allow support for a non-Microsoft Windows based domain (Kerberos). A realm trust uses Kerberos V5 authentication only, no NTLM is allowed.
A realm trust is one-way by default (but you can create a trust in the opposite direction if needed), and they are non-transitive, the concept of transitivity doesn’t really come into play.
Within our case study let’s have a quick look at this type of trust. The us.cashcow.co.uk office has a Unix system it uses for its stock maintenance, its an old system that the organisation has yet to replace, therefore a realm trust has been created from unix.cashcow.co.uk to us.cashcow.co.uk to allow users within us.cashcow.co.uk domain to authenticate and use resources in the unix.cashcow.co.uk domain.
I’ve used a realm trust before for a use case very similar to that of our example case study to allow users to authenticate with an existing Unix based email system on a single server, before users needed to explicitly login to the email system, with the trust in place, this was made much more streamlined.
Conclusion
Microsoft provide a much more detailed explanation here, but hopefully my overview has given you a clear understanding of the basic concepts.
Image Attribution: Alfons Morales