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 the plan.

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.

Forestry
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 trust.

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 be set.

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.

External Trust
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 resources.

(See Figure 1.)

Trust direction
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.

Selective authentication
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.

External trust
Figure 3. Wingtiptoys.com, shown with an external trust to Tailspintoys.com.

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).

Trusted and trusting
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 about practice…

Featured