Domain Locator Across a Forest Trust

Rob and Mike here. We’re asked, many times, why a user does not authenticate against a local domain controller in the same site when logging on across a forest. We’ve setup the most common scenario to help explain how domain locator works for user logons across a forest.


Let’s explain the typical scenario in which we see this problem: The scenario starts with two separate Active Directory forests: and Each forest has a forest (i.e. kerberos) trust to the other. The forest has one Active Directory site name CHARLOTTE. The forest contains two sites: REDMOND and CONTOSO. Administrators in the forest created the CONTOSO site and subnet to support logons for users from terminal servers in the forest.

Figure 1 Forest trust configuration


Users from logon to a terminal server existing in the forest. However, Users experience a slower-than-usual logon, and the LOGONSERVER environment variable shows the name of a remote domain controller in the REDMOND site rather than the domain controller from the CONTOSO site.

However, administrators from the domain expect users from their domain (logging on terminal servers) to authenticate using the domain controller located in the CONTOSO site. The CONTOSO site is the same physical locations as the terminal server. Authentication should occur in the local site and should be fast, right?

DC Locator

It is important to know how a Windows computer selects a domain controller. The computer, during startup, determines the Active Directory site in which it belongs. Windows accomplishes this by examining the subnet of its current network configuration. Then, the computer queries a domain controller that hosts the computer object(using the Windows API DsGetSiteName). The domain controller answers this query with the name of the site associated with the computer’s currently configured subnet. This is all done by the NetLogon service, which runs the DC Locator code at boot and periodically rechecks the domain controllers’ location.

The computer determines the site name using a domain of which the computer is a member—not the user’s domain. This determination occurs during computer startup—not during user logon. Microsoft Support article 939252 (;EN-US;939252) describes how you can change this behavior

Windows writes the site name to the registry during each computer startup. You can view the registry to determine the site to which the computer believes it belongs. You should NOT modify this registry value. The path to this registry value is:

Domain Controller discovery during user logon

Windows will attempt to use the closest domain controller (on the same subnet) to the local computer for authentication. Windows finds the closest domain controller by using DNS and SRV resource records.

Here’s how it works: Windows first performs a DNS query to find a _ldap SRV record for the computer’s current site, but using the domain name selected from the CTRL+ALT+DEL sequence – the domain name of the user. An example looks like:

_ldap._tcp.<Computer Site Name>._sites.dc._msdcs.<User Domain>.com: type SRV, class IN

The DNS server responds indicating a record by that name is not found. Windows then attempts to find any domain controller within the user’s domain. Windows accomplishes this by removing the site name from the DNS query. The example similar to the one above:

_ldap._tcp.dc._msdcs.<User Domain>.com: type SRV, class IN

The DNS server’s response to the above request includes a resource record for every domain controller in the user’s domain. Since the client receives the list of domain controllers in no particular order this result is usually the cause as to why the domain controller locator does not use the closest domain controller for authentication.

The Netlogon service of a domain controller is responsible for dynamically registers the _ldap service resource records with its configured DNS server. This registration includes the site specific and domain specific _ldap records.

Our scenario involves a terminal server, which allows multiple users sessions. This is a great way to take network captures of user logon related issues by sing one of the logon sessions to take the network capture. It is always best to clear the DNS and NetBIOS name caches before starting a network capture. This ensures the network capture includes name resolution. You can clear these caches by using IPConfig /FlushDNS and NbtStat –R from a command window (under an elevated command prompt for Server 2008 and Vista).

Here is a snippet of the output of the network capture.


Figure 2 network capture of user logon

The results of the network capture show the domain controller locator attempts to locate a domain controller in the site with the same name as the site of the computer; but in the user’s domain (frame 3). The DNS server responds with no such name. This is correct. The forest has only two sites: REDMOND and CONTOSO. Frame 4 queries for an SRV record a second time; however, this time the query does not include the site name of the computer (_ The DNS response provides a positive answer to the second query. The answer includes a _ldap record for each domain controller in the domain (the user’s domain).

We’ve covered the background information and the problem. Now, let’s talk about how to fix it. We can accomplish this by using Active Directory Sites and Services to rename the CONTOSO site in the domain to CHARLOTTE (the name of the site hosting the computer in the domain). Active Directory site configuration is stored in the configuration partition of Active Directory. Renaming the site creates a change and you’ll want ensure this replication converges– especially to the domain controller that is now located in the CHARLOTTE site of the domain. After Active Directory replication completes, then restart the Netlogon service on the domain controller in CHARLOTTE site (in the domain). This registers the service resource records in DNS for the domain controller, including the new site in which it belongs.


Figure 3 Forest trust configuration after site rename

Let’s take another network trace of a domain user logon from the terminal server in the domain.


Figure 4 Network capture after site rename in

The same DNS query from figure 1 appears in figure 2. Frame 3 shows the domain controller locator attempting to find a domain controller service resource record in the CHARLOTTE site of the user’s domain, However, the difference between figure 1 and figure 2 is the DNS response. Figure 1 returned a negative DNS response because a resource record for the domain controller did not exist in the CHARLOTTE site in the domain. But, figure 2 shows a positive DNS response (frame 5) for a service resource record for a domain controller in the CHARLOTTE site of the domain.


After renaming the sites so that they match in both forests, the terminal server in the domain successfully located a domain controller covering the CHARLOTTE site for domain. Ideally, in this scenario you would also want the domain controller covering for the CHARLOTTE site to be on the same subnet as the terminal server. This helps expedite logon requests originating from the terminal servers. Regardless, the configuration provides a way to distinguish a specific domain controller for use with logons that span across forests.

– Rob Greene and Mike Stephens