4. Managing Domain Controllers in Sites
There may be times when you need to manage domain controllers in
Active Directory sites:
-
You create a new site and move an existing domain controller
to it. -
You demote a domain controller. -
You promote a new domain controller.
When you create your Active Directory forest, the first domain
controller is automatically placed under the site object named
Default-First-Site-Name. You can see the domain
controller SERVER01.contoso.com in Figure 5. Additional domain
controllers are added to sites based on their IP addresses. For
example, if a server with IP address 10.1.1.17 is promoted to a domain
controller in the network shown in Figure 4, the server is
automatically added to the BRANCHA site, because the 10.1.1.0/24
subnet is associated with the BRANCHA site. Figure 5 shows SERVER02 in the
BRANCHA site.
Each site contains a Servers container, which itself contains an
object for each domain controller in the site. The Servers container in
a site should show only domain controllers, not all servers. When you promote a
new domain controller, the domain controller is, by default, placed in
the site associated with its IP address. However, the Active Directory
Domain Services Installation Wizard allows you to specify another
site. You can also pre-create the server object for the domain
controller in the correct site by right-clicking the Servers container
in the appropriate site, pointing to New, and then clicking
Server.
Finally, you can move the domain controller to the correct site
after installation by right-clicking the server and clicking Move. In
the Move Server dialog box, select the new site and click
OK. The domain controller is moved. It is a best practice to place a
domain controller in the site object that is associated with the DC’s
IP address. If a DC is multihomed, it can belong to only one site. If
a site has no domain controllers, users can still log on to the
domain; their logon requests are handled by a domain controller in an
adjacent site or another domain controller in the domain.
To remove a domain controller object, right-click it and click
Delete.
6. Understanding Domain Controller Location
You started this lesson by examining AD DS as a distributed
service, providing authentication and directory access on more than
one domain controller. You learned to identify where, in your network
topology, to define sites and place domain controllers. Now you are ready to
examine how, exactly, service localization works—how Active Directory
clients become site aware and locate the domain controller in their
site. Although this level of detail is unlikely to appear on the
certification examination, it can be extremely helpful when you need
to troubleshoot authentication of a computer or of a user.
When a domain controller is added to the domain, it advertises
its services by creating Service Locator (SRV) records, also called locator
records, in DNS. Unlike host records (A records), which map host
names to IP addresses, SRV records map services to host names. The
domain controller advertises its ability to provide authentication
and directory access by registering Kerberos and LDAP SRV records.
These SRV records are added to several folders within the DNS zones
for the forest. The first folder is within the domain zone. It is
called _tcp, and it contains the SRV records for all domain
controllers in the domain. The second folder is specific to this
site, in which the domain controller is located, with the path
_sites\sitename\_tcp, where
sitename is the name of the site. In Figure 6, you can see
the Kerberos and LDAP SRV records for SERVER02.contoso.com in its
site, _sites\BRANCHA\_tcp. You can also see the _tcp folder at the
first level beneath the zone.
The same records are registered in several places in the
_msdcs.domainName zone—for example,
_msdcs.contoso.com in Figure 6. This zone
contains records for Microsoft Domain Controller Services. The
underscore characters are a requirement of RFC 2782.
Locator records contain:
-
The service name and
port This portion of the SRV record indicates a
service with a fixed port. It does not have to be a well-known
port. SRV records in Windows Server 2008 R2 include LDAP (port
389), Kerberos (port 88), Kerberos Password protocol (KPASSWD, port 464),
and GC services (port 3268). -
Protocol TCP or UDP are
indicated as a transport protocol for the service. The same
service can use both protocols, in separate SRV records.
Kerberos records, for example, are registered for both TCP and
UDP. Microsoft clients use only TCP, but UNIX clients can use
UDP. -
Host name
The name corresponds to the A (Host) record for
the server hosting the service. When a client queries for a
service, the DNS server returns the SRV record and associated A
records, so the client does not need to submit a separate query
to resolve the IP address of a service.
The service name in the SRV record follows the standard
DNS hierarchy, with components separated by dots. For example, the
Kerberos service of a domain controller is registered as:
kerberos._tcp.siteName._sites.domainName
Reading this SRV record name right to left like other DNS
records, it translates to:
-
domainName: the domain or zone—for
example, contoso.com -
_sites: all sites registered with DNS -
siteName: the site of the domain
controller registering the service -
_tcp: any TCP-based services in the site -
kerberos: a Kerberos Key Distribution Center (KDC) using
TCP as its transport protocol
Domain Controller Location
Imagine that a Windows client has just been joined to the
domain. It restarts, receives an IP address from a DHCP server, and
is ready to authenticate to the domain. How does the client know
where to find a domain controller?
It does not. Therefore, the client queries the domain for a
domain controller by querying the _tcp folder, which, you’ll
remember, contains the SRV records for all domain controllers in the domain. DNS
returns a list of all matching DCs, and the client attempts to
contact all of them on this, its first startup. The first domain
controller that responds to the client examines the client’s IP
address, cross-references that address with subnet objects, and
informs the client of the site to which the client belongs. The
client stores the site name in its registry, and then queries for
domain controllers in the site-specific _tcp folder. DNS returns a
list of all DCs in the site. The client attempts to bind with all,
and the DC that responds first authenticates the client.
The client forms an affinity for this DC and will attempt to
authenticate with the same DC in the future. If the DC is
unavailable, the client queries the site’s _tcp folder again and
attempts to bind with all DCs in the site. But what happens if the
client is a mobile computer—a laptop? Imagine that the computer has
been authenticating in the BRANCHA site, and then the user brings
the computer to the BRANCHB site. When the computer starts up, it is
assigned an IP address appropriate for the BRANCHB site by a DHCP
server that services the site. The computer then attempts to
authenticate with its preferred DC in the BRANCHA site. That DC
notices the client’s IP address is associated with BRANCHB and
informs the client of its new site. The client then queries DNS for
domain controllers in BRANCHB.
You can see how, by storing subnet and site information in
Active Directory and by registering services in DNS, a client is
encouraged to use services in its site—the definition of service localization.
What happens if a site has no domain controller? Sites can be
used to direct users to local copies of replicated resources such as
shared folders replicated within a DFS namespace, so you might have
sites without a DC. In this case, a nearby domain controller
registers its SRV records in the site in a process called
site coverage. To be precise, a site without a
DC is generally covered by a domain controller in a site with the lowest cost to
the site requiring coverage. You learn more about site link costs in
the next lesson. You can also manually configure site coverage and
SRV record priority if you want to implement strict control over
authentication in sites without DCs. The domain controller
location URL just listed contains details about the
algorithm that determines which DC automatically covers a site
without a DC.
Practice Configuring Sites and Subnets
In this practice, you use best practices to implement a
structure of sites and subnets for the contoso.com
domain.
EXERCISE 1 Configure the Default
Site
A new domain contains the Default-First-Site-Name site. In
this exercise, you rename that site and associate two subnets with
the site.
-
Open the Active Directory Sites And Services
snap-in. -
Expand Sites, right-click Default-First-Site-Name, and
click Rename. -
Type HEADQUARTERS and
press Enter.
Because site names are registered in DNS, you should use
DNS-compliant names that avoid special characters and
spaces. -
Right-click Subnets and click New Subnet. -
In the Prefix box, type 10.0.0.0/24. -
In the Select A Site Object For This Prefix list, select
HEADQUARTERS. -
Click OK. -
Right-click Subnets and click New Subnet. -
In the Prefix box, type 10.0.1.0/24. -
In the Select A Site Object For This Prefix list, select
HEADQUARTERS. -
Click OK.
EXERCISE 2 Create an Additional
Site
Sites allow you to manage replication traffic and localize
services such as the authentication and directory access provided
by domain controllers. In this exercise, you create a second site
and associate a subnet with it.
-
Open the Active Directory Sites And Services
snap-in. -
Right-click Sites and click New Site. -
Type BRANCHA in the Name
box. -
Select DEFAULTIPSITELINK. -
Click OK.
An Active Directory Domain Services dialog box appears,
explaining the steps required to complete the configuration of
the site. -
Click OK. -
Right-click Subnets and click New Subnet. -
In the Prefix box, type 10.1.1.0/24. -
In the Select A Site Object For This Prefix list, select
BRANCHA. -
Click OK. -
In the Active Directory Sites And Services snap-in, expand the Subnets
node. -
Right-click 10.1.1.0/24 and click Properties. -
In the Description box, type Primary subnet for branch
office. -
In the Site drop-down list, select BRANCHA. -
Click OK.
|
