An AD forest relies on TCP/IP
for communications between member computers, between domain
controllers, and between member computers and domain controllers. DNS
provides name resolution and assists in the location of domain services
through the use of SRV records. All of the benefits of AD (such as the
centralized authentication database, computer management through Group
Policy, and the centralization of multiple services) will not be
available if DNS is incorrectly configured. Other TCP/IP-based protocols
(such as the Windows Time Service, DHCP, and SMTP) are also important
components.
This section discusses how TCP/IP relates to AD
transport, access, and support. Here we will examine dependencies
between AD and DNS, how to configure DNS for AD, how to use Windows
Server 2003 AD application partitions to manage DNS Zone information,
how AD uses DNS, how to configure the Windows Time Service, how to
integrate DHCP with AD, and how NetBIOS and WINS are used in an AD
domain. This is a long section, but critically important to AD
administration. The most important subsection (the one that discusses
dependencies between AD and DNS) is covered first because AD malfunction
is often the result of DNS problems.
1. AD/DNS Dependencies
The interdependency between AD and DNS involves the following AD components:
Domain controller locator
This is implemented in the NetLogon service and enables clients to locate a DC.
AD domain names in DNS
Each domain has a DNS domain name. Every Windows Server 2003 server has a DNS name.
DNS delegation resource records
These reside in the parent zone of the zone that is delegated (that is, the zone that supports the AD domain).
DNS forwards
These are used by AD clients in one domain to locate a DC in another domain.
AD DNS objects
Domains are represented as objects in AD
and as nodes in DNS. DNS domain names and AD domain names appear to be
the same. However, they represent two different namespaces. While DNS
resolves domain names and computer names to resource records and
eventually to IP addresses, AD resolves domain object names to object
records. An AD object name and a DNS host record can, however, represent
the same computer.
To troubleshoot problems with logon, replication,
Group Policy, and other domain activities, you should be familiar with
how DNS and its SRV records are used.
For domain resources to be located on the
network, they must be registered with appropriate name services. DNS
registration must occur either dynamically or manually. If the Windows
domain is configured for dynamic updates, it follows the standard
described in RFC 2136, Dynamic Updates in the Domain Name System (DNS UPDATE).
When a Windows Server 2003 DC starts, several
processes interact with a DNS and/or WINS name server(s), including DNS
name registration, DNS host record creation, and LDAP lookup. First, the
DC registers its name with any name services configured for the
network. For example, let's say that the domain controller regalinn is in the domain chicago.local, where both DNS and Windows Internet Name Service (WINS) services are configured. This DC registers its DNS name regalinn.chicago.local with DNS and its NetBIOS name, regalinn
with WINS. If other, third-party name services are configured for the
network and the DC is properly configured, the DC can also register its
name in the appropriate format with that name service. When a
workstation or server starts, in order to find its DC, it must use the
name services (DNS, WINS) provided to locate the DC on the network. Once
it finds the DC, the information is cached for later use.
Domain name registration in WINS (the creation of a domain_name[1C] record)
occurs by broadcast, or by directing a NetBIOS name registration
request to the NetBIOS name server. Windows clients that are not
DNS-enabled can use WINS to find Windows Server 2003, Windows 2000, and
Windows NT 4.0 domain controllers.
In addition to name registration, the NetLogon
service on the DC dynamically creates the host or A record (server name
and IP address) and SRV records in DNS. SRV records identify the
services that the DC provides (such as LDAP, Kerberos, TCP, and, if the
DC is a GC, that record as well).
Finally, the _msdcs.dnsdomainname
is used to find an LDAP server that is running TCP and is performing a
specific server role (such as domain controller or Kerberos server).
Finding these servers is important to domain and forest operations such
as authentication, resource location, replication, and so on.
Configuring DNS to properly interact with AD is
important because if it is not, these functions (as well as others that
are based on them) cannot occur. It is possible to correctly configure
DNS so that it functions as a name server on your network and still not
have it correctly configured so that AD can work correctly. Your DNS
administrator must understand AD's requirements and correctly configure
DNS for AD.
2. How AD Uses DNS
As shown in Table 1,
there are multiple listings of SRV records for each service offered by
AD DCs. Each SRV record can be found in multiple containers. This
provides multiple options for locating
specific DCs in the forest. This section explains the ways these records are used, including the following:
Table 1. SRV records used in AD
| SRV record | Description |
|---|
| _kerberos | Indicates the location of a Key Distribution Center (KDC) |
| _kpasswd | Indicates the location where password changes are recorded |
| _ldap | Indicates the location of an LDAP server |
| _gc | Indicates the location of a global catalog (GC) server |
2.1. How DCs are located
When member computers boot, when users log on,
or when replication initiates, a DC must be located. Let's look at how
the process works when locating a DC using DNS. (A similar process is
used by legacy Windows clients to locate a DC via WINS.)
On the client, a remote procedure call (RPC) is
made to the local NetLogon service. The NetLogon service implements the
Locator API (DsGetDcName). The client collects information needed to
select a DC and provides it to the NetLogon service using DsGetDcName.
(For example, the user's credentials entered during logon specify the
domain in which his or her account resides.) The NetLogon service
queries DNS by using the DNS-compatible LocatorDsGetDcNme to obtain the
SRV records and A records from DNS.
The NetLogon service queries the discovered DCs
using an LDAP UDP search. The search attempts to find a DC in the site
closest to the client. In an AD domain, the site information in DNS is
used to aid in this discovery. Site information is included in many
places in DNS so that a search for the different roles that a DC may
play all can be located in the closest site.
Available DCs respond. NetLogon services returns
information to the client from the first DC to respond. The NetLogon
service caches the discovered DC information for use in future requests.
2.2. How site information is used during logon
During logon, NetLogon attempts to find a DC in
the site closest to the client. While site information for DCs is
included in the DNS SRV records, site information of clients is stored
in the client's registry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName
value. This information is used to aid in the selection of a DC in the
site closest to it. When the computer is located in the site that is
recorded in the registry, the NetLogon query quickly locates a DC from
this site (or one that is close to it). However, the NetLogon service on
the DC uses the client's IP address to determine its site and returns
this information to the client. If the two sites (the client registry
site and the DC calculated site) do not match, then additional DC
queries and even additional DNS queries may result.
When site information doesn't match, it is
usually because the computer has been moved into another site. (A
laptop, for example, may be moved from location to location. Its
registry-based site information may then easily be out of date.) This is
why the site information in the DynamicSiteName value in the registry
is not used alone. During NetLogon startup, the NetLogon service on each
DC enumerates the site object in the AD Configuration container and
NetLogon is also notified of any changes to Site objects. This
information is used by NetLogon to create (in the DC's memory) a
subnet-to-site mapping table.
The client receives DC IP address information
from DNS and queries each DC in turn to find out which ones are
available. AD on the DC intercepts the query and passes it to NetLogon
on the DC. NetLogon on the DC takes the client IP address (included in
the query) and looks it up in its subnet-to-site mapping table. The DC
then returns information to the client, including the name of the site
of the client, the site name of the DC, and an indication of whether it
(the DC) is located in the site closest to the client.
The client uses this information to determine whether to try to find a better DC:
If the DC is located in the site closest to the client, then this DC is used.
If
no DC is in the site closest to the client, but the client has already
tried to find a DC in the site the DC says the client is in, the client
uses the current DC.
If the DC is not in
the site closest to the client and the client has not looked for a DC in
that site, the client updates its site information and sends a new DNS
query. If this one is not successful, then the original DC is used.
You can override the DyanmicSiteName value, but
you should do so by modifying the SiteName entry at the same location.
When the SiteName value is used, the DynamicSiteName value is
disregarded.
2.3. How DNS is used for AD replication
Replication topologies are configured both
automatically and manually, and the information is stored in AD. These
records assist replication partners in locating each other and in mutual
authentication. However, the actual location requires more than a
simple DNS lookup.
The DC finds its partner's GUID in AD. (A
listing of GUIDs for each DC is at CN=NTDS Settings, CN=Sites,
CN=Configuration, DC=domain_name, DC=domain_name_extension.) The DC
queries DNS looking for an associated CNAME record. The CNAME record is
of the form guid.msdcs.forest.root, as shown in Figure 1.
If the query is
successful, the name of the DC is returned. A second DNS query is used
to obtain the host record. The IP address from the host record is used
to request a connection to the replication partner. If CNAME or host
record is missing from DNS, a connection cannot be made and replication
will not occur.
