Domain Controller Location Process

Each Windows 2000–based domain controller registers its DNS domain name on the DNS server and registers its NetBIOS name by using a transport-specific mechanism (for example, WINS). Therefore, a DNS client locates a domain controller by querying DNS, and a NetBIOS client locates a domain controller by querying the appropriate transport-specific name service. Because the code for the Windows 2000 IP/DNS-compatible Locator and the Windows NT 4.0–compatible Locator is shared, both DNS clients and NetBIOS clients are supported.

The process for locating a domain controller can be summarized as follows:

  1. On the client (the computer that is locating the domain controller), the Locator is initiated as a remote procedure call (RPC) to the local Net Logon service. The Locator API (DsGetDcName) is implemented by the Net Logon service.

  2. The client collects the information that is needed to select a domain controller and passes the information to the Net Logon service by using the DsGetDcName API.

  3. The Net Logon service on the client uses the collected information to look up a domain controller for the specified domain in one of two ways:

    • For a DNS name, Net Logon queries DNS by using the IP/DNS-compatible Locator — that is, DsGetDcName calls DnsQuery to read the SRV records and A records from DNS after it appends an appropriate string to the front of the domain name that specifies the SRV record.

    • For a NetBIOS name, Net Logon performs domain controller discovery by using the Windows NT 4.0–compatible Locator — that is, by using the transport-specific mechanism (for example, WINS).

    note-iconNote

    In Windows NT 4.0 and earlier, "discovery" is a process for locating a domain controller for authentication in either the primary domain or a trusted domain.

  4. The Net Logon service sends a datagram to the discovered domain controllers ("pings#34; the computers) that register the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP UDP search.

  5. Each available domain controller responds to the datagram to indicate that it is currently operational and then returns the information to DsGetDcName.

  6. The Net Logon service returns the information to the client from the domain controller that responds first.

  7. The Net Logon service caches the domain controller information so that it is not necessary to repeat the discovery process for subsequent requests. Caching this information encourages the consistent use of the same domain controller and, thus, a consistent view of Active Directory.

DsGetDcName API

The following parameters are the DsGetDcName API parameters that Net Logon uses to collect information from the client and to compose the DNS or WINS query. As described in "Domain Controller Location Process" earlier in this chapter, the API is called remotely in a datagram that is sent to the discovered domain controllers, and the domain controller provides the information to the client.

ComputerName    The name of the computer that collects the information. The value of this parameter is usually NULL, which denotes the local computer. The DsGetDcName API is passed by RPC to the specified computer.

DomainName    The name of the domain to be queried. This name can be either a DNS-style name (for example, reskit.com.) or a flat, NetBIOS-style name (for example, reskit). If a DNS-style name is specified, the name can be specified with or without a trailing dot.

DomainGuid    The GUID of the domain being queried. This value is used when a domain has been renamed. If this value is specified and DomainName has been renamed, DsGetDcName attempts to locate a domain controller in the domain that has the specified DomainGuid.

SiteName    The name of the site in which the domain controller that is returned should be located. This parameter is usually not specified. When the site is not specified, the domain controller that is returned is in the site that is closest to the one in which ComputerName is located.

Flags    Additional information that the application can use to process the request. Flags include the following:

DS_FORCE_REDISCOVERY . Requires that a domain controller be determined, even if a domain controller is currently known in the cache. This flag can be used when an additional domain controller becomes available or when an existing domain controller has been detected to be unavailable. This function guarantees only the domain controller that was returned when the domain controller was initially entered into the cache. The DS_FORCE_REDISCOVERY flag should not be specified unless this function has been called recently without the flag. An attempt to gain access to the cached domain controller should be made. Only if this initial attempt to gain access fails should the flag be used to call the function again.

DS_DIRECTORY_SERVICE_REQUIRED . Requires that the returned domain controller support Directory Server API (is running Windows 2000 Server).

DS_DIRECTORY_SERVICE_PREFERRED . Prefers that the returned domain controller support Active Directory (is running Windows 2000 Server). If no such domain controller is available, a domain controller that is running Windows NT 4.0 or earlier is returned. If no domain controller that supports a directory service is available, DsGetDcName returns the name of the closest non-Active Directory domain controller; however, DsGetDcName returns the non-Active Directory domain controller information only after the attempt to find an Active Directory domain controller has timed out.

DS_GC_SERVER_REQUIRED . Requires that the returned domain controller be a Global Catalog server for the forest of domains that has the specified domain as the root. This flag cannot be set if the DS_PDC_REQUIRED flag is set.

DS_PDC_REQUIRED . Requires that the returned domain controller be the primary domain controller for the domain. This flag cannot be set if the DS_GC_SERVER_REQUIRED flag is set. If this flag is specified, the DS_DIRECTORY_SERVICE_PREFERRED flag and DS_WRITABLE_REQUIRED flag are ignored.

DS_WRITABLE_REQUIRED . Requires that the returned domain controller host a writable copy of Active Directory (or Security Accounts Manager [SAM]. If the specified DomainName is a NetBIOS name, this flag causes DsGetDcName to find either a primary domain controller or a Windows 2000 Server–based domain controller. If the specified DomainName is a DNS name, this flag is ignored.

DS_IP_REQUIRED . Requires that the IP address of the discovered domain controller be returned.

DS_KDC_REQUIRED . Requires that the returned domain controller currently be running the KDC service.

DS_TIMESERV_REQUIRED . Requires that the returned domain controller be currently running the Windows Time Service.

DS_GOOD_TIMESERV_PREFERRED . Prefers that the returned domain controller be a "reliable" time server. The Windows Time Service can be configured to declare one or more domain controllers as "reliable" time servers. This flag is intended for use only by the Windows Time Service. The behavior of the flag is subject to change to achieve the implementation that best supports the Windows Time Service (W32time).

DS_IS_FLAT_NAME . Specifies that the DomainName parameter be a NetBIOS name. As such, the IP/DNS-compatible Locator is not tried, and the Windows NT 4.0–compatible Locator is used. (For more information about locating a domain controller by using a NetBIOS name, see "Windows NT 4.0–Compatible Locator Process for Non-IP/DNS Clients" later in this chapter.) This flag cannot be specified with the DS_IS_DNS_NAME flag. It is valid to set neither DS_IS_FLAT_NAME nor DS_IS_DNS_NAME; however, DsGetDcName() takes longer to find a domain controller because it must try both the DNS-style and NetBIOS names. In addition, it is potentially ambiguous to specify neither flag. For example, if you specify a domain name of "reskit," a domain with a NetBIOS name of "reskit" exists on your network, and a different domain with a DNS-style name of "reskit" also exists on your network, DsGetDcName() might find a domain controller in either domain.

DS_IS_DNS_NAME . Specifies that the DomainName parameter is a DNS name. (For more information about the DomainName parameter, see "Windows NT 4.0–Compatible Locator Process for Non-IP/DNS Clients" later in this chapter.) This flag cannot be specified by using the DS_IS_FLAT_NAME flag.

DS_AVOID_SELF . Specifies that the domain controller returned should not be the domain controller named by ComputerName . If ComputerName is not a domain controller, this flag is ignored. This flag can be used to get the name of another domain controller in the domain.

DS_RETURN_FLAT_NAME . Specifies that the returned DomainControllerName and returned DomainName must be flat names. If a flat name is not available, an error message is returned. This flag cannot be specified by using the DS_RETURN_DNS_NAME flag.

DS_RETURN_DNS_NAME . Specifies that the returned DomainControllerName and returned DomainName must be DNS names. If a DNS name is not available, an error message is returned. This flag cannot be specified with the DS_RETURN_FLAT_NAME flag. This flag implies the DS_IP_REQUIRED flag.

DS_ONLY_LDAP_NEEDED . Specifies that the server returned must be an LDAP server. The server returned is not necessarily a domain controller. No other services are implied to be present at the server. The server returned does not necessarily have either a writable Configuration container or a writable Schema container. The server returned is not necessarily used to create or modify security principles. This flag can be used with the DS_GC_SERVER_REQUIRED flag to return an LDAP server that also hosts a Global Catalog server. The returned Global Catalog server is not necessarily a domain controller. No other services are implied to be present at the server. If this flag is specified, the following flags are ignored: DS_PDC_REQUIRED, DS_TIMESERV_REQUIRED, DS_GOOD_TIMESERV_PREFERRED, and DS_KDC_REQUIRED.

For more information about the DsGetDcName API and DsGetDcName flags, see the Microsoft Platform SDK link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .