Microsoft KB Archive Search

Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

  1. Home
  2. 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

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

View products that this article applies to.

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

↑ Back to the top

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. Also assume that an external trust is established between SOURCE.COM and TARGET.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 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 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 SOURCE.COM forest and a domain controller in the TARGET.COM forest, the locator initiates the following process:
  1. To locate a domain controller in the TARGET.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 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.TARGET.COM
  2. The DNS server of the TARGET.COM forest domain (the TARGET domain) sends a response to the DNS server in the SOURCE domain that says that the domain cannot find an appropriate match for SourceSite. This information is passed to the SOURCE domain controller.
  3. The SOURCE 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.TARGET.COM
  4. When the TARGETDNS server receives this query, it searches for a list of domain controllers that are registered in the TARGET domain.
  5. The TARGET domain DNS server tries to select a domain controller by using DNS Netmask Ordering 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, a far-remote Target domain controller may be choosen, and pass-through authentication that is initiated in the SOURCE.COM forest for users in the TARGET.COM forest takes more time.

Note Verify your result. Run the nltest /sc_query command on the domain controller in the SOURCE domain to locate the domain controller that the TARGET domain that is 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 TARGET 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 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.
A TARGET 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 SOURCE 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 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 IP subnet information 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 this subnet.
  4. After you create the subnet, assign this subnet to an existing site that is located near the SOURCE domain site subnet. In this example, the subsite is called TargetSite.
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 optimization occurs for this example:
  1. The domain controller in the SOURCE domain sends the following site-specific DNS search query that has its own site for a LDAP server in the TARGET domain:
    target.com DNS: 0x3A16:Std Qry for _ldap._tcp.SourceSite._sites.dc._msdcs.target.com
  2. Because the site name is unknown, the DNS server from the TARGET domain (target.com) generates the following error message:
    DNS: Name does not exist
  3. The SOURCE domain controller queries as follows after the fallback:
    Qry for _ldap._tcp.dc._msdcs.target.com
  4. The DNS server from the TARGET domain (target.com) generates a list of LDAP servers that are globally registered.
  5. 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.
  6. 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 SOURCEdomain controller. The queried domain controller is now the TargetSite for the matching subnet-site configuration as described in Method 3.
  7. 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
  8. The DNS server from the target.com domain generates a list of LDAP servers that are registered for this site.
  9. The SOURCE domain controller sends another LDAP SearchRequest (Netlogon ping) to the local domain controller that is returned from the DNS server.
  10. In the search response, the domain controller indicates that it covers the matching site (TargetSite).
  11. The SOURCE domain controller selects this TARGET domain controller to set up the secure trust channel to the target.com 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.

↑ Back to the top

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

↑ Back to the top

Keywords: KB916474, kbtshoot

↑ Back to the top

Article Info
Article ID : 916474
Revision : 4
Created on : 12/28/2006
Published on : 12/28/2006
Exists online : False
Views : 263