MCITP 70-640: Active Directory Trusts


Uploaded by itfreetraining on 08.04.2012

Transcript:
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.