Truly understanding cross-forest authentication
doesn't just mean you understand authentication across multiple
forests—it also means you understand the process of authentication and
trusts within a single forest.
The term cross-forest authentication
can take you aback a bit when you first hear it. But all this refers to
is the authentication of credentials across multiple forests through
the use of forest trusts. Since by now you've most likely seen forest
trusts or been tested on forest trusts, this process should prove to be
relatively easy for you. But for the sake of completeness and also
because they are an absolutely vital aspect of the exam, we're going to
cover forests in their entirety. More so than any other exam, the 70-647
exam asks you to understand every single aspect of forest trusts.
Recall that a large part of
being an enterprise administrator is not just making administrative
decisions but also making design decisions. There's certainly more than
one way to organize an enterprise. What the enterprise administrator
exam is going to test you on is not just whether you're capable of
designing an enterprise but also whether you are capable of designing an
enterprise in the best way possible. The best way to make sure you pass
the exam is to familiarize yourself with the advantages and
disadvantages of each type of trust and where they need to play a role
in your environment.
Types of Trusts
We briefly covered the different types of trusts in Windows Server 2008
by name only. Let's review each of these trusts one more time in rapid
fire, just so they're fresh in your mind:
Forest trusts
Trusts that exist between two entire forests. As an example, the MyCorp.com and MegaCorp.com forest could share a trust between them that exists on the entire forest level.
Domain trusts
Trusts that exist
between two individual domains, somewhere within the forest. The
majority of trusts placed in a multiforest environment are usually
domain-based trusts, because they occur far more frequently than trusts
between entire forests.
External trusts
Trusts designed for legacy Windows environments, such as NT 4, to exist within a modern-day trust.
Realm trust
Trusts designed to handle Unix-based servers in a Windows infrastructure.
Shortcut trust
Domain trusts that
bypass the normal tiered hierarchy of domain trusts up and down the root
domain and instead connect directly from one domain to another.
As you can see, or possibly have
seen before, each of these types of trusts has a specific purpose and
needs to be applied at a specific point. And furthermore, each of these
types of trusts can be further refined by several categories of
information.
To begin with, trusts can be either one-way or two-way.
1. One-Way Trusts
A one-way trust
is the foundational trust that is used for all trust design. In a
one-way trust, the trust flows in one direction, and the access
direction flows in another. This is visually explained in Figure 1,
with a one-way trust model. In this figure, you can see that the
direction of the trust points in one direction. What this means is that
the organization that issues the trust is saying "I trust this."
Because when the domain says
that it trusts another, it points in one direction, and this means the
other domain can take advantage of this trust. It's like when you give
the key to your house to your house cleaner or to a friend. When your
friend decides that she'd like to come over to use your coffee machine
for a nice cup of joe, she's using your resources because you trust her.
(We are assuming she doesn't make a mess and abuse your trust. That
wouldn't be fun at all.)
One-way trusts can either be incoming or outgoing.
If they are incoming, it means they will trust incoming connections. If
they are outgoing, it means they will trust outgoing connections.
2. Two-Way Trusts
A two-way trust
is a trust that is issued in two directions. However, unlike what you
might think, a two-way trust is not simply a trust that exists in two
directions. Instead, it is two individual one-way trusts that are
applied to each domain. This is because trusts are, in practice, binary.
Either you trust something or you don't. That trust goes just one way.
Returning to the friend example, you may very well trust your friend,
but your friend may not trust you.
You can see this type of trust in Figure 2.
In this figure, the MyCorp and MegaCorp domains each trust each other
and form two one-way trusts that allow the authentication of resources
to each of the individual domains.
Accordingly, each domain in this figure will be able to access resources in the other domain.
3. Transitivity
Active Directory
trusts come in two flavors: transitive and nontransitive. This happens
regardless of whether the trust is two-way or one-way. In a transitive
trust, the trust relationship extends upward, and the trust is
established at the lowest level. So if you created a transitive trust to
a domain that extends deeply within your forest structure, that
transitive trust would accordingly trust all the domains up to the root
domain.
In a nontransitive
trust, the trust that is established is restricted to the two domains
that have been joined. For example, if two lower-level domains are
established by a nontransitive two-way trust, they will directly access
one another's resources, but the trust will not be established in an
upward direction throughout the forest. Those two domains, and those two
domains only, will trust one another.
4. Forestwide Authentication and Selective Authentication
The easiest way to explain forestwide and selective authentication is to consider Figure 3,
which shows two separate forests that each contain several domains. So,
most likely, each of these forests represents an infrastructure that
consists of several hundred or several thousand users. Each forest is a
living, breathing system that has its own infrastructure and runs
completely independently from the other.
But if for some reason
these two independent structures had to merge or needed complete access
to each other's resources, they could form a "forestwide" trust. This
means one forest would trust each other in its entirety, and each forest
would be able to use the other's authentication scheme.
In theory (and sometimes in
practice), this is a good idea, because it really does ease the effort
of having to administer two different structures. Effectively, they
almost become one, because administrators can more easily define trusts
and access. However, most of the time, administrators require a
finer-grained level of control. Thus, forests can also trust each other
through the process of selective authentication.
In selective authentication,
users are not allowed to authenticate to a specific domain controller
unless an administrator has specifically authorized this. The usefulness
of this is that it keeps users from wandering into places that they
aren't supposed to be and, well, messing things up. So, for instance, in
our example, MyCorp could authenticate to MegaCorp's resources through a
selective trust that allows users only in an individual domain (say
Tokyo) to access resources in the MegaCorp forest. Otherwise, the users
would be denied. By doing this, we tighten up security and make sure
there aren't any authentication leaks. It's a good security practice and
usually required by most enterprises.
5. Trust Scopes
Trusts are said to either be intraforest, meaning that the trust exists solely in its own self-contained forest, or interforest,
meaning the trust extends between two different forests. Within an
intraforest trust, you will normally see the following types of trusts
being utilized:
Tree-root
Parent-child
Shortcut
This is because, by default, a
two-way transitive relationship exists between the tree and root and
accordingly between parent-child domains. Shortcut trusts are most
usually seen on the intraforest level because they can remove a burden
from machines higher up in the forest structure and can instead
invalidate each other. It's like being in a classroom and giving two
students permission to grade each other's homework. It's a shortcut,
because they'll get it done more quickly than you will, plus it removes a
burden from the teacher.
On the interforest trust level, you'll usually see only two types of trusts:
Forest trusts
External trusts
Using a little logic, you can
see that this is because if two forests are to trust one another, they
will need to have an external trust. Note that in an external trust, the
legacy domain is not considered part of the live and active portion of
Active Directory. Instead, it's considered an outside source.
6. Trust Tools
When administering trusts, you
have several tools available to you to make the process a lot simpler
and more expedient. One of the best resources is a command-line tool
called nltest, which lets you do the following five things that are documented on Microsoft TechNet:
Get a list of domain controllers
Force a remote shutdown
Query the status of trust
Test trust relationships and the state of domain controller replication in a Windows domain
Force a user account database to synchronize on Windows NT 4.0 or earlier domain controllers
NOTE
Trusts make active use of SIDs, security tokens, and access lists to determine authentication and authorization decisions.
In Exercise 3.3,
you'll create a forest trust between two different forests using the
tools available to you through the Windows Server 2008 trust wizards.
Using this, you can connect two different forests to share resources.
Prerequisites: To perform
this exercise, you must first have two servers running Windows Server
2008 that have been elevated to domain controllers in their own
respective forests. In this exercise, there are two forests with their
root domains named domain.com and domain2.com. For this exercise, you
will be executing the commands from the domain.com domain.
Make sure you are logged in as either a domain or enterprise administrator.
Access the DNS manager by selecting Start => Administrative Tools => DNS.
Expand your DNS server, and select Conditional Forwarders.
Right-click the whitespace to the right, and select New Conditional Forwarder. It will open the dialog box shown here.
In the DNS Domain field, type domain2.com.
Select the Click Here To Add An IP Address Or DNS Name text, and enter the IP address of the domain2.com server.
Select Store This Conditional Forward In Active Directory.... Also ensure that All DNS Servers In This Forest is selected.
Repeat this process on the domain2.com, but point the DNS conditional forwarder to the domain.com domain.
Open the Active Directory Domains And Trusts tool by selecting Administrative Tools => Active Directory Domains And Trusts.
Right-click domain.com, and select Properties.
Select the Trusts tab, as shown here.
Select New Trust, and then click Next. Enter domain2.com in the Name box.
Select the Forest Trust radio button, and then click Next.
Select Two-Way, because this will be a two-way trust.
When
the next screen appears, select the Both This Domain And The Specified
Domain radio button. This will allow you to create the trust on both the
domain.com domain and the domain2.com domain, which means you don't
have to repeat the process. Afterward, click Next.
When
prompted for credentials, enter the username and password of an account
on the domain2.com server that is authorized to create a trust. A safe
bet is an account in the enterprise administrator group.
Select the Forestwide Authentication button when asked about policies in the target
forest, and then click Next. Alternatively, at this point you can
select individual access to each domain and server that you want to make
available with the Selective Authentication button.
Select the Forestwide Authentication button when asked about policies in the local
forest, and then click Next. Alternatively, at this point you can
select individual access to each domain and server that you want to make
available with the Selective Authentication button.
Click Next on the summary screen.
Click Next on the confirmation screen.
On the next two screens, select the radio buttons to confirm the forest trust, and then click Finish.
You
can test your forest trust by accessing the Active Directory Domains
And Trusts tool once again, right-clicking the Active Directory Domains
And Trusts section above the domain.com name, and selecting Change
Forest. Then, enter the domain2.com domain name, and you will see the domains swap. It's a very rewarding feeling.
