Join Rick Trader for an in-depth discussion in this video AD DS trusts overview, part of Windows Server 2012 Active Directory: Domain Service Design.
- Anytime you're in a multiple vein environment, whether you be in a single forest or a multiple forest situation, users from one domain may have to access resources in another domain. Or in order for a DNS to resolve resources between those different domains, we need to set up trust relationships, so that we can access those resources appropriately and efficiently. So we're gonna be looking at some of the terms that are involved in setting up trusts, or establishing the trusts, or even after the trusts have been established, some of the troubleshooting aids.
So some of the terms we're gonna be looking at is, a term called trusted and trustee. If you think about it in this mindset, alright, you have an environment over here where there are some resources, there's an environment over here where there's user accounts. So, I'll put an R for resources, an A for accounts. Now, it could also be accounts over here, and resources over there. But for simplicity, we have resources and we have an accounts. When I'm looking at this, I have the resources. This is commonly referred to as the trusting domain.
If you think about it, you kinda make a kind a joke out of it. ing has the things. Trusting has the resources. Over here, we have the trusted domain. Kind of a joke that's always made, "Ted has the users." So if you remember, Ted has users, ing has the things. When it comes to setting up the trust relationships, when someone says, "Hey I have domain A, "and I have Domain B", right, or whatever the names might be, I have a situation where I have users in Domain A that need to access resources in Domain B.
So is Domain A the trusting domain, or is Domain A the trusted domain? What are they? Very simply, Ted has the users, ing has the things. So I'm gonna set up a trust relationship where Domain B trusts Domain A. Again, A is the users, B is the resources. So Domain B is trusting Domain A. So we're gonna set up a trust relationship where Domain B trusts A. Notice the arrow, the point.
The point of the arrow always points toward the trusted domain, not the trusting domain. I make a joke of that a lot of times in class. You're trusting me, you're trusting my users. They're not gonna access your resources. The point of the arrow is up against my chest, so if I do anything wrong, or my users do something wrong, you can sever the trust, just by pushing the arrow in. Take it as morbid as you want, right? But it's something to think about. So again, right, the trusting is the resources, trusted is Ted, or users.
The arrow always points toward Ted. So we always have those trusted and trusting environments. It is possible that when we set up a trust, this is currently a one-way trust, there also may be a trust coming this way. So now, this user also becomes the trusted domain, and this domain also becomes the trusting domain. Notice the point of the arrows. This is commonly referred to as a two-way trust relationship.
There'll always configure as a one-way, right, when we do them manually. But then you can configure them each direction. So we can have a situation where I'm trusting your users, and you're trusting my users for maybe a full environment of some type of commerce resource sharing. So we have our trusting and trusted. The next thing we have are these terms called transitive and non-transitive. Now, if you think about it, right, if you're transiting through someone else's city, or you're transiting through a state, you're moving through that state to get to the other side.
If it's a non-transitive environment, you kinda hit a brick wall and you can't get across. If you think about that the same way when it comes to trust relationships, we have transitive and non-transitive. So, let's use this as an example. Oops, let's turn this around. Here's my house with my garage, right? Here is Adam's house, with Adam's garage. And over here sets John's house with John's garage, right? So we've got mine, Adam's, and John's.
Those are our garages. And we're gonna be setting up a situation here where Adam trusts me to use the tools that are in his garage. And Adam trusts John, so that John can use the tools in his garage. Well, just because Adam trusts me, and Adam trusts John, doesn't mean I can access John's tools, and John can access my tools.
That's referred to as a non-transitive relationship, a non-transitive relationship. I can't transit through this environment all the way over here to access those resources just because the trust relationship exists. The same thing exists when we set up trust relationships between domains. If this happens to be our Active Directory environment, okay and we've got Domain A, B, and C, just because we have these trust relationships, doesn't mean that Domain A users can access Domain C's resources, or vice versa.
Because explicit trusts are non-transitive. A transitive trust means that users from this environment can actually transit through that environment to access those resources. So we're gonna see when we start discussing specific types of trusts in the environment, some of those trusts are transitive trusts, and some of those trusts are non-transitive trusts, depending on the environment you're working with. So you'll see three different types of trust environments. So what are those environments? As an overview, these are the types of trusts that you may come across when you're working with Active Directory.
Or even when you're working with NT 4.0 you may have dealt with some of those trusts before. Some of these trusts became available in Server 2003 and later. And we'll discuss in more detail each one of these trust relationships in future sessions. But right now, the types of trusts that you may deal with, real simple overview of them. You have a parent-child trust. When I create a child domain in an environment, there is an automatic trust relationship that is going to occur between that child and that parent. If I have multiple trees in my forest, there's an automatic trust relationship that occurs from the tree root of the new tree and the forest root of your established forest.
We'll have situations where users in this tree want to access resources in this tree. And we're gonna see that there's an issue where going up through one tree down to the other tree to gain access to resources, we'll be able to create these things called shortcut trusts inside of our forests. We're gonna have situations where Company A wants to have resources over in Company B. And we'll set up external trusts between those two companies. And we'll look at what the restrictions are, and how we go about setting those up. We have forest-level trusts. Microsoft introduced these in Server 2003.
So this entire forest can trust this entire forest, for a complete sharing of resources between the forests. And then finally, you may set up a trust relationship between a Kerberos environment, such as a UNIX, a Linux, or a Red Hat environment, that allows you to actually either share resources with them, or access resources in their environments.