Q: We have a multi-forest Active Directory (AD) infrastructure that consists of a central account forest, which is managed by our IT department, and a resource forest for our Microsoft Exchange infrastructure, which is managed by a service provider. These forests are connected via a WAN link. To speed up the authentication process for users connecting to their Exchange mailbox located in the resource forest (our users use their AD accounts, which are defined in our central account forest), and to make authentication independent of WAN outages, we would like to set up local domain controllers (DCs) of the account forest in the data center of our messaging service provider. What must I do to ensure that the DCs of the resource forest effectively use the local DCs of the account forest for authentication traffic? In other words, how can I ensure that the inter-forest authentication traffic doesn't cross the WAN anymore?
A: To ensure that your resource forest’s DCs use the local account forest DC in the service provider’s data center, you must ensure that the name of the site that contains the account forest’s local DCs and the name of the site containing the resource forest’s DCs are identical. To do so, create a site named, for example, datacenter-site in the account forest AD and put the local data center DCs in that site. Then create a site with the same name (i.e., datacenter-site) in the resource forest AD and put the resource forest DCs in that site.
The reason the site names in both forests must be identical is because of the AD DC locator process, which is DNS-based and queries for the site closest to the site in which the local DC is located. If the site names match, the DC locator will pick a DC in that site with the same name. For more information about the DC locator process, see http://support.microsoft.com/kb/247811.
Also, you must ensure your resource forest’s DCs use the local DCs of the account forest by resetting the secure channel between the resource forest DCs and the account forest DCs. The secure channel is a secure communication pipe that's automatically set up between Windows DCs (and also between DCs and workstations) to secure the authentication traffic that occurs between DCs.
After your local DCs in the data center are operational, you can reset the resource forest’s DCs secure channels using the Nltest command-line utility. Nltest can be used to troubleshoot the Windows netlogon service and to manage secure channels. Resetting the secure channel will force the DCs to locate a new DC secure channel partner that's preferably as close as possible (AD site-wise) to the local DC.
For example, to reset the secure channel to a domain named account.contoso.com for a DC named Resource_DC01, you would use the following Nltest command:
Nltest /server:Resource_DC01 /sc_reset:account.contoso.com
To query the current secure channel partner for the same DC, you would run the following Nltest command:
Nltest /server:Resource_DC01 /sc_query:account.contoso.com
