Errors are likely to occur either when creating, validating or using a cross-forest trust. Typical errors you'll see are "unable to contact the domain" or "domain is not available."
The first thing to check is DNS. Let's go back to a scenario created in a previous article on how to create a cross-forest trust in Active Directory:
More on Active Directory cross-forest trusts
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.
In that scenario, secondary zones or conditional forwarders that point to the other domain/forest should have been created. For example, define a secondary zone for ABC.com in the Corp.com DNS servers and vise versa.
To test DNS, try the following:
- Ping the forest root domain by name from the other forest. The other forest's DNS server should reply. For example: From the Corp.net domain, ping the ABC.com domain name. One of the authoritative DNS servers for ABC.com should reply.
- If you can't ping the domain name, ping a DC in the other forest -- by name -- then address if the name fails.
- Be sure network connections are working -- ping the IP address, other machines on the subnet and so on. If you can't ping the address, it's a network issue. If you can ping the address but can't ping the name, it's a DNS issue.
- Ensure the SRV records for the DC in each forest are registered properly. Take a few minutes and browse through all the zone folders. Make sure there are no SRV records for non-existent DCs, that the Host record points to the correct IP address and that a Kerberos and LDAP SRV record exist for each DC in the various folders. Also, if there is a child domain and it's a delegated zone, make sure the delegation record points to the correct IP address of a DNS server in the child domain.
- Make sure that the domain controllers are powered up. Seems obvious, but you might be surprised.
Next, verify the trust by going to the Domains and trusts snap-in. Right-click on the domain icon, and in the trusts tab, select the trust and click Properties. In the Properties tab, click the Verify tab. If the trust is created but can't be validated, delete both sides of the trust and recreate. The error can often be corrected in this manner.
If the trust is created and validated but you can't do trusted operations, such as logging in across the trust or finding users in the other forest, check the system time in both forests. The system time on the PDC in the root domain in both forests must be synchronized. You can do this manually or configure them to point to an external time source.
Perform the following operations to verify functionality of the trust:
- Create a share on one of the domain controllers in one forest. Grant permission to allow a user or group from the other domain access to the share. Log on to a computer in the other forest with that user or as a member of the group granted access and see if you have the appropriate rights.
- Log on to the member server in one forest with an account from the other forest.
- Configure the Users and Computers snap-in on one forest to manage a domain in the other forest.
In the snap-in, right-click on the Active Directory Users and Computers icon and select "connect to
domain." Locate the icon for the other trusted forest. This will allow you to see the domain in the
trusted forest – users, groups and so on.
- Do the resources in that domain show up?
- Can you modify them? Try to create a user, a group, change the attribute of an existing user.
- Notice that you can't add users from one forest to the global group in the other forest. You must add them to a local group and then add the global group to the local group.
It is important to note that when you create a trust, you determine the level of security you want. That is, you can have it wide open so that authenticated users in one forest have the same rights as authenticated users in the other, or you can set it so that you must explicitly grant access to resources in the other domain. This can be changed after the trust is built via the trust wizard.
And make sure the time is synchronized in the domains. Even if a trust is successful, if the time gets out of sync, the trust will fail. The best way to do this is to set the root domain PDC of each forest to point to the same external time source. Remember, however, that Kerberos tickets are not encrypted going across a cross forest trust.
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.
This was first published in March 2008