One of the important features of Windows Server 2003 was that Microsoft finally achieved the ability to create a true Kerberos trust between forests, also called a "cross-forest trust." This was noticeably missing in Windows 2000 Server, which allowed only NTLM or "external" trusts that did not have transitivity.
Building a cross-forest trust permits a trust to be established between the root domain of two forests, and any child domain in either forest can have access to resources in the other forest without an explicit trust, as Windows 2000 required.
Recently, I was working with a client to resolve an issue regarding Microsoft Exchange Server working across a trust. In that situation, it became necessary to create a new trust. Although the client's admins were experienced, they had never built a cross-forest trust.
For anyone who needs a refresher on how to build a cross-forest trust, here are the steps:
Background: In our scenario, let's consider two forests, Corp.net and ABC.com. There is a child domain, NA.corp.net, in the Corp.net forest, but ABC.com is a single domain forest. Our goal will be to create a two-way trust between the Corp.net domain and the ABC.com domain. Because it's a transitive trust, the NA domain will be able to use the trust as well.
Preparation is key for a cross-forest trust
Before creating the trust, there are a few issues that need to be addressed. First, ensure that the system time is synchronized. Because Kerberos will be used for authenticating the trust, the time skew between the two forests must be within five minutes -- or whatever the time skew is set to. The best way to do this is to manually check the system time on the PDC of the root domain of each forest and set both to point to the same external time source. If the time isn't in sync, the trust can be built but operations across it won't work because of authentication failure -- just like with any other time sync issue.
The next step is to provide DNS name resolution between the two forests. There are a number of ways to do this. In our scenario, you can configure a secondary zone for ABC.com to be hosted on the Corp.net DNS server, and a secondary zone of Corp.net on the ABC.com DNS server. The same thing could be accomplished using conditional forwarders or even simple forwarding. I prefer defining a conditional forwarder for each domain on the DNS servers in the other domains. Thus, Corp.net would be defined on ABC.com DNS servers and vice versa. After this is accomplished, make sure each domain name can be pinged from a client in the other domain.
Finally, both forests must be in Windows Server 2003 forest functional mode. Set all domains to Windows Server 2003 domain functional mode, and then set the forest mode.
Creating the trust in Active Directory
You can initiate the trust wizard from either domain, but do it from a DC -- preferably the PDC -- in the root domain of the forest.
- Go to the Active Directory Domains and Trusts snap-in (domain.msc). In Active Directory Domains and Trusts snap-in, right click the Corp.net domain icon and select Properties. Click on the Trusts tab. This will initiate the New Trust Wizard. Click Next on the welcome screen.
- In the Trust Name screen, enter the name of the other domain. In this case, we are running the wizard from Corp.net, so we enter ABC.com in this field and click Next.
- In the Trust Type dialog, shown in Figure 1, you can select External Trust or Forest Trust. The External Trust would be an NTLM type (non-transitive) trust. Select Forest Trust to build a transitive, Kerberos type trust. Keep in mind that if the Forest Trust option is greyed out, the forest functional level has not been set.
Figure 1: You can select External Trust or Forest Trust in the Trust Type dialog.
- In the Direction of Trust screen, shown in Figure 2, you can select a two-way trust or a one-way outgoing or one-way incoming trust, demonstrating the flexibility of establishing a trust from either domain. In this example, we will create a two-way trust.
Figure 2: In the Direction of Trust screen, you can select a two-way trust or a one-way outgoing or one-way incoming trust
- When you select a two-way trust, you will be presented with the Sides of Trust dialog. In Figure 3, I selected the option to create both ends of the trust. Following that dialog, an authentication screen is presented to allow entry credentials in the other domain that will permit creation of the trust.
Figure 3: Sides of Trust dialog
- Next, Figure 4 shows the Outgoing Trust Authentication Level – Local Forest. Here we can select Forest Wide Authentication or Selective Authentication. This is the authentication level for the trust going from the local forest to the other (remote) forest. In simple terms, if you select Forest Wide Authentication, the Authenticated Users group in the remote domain will behave as if it were in the Authenticated Users group in the local forest. In other words, wide open. The Selective Authentication option allows administrators in the local forest to grant specific rights for users in the remote domain to local domain resources by group or user account. Forest Wide Authentication is used for a two-forest configuration for one company, while Selective Authentication would be appropriate for an extranet where you want more control of individual resources.
Figure 4: Outgoing Trust Authentication Level – Local Forest
- The ensuing screen is Outgoing Trust Authentication Level – Specified Forest. The questions are the same here to allow you to select Forest Wide or Selective Authentication, from the remote forest to the local forest.
- Next, there is a summary screen reviewing the trust choices. After that, there will be screens asking if you want to confirm the incoming trust and the outgoing trust. Select the "Yes" option to test the trust.
- Figure 5 shows that we have created a two-way trust to the ABC.com domain.
Figure 5: A two-way trust to the ABC.com domain has been created
There you have it. Although this procedure shows the creation of a two-way trust, similar steps would be used to create a one-way. Remember that the system time between the DCs in the two forests must be within the five-minute time skew and name resolution must be maintained.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He wrote Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Olsen is a Microsoft MVP for Windows Server-File Systems.
