Welcome to the Active Directory Trusts video,
one part of the free Active Directory course. When you have one domain and one forest, looking
after Active Directory is quite easy. In fact, if you can stay with one domain and one forest,
then you should do that. In the real world this may not occur.
Imagine this: your company already has two large business units that work independently
of each other. They have their own domain and child domains and own namespace. The company
buys another company which has its own forest and its own child domains. Your company expands
and with it, multiple new domains are created. Some of these new domains have child domains
of their own. In order to meet the needs of the business, users in any domain must be
able to access resources in any other domain. Remember that each Domain effectively has
its own copy of the Active Directory database. Each domain essentially runs by itself. So
what happens when a user wants to access a resource in another domain?
To make administration easy, Active Directory automatically creates a two way trust relationship
between parent and child domains. This trust relationship is called a transitive trust.
A transitive trust simply means I trust you and any other domains that you decide to trust
or, to a quote a familiar saying, “Any friend of yours is a friend of mine”.
To understand transitive trusts better, let’s remove all the trusts and rebuild the relationships
with non-transitive trusts. The parent domain wants to trust its child domains, so we would
create two way trusts like this. Now imagine that one of the child domains
has two child domains of its own. In order for its children to trust the child domain,
two trust relationships need to be created, so let’s create two more two way non-transitive
trusts. Now the root domain wants to access the two new domains so two more trusts need
to created. In order for the child domains to trust each
other, two horizontal trusts need to be created like this. Lastly, the two new child domains
need to be connected to the other child domain like this.
This is a total of 10 trusts for 5 domains. I have only done a small part of the diagram
but imagine I did the whole lot. In order to ensure everyone has access to each domain
you would need to create 66 trusts for the 12 domains shown.
This is why non-transitive trusts do not scale well. They are great in that you can
choose which domain accesses which domains, but on any decent sized network, managing
these trusts soon becomes very difficult. Let’s go back to transitive trusts. Every
child domain is connected to its parent domain. If the parent wants to access a resource in
the bottom domain, it will go through the transitive trust of the child domain. The
child domain will then pass the request through its trust relationship to its child domain.
That’s what a transitive trust is. It allows a trust to be extended outside the domain
to which it is directly connected. Let’s look at a different example. Say this
domain wants to access this domain. It would go up to its parent. Its parent would pass
the request to the root domain. The root domain would pass the request via a transitive trust
automatically created between the trees in the forest. This trust is called a tree trust.
It is essentially the same as a parent child trust and is created automatically by Active
Directory. Once the request passes over the tree root
trust, it would finally be passed down by this domain to its child. In order to get
to its destination, the request had to go over 4 transitive trusts, all of which were
created automatically. You are probably thinking this is great: I
can share anything I want with anyone in the forest and as long as I give them permissions
to access the resource, Active Directory will do the rest. This is true, but could there
be delays going over 4 transitive trusts to get to your destination even if it is done
automatically? In the real world, most of the time the parent
and child domains will do most of the sharing between each other, but sometimes you may
have two domains that are quite a distance from each other in the hierarchy but communicate
with each other a lot. When this occurs you can create what is called
a shortcut trust. A shortcut trust provides a direct trust relationship between the two
domains, saving them from having to go through the whole hierarchy. I think you will agree
that creating an occasional shortcut trust where it is needed is a lot better than creating
trusts between all the domains in the forest. In this particular case we also have another
company that has its own forest. Perhaps they are owned by the same company but they want
to keep their own domains and forest separate. When this occurs, you can create what is called
a forest trust. In order to create a forest trust you must
be running at least Windows Server 2003 or higher forest functional level. Forest trusts
are not created by default and must be manually created by an administrator. Once created,
any domain in either forest will be able to access resources in any other domain, assuming
that they have access. Just like parent child trusts, forest trusts are transitive. In some cases you may need to create a trust
relationship between Active Directory and a non Active Directory system. Assuming both
systems use Kerberos you can create what is called a realm trust. These are created manually
and can be either transitive or non-transitive, one way or two way.
The last trust you may come across is an external trust. An external trust is generally used
to connect to a Windows NT 4 domain. These trusts need to be created manually and are
non-transitive. They are also one way only but you can make them two way by simply creating
two trust relationships, one going in each direction.
This covers all the different trusts in Active Directory. In most cases you can see a trust
relationship will be created for you automatically. The trust relationship is in both directions
and is transitive so new domains and child domains will automatically have access to
each other. All the hard work is done for you.
Two way trusts are easy to understand and use. Resources are shared both ways. In some
cases you may have to deal with a one way trust. Let’s look at an easy way to understand
the terminology when dealing with a one way trust.
Let’s say you have domain A with a share in it. You have a user in domain B called
John. The question is, does domain A trust John? In order for a user to access a resource
in anther domain, the other domain must trust that user. So that question is does Domain
A trust John? You are told that domain A trusts domain B.
Since John is in domain B he can access resources in Domain A. This of course assumes that John
has access to these resources. The trust relationship only creates the path for a user to access
a resource it does not grant them permissions. If a user Jane was in Domain A, she would
not be able to access resources in Doman B. In order for this to occur, Doman B needs
to trust domain A. If you get confused draw an arrow between the two domains with the
direction of the trust. In order for the user to access the other domain the arrow must
point towards the user. Now that we understand how trusts work, I
will change to my Windows Server to demonstrate how to create trusts.
To view the current trusts or make changes, open Active Directory Domains and Trusts from
Administrative Tools under the start menu. As I expand down through the domains, notice
that I have the east and west domain under my root domain and the sales domain under
the east domain. All these domains are linked together via transitive trusts automatically
created when the domains were created. If I select the root domain and then right
click and select properties, I can then select the trusts tab to view the trusts that are
currently set up. Currently there are trusts in both directions set up between this domain
and the child domains. The sales domain will not be shown since that trust relationship
is between the east and sales domains. To create a new trust, select the option at
the bottom, “new trust.” Once you are past the welcome screen, enter in the domain,
forest or Kerberos Realm for which you want to set up the trust. It is important that
your DNS can resolve the other end before you perform this setup. In this case I will
create a forest trust between the ITFreeTraining domain and the HighCostTraining domain. At
present, both domains are in the root domain of their own forest.
Windows will find and detect that the other side is another forest. You could choose the
first option, “external trust,” which will create a trust between the two domains.
This in a non-transitive trust so only the two domains selected will be able to use the
trust. This is also the trust you would need to use for NT 4 domains.
In this case I want to select the second option, “forest trust.” This will allow any domains
in either forest to access any other domain in the other forest.
On the next screen you can select which direction the trust will go or the default option two
ways. In this case both forests will be sharing resources with each other so I will accept
the default option of two ways. The next screen gives you the option to create
the trust in this domain or both domains. In a lot of cases you won’t have an account
in the other forest. This is especially the case if the other forest is another company.
If you do not have access, select the option “this domain only.” In order for the trust
to work, the other company will have to perform the same procedure in their Active Directory
environment as I have just done. The next screen allows you to determine how
the default authentication will work. In order for a user to gain access to a resource in
another domain, they need to be given permission to that resource. Having said this, there
are plenty of resources in a domain that everyone can access without permissions being set for
that user. For example, authentication from a domain controller or access a share with
permissions set to everyone. If the company is trusted, select the first option, “forest
wide authentication.” The user will still need to be given access to resources but will
be able to access any resource that is available to everyone and authenticate off Domain Controllers
in the forest. In some cases you may create a forest trust
between your company and another company. In this case you may want to be very careful
about what you give them access to. In this case you would select “selective authentication.”
This option will only allow them access to servers that you decide they can access. This
includes Domain Controllers. Using this option you can select which Domain Controllers that
they can access just for authentication. This gives you more security but takes a little
bit more work to set up. In this case I will select the option “selective
authentication” to show you how to configure. On the next screen you need to enter in
a password for the trust. This password will need to be entered in on the other side using
the same wizard as here. When the two forests connect up for the first time, this password
is used to ensure that both servers are talking to the correct party.
The next screen will confirm that a forest trust is about to be created. Once I press
next I will be informed the forest trust was created.
The next screen will ask if you want to confirm the outgoing trust. So far the trust has been
created but this step will confirm that the trust is working with the password I entered.
Before you can perform this step you need to ensure that an Administrator in the other
forest has completed this wizard and thus created their side of the trust.
On the next screen the incoming trust can also be confirmed. In this case you will be
required to use a username and password from the other forest. In a lot of cases you
may not have this, especially if you are connecting to another company.
The wizard is now complete and the forest trust has been setup. The trust will appear
in the outgoing and incoming trusts with the transitive trusts that have already been automatically
created. Since I used selective authentication in the
forest trust, I will now open Active Directory Users and Computers and give the administrator
in the HighCostTraining Domain access to authenticate from my Domain Controller.
By default the option that I am after will not appear. In order to get it to appear,
open “view and select advanced features.” This will show a lot of options that are normally
hidden. From here I will open the Domain Controllers OU and open the properties for my domain controller.
To give access, select the security tab and then press the button add. Since the forest
trust has been added, I can now enter in the administrator from the high cost training
domain and Windows will find the user without a problem and they will be added to permissions
listed for this Domain Controller. Once added, I need to tick the box “allowed
to authenticate.” Steps like these will need to be performed on every server that
they need to access. This is more work, but does prevent users from accessing other resources
on the network unless you specify that they can.
That’s it for forest trusts. I will now go back to Active Directory Domain and Trusts
and demonstrate how to create a shortcut trust. In this case I will create the shortcut trust
between the sales domain and the west domain. In order to do this, first open the properties
for the sales domain. Like the forest trust, press “new trust”
to start the wizard. In this case I will enter in the domain name of West.ITFreeTraining.Local.
Windows will detect that this is another domain in the forest and ask me straight away if
I want to make this trust one way or two. I will accept the option two way and move
on. The next screen asks if I want to create the trust in this domain or both domains.
Since I have a username and password for the other domain with enough permissions, I will
select the option “both” so that both directions of the trust get created at once.
Next I will be asked for a username and password in the other domain. Like the forest trust,
if you did not have a username and password for the domain, an Administrator on the other
domain would have to run this wizard as well and create the trust on their side using a
shared password. On the next screen notice that Windows has
detected that this will be a shortcut trust. In a lot of cases Windows will auto detect
the trust that you are trying to create. The next screen will ask if I want to confirm
the outgoing trust. In this case I will need to ensure that it was created and working
properly. I will also get the same option for the incoming trust which I will also confirm.
Once I complete the wizard, notice that the new shortcut trust has been created in both
the incoming and outgoing sections. That’s it for creating trusts.
There is one last point I need to cover that is in the exam objectives for Trusts and that
is Sid filtering. To consider how Sid filtering works you first need to understand Sid history.
To understand Sid History consider this example where Sid History would come into play.
Consider that you have two domains. The decision is made to migrate the users from one domain
to the other. In order for this to occur, new users are created in one domain with the
same user names as the other domain. The problem occurs because these new users will have a
different security identifier or Sid. Since they are new users with new Sids, they
will not have access to any of the resources that they used to have. This is where Sid
history comes into play. When migrations like this are performed, the new user account has
an area called Sid history which can store all that users’ previous Sids. When they
access a resource, Windows can look at the Sid history and work out that they are the
same user even though the primary Sid used with the user account has changed.
What does all this have to do with trusts? With trusts you need to understand that by
default Sid filtering is enabled and this will affect Sid history. When a user attempts
to travel over a trust to access a resource, Windows will filter out all the Sid history
for that user that does not match the domains of the trusts the user came over. This means
any legacy Sid’s will be removed as soon as the user travels over a trust to gain access
to a resource. This means the user will be denied access to a resource if it was assigned
under an old domain name. This is done to strengthen security. Even
though it is not as easy as it may sound, an administrator could access the Sid history
for a user and create any Sid that they wanted. Using that user they could then access resources
in another domain. This is why Microsoft has enabled Sid filtering over all trusts by default.
For the exam, you simply need to know that all trusts have Sid filtering enabled and
that Sid Filtering removes any Sid from Sids history for old domains.
Well, that is everything that you need to know about Windows Trusts. In the next video
I will look at sites. Sites allow you to divide Active Directory so it matches your physical
network topology. I hope you have enjoyed this free video. Thanks for watching.
