Exercises in Trust
Setting up forest trusts can be tricky. Here’s a step-by-step instruction guide.
In last month’s column I discussed the realities of trust relationships
in Windows Server 2003. This month, I’ll drop the pontification and provide
I’m sure you’ve spent time deciding exactly what kind of a trust is necessary. Just because a forest trust is possible doesn’t mean you need to create one, when one or two external trusts will do. Even a forest trust can be limited by using selective authentication, but is this the right way to go? Only you can answer those questions.
There are three steps to trust building:
Prepare the landscape. The actual process of
creating an external trust is simple, if you’ve prepared the environment.
Create the trust. You’ll need your partner to
help with this one.
Grant users and groups access. This is the real
work; after all, the trust is just a requirement so this can be done.
The trust creation process isn’t some mysterious process requiring special
charms and wizardry. The normal needs for network connectivity, name resolution
and proper authority form the basis on which the relationship is built.
Many failed trust relationships are the results of ignoring these areas,
so spending a little time on them up front may save hours of troubleshooting.
Before a forest trust can be consummated, these things must be true:
DNS infrastructure must be correctly configured.
Both forests must be Windows 2003 forests.
All domain controllers must be running Windows 2003.
Both forests must be at Windows 2003-level functionality.
Participants on both sides of the trust must be domain administrators
in the root domain of the forest, members of the Enterprise Admins group
or delegated the authority to create a trust.
Incoming Trust Builders, a new group in Windows 2003, empowers members
to create one-way incoming forest trusts.
To create the forest trust from one location, you must have proper credentials
for the partner forest.
Time must be synchronized between the two forests.
One other thing: Name resolution is an essential ingredient of creating
a forest trust and, of course, for use of the trust relationship to access
resources in partner trusts. I’m assuming your DNS infrastructure for
both forests is correctly configured. If you’re having DNS problems, stop
right here—get DNS straightened out before attempting to create a forest
Ensuring Correct Functional Level
You don’t need every server in the forest to be Windows 2003 to create
a forest trust. However, you do need to make sure all DCs in all domains
in both forests are running Windows 2003. Furthermore, both forests must
be at Windows 2003 functional level.
The first step is easy, if costly and time consuming in a multi-domain
forest. In a test lab, we can simply build our forests that way. But like
Windows 2000 native mode, Windows 2003 forest functional level doesn’t
magically happen just because all of our DCs are running Windows 2003.
Setting forest functional level is a two-step process. First, each domain
must be set to Windows 2003 functional level, and then the forest must
Remove NT 4.0
First, ensure that no Windows NT 4.0 DCs remain. If you don’t, you risk
orphaning those DCs and providing yourself with a troubleshooting headache.
When the functional level of the domain is raised, there’s no failsafe
that stops the process if NT 4.0 DCs are still part of the domain. Instead,
replication with the NT 4.0 DCs just stops. This is true whether you’re
raising the level to Win 2K native or Windows 2003.
Create the Trust
You have to go through the exercises just described to prepare the forest
for a forest trust. However, if an external trust is all you need, you
can create one without raising the forest functional level. You can also
create external trusts between a Win2K domain in another forest and the
Windows 2003 domain or between Windows 2003 and an NT 4.0 domain. If,
however, you want to use Selective authentication within the trusting
domain, that domain must be at the Windows 2003 domain functional level.
Remember, an external trust is—like it is in Win2K—a one-way, non-transitive
trust that only exists between the two domains. To make trusts go both
ways, you must create two trusts, one in each direction. Instructions
for both types of trust, external and forest, follow.
To create an external trust that uses selective authentication, determine
which domain in each forest will participate. Microsoft documentation
and the Trust Wizard call the domain from which you begin the trust process
the local domain. The other domain is called the specified domain. In
this example, we’ll create a one-way trust between tailspintoys.com and
wingtiptoys.com. Since I’ll run the wizard from a DC in tailspintoys.com,
it’s the local domain, while wingtiptoys.com is the specified domain:
1: Log on as a member of Domain Admins for tailspintoys.com.
2: Open Start, Administrative Tools, Active Directory Domains and Trusts.
3: Right-click the tailspintoys.com domain object and select Properties from the context menu.
4: Click the Trusts tab and then click New Trust.
5: On the Trust Wizard welcome page, click Next.
6: Enter the name of the domain to create a trust with wingtiptoys.com, then click Next.
7: On the Trust page, select External Trust and then click Next.
8: Select One-way, outgoing trust.
Remember, incoming and outgoing refer to the direction of trust. To put
it in NT 4.0 terms: The outgoing trust means the users in the specified
domain will be able to access resources in the local domain; the specified
domain is the trusted domain; and the local domain is the trusting domain.
Or, as the Trust Wizard puts it, “users in the specified domain, forest
or realm can be authenticated in this domain.” In our example, this means
that we’ll be able to give users in the Wingtiptoys.com domain access
to resources in the Tailspintoys.com domain. However, because we specified
a one-way trust, the users can’t be given access to resources in Wingtiptoys.
An interesting side effect of this new way of thinking is that for Wingtiptoys,
this trust is an incoming trust. If we were to create the trust using
the Wingtiptoys DC, or complete it from there, we’d create an incoming
trust. If this is confusing, think of it this way: We’re offering to trust
outsiders. We’re extending the boundaries of Tailspintoys trust outward.
However, from Wingtiptoys’ point of view, they’re getting in some more
(See Figure 1.)
|Figure 1. Options for selecting the direction
of the trust. (Click image to view larger version.)
In our case, we want a one-way trust relationship, but in Windows 2003, we could have chosen a two-way trust. In this case, users in both domains can be given access to resources in either domain.
9: Select the side of the trust to create. Since we’re running our own show, we choose both the local (Tailspintoys) and the external (Wingtiptoys) domains. If we had the credentials for only one domain, we’d choose local, and the Trust Wizard would need to be run at the other domain by an authorized administrator to complete the trust.
10: Next, enter the user name and password for a domain administrator in Wingtiptoys.
11: Finally, select the authentication scope. This is new in Windows 2003.
Selecting Selective authentication (Figure 2) allows access limitations for
Wingtip users for specified servers in the domain.
|Figure 2. Choose Selective authentication to limit
user access from the trusted domain. (Click image to view larger version.)
12: Note the summary and click Next twice.
13: Confirm the trust by clicking OK.
14: The trust property page should show the domain in the proper category as
shown in Figure 3.
|Figure 3. Wingtiptoys.com, shown with an external trust
Create a Forest Trust
To create a forest trust, there can’t be an already existing trust relationship
between the forests. So if you have an external trust with a forest and
want to change it to a forest trust, you’ll have to remove the external
trust first. That’s a simple process: Simply select the trust and remove
it. However, users who’ve been granted access to resources won’t be able
to use them until the forest trust is properly established. If you’re
following along, don’t forget to remove the external trust created in
the last exercise.
To create the forest trust:
1: Log on as a member of Domain Admins in the forest root domain of Tailspintoys (the local domain), then open Start, Administrative Tools, Active Directory Domains and Trusts.
2: Right-click the domain node for the forest root domain and select Properties from the context menu.
3: Select the Trust tab.
4: Click New Trust.
5: Enter the DNS name Wingtiptoys (the specified domain) for the name of the other forest.
6: Select Forest Trust, then Next.
7: Select the two-way for the Trust direction, then click Next.
8: On the Outgoing Trust Authentication Level, select Selective authentication and then click Next.
9: On the Incoming Trust Authentication Level page select Selective authentication and click Next.
10: Note the summary information, then click Next.
11: Confirm the incoming trust, then click Next.
12: Confirm the outgoing trust, then click Next.
13: Review Trust status, then click Next.
14: In the Trust Properties page, confirm that the specified domain name
is listed in the trusted (outgoing trusts) and trusting (incoming) trust
boxes (see Figure 4).
|Figure 4. If you’ve done it right, Wingtiptoys
should be listed as both a trusted and trusting domain.
Access Across Forest Boundaries
In an external trust, two domains in different forests develop a relationship
so that users in one or both domains can be given access to resources
in the other. The trust doesn’t provide this access, with the exception
of providing users in the trusted domain the ability to authenticate to
the trusting domain. In essence, the trusting domain accepts the word
of the trusted domain that the account is valid and the password is correct.
All other access must be granted.
While this seems to mean that users can’t gain access to the other domain’s resources until it’s granted, that’s not so. If users are authenticated to the trusting domain, they’re added to the Everyone group. In our example, the users from the Wingtiptoys domain, once authenticated to the Tailspintoys domain, can access resources and have the privileges granted to the Everyone group in Tailspintoys. It’s all very well to tell you to remove access for the Everyone group but, in reality, that’s quite difficult to do across all servers and workstations in the enterprise. Instead, to keep trust partners from inadvertently opening resources, choose Selective authentication.
After the external trust is built, “Permission to authentication” must be granted on every server to which Wingtiptoys users need to have access. Later, when the external trust is removed and a forest trust created, Selective authentication must be selected. In order to give access to users across the forest boundary, we have to give groups from the trusted domain “allowed to authenticate” to each domain in the forest where we want to allow this.
Remember to document your choice of Selective authentication and instruct admins on how to use the allowed to authenticate permission. It’s easy to give groups in the trusted domain this permission. For example, we’ll grant the Wingtiptoys\Accounting group allowed to authenticate permission to the Tailspintoys.com domain and to Server1, where a folder’s been set up for them to share information with Accountants at Tailspintoys.
1: Log on to a domain in the Tailspintoys domain.
2: Open Active Directory Users and Computers.
3: Select View, then click Advanced Features to select it.
4: Select the DC’s OU and right-click it, then Properties.
5: On the security page, click Add, then Location. Select Wingtiptoys.com.
6: Use the object picker to select the wingtiptoys.com\Accountants group and add it.
7: Back on the Security tab, select the Accountants group and click the check box Allowed to authenticate.
8: Repeat for other DCs in the domain.
9: From the Computers container, right-click Server1 and select its properties. From the Security tab, add the Accountants group and grant them the Allowed to authenticate permission.
10: Access the server file system
and grant the wingtiptoys\accounting group access as necessary.
So, there you have it. Simple, huh? No? Well, you know what they say