Most companies nowadays have, or they prepare having multiple Active Directory forests in their environment, and as you know, forests are a completely different entity compared to an additional domain or tree. One forest does not trust another one, and can’t share information with another forest, unless a trust is created between the two. Usually we need a trust between two forests when:
- the company just created a DMZ zone and built a completely new forest, and this new forest needs to access resources in the internal domain.
- the company just merged with another one and until the fusion is completed, users need to be able to authenticate and share resources on both forests.
- there are business units in an organization that are independent and you want them to be isolated from each other and not combine them in a single forest.
This are just a few scenarios, but the principle is the same for all: if the company has two separate Active Directory entities and they need to share resources, then a trust is needed between the two. In order to make two forests trust each other, first we need to create a site-to-site VPN connection so they can communicate at the IP level, then open the proper firewall ports (on both sides):
|Kerberos authentication||TCP, UDP||88|
|RPC Endpoint mapper||TCP||135|
|Network basic input/output system (NetBIOS) name service||TCP, UDP||137|
|DFSN, NetLogon, NetBIOS Datagram Service||UDP||138|
|DFSN, NetLogon, NetBIOS Datagram Service||TCP||139|
|SMB – File Replication Service||TCP, UDP||445|
|Kerberos password change||TCP, UDP||464|
|LDAP GC – Global Catalog from client to domain controller||TCP||3268|
|LDAP GC SSL||TCP||3269|
For this article I prepared two sites, vkernel.local (primary site or local site) and contoso.com (other site) connected trough a VPN connection. Now I’m not going to show here how to create the firewall rules in order for the trust to happen because I have an article just for that. In the end, the ports and protocols listed in the above table need to be present in a TMG firewall rule. Your company might be using another type of firewall, and if that’s the case, contact your network team and pass them those ports and protocols or read the vendor’s documentation on how to configure the firewall.
Now that our connection between sites it’s working, the next step will be to configure DNS. This is a must, because if DNS is not configured the trust creation wizard will fail. Let’s start with the primary site (vkernel.local) by login in to a domain controller and open the DNS Manager console. Right-click the Forward Lookup Zones folder and choose New Zone.
In the Zone Type page select the Stub zone radio button then click Next.
Leave the defaults here and continue the wizard.
The zone name that we need to type in this box needs to mach the name of the forest in the other site. In our case its contoso.com. Type it in then continue the wizard.
The zone we just specified sits on a DNS server or a domain controller in the other site. In this page we need to provide the IP address of that DNS server or domain controller. Click Next when you’re done. If your firewall is properly configured with the ports and protocols mentioned in the begging of the article the IP address should be resolved to the server name.
Click Finish to create the zone.
Looking in the DNS Manager console we should see the new zone as available and healthy. Only the name servers and domain controllers will be listed in the zone, so don’t worry if you don’t see any other entries like computers, mail servers etc.
Going in the contoso.com site we need to run the same wizard just with other values, the local site values. Again, choose Stub zone in the Zone Type page then click Next.
Once you reach the Zone Name page, type the name of the zone from the local site then click Next.
Type the IP address of at least one DNS server or domain controller from the vkernel.local domain then click Next.
Click Finish to create the DNS zone.
Like before, we should see the DNS zone healthy and replicated.
Now if we log in on a client in the local domain (vkernel.local) and PING another client (using the FQDN) in the other domain, the name should be resolved with no problems. It should work vice-versa also.
Since our DNS is working fine, the next step will be to create the trust between the two forests. This can be created from any domain controller in the forest and in order to be able to initiate this trust you need to be logged in with an account that is part of the Domain Admins or Enterprise Admins group. For this demo, we are going to do this from the local site (vkernel.local), so log in on one of the domain controllers here, and open the Active Directory Domains and Trusts console.
In case you have multiple domains and trees in the forest, like I do, you can create a trust just between a specific domain in this forest and another forest or domain. This is also called an External Trust, which I’m going to explain in just a second, but for now we are going to launch the New Trust Wizard right from the root. This way we get all the available options in the wizard.
Right-click the root name and choose Properties.
In the window that opens go to the Trusts tab and click the New Trust button. As you can see I already have some trusts displaying here, and these were automatically created when I built the domains in this forest.
Click Next to skip the Welcome screen.
Here we need to type the domain name or forest name with which to create the trust. The name must mach the DNS stub zone name created earlier, and in our case is contoso.com.
In the Trust Type screen as you can see, we have two options:
- External trust – This is used when we want to create a trust between a child domain in a forest with another child domain in another forest. This way only the two domains can share resources and trust each other and the other child domains in those two forests cannot.
- Forest trust – By using this type of trust, one forest trusts another forest and by default the trust is so called Transitive. Transitive means that all domains and child domains in one forest automatically trust the other domains and child domains in the other forest based on the trust direction.
For this example we are going to create a Forest trust, so select the second radio button and click Next.
In this page of the wizard we specify the direction in which the trust should happen because not every time the trust needs to go in both directions. Now I know that this terminology is a little bit confusing, OK… more than a little bit, but try to think of it this way:
- Incoming Trust: With incoming trust, the trust is created in the trusted domain, vkernel.local in this case, and users in the trusted domain are able to access network resources in the other domain, the trusting domain, contoso.com in this case. Users in the other domain cannot however access network resources in the trusted domain.
- Outgoing Trust: With outgoing trust, users in the other domain, contoso.com in this case, can access network resources in the initiating domain, vkernel.local in this case. Users in the initiating domain are not able to access any resources in the other domain.
I always think of a DMZ zone where users come in and they need to authenticate with their internal domain credentials, so we create and outgoing trust. If its the other way around, we create and incoming trust. Make your choice then click Next. For this article I’m going to create a two-way trust.
This is a very useful page and it can saves us a lot of work sometimes. Since the trust relationship needs to be created on both sides (local domain and specified domain) in order for the trust to work, if we select the second option, Both this domain and the specified domain we are creating the trust relationship in both domains at once. For short, we don’t need to launch this wizard again in the other domain because everything is created remotely with this one, as long as we have the proper permissions. If you don’t have delegated permissions in the specified domain to create the trust relationship, then you need to contact the domain administrators for the other domain to create it once you are done here.
This page of the wizard its available only if you choose Both this domain and the specified domain in the previous page. Here we need provide the proper credentials to authenticate in the other domain, and this account needs to have proper permissions (Domain/Enterprise Administrator) to create the trust relationship.
As you can read in the explanation, if we go with Selective authentication we will have to manually grant access to each domain and server we want to make available to users in the specified forest. If that’s your case, go ahead, but for now select Forest-wide authentication and click Next.
Since this is a two-way trust we need to configure the trust authentication level on the other forest also. Again, select Forest-wide authentication then continue the wizard.
By clicking Next, the wizard will create the trust between the two forests and in the Trust Creation Complete page we can see the results of the operation.
The next two screens are to confirm the outgoing and incoming trust. Click Next and choose Yes on both of them to confirm the trust.
Click Finish to close the wizard.
Back in the forest Properties window, we can see the trust was created and automatically set as Transitive. Click OK to close the window.
Now that we’ve set up the trust, it’s time to test it and see if it actually works. A good example will be a shared folder in the local domain (vkernel.local) on which we give access to a user or a security group from the other domain/forest (contoso.com). Go ahead, create the folder in the local domain and share it by setting the share permissions to Full Control for Authenticated Users. Once you’re done with that, go on the Security tab, click the Edit button then the Add button on the new window. In the Select Users, Computers, Service Accounts, or Groups window we need to push another button, and that’s the Locations button in order to select the other forest.
Select the contoso.com forest and click OK.
Back in the Select Users, Computers, Service Accounts, or Groups window, type the username or security group you want to grant access to the share. If you can’t remember the exact name you can always search for it by clicking the Advanced button and look-it up in the list. Hit OK when done.
Customize the permissions on the user or security group then click OK.
Now log in on a client in the other domain (contoso.com) with a user that is part of the share ACL, and do a UNC path to access the share.
The user should be able to access it, and depending on the permissions, he or she can write, delete or create files and folder in this share.
And that’s it! This is all it takes to create an Active Directory forest trust. It’s not easy, mostly because of the terminologies used to create the trust but it’s not difficult either. Off course, trusts can be created between more that just two forest, and all you have to do is run the New Trust Wizard again. There are still some things I did not discussed in this article like shortcut trusts, domain trusts etc because they were out-of-scope and because of the space required for the article, but they will appear in future articles, that’s for sure.
Want content like this delivered right to your