Microsoft KB Archive/916474

= 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 =

Article ID: 916474

Article Last Modified on 12/28/2006

-

APPLIES TO

 Microsoft Windows Server 2003 Service Pack 1, when used with:  Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)

 Microsoft Windows Server 2003, Standard Edition (32-bit x86) 

-



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  domain) may take lots of time. When you run the nltest /sc_query command, you may find that for the domain in the other forest, a domain controller was chosen that is less optimal for the network topology. 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 .COM. Assume that the name of the forest to which you create the trust is .COM. Also assume that an external trust is established between .COM and  .COM in the forest by using the FQDN. Additionally, the trust is set up as follows:
 * SOURCE trusts TARGET
 * TARGET contains the user accounts

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  domain). This command lists the number of trusts that are created in the  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 the Net Logon service uses DC Locator to set up a secure trust channel between forests
To set up a secure trust channel between a domain controller in the .COM forest and a domain controller in the  .COM forest, the locator initiates the following process:  To locate a domain controller in the .COM forest, the locator initiates 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  domain. However, the domain part of the DNS query uses the .COM forest name. For example, if the name of the forest is .COM, and the name of the site is SourceSite, the DNS query is as follows:

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

</li> The DNS server of the .COM forest domain (the  domain) sends a response to the DNS server in the   domain that says that the domain cannot find an appropriate match for SourceSite. This information is passed to the SOURCE domain controller.</li> The  domain sends another DNS query that does not specify any site information. In the example that is used in this section, the DNS query sends the following query:

_ldap._tcp.dc._msdcs. .COM

</li> When the DNS server receives this query, it searches for a list of domain controllers that are registered in the   domain.</li> The  domain DNS server tries to select a domain controller by using DNS Netmask Ordering and responds to the domain controller in the   domain by sending the information about the selected domain controller.</li></ol>

However, the IP address structure and the subnet mask structure of the domain controller in the .COM forest may be different from that of the domain controller in the  .COM forest. Therefore, a far-remote Target domain controller may be choosen, and pass-through authentication that is initiated in the .COM forest for users in the  .COM forest takes more time.

Note Verify your result. Run the nltest /sc_query command on the domain controller in the  domain to locate the domain controller that the   domain that is used to establish a secure trust channel with the   domain.

How to optimize pass-through authentication of user accounts
To optimize pass-through authentication of user accounts in the .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   domain that has the same name as that of the site that hosts the domain controller in the   domain.
 * 2) Link this site to other sites in the   domain, and then assign domain controllers to this site.

The  domain controller should be a server that has good network connectivity to SourceSite.

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

 * 1) Select a domain controller in the   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   domain site name.

A  domain controller should be a server that has good network connectivity to SourceSite.

Method 3: Use an optimization feature of the Net Logon Service

 * 1) Obtain the IP subnet information for the   domain site SourceSite from the domain site configuration in Active Directory Sites and Services snap-in. If the IP address of the domain controller that the   domain site hosts does not match the subnet information, you can use the IP address of the domain controller instead.
 * 2) In the   domain, create a matching subnet object for the IP subnet information or for the domain controller IP address that you obtained earlier from the   domain.
 * 3) Use the Active Directory Sites and Services snap-in to create this subnet.
 * 4) After you create the subnet, assign this subnet to an existing site that is located near the  domain site subnet. In this example, the subsite is called TargetSite.

Note You may want to identify the broadest subnet that defines the  domain site and assign the subnet to the   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  domain site to locate the best or closest resource in the   domain.

After you complete these steps, the following optimization occurs for this example: <ol> The domain controller in the  domain sends the following site-specific DNS search query that has its own site for a LDAP server in the   domain:

target.com DNS: 0x3A16:Std Qry for _ldap._tcp.SourceSite._sites.dc._msdcs.target.com

</li> Because the site name is unknown, the DNS server from the  domain (target.com) generates the following error message:

DNS: Name does not exist

</li> The  domain controller queries as follows after the fallback:

Qry for _ldap._tcp.dc._msdcs.target.com

</li> The DNS server from the  domain (target.com) generates a list of LDAP servers that are globally registered.</li> A domain controller is selected from the LDAP servers that are globally registered, and a LDAP SearchRequest (Netlogon ping) is sent to the domain controller.</li> In the LDAP response, the queried domain controller propagates its name, the site it covers, and the site that has a matching subnet-site configuration for the IP of the sending domain controller. The queried domain controller is now the TargetSite for the matching subnet-site configuration as described in Method 3.</li> Because the responding domain controller is in a different site than the subnet-site match that is returned, the responding domain controller initiates the following site specific DNS query of the received site match in the target.com domain:

Qry for _ldap._tcp.TargetSite._sites.dc._msdcs.target.com

</li> The DNS server from the target.com domain generates a list of LDAP servers that are registered for this site.</li> The SOURCE domain controller sends another LDAP SearchRequest (Netlogon ping) to the local domain controller that is returned from the DNS server.</li> In the search response, the domain controller indicates that it covers the matching site (TargetSite).</li> The  domain controller selects this   domain controller to set up the secure trust channel to the target.com domain.</li></ol>

These steps are documented in the Netlogon.log file on the domain controller in the  domain. If you have turned on Net Logon service logging, entries are logged that resemble the following: <pre class="fixed_text">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  domain. If a user from the  domain performs an interactive logon on a client from the   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  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.

<div class="references_section">