3.1.1 Example 1: Locate a Domain Controller
This example shows the pattern to locate a domain controller that is based on the domain name provided--both flat, NetBIOS names and the fully qualified Domain Name System (DNS) names that are preferred for Active Directory-style domains. This example is useful in order to locate a domain controller for the purpose of joining a domain or performing other domain-related operations in a domain environment.
This example builds on the use case described in section 2.7.7.3.1, Locate a Domain Controller - Domain Client.
Prerequisites
The general requirements that are set forth in section 2.6, Assumptions and Preconditions.
The Active Directory system meets all preconditions described in section 2.7.7.3.1.
Initial System State
The location of a domain controller (DC) is not known.
Final System State
A DC that meets the required capabilities is located, and information about the DC is provided to the caller. If this goal cannot be achieved, an error is returned indicating that a DC could not be located.
Upon failure, the local state of the client computer remains unchanged.
Sequence of Events
This task can be performed by using one or both of two possible approaches: DNS-based location or NetBIOS-based location. If the FQDN of the domain is available, the DNS-based location is performed. If only the NetBIOS name of the domain is available, or if the DNS-based location is unsuccessful, the NetBIOS-based location is performed.
Locate a Domain Controller by Using the DNS Infrastructure
The following sequence diagram shows the message flow that is associated with this example.
Figure 41: Message flow for domain location that is based on a DNS domain name
The FQDN of the domain in which the domain controller is to be located is available. The domain client makes use of the FQDN of the domain along with site information from the client and sends an SRV query to the DNS server to get a list of IP addresses of candidate domain controllers.
If no candidate domain controllers can be identified using SRV queries, the client falls back to NetBIOS-based location (described later in this section).
Active Directory servers offer the Lightweight Directory Access Protocol (LDAP) service over the TCP protocol; for example (see [MS-ADTS] section 6.3.6), clients can find an LDAP server by querying DNS for a record of the form:<6>
_ldap._tcp.DnsDomainName
After the list of candidate domain controllers is obtained by using the DNS Infrastructure, the domain client selects a candidate domain controller that is based on a weighted random order ([RFC2052]). The client sends A/AAAA DNS queries to resolve the SRV record to an IP address.
The domain client receives the IP address that was resolved from the SRV record in an A/AAAA DNS response.
After the IP address is known, the client sends an LDAP "Ping" to the candidate domain controller to determine whether the domain controller is in fact handling requests and whether its capabilities satisfy the client's requirements.
Upon receipt of a successful LDAP Ping response, the domain client validates that the capabilities that the domain controller returned satisfy the requested capabilities. If the capabilities that the domain controller returned are incompatible with the requirements that the client specifies, the client selects another candidate domain controller from the list of domain controller SRV records that were returned in step 2 and repeats steps 3 through 6.
If all the responses in the SRV records have been checked and each SRV record points to a server that is either not available or does not match the requirements, then the DC location operation fails. In this case, the client falls back to NetBIOS-based DC location (described later in this section). If a domain controller still cannot be found, an error is returned indicating that a domain controller could not be located.
If the domain in which the domain controller is to be located is the same as the client computer's domain, the site name abstract data is updated with the client site name information that the domain controller returns as part of the LDAP Ping response.
Locate a Domain Controller by Using the NetBIOS Infrastructure
The following sequence diagram shows the message flow that is associated with this example.
Figure 42: Message flow for domain location that is based on a NetBIOS domain name
When the FQDN of the domain is not available, the domain client determines the NetBIOS name of the domain based on the client's abstract data. If the NetBIOS name cannot be determined, an error is returned indicating that a domain controller could not be located. The domain client queries the NetBIOS name server for NetBIOS group names that contain the list of DCs.
The NetBIOS name server responds with the NetBIOS group names.
By using the NetBIOS group names that domain controllers register along with their capabilities, the domain client sends a MAILSLOT Ping to candidate domain controllers by using the Remote Mailslot Protocol [MS-MAIL]. The Ping response is used to determine availability and to confirm that the domain controller supports all the specified requirements.
Upon receipt of a successful MAILSLOT Ping response, the domain client validates that the capabilities that the domain controller returned satisfy the requested capabilities. If no domain controllers respond or if none match the required capabilities, the client returns an error indicating that a domain controller could not be located.