Types of Locators

On the basis of parameters passed to Net Logon in the DsGetDcName API, the process of locating a domain controller proceeds in one of two ways:

• The IP/DNS-compatible Locator is used if the domain name passed to DsGetDcName is a DNS-compatible name. The Net Logon service on the client looks up the name in DNS (by calling DnsQuery) after it appends an appropriate string to the front of the domain name. The DNS service supports a query for determining the set of domain controllers. If the client site name is known, the client DNS query specifies the site. DNS returns the IP addresses of domain controllers that match the DNS query. The client Net Logon service sends an LDAP UDP message to one or more of the domain controllers that have been returned by DNS in order to determine whether any of the specified domain controllers are running and support the specified domain.
• The Windows NT 4.0–compatible Locator is used if the domain name passed to DsGetDcName is a NetBIOS name. The Net Logon service on the client sends a transport-specific logon request query to locate a domain controller in a particular domain and then sends a mailslot message to one or more of the domain controllers to determine whether any of the domain controllers it found are running and support the specified domain.

For more information about the DsGetDcName Locator API, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. For more information about DNS and IP address resolution, see "Introduction to DNS" and "Windows 2000 DNS" in the TCP/IP Core Networking Guide.

IP/DNS-Compatible Locator Process for Windows 2000 Clients

The IP/DNS-compatible Locator uses DNS SRV records to locate the closest domain controller on the basis of the site name registered for a particular domain controller.

Note

A site name is registered in DNS as a DNS label, which implies that the site name must syntactically conform to the rules of a DNS label. For example, a label cannot be more than 63 octets long and cannot contain illegal characters such as a dot. (For more information about DNS naming rules, see "Introduction to DNS" and "Windows 2000 DNS" in the TCP/IP Core Networking Guide.)

The IP/DNS-compatible Locator algorithm runs in the context of the Net Logon service that is running (typically) on the client. The following process takes place after the Net Logon service has established that a DNS name is being requested.

1. Locator queries DNS (calls DnsQuery) and specifies one of the criteria-specific DNS host names. If the client has site information, it first queries the site-specific DNS names. On the basis of parameters to the DsGetDcName API and the success or failure of a previous lookup, DNS is queried as follows:



Note

When DsGetDcName is called without specifying a site, DsGetDcName always attempts to find a domain controller in the site of the client or the site closest to the client, as described in "Automatic Site Coverage" earlier in this chapter. The details of site-specific discovery are omitted in the discussion that follows.

• If the DS_PDC_REQUIRED flag is specified, look up the _ldap._tcp.pdc._msdcs.DnsDomainName name. Return any success or failure to the caller.
• If the DS_GC_SERVER_REQUIRED flag is specified and the SiteName parameter is specified, look up the _ldap._tcp.SiteName._sites.gc._msdcs.DnsForestName name. If no domain controller is found, go to the next step. Otherwise, return any success or failure to the caller.
• If the DS_GC_SERVER_REQUIRED flag is specified and the SiteName parameter is not specified, look up the _ldap._tcp.gc._msdcs.DnsForestName name. Return any success or failure to the caller.
• If the DS_KDC_REQUIRED flag is specified and the SiteName parameter is specified, look up the _kerberos._tcp.SiteName._sites.dc._msdcs.DnsForestName name. If no domain controller can be found, go to the next step. Otherwise, return any success or failure to the caller.
• If the DS_KDC_REQUIRED flag is specified and the SiteName parameter is not specified, look up the _kerberos._tcp.dc._msdcs.DnsForestName name. Return any success or failure to the caller.
• If the DS_ONLY_LDAP_NEEDED flag is specified and the SiteName parameter is specified, look up the _ldap._tcp.SiteName._sites.DnsDomainName name. If no computer is found, go to the next step. Otherwise, return any success or failure to the caller.
• If the DS_ONLY_LDAP_NEEDED flag is specified and the SiteName parameter is not specified, look up the _ldap._tcp.DnsDomainName name. Return any success or failure to the caller.
• If the SiteName parameter is specified, look up the _ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName name. If no domain controller is found, go to the next step. Otherwise, return any success or failure to the caller.
• If the SiteName parameter is not specified, look up the _ldap._tcp.dc._msdcs.DnsDomainName name. If no domain controller has that name (which is not the same as "If no domain controllers can be found"), go to the next step. Otherwise, return any success or failure to the caller.
• If the DomainGuid parameter is specified, look up the _ldap._tcp.DomainGuid.domains._msdcs.DnsForestName name. Otherwise, return any success or failure to the caller.
2. If IP is not supported or DNS is not supported (indicated by an error message that is returned from the DnsQuery API), call the Windows NT 4.0–compatible Locator.
3. If the specified name cannot be found (perhaps because the domain has been renamed), call the Windows NT 4.0–compatible Locator.
4. DNS returns a list of IP addresses that match the target domain in the SRV records (that is, IP addresses of domain controllers in the specified domain) that are sorted by priority and weight, as described the Internet Draft "A DNS RR for specifying the location of services (DNS SRV)." (For more information about this draft, see the Internet Engineering Task Force [IETF] link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Follow the links to Internet Drafts, and then use a keyword search.) The client pings each IP address in the order returned. The ping is a UDP LDAP query to port 389. The client pings each domain controller from the list. After each ping, the client waits one-tenth of a second for a response to the ping (or to any previous ping), and then pings the next domain controller. Choosing the domain controllers at random provides a first level of load balancing. Doing multiple pings in quick succession ensures that the discovery algorithm terminates in a finite amount of time.
5. The pinging continues until a viable response has been received or all of the returned domain controllers have been tried.
6. When a domain controller responds to the ping, the information supplied in the response is compared to the information specified to DsGetDcName. If the information does not match, the response is ignored.
7. The first domain controller to respond to a ping is returned to the caller.

Windows NT 4.0–Compatible Locator Process for
Non-IP/DNS Clients

When the IP/DNS Locator cannot be used, domain location proceeds by using the Windows NT 4.0–compatible Locator. The IP/DNS Locator is not used under any of the following conditions:

• A NetBIOS domain name is supplied to DsGetDcName.
• IPX or NetBEUI is the only available transport.
• A Windows NT 3.51 or Windows NT 4.0 domain controller is being located.
• A Windows 3.1, Windows for Workgroups 3.1, Windows for Workgroups 3.11, Windows NT 3.51, Windows NT 4.0, Windows 95, or Windows 98 client is doing the locating.

In these cases, the Windows NT 4.0–compatible Locator is used to locate a domain controller in the domain. In general, the Windows NT 4.0–compatible Locator works as follows:

1. The client discovers a domain controller in a domain by sending a NETLOGON_SAM_LOGON_REQUEST message to \mailslot\net\ntlogon mailslot on the DomainName[1C] NetBIOS name of the domain whose domain controller is being discovered.
2. The DomainName[1C] NetBIOS name is registered by every Windows NT domain controller in the domain. The specific name resolution mechanism and datagram delivery mechanism that are used are transport-specific. The client uses the first domain controller that responds to the message.

Note

The algorithm described here locates any domain controller in the domain. A similar algorithm, implemented in NetGetDcName in Windows NT 4.0, is used when the caller specifies finding a primary domain controller.

Domain Controller Request

A client requests a domain controller by using the NETLOGON_SAM_LOGON_REQUEST message. In Windows 2000, this message is enhanced to contain the following new information:

• The NtVersion field specifies that Windows 2000–specific fields be present and that the response must contain more information.
• The RequestedDomainName field is used by Net Logon to identify the queried domain if the RequestedDomainGuid field is not present. This field immediately follows the existing DomainSid field.
• The RequestedDomainGuid field is used by Net Logon to identify the queried domain. This field immediately follows the RequestedDomainName field.

A Windows NT 3.51–based or Windows NT 4.0–based domain controller ignores the additional information in the query message.

Note

When a Windows 2000 domain has an external trust relationship with a non–Windows 2000 domain (a Windows NT 3.51 or Windows NT 4.0 domain), discovery of domain controllers in the external trusted domain is performed immediately when the client starts. Discovery at logon is not possible because the accounts in the trusted domain, which is outside the forest, are not available in the Global Catalog. The Global Catalog is required for logging on to the domain.

Domain Controller Response

A domain controller responds to the NETLOGON_SAM_LOGON_REQUEST message with a NETLOGON_SAM_LOGON_RESPONSE mailslot message as follows:

1. A Windows NT 3.51–based or Windows NT 4.0–based domain controller returns a NETLOGON_SAM_LOGON_RESPONSE mailslot message.
2. A Windows 2000–based domain controller returns a NETLOGON_SAM_LOGON_RESPONSE mailslot message to a client that is running Microsoft® Windows® version 3.1, Microsoft® Windows® for Workgroups version 3.1, Microsoft® Windows® for Workgroups version 3.11, Windows NT 3.51, or Windows NT 4.0.
3. A Windows 2000–based domain controller returns a NETLOGON_SAM_LOGON_RESPONSE_EX message to a Windows 2000–based client. All characters in this message are in the UTF-8 character set. The response message contains the following additional information:
• The NtVersion field indicates that Windows 2000–specific fields are present.
• The DomainGuid field returns the GUID of the domain.
• The DnsDomainName field returns the DNS name of the domain.
• The DnsForestName field returns the DNS domain name of the forest in which the domain controller is located.
• The DcSiteName field returns the name of the site in which the domain controller is located.
• The ClientSiteName field returns the name of the site in which the client is located.
• The DcSockAddr field returns the IP address of the domain controller.
• The Flags field indicates the following information about the domain controller:

Whether it is the primary domain controller.

Whether it supports the Global Catalog.

Whether it supports Active Directory.

Whether it is in the site closest to the client.

The Windows NT 4.0–compatible Locator cannot completely implement the DsGetDcName flag, which requires that a domain controller that supports the directory service API is returned (that is, the returned domain controller must be running Windows 2000). When the DomainGuid parameter is NULL, WINS is configured, and no Windows 2000–based domain controllers are among the 25 closest domain controllers in the domain, then DsGetDcName fails as though no domain controller were available.

Requerying to Find the Closest Site

A client that is running Windows 2000 and using the Windows NT 4.0–compatible Locator to find a domain controller attempts to find a domain controller in the site closest to it. After the client finds a domain controller, the mailslot response is inspected to determine the following:

• Whether the DNS domain name of the domain was returned. (The value is not TRUE if the domain controller is running Windows NT 3.51 or Windows NT 4.0.)
• Whether the ClientSiteName was returned. (The value is not TRUE if there is no subnet object that matches the IP address of the client.)
• Whether the domain controller did not indicate that it is in the site closest to the client.

If all of these conditions have the value TRUE, DsGetDcName calls DsGetDcName again and passes the DNS domain name and the site name. This new call to DsGetDcName uses the IP/DNS Locator to try to find a domain controller in the named site. If the new call finds a domain controller, that domain controller is returned to the client as the result of the original DsGetDcName call. If the new call does not find a domain controller, the original domain controller is returned.

© 1985-2000 Microsoft Corporation. All rights reserved.