How to optimize pass-through authentication of user accounts after you create an external trust between two Microsoft Windows Server 2003 Service Pack 1 (SP1)-based forests (916474)


The information in this article applies to:

  • Microsoft Windows Server 2003 SP1, when used with:
    • Microsoft Windows Server 2003, Enterprise Edition
    • Microsoft Windows Server 2003, Standard Edition

INTRODUCTION

You have created an external trust between two Microsoft Windows Server 2003 Service Pack 1 (SP1)-based forests by using fully qualified domain names (FQDN). However, in this case, pass-through authentication of the user accounts in the domain that did not originate the trust (the TARGET domain) may take lots of time. This article discusses how to optimize pass-through authentication after you create an external trust between two Windows Server 2003 SP1-based forests.

MORE INFORMATION

When you create an external trust between two forests by using FQDNs, the Domain Name System (DNS) name is referenced in the Trusted Domain Object (TDO) by using a trustType:2 value. This object is specified in the System folder in Active Directory User and Computers. This object represents the trust relationship between the domains in the two forests.

For example, assume that the name of the forest in which you create the trust is SOURCE.COM. Assume that the name of the forest to which you create the trust is TARGET.COM. After you establish a trust relationship between these two forests, run the nltest command together with the /domain_trusts switch on the domain controller for the domain that initiated the trust (the SOURCE domain). This command lists the number of trusts that are created in the SOURCE domain. For example, the nltest /domain_trusts command displays output that resembles the following:
List of domain trusts:
    0: TARGET TARGET.COM (NT 5)
    1: SOURCE SOURCE.COM (NT 5)

How DNS sets up a secure trust channel between forests

To set up a secure trust channel between a domain controller in the SOURCE.COM forest and a domain controller in the TARGET.COM forest, DNS initiates the following process:
  1. To locate a domain controller in the TARGET.COM forest, DNS must initiate a site-specific DNS query. The site name that is used for the query is the name of the site that hosts the domain controller in the SOURCE domain. However, the domain part of the DNS query uses the TARGET.COM forest name. For example, if the name of the forest is TARGET.COM and the name of the site is SourceSite, the DNS query is as follows:

    _ldap._tcp.SourceSite._sites.dc._msdcs.msdcs.TARGET.COM

  2. The TARGET.COM forest domain (the TARGET domain) sends a response to the domain controller in the SOURCE domain that says that the domain cannot find an appropriate match for SourceSite.
  3. The SOURCE domain sends another DNS query that does not specify any site information. For example, the DNS query sends the following query:

    _ldap._tcp.dc._msdcs.TARGET.COM

  4. When the TARGET domain receives this query, it searches for a list of global catalog domain controllers that are registered in the TARGET domain.
  5. The TARGET domain selects a domain controller and responds to the domain controller in the SOURCE domain by sending the information about the selected domain controller.
However, the IP address structure and the subnet mask structure of the domain controller in the TARGET.COM forest may be different from that of the domain controller in the SOURCE.COM forest. Therefore, pass-through authentication that is initiated in the SOURCE.COM forest for users in the TARGET.COM forest takes more time.

Note Run the nltest /sc_query command on the domain controller in the SOURCE domain to locate the domain controller that the TARGET domain used to establish a secure trust channel with the SOURCE domain.

How to optimize pass-through authentication of user accounts

To optimize pass-through authentication of user accounts in the TARGET.COM forest, use one of the following methods.

Method 1: Create the same site name in the forest to which you want to create a trust relationship

  1. Create a site in the TARGET domain that has the same name as that of the site that hosts the domain controller in the SOURCE domain.
  2. Link this site to other sites in the TARGET domain, and then assign domain controllers to this site.
The domain controllers that you assign must have a DNS structure that closely matches the DNS structure of the domain controller that is hosted in the SOURCE domain site.

Method 2: Use Net Logon Group Policy to register the site name on a domain controller

  1. Select a domain controller in the TARGET domain.
  2. Use the Sites Covered by the domain controller locator DNS SRV Records Net Logon service Group Policy settings on that domain controller to register the SOURCE domain site name.
The domain controller that you select in the TARGET domain must have a DNS structure that closely matches the DNS structure of the domain controller in the SOURCE domain site.

Method 3: Optimize the Net Logon service

  1. Obtain the subnet IP address of the SOURCE domain site from the domain site configuration. If the IP address of the domain controller that the SOURCE domain site hosts does not match the subnet information, you can use the IP address of the domain controller instead.
  2. In the TARGET domain, create a matching subnet object for the subnet IP address or for the domain controller IP address that you obtained earlier from the SOURCE domain.
  3. Use the Active Directory Sites and Services snap-in to create a subnet.
  4. After you create the subnet, assign this subnet to an existing site that is located near the SOURCE domain site subnet.
Note You may want to identify the broadest subnet that defines the SOURCE domain site and assign the subnet to the TARGET domain site as long as it does not conflict with previous site definitions. This setting allows for the most domain controllers and clients in the SOURCE domain site to locate the best or closest resource in the TARGET domain.

After you complete these steps, the following events occur:
  1. The domain controller in the SOURCE domain sends a site-specific DNS search query to the TARGET domain.
  2. The TARGET domain sends a list of available domain controllers back to the domain controller in the SOURCE domain.
  3. The domain controller in the SOURCE domain selects a domain controller from the search result and sends a DNS search query to this domain controller.
  4. In the DNS query response, the queried domain controller from the TARGET domain broadcasts the following information:
    • The name of the domain controller
    • The site that the domain controller covers
    • The site that contains a matching subnet configuration for the IP address of the sending domain controller in the SOURCE domain
  5. The domain controller in the SOURCE domain initiates another site-specific DNS query. This query occurs because the domain controller finds that the queried domain controller is in a different site than the site that was returned in step 4.
  6. The domain controller in the SOURCE domain resends a site-specific DNS query by using the site name that was obtained from the TARGET domain and that is located near the subnet of the SOURCE.COM forest site.
  7. The trusted domain sends a DNS query response that contains a list of domain controllers in that site.
  8. After it receives the DNS response, the domain controller in the SOURCE domain sends a site-specific DNS query to a domain controller that is included in the list.
  9. The domain controller in the TARGET domain indicates in the DNS query response that it belongs to the site that was mentioned in the DNS query.
  10. The domain controller in the SOURCE domain then selects this domain controller to create a trust channel to the TARGET domain.
These steps are documented in the Netlogon.log file on the domain controller in the SOURCE domain. If you have turned on Net Logon service logging, entries are logged that resemble the following:
10/13 10:18:51 [MAILSLOT] NetpDcPingListIp: target.com: Sent UDP ping to 10.137.199.143
10/13 10:18:51 [MISC] NetpDcGetNameIp: target.com Trying to find a DC in a closer site: TargetSite  // optimization step
10/13 10:18:51 [MAILSLOT] NetpDcPingListIp: target.com: Sent UDP ping to 10.129.0.108
10/13 10:18:51 [SESSION] SOURCE: EU: NlDiscoverDc: Found DC \\DC04.target.com
Note Method 3 is specific to the IP address setting of the domain controllers in the SOURCE domain. If a user from the TARGET domain performs an interactive logon on a client from the SOURCE domain, authentication may require a domain controller that is a global catalog server. If the IP address of the client has no match in the matching site configuration on the TARGET domain, a domain controller that acts as a global catalog server may be chosen that may be less optimal. If a match in the site configuration is available, Method 3 may be a better way to locate a local DFS resource than Method 1 or than Method 2. Decide which method to use based on business requirements.

REFERENCES

For more information about the Nltest.exe utility, click the following article number to view the article in the Microsoft Knowledge Base:

158148 Domain Secure Channel Utility -- Nltest.exe

For more information about the Net Logon Group Policy that is used to register a site on a domain controller, click the following article number to view the article in the Microsoft Knowledge Base:

306602 How to optimize the location of a domain controller or global catalog that resides outside of a client's site

For more information about how to enable Net Logon service logging, click the following article number to view the article in the Microsoft Knowledge Base:

109626 Enabling debug logging for the Net Logon service

Modification Type:MajorLast Reviewed:4/20/2006
Keywords:kbtshoot KB916474 kbAudITPRO
©2004 Microsoft Corporation. All rights reserved.