Microsoft press windows server 2008 active directory resource kit - part 2 pot

Chapter 2: Active Directory Domain Services Components 53
domain trusts the NA.ADatum.com domain, and the EMEA.ADatum.com domain trusts the
ADatum.com domain, then transitivity means that the EMEA.ADatum.com domain also trusts
the NA.ADatum.com domain. Therefore, users in the NA.ADatum.com domain can access
resources in the EMEA.ADatum.com domain and vice versa. The transitive trusts also apply
to the tree root trusts. The NA.ADatum.com domain trusts the ADatum.com domain, and the
ADatum.com domain trusts the TreyResearch.com domain. Therefore, the NA.ADatum.com
domain and the TreyResearch.com domain also share a transitive-trust relationship.
Shortcut Trusts
In addition to the automatic, two-way transitive trusts that are created when a new child
domain is created, shortcut trusts can be created between domains in the forest. Shortcut
trusts are used to optimize performance when accessing resources between domains that are
connected through transitive trusts. A shortcut trust is desirable when there is frequent
resource access between domains that are remotely connected through the domain tree or
forest. For example, the trusts at A. Datum could be configured as illustrated as Figure 2-10.
Figure 2-10 Trusts in the ADatum forest.
If a security group in the Research.EMEA.ADatum.com domain has a frequent need to access
a shared resource in the Sales.NA.ADatum.com domain, and with only transitive trusts estab-
lished between the domains, users in the Research.EMEA.ADatum.com domain must be
referred to a domain controller in every domain in the tree between them and the domain that
contains the resource. This is not efficient if the need is frequent. A shortcut trust is a direct
trust that will efficiently enable users in the Sales.EMEA.ADatum.com domain to be referred
to a domain controller in the Research.NA.ADatum.com domain—without traversing the
entire directory tree to get there. Figure 2-10 illustrates this shortcut trust. Shortcut trusts can
be configured as one-way or two-way trusts. Shortcut trusts are not transitive.
ADatum.com
ADatum Forest
Parent-child trust
Shortcut trust
WoodgroveBank.com
NA.ADatum.comEMEA.ADatum.com

Sales.NA.ADatum.comResearch.EMEA.ADatum.com
Forest Trust
WoodgroveBank Forest
54 Part I: Windows Server 2008 Active Directory Overview
Forest Trusts
A forest trust is a two-way transitive trust between two separate forests. With a forest trust,
security principals in one forest can be given access to resources in any domain in a
completely different forest. Also, users can log on to any domain in either forest using the
same UPN. Figure 2-10 illustrates a forest trust between the ADatum.com forest and the
WoodgroveBank.com forest.
Note
In order to configure a forest trust, both forests must be at the Windows Server 2003
forest functional level or higher.
Forest trusts can be very useful in a Windows Server 2008 environment. If an organization
requires more than one forest for political or technical reasons, the use of a forest trust means
that it is easy to assign access to resources across all the domains, regardless of which forest
the user or resource is in. If two companies that have deployed Windows Server 2008 forests
merge, the two forests can be logically joined by using the trust.
Although forest trusts do provide some excellent functionality, they are also subject to some
limitations:
■ Forest trusts are not transitive to other forests. For example, if ADatum.com has a forest
trust with WoodgroveBank.com, and WoodgroveBank.com has a forest trust with
Fabrikam.com, ADatum.com does not automatically have a forest trust with Fabrikam.com.
■ Forest trusts only make authentication possible between forests; they do not provide
any other functionality. For example, each forest will still have a unique global catalog,
schema, and configuration directory partition. No information is replicated between the
two forests—the forest trust just makes it possible to assign access to resources between
forests.
■ In some cases, you may not want to have all the domains in one forest trust all the
domains in another forest. If this is the case, you can set up one-way, nontransitive

external trusts between individual domains in two separate forests. As an alternative,
you can also configure selective authentication on the forest trust, which means that you
must explicitly enable users from a trusted domain to access resources on a server in
the trusting domain.
More Info
For more information on planning forest trusts, see Chapter 5.
External Trusts
An external trust is a trust relationship that can be created between AD DS domains that are
in different forests or between an AD DS domain and a Windows NT 4.0 or earlier domain.
Chapter 2: Active Directory Domain Services Components 55
External trusts can be used to provide access to resources in a domain outside of the forest
that is not already joined by a forest trust or to create a direct trust between two domains that
are joined by a forest trust. An external trust is different from a forest trust in that the external
trust is configured between any two domains in either forest, not just between the forest root
domains. In addition, external trusts have the following characteristics:
■ External trusts are not transitive. Only two domains participate in the trust relationship.
■ You must configure both sides of the trust relationship. If you want to configure a two-
way trust, you must configure a trust for each direction.
■ External trusts enforce SID filtering by default in Windows Server 2008. SID filtering is
used to verify that incoming authentication requests made from security principals in
the trusted domain contain only SIDs of security principals in the trusted domain. SID
filtering ensures that administrators in the trusted domain cannot use the SIDHistory
attribute to gain unauthorized access to resources in the trusting domain.
Realm Trusts
The last type of trust is a realm trust. A realm trust is configured between a Windows
Server 2008 domain or forest and a non-Windows implementation of a Kerberos v5 realm.
Kerberos security is based on an open standard, and there are several other implementa-
tions of Kerberos-based network security systems available. Realm trusts can be created
between any Kerberos realms that support the Kerberos v5 standard. Realm trusts can be
either one-way or two-way, and they can also be configured to be transitive or nontransitive.

Sites
All of the AD DS logical components discussed so far are almost completely independent of
the physical infrastructure for your network. For example, when you design the domain
structure for a corporation, where the users are located is not the most important question
you need to ask. All the users in a domain may be located in a single office building, or they
may be located in offices around the world. This independence of the logical components
from the network infrastructure comes about largely as a result of the use of sites in AD DS.
Sites provide the connection between the logical AD DS components and the physical
network infrastructure. A site is defined as an area of the network where all domain controllers
are connected by a fast and reliable network connection. In most cases, a site contains one or
more Internet Protocol (IP) subnets on a local area network (LAN) or very high-speed wide
area network (WAN) and connected to the rest of the network with slower WAN connections.
On the Disc
To display information on the sites AD DS forest, run the ListADDSSites.ps1
Windows PowerShell script on the CD.
56 Part I: Windows Server 2008 Active Directory Overview
The primary reason for creating sites is to be able to manage any network traffic that must use
slow network connections. Sites are used to control network traffic within the Windows
Server 2008 network in three different ways:
■ Replication One of the most important ways that sites are used to optimize network
traffic is in the management of replication traffic between domain controllers. For
example, within a site, any change made to the directory will be replicated within a few
minutes. The replication schedule between sites can be managed so that the replication
traffic will occur less frequently or during nonworking hours. By default, replication
traffic between sites is compressed to conserve bandwidth, while replication traffic
within a site is not compressed. (Chapter 4 goes into much more detail on the differ-
ences between intersite and intrasite replication.)
■ Authentication When a user logs on to a Windows Server 2008 domain from a
Windows 2000, Windows XP Professional, or Windows Vista client, the client
computer will always try to connect a domain controller in the same site as the client.

As discussed in Chapter 3, every domain controller registers site-specific service locator
(SRV) records—when the client computer tries to locate a domain controller, it will
always query the DNS servers for these site records. This means that the client logon
traffic will remain within the site.
■ Site-aware network services The third way that sites can preserve network bandwidth
is by limiting client connections to site-aware applications and services on the site. For
example, by using Distributed File System (DFS), you can create multiple replicas of a
folder in different sites on the network. Because DFS is designed to be aware of the site
configuration, client computers always try to access a DFS replica in their own site
before crossing a WAN link to access the information in another site. As well, Exchange
Server 2007 uses the AD DS site configuration to define the message routing topology
within the organization. Messages sent between Exchange Servers in the same site will
always be sent directly from the source Exchange Server to the destination Exchange
Server, even if a message needs to be sent to several servers in the same site. Only single
copies of messages are sent between Exchange Servers in different sites, even if the mes-
sages are intended for users on several different Exchange Servers in the destination site.
Every computer on a Windows Server 2008 network will be assigned to a site. When AD DS
is installed in a Windows Server 2008 environment, a default site called Default-First-Site-
Name is created, and all computers in the forest will be assigned to that site unless additional
sites are created. When additional sites are created, the sites are linked to IP subnets. When
a server running Windows Server 2008 is promoted to become a domain controller, the
domain controller is automatically assigned to a site that corresponds to the computer’s IP
address. If needed, domain controllers can also be moved between sites using the Active
Directory Sites and Services administrative tool.
Client computers determine their sites the first time they start up and log on to the domain.
Because the client computer does not know which site it belongs to, it will connect to any
Chapter 2: Active Directory Domain Services Components 57
domain controller in the domain. As part of this initial logon process, the domain controller
will inform the client which site it belongs to, and the client will cache that information for the
next logon.

Note
If a domain controller or a client computer has an IP address that is not linked to a
specific site, that computer will be placed in the Default-First-Site-Name site. Every computer
that is part of a Windows Server 2008 domain must belong to a site.
As mentioned earlier in this chapter, there is no direct connection between sites and the other
logical concepts in AD DS. One site can contain more than one domain, and one domain can
cross multiple sites. For example, as shown in Figure 2-11, the Seattle site contains both the
ADatum.com domain and the NA.ADatum.com domain. The TreyResearch.com domain is
spread across multiple sites.
Figure 2-11 Sites and domains within an AD DS forest.
Note Sites are discussed in more detail in several other chapters in this book. Chapter 3
details the role of DNS and sites for client logons. Chapter 4 addresses the role of sites in
replication and how to create and configure sites. Chapter 5 goes into detail on designing an
optimal site configuration for an AD DS forest.
Organizational Units
By implementing multiple domains in a forest, either in a single tree or in multiple trees,
Windows Server 2008 AD DS can scale to provide directory services for almost any size
network. Many of the components of AD DS, such as the global catalog and automatic
transitive trusts, are designed to make the use and management of this enterprise directory
efficient regardless of how big the directory gets.
ADatum.com
Denver_Site
NA.ADatum.com
Vancouver_Site
TreyResearch.com
Seattle_Site
Calgary_Site
58 Part I: Windows Server 2008 Active Directory Overview
Organizational units (OUs), however, are designed to make AD DS easier to administer at a
smaller scale. OUs are used to make the management of single domains more efficient. A

domain might contain tens of thousands of objects (or even millions). Managing this many
objects without some means of organizing the objects into logical groupings is very difficult.
OUs are used to create a hierarchical structure within a domain. Figure 2-12 shows an example
of what the OU structure might look like at A. Datum.
Figure 2-12 An OU structure can have many layers.
OUs are container objects that can contain several types of directory service objects, including
the following:
■ Computers
■ Contacts
■ Groups
■ inetOrgPerson
■ Printers
■ Users
■ Shared folders
■ Organizational units
ProductOU SalesOU R&DOU
ADatum.com
ProductOU MarketingOU
SeattleOU CalgaryOU DenverOU
DesignOU ManuOU
Chapter 2: Active Directory Domain Services Components 59
OUs are used to group objects together for administrative purposes. There are two ways that
OUs can be used as administrative units: to delegate administrative rights and to manage a
group of objects as a single unit.
Using OUs to Delegate Administrative Rights
OUs can be used to delegate administrative rights. For example, a user can be given the rights
to perform administrative tasks for a specific OU. These rights could be high-level rights, in
which the user has full control of the OU and all objects in the OU, or the rights can be very
limited and specific (such as only being able to reset passwords for users in that OU). The
user that has been given administrative rights to an OU does not by default have any admin-

istrative rights outside the OU.
The OU structure is very flexible in assigning rights (also called permissions in many
Windows dialog boxes and Properties sheets) to objects inside the OU. The OU itself has an
access control list (ACL) where you can assign rights for that OU. Each object in an OU and,
in fact, each attribute for each object, also has an ACL. This means that you can have extremely
precise control of the administrative rights anyone can have in the OU. For example, you can
give a Help Desk group the right to change passwords for users in an OU but not to change
any other properties for the user accounts. Or you can give the Human Resources department
the right to modify any personal information on all user accounts in all OUs but not give them
any other rights to any other attributes on the user accounts, or any rights to any other
objects. You can also grant rights to individual objects within the OU if there are some objects
that you want to have different rights than the other objects in the OU.
Using OUs to Administer Groups of Objects
Another reason for using OUs is to group objects together so that the objects can all be admin-
istered the same way. For example, if you want to administer all of the workstations in a
department the same way (such as limiting which users have the right to log on to the work-
stations), you can group all the workstations into an OU and configure the Logon Locally
permission at the OU level. This permission is applied to all workstations in that OU. If a
collection of users needs the same standard desktop configuration and the same set of
applications, the users can be put into an OU and Group Policy can then be used to configure
the desktop and to manage the installation of applications.
In many cases, objects in an OU will be managed through Group Policy. Group Policy can be
used to lock down user desktops, to give them a standardized desktop, to provide logon and
logoff scripts, and to provide folder redirection. Table 2-3 provides a brief list of the types of
settings available in Group Policy.
60 Part I: Windows Server 2008 Active Directory Overview
Group Policy objects will be most commonly assigned at the OU level. This eases the task of
administering the users in the OU because you can assign one Group Policy object—for example,
an administrative template policy—to the OU, which is then enforced on all the users or
computers in the OU.

Note
OUs are not security principals. This means that you cannot use an OU to assign
permissions to a resource and then have all of the users in the OU automatically inherit those
permissions. OUs are used for administrative purposes. To grant access to resources, use
security groups.
Summary
This chapter introduced the basic physical and logical components of AD DS in Windows
Server 2008. Although having an understanding of the physical components is important
(especially when dealing with database management, domain controller placement, and
schema management), most of the work you will do in AD DS will be with the logical compo-
nents. Most of the rest of this book deals with the logical structure of AD DS.
Table 2-3 Group Policy Setting Types
Setting Types Explanation
Administrative templates Used to manage registry-based parameters for configuring
application settings and user desktop settings, including access
to the operating system components, access to control panel,
and configuration of offline files.
Security Used to manage the local computer, domain, and network security
settings, including controlling user access to the network,
configuring account policies, and controlling user rights.
Software installation Used to centralize the management of software installations and
maintenance.
Scripts Used to specify scripts that can be run when a computer starts or
shuts down, or when a user logs on or off.
Folder redirection Used to store certain user profile folders on a network server.
These folders, such as the My Documents folder, appear to be
stored locally but are actually stored on a server where they can
be accessed from any computer on the network.
Preferences Used to manage options related to Windows settings or Control
Panel settings, including drive mappings, environment variables,

network shares, local users and groups, services, devices, and
many more.
Chapter 2: Active Directory Domain Services Components 61
Additional Resources
■ Chapter 5, “Designing the Active Directory Domain Services Structure,” goes into detail
about designing the AD DS logical and physical configuration.
■ The Domain and Forest Trusts Technical Reference at />windowsserver/en/library/92b3b6cb-9eb3-4dd7-b5f6-3fa9be8080821033.mspx?mfr=true
provides details on trusts in an Active Directory. This resource refers to Windows
Server 2003, but the way trusts are implemented has not changed significantly in
Windows Server 2008.
■ The Script Repository: Active Directory Web site located at />technet/scriptcenter/scripts/default.mspx?mfr=true has several scripts that can be used
to enumerate and modify the AD DS objects.
Related Tools
Windows Server 2008 provides several tools that can be used when managing the AD DS
logical and physical components. Table 2-4 lists some of these tools and their uses.
Resources on the CD
■ ListDomainControllers.ps1 is a Windows PowerShell script that lists all of the domain
controllers in your domain and global catalog servers in your forest.
■ ListFSMOs.ps1 is a Windows PowerShell script that lists all of the operations master
servers in your forest and domain.
■ ListADDSDomains.ps1 is a Windows PowerShell script that lists information about all
of the domains in your forest.
■ ListADDSSites.ps1 is a Windows PowerShell script that lists information about all of the
sites in your forest.
Table 2-4 AD DS Management Tools
Tool Name Description and Uses
Active Directory Users
and Computers
Use to configure AD DS domains including configuring and managing
OUs and all other domain objects.

Active Directory
Domains and Trusts
Use to configure AD DS trusts.
Active Directory Sites
and Services
Use to configure sites and replication.
Ntdsutil.exe
or Dsbutil.exe
Use to manage the AD DS data store files and to transfer FSMO roles
between domain controllers.
ADSI Edit Use to view and modify the contents of AD DS partitions.
62 Part I: Windows Server 2008 Active Directory Overview
Related Help Topics
■ “Managing Trusts” in Active Directory Domains and Trusts help.
■ “Managing Forest Trusts” in Active Directory Domains and Trusts help.
■ “Understanding Domains” in Active Directory Users and Computers help.
63
Chapter 3
Active Directory Domain
Services and Domain Name
System
In this chapter:
Integration of DNS and AD DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
AD DS Integrated Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Integrating DNS Namespaces and AD DS Domains . . . . . . . . . . . . . . . . . . . . . . . . . 81
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Additional Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Microsoft Windows Server 2008 Active Directory Domain Services (AD DS) requires Domain
Name System (DNS) to locate resources on a network. Without a reliable DNS infrastructure,

AD DS replication between domain controllers on your network will fail, your Microsoft
Windows XP and Windows Vista clients will not be able to log on to the network, and servers
running Microsoft Exchange Server 2007 will not be able to send e-mail. Essentially, if your
DNS implementation is not stable and available, your Windows Server 2008 network will fail.
This means you must have a thorough knowledge of DNS concepts and the Windows
Server 2008 implementation of DNS if you are going to manage a Windows Server 2008 AD
DS environment.
AD DS is tightly integrated with DNS in several ways. First of all, all Microsoft Windows 2000
or later computers use DNS to locate domain controllers in an AD DS environment. This
includes client computers that are trying to log on to the network, domain controllers trying
to connect to replication partners, or Exchange Servers looking up e-mail recipient information
in AD DS. Only after the DNS lookup fails will these computers attempt to use NetBIOS name
resolution by using Windows Internet Name Service (WINS), broadcasts, or LMHosts files.
Secondly, you can store DNS zone data in the AD DS data store, which provides enhanced
functionality and security. In addition, AD DS domain names are DNS names. If your AD DS
forest includes several domains in a hierarchical (parent-child) configuration, or in a peer
(multiple domain trees) configuration, your DNS implementation should correspond to the
AD DS domain implementation.
64 Part I: Windows Server 2008 Active Directory Overview
Important Because DNS is essential for AD DS, you must become familiar with DNS
concepts and know how DNS is implemented. If you are not familiar with DNS, you should
consult some of the excellent resources available on the Microsoft Web site, such as the DNS
Technical Reference located at />6e45e81e-fb44-4a20-a752-ebe740e2acc61033.mspx.
Integration of DNS and AD DS
AD DS cannot function without a reliable DNS configuration. DNS is critically important in
AD DS because DNS provides the information that computers on the network need to locate
the AD DS domain controllers. This section takes a detailed look at the information that is
stored in DNS and the process that a client computer uses to locate the domain controllers.
On the Disc
Because of the dependency AD DS has on DNS, you should ensure that you

have current documentation for all DNS zones managed by your company. You can use
the DNSConfig.xlsx spreadsheet on the CD to document your DNS zone and DNS server
configurations.
Service Location (SRV) Resource Records
To facilitate the location of domain controllers, AD DS uses service location or SRV resource
records. An SRV record, which is described in RFC 2782, “A DNS RR for Specifying the
Location of Services (DNS SRV)” at is used to identify
computers that provide services located on a Transmission Control Protocol/Internet Protocol
(TCP/IP) network. In Windows Server 2008, all domain controllers register SRV records in
DNS that identify the computers as providing AD DS related services.
Note
All networks require some means to locate computers that provide domain services. In
Windows NT, domain logon was based on NetBIOS names. Every domain controller registered
the NetBIOS name Domainname with a <1C> as the sixteenth character in the name on the
network and in Windows Internet Name Service (WINS). When a client tried to log on to
the network, the client would try to locate the servers that had the domain controller name
registered. If the client could not locate one of these servers, the logon would fail. In Windows
2000 or later, the SRV records are used to locate domain controllers. Without the SRV records,
these clients will also not be able to log on to the Windows Server 2008 domain. Windows
Server 2008 domain controllers still register the domain NetBIOS name on the network and in
WINS if a WINS server is configured.
Chapter 3: Active Directory Domain Services and Domain Name System 65
Every SRV record uses a standard format, as explained in Table 3-1 and as shown in the fol-
lowing example of one of the records used by AD DS:
_ldap._tcp.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com
Figure 3-1 shows this record in the DNS management console.
Essentially, the information in this record states that if a client is looking for a Lightweight
Directory Access Protocol (LDAP) server in the ADatum.com domain, the client should con-
nect to SEA-DC1.ADatum.com.
Table 3-1 The SRV Record Components

Component Example Explanation
Service _ldap The service that this record identifies. This
service identifies this server as a server that will
respond to LDAP requests.
Protocol _tcp The protocol used for this service. It can be
either TCP or user datagram protocol (UDP).
Name ADatum.com The domain name that this record refers to.
TTL 600 The default Time to Live for this record
(in seconds).
Class IN The standard DNS Internet class.
Resource Record SRV Identifies the record as an SRV record.
Priority 0 Identifies the priority of this record for the client.
If multiple SRV records exist for the same service,
the clients will try to connect first to the server
with the lowest priority value.
Weight 100 A load-balancing mechanism. If multiple
SRV records exist for the same service and the
priority is identical for all the records, clients will
choose the records with the higher weights
more often.
Port 389 The port used by this service.
Target SEA-DC1.ADatum.com The host that provides the service identified by
this record.
66 Part I: Windows Server 2008 Active Directory Overview
Figure 3-1 Example of an SRV record.
SRV Records Registered by AD DS Domain Controllers
The domain controllers in a Windows Server 2008 domain register many SRV records in
DNS. The following list includes all of the records registered by the first server in a forest:
Adatum.com. 600 IN A 10.10.10.10
Adatum.com. 600 IN AAAA 2001:4898:28:4:343e:eb57:e7d1:a87c

_ldap._tcp.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com.
_ldap._tcp.Default-First-Site-Name._sites.Adatum.com. 600 IN SRV 0 100 389
SEA-DC1.Adatum.com.
_ldap._tcp.pdc._msdcs.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com.
_ldap._tcp.gc._msdcs.Adatum.com. 600 IN SRV 0 100 3268 SEA-DC1.Adatum.com.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.Adatum.com. 600 IN SRV 0
100 3268 SEA-DC1.Adatum.com.
_ldap._tcp.64c228cd-5f07-4606-b843-d4fd114264b7.domains._msdcs.Adatum.com.
600 IN SRV 0 100 389 SEA-DC1.Adatum.com.
gc._msdcs.Adatum.com. 600 IN A 10.10.10.10
175170ad-0263-439f-bb4c-89eacc410ab1._msdcs.Adatum.com. 600 IN CNAME
SEA-DC1.Adatum.com.
gc._msdcs.Adatum.com. 600 IN AAAA 2001:4898:28:4:343e:eb57:e7d1:a87c
_kerberos._tcp.dc._msdcs.Adatum.com. 600 IN SRV 0 100 88 SEA-DC1.Adatum.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.Adatum.com. 600 IN
SRV 0 100 88 SEA-DC1.Adatum.com.
_ldap._tcp.dc._msdcs.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.Adatum.com. 600 IN SRV 0
100 389 SEA-DC1.Adatum.com.
_kerberos._tcp.Adatum.com. 600 IN SRV 0 100 88 SEA-DC1.Adatum.com.
_kerberos._tcp.Default-First-Site-Name._sites.Adatum.com. 600 IN SRV 0 100 88
SEA-DC1.Adatum.com.
_gc._tcp.Adatum.com. 600 IN SRV 0 100 3268 SEA-DC1.Adatum.com.
_gc._tcp.Default-First-Site-Name._sites.Adatum.com. 600 IN SRV 0 100 3268
SEA-DC1.Adatum.com.
Chapter 3: Active Directory Domain Services and Domain Name System 67
_kerberos._udp.Adatum.com. 600 IN SRV 0 100 88 SEA-DC1.Adatum.com.
_kpasswd._tcp.Adatum.com. 600 IN SRV 0 100 464 SEA-DC1.Adatum.com.
_kpasswd._udp.Adatum.com. 600 IN SRV 0 100 464 SEA-DC1.Adatum.com.
DomainDnsZones.Adatum.com. 600 IN A 10.10.10.10

DomainDnsZones.Adatum.com. 600 IN AAAA 2001:4898:28:4:343e:eb57:e7d1:a87c
_ldap._tcp.DomainDnsZones.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com.
_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.Adatum.com. 600 IN
SRV 0 100 389 SEA-DC1.Adatum.com.
ForestDnsZones.Adatum.com. 600 IN A 10.10.10.10
ForestDnsZones.Adatum.com. 600 IN AAAA 2001:4898:28:4:343e:eb57:e7d1:a87c
_ldap._tcp.ForestDnsZones.Adatum.com. 600 IN SRV 0 100 389 SEA-DC1.Adatum.com.
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.Adatum.com. 600 IN
SRV 0 100 389 SEA-DC1.Adatum.com.
Note When one of the Windows Server 2008 servers is promoted to a domain controller,
all of these records are written to a file called Netlogon.dns, which is located in the
%systemroot%\system32\config folder. If you do not want to enable dynamic updates on
the DNS servers, you can import these records into the DNS zone.
The first part of the SRV record identifies the service that the SRV record points to. The
possible services are:
■ _ldap AD DS is an LDAP-compliant directory service, with the domain controllers
operating as LDAP servers. The _ldap SRV records identify the available LDAP servers
on the network. These servers could be Windows Server 2008 domain controllers,
previous versions of Windows domain controllers, or other LDAP servers.
■ _kerberos The primary authentication protocol for all Windows 2000 and later clients
and servers. The _kerberos SRV records identify all the Key Distribution Centers
(KDCs) on the network. These could be Windows Server 2008 domain controllers,
previous versions of Windows domain controllers, or other KDC servers.
■ _kpasswd The _kpasswd SRV record identifies the Kerberos password-change servers
on the network (again either Windows Server 2008 domain controllers, previous ver-
sions of Windows domain controllers, or other Kerberos password-change servers).
■ _gc The _gc SRV record is specific to the global catalog function in AD DS. Only
Windows Server 2008 or previous versions of Windows domain controllers that are
configured as global catalog servers register this record.
Many of the SRV records also contain a site identifier in addition to the components listed in

Table 3-1. One of the reasons for implementing sites is to ensure that the network clients
will always try to log on to a domain controller that resides in the same site as the client. The
site records are essential for the computers to locate domain controllers in the same site as
the client. The process that a client uses to locate the site information is discussed in the next
section.
68 Part I: Windows Server 2008 Active Directory Overview
Another essential component of the SRV records is the _msdcs value that appears in many of
the records. Some of the services provided by the SRV records are non–Microsoft specific. For
example, there could be non-Microsoft implementations of LDAP or Kerberos servers on the
network. These servers could also register an SRV record with the DNS server. Windows Server
2008 domain controllers register the generic records (for example, _ldap._tcp.ADatum.com),
but the domain controllers also register records containing the _msdcs reference. These
records refer only to Microsoft-specific roles, that is, to Windows 2000 and later domain
controllers. The records identify the primary function of each server as gc (global catalog), dc
(domain controller), or pdc (primary domain controller emulator).
Note
You may notice that the resource records with an _msdcs value appear in a different
zone than the other resource records in the DNS management console. The zone name is
called _msdcs.domainname rather than just domainname. If you install DNS on a domain
controller when you run the Active Directory Domain Services Installation Wizard on the first
domain controller in a domain, the DNS zones are stored in application partitions in the AD DS
data store. The _msdcs zone information is stored in an application partition that is replicated
throughout the AD DS forest, whereas the domain zone is stored in an application partition
that is replicated to all AD DS domain controllers that are also DNS servers. For more detail, see
the next two sections in this chapter.
Another record that is registered contains the domain’s globally unique identifier (GUID).
This record enables a client to locate a domain controller in a domain on the basis of its GUID.
The domain GUID record is used to locate domain controllers in the event of a domain
rename.
Windows Server 2008 domain controllers also register the following DNS host (A/AAAA)

records for the use of LDAP clients that do not support DNS SRV records:
■ DNSDomainname 600 IN A IPv4Address Enables a non–SRV-aware client to locate any
domain controller in the domain by looking up an A record. A name in this form is
returned to the LDAP client through an LDAP referral. These host records are registered
for the AD DS domain name, as well as the ForestDNSZones and Domain DNSZones
domain names.
■ DNSDomainname 600 IN AAAA IPv6Address Enables a non–SRV-aware client to locate
any domain controller in the domain by looking up an AAAA record. Domain control-
lers configured with IPv6 enabled do not register the link-local IPv6 address but will
register statically configured IPv6 addresses. These host records are registered for the
AD DS domain name, as well as the ForestDNSZones and Domain DNSZones domain
names.
Chapter 3: Active Directory Domain Services and Domain Name System 69
■ gc._msdcs.DnsForestName Enables a non–SRV-aware client to locate any global catalog
server in the forest by looking up an A record. A name in this form is returned to the
LDAP client through an LDAP referral.
How It Works: SRV Records and RODCs
For security reasons, read-only domain controllers (RODC) and read-only global catalog
servers (ROGC) are not enabled by default to register their own DNS records. Instead,
the RODC or ROGC sends a DNS update request to a writable Windows Server 2008
domain controller, which validates and then registers the records on behalf of the
RODC or ROGC.
In addition, RODCs only register the site-specific LDAP and Kerberos and CName
records in DNS. By default, only users in the same site as the RODC site users should
be able to discover and use them. This can be achieved by registering only site-specific
records. ROGCs also register the site-specific GC records. Because RODCs cannot be
used to change passwords, the servers do not register Kpasswd records.
Ashish Sharma
SDE II, US-Directory and Service Business
DNS Locator Service

The domain controllers running Windows Server 2008 register some or all of the records
described earlier in DNS. These records then play an essential role when a client like
Windows 2000 or later tries to log on to the domain. The following steps describe the process
that these clients use to log on to the domain:
1. When the user logs on, the client computer sends a remote procedure call (RPC) to the
local Net Logon service, initiating a logon session. As part of the RPC, the client sends
information such as the computer name, domain name, and site name to the Net Logon
service.
2. The Net Logon service uses the domain locator service to call the DsGetDcName() API,
passing one of the flag parameter values listed in Table 3-2.
Table 3-2 A Subset of the DsGetDcName Flag Parameter Values
DsGetDcName Flag Values DNS Record Requested
DS_PDC_REQUIRED _ldap._tcp.pdc._msdcs.domainname
DS_GC_SERVER_REQUIRED _ldap._tcp.sitename._sites.gc._msdcs.forestrootdomain-
name
DS_KDC_REQUIRED _kdc._tcp.sitename._sites.dc._msdcs.domainname
DS_ONLY_LDAP_NEEDED _ldap._tcp.sitename._sites._msdcs.domainname
70 Part I: Windows Server 2008 Active Directory Overview
Note In almost all cases, the DsGetDcName function also includes the sitename
parameter. For all of the requests except the DS_PDC_REQUIRED request, the client
always makes an initial request using the site parameter. If the DNS server does not
respond to the request, the client will send the same request without the site parameter.
For example, if the DS_KDC_REQUIRED request is not fulfilled, the client will send a
request for the _kdc._tcp.dc._msdcs.forestrootdomain record. This can happen when the
client site is not configured or not available.
Windows Server 2008 introduces a new flag called DS_TRY_NEXTCLOSEST_SITE. When
this flag is set, the client will try to locate a domain controller in the same site as the
client. If that fails, the client will use the AD DS site link configuration to locate a domain
controller in the next closest site.
Windows Server 2008 introduces another new flag that can be used by the

DSGetDCName function. This flag, DS_IP_VERSION_AGONISTIC, is used by the client
to specify that they want either an IPv4 or IPv6 address. If this flag is not set, the locator
will return an IPv4 address.
The client may also pass the DomainGUID parameter rather than the domain name
to DsGetDcName(). In this case, the client is requesting the _ldap._tcp.domain-
GUID.domains._msdcs.forestname record. This will only happen when a domain has
been renamed.
3. The DNS server returns the requested list of servers. The client then sorts the list based
on priority. The list of the same priority servers are randomized based on weight. The
client then processes the servers list in order. It gets the addresses of each server and
sends an LDAP query using UDP port 389 to each of the addresses in the order they
were returned. After each packet is sent, the client waits for a response, and if no
response is received, it sends a packet to the next domain controller. The client continues
this process until it receives a valid response that specifies the requested services
(e.g., time service, writable DC) or has tried all of the domain controllers.
4. When a domain controller responds to the client, the client checks the response to
make sure that it contains the requested information. If it does, the client begins the
logon process with the domain controller.
5. The client caches the domain controller information so that the next time it needs to
access AD DS, it does not have to go through the discovery process again.
Direct from the Source: How a Client Determines Availability of a
Domain Controller
When a client tries to locate a domain controller after it has received the IP address from
DNS, it varies the time it waits for a response based on the number of domain controllers
it has already pinged. For the first five domain controllers, it waits for 0.4 seconds, and
for next five domain controllers, it waits for 0.2 seconds. After 10 domain controllers
have been pinged, the client uses a 0.1 second wait for the remaining requests.
Chapter 3: Active Directory Domain Services and Domain Name System 71
The algorithm is designed to reduce network traffic if possible and also to ensure that
the client receives a response in a reasonable time if all the queries fail. The logic is that

if the domain controllers are slow because of a high load, the first 10 domain controllers
should be able to respond with the longer wait time before the client increases the
frequency of requests, which results in increased network traffic.
Ashish Sharma
SDE II, US-Directory and Service Business
How the Client Determines Which Site It Belongs To
Having site-specific records is important in order for AD DS to operate efficiently,
because a lot of client network traffic can be limited to a particular site. For example, the
client logon process always tries to connect to a domain controller in the client site before
connecting to any other sites. So how does the client know which site it belongs to?
The site information for the forest is stored in the configuration directory partition in AD
DS, and this information is replicated to all domain controllers in the forest. Included
with the configuration information is a list of IP subnets that are associated with a
particular site. When the client logs on to AD DS for the first time, the first domain
controller to respond compares the client’s IP address with the site IP addresses. Part of
the domain controller’s response to the client is the site information, which the client
then caches. Any future logon attempts will include the client site information.
If the client is moved between sites (for example, a portable computer may be connected
to a network in a different city), the client still sends the site information as part of the
logon. The DNS server will respond with the record of a domain controller that is in
the requested site. However, if the domain controller determines that the client is not
in the original site based on the client’s new IP address, it will send the new site
information to the client. The client then caches this information and tries to locate a
domain controller in the correct site.
If the client is not in any site that is defined in AD DS, it cannot make site-specific
requests for domain controllers.
Direct from the Source: IPv6 Addressing and Site Determination
Windows Server 2008 provides full support for IPv6. This means that the domain
controller can use any of the client’s IP addresses when determining the client’s site.
These addresses include the IPv4 address, the global IPv6 address, and the link-local

IPv6 address.
72 Part I: Windows Server 2008 Active Directory Overview
When the domain controller gets a client’s IP address, it tries to find the corresponding
site in the configuration. By default, the domain controller will use only one of the IP
addresses even if both IPv4 and IPv6 addresses are used. Prior to Windows Server 2008,
if the provided IP address did not map to a site, the domain controller would return no
site mapping to the client. In Windows Server 2008, the domain controller will use both
the client’s IPv4 and global IPv6 address, and it returns the corresponding site for those
addresses if mapped.
This has implications for AD DS site configuration. In previous versions of AD DS, you
only had to assign the correct IPv4 subnets to a site. In Windows Server 2008, you
should configure both the IPv4 and global IPv6 subnet addresses to a particular site.
Ashish Sharma
SDE II, US-Directory and Service Business
After a client computer authenticates, it will cache the domain controller information for a
default of 15 minutes. If the client computer authenticated when no domain controller was
available in its site, it will have authenticated with a domain controller in a different site. This
means that the client computer will use the domain controller in a different site for all AD DS
lookups for those 15 minutes. To modify this default value, create a REG_DWORD entry named
CloseSiteTimeout in the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
key. You can configure a value of 1 minute to 49.7 days for this entry. Use caution when
changing the value of this entry. If the value is too high, then the client may use a domain
controller in a different site for a long period of time. If the value is too low, then repeated
attempts to find a domain controller can create excessive network traffic.
Automatic Site Coverage
You can create sites in AD DS without installing a domain controller in the site. Or you may
create a site that contains domain controllers for one domain, but client computers from a
different domain in the forest may need to log on in the site. This means that client computers
in the site will need to authenticate to a domain controller in a different site. To ensure that
these clients will still choose the best available domain controller, AD DS is designed so

that the domain controllers will automatically calculate which domain controllers will register
the SRV records for sites that do not have domain controllers. This feature is called automatic
site coverage.
Note
Automatic site coverage is a dynamic process. If a domain controller in a particular site
is unavailable, other domain controllers will automatically configure the site coverage records
for the site.
Chapter 3: Active Directory Domain Services and Domain Name System 73
The domain controllers use the sites and site link information to determine which domain
controller will provide coverage for a site with no domain controllers. All domain controllers
are aware of all sites, site links, and domain controllers, because this information is stored in
the Configuration partition in AD DS. All domain controllers first build a list of target sites,
that is, sites that do not have any domain controllers in the local domain controller’s domain.
The domain controllers then build a list of potential sites that could provide automatic site
coverage. This list includes all sites that have domain controllers in the specific domain.
By default, the domain controllers in the site with the lowest cost site links to the target site
will provide site coverage. If more than one site is linked with the lowest cost site links, the
site with the largest number of domain controllers will provide site coverage. If two or more
sites still qualify, the site that is first alphabetically is selected. The domain controllers in the
selected site then register the site-specific SRV records for the domain controllers for this
domain in the target site.
Note
When you deploy an RODC in a separate site, Windows Server 2003 domain controllers
will provide automatic site coverage for the site. This is because Windows Server 2003 domain
controllers do not include RODCs in their automatic site calculations. See Chapter 5, “Designing
the Active Directory Domain Services Structure,” for details on how you can address this issue.
Managing DNS Registration by Using Group Policy
You can manage how AD DS domain controllers register SRV records in DNS by using
group policies. To apply these settings to all domain controllers, you can modify the
Default Domain Controllers Policy. If you want to apply different policies to domain

controllers, you will need to create a new group policy object and then use a filter to
apply the group policy to only specified domain controllers. The following table lists the
settings that are available. These settings are available in the DC Locator DNS Records
folder under Administrative Templates\System\Net Logon.
Group Policy Setting Description
Domain Controller Address Type
Returned
Determines whether the DC Locater returns just IPv4
addresses or IPv4 and IPv6 addresses. By default, both
types of addresses are returned, but if this setting is
disabled, only IPv4 addresses will be returned.
Dynamic Registration of the DC
Locator DNS Records
Determines if Dynamic Registration of the DNS
resource records is enabled. These DNS records are
dynamically registered by the Net Logon service.
DC Locator DNS records not
registered by the DCs
Determines which DNS records are not registered by the
Netlogon service. You can restrict domain controllers from
registering specific types of records.
Refresh Interval of the DC Locator
DNS Records
Specifies the Refresh Interval of the DNS resource records
for domain controllers to which this setting is applied.
74 Part I: Windows Server 2008 Active Directory Overview
AD DS Integrated Zones
In addition to using DNS to locate domain controllers, Windows Server 2008 can also be
integrated with DNS by storing the DNS zone information in the AD DS data store.
Weight Set in the DC Locator DNS

SRV Records
Specifies the Weight field in the SRV resource records
registered by the domain controllers to which this setting
is applied.
Priority Set in the DC Locator DNS
SRV Records
Specifies the Priority field in the SRV resource records
registered by domain controllers to which this setting is
applied.
TTL Set in the DC Locator DNS
SRV Records
Specifies the value for the Time-To-Live (TTL) field in Net
Logon registered SRV resource records.
Automated Site Coverage by the
DC Locator DNS SRV Records
Determines whether domain controllers dynamically
register DC Locator site-specific SRV records for the clos-
est sites where no domain controller for the same domain
exists (or no global catalog for the same forest exists).
Sites Covered by the DC Locator
DNS SRV Records
Specifies the sites for which the domain controllers
register the site-specific SRV records if no domain
controller for the domain is available in the site.
Sites Covered by the GC Locator
DNS SRV Records
Specifies the sites for which the global catalog servers
should register if no global catalog server for the forest is
available in the site.
Sites Covered by the Application

Directory Partition Locator DNS
SRV Records
Specifies the sites for which the domain controllers
hosting the application directory partition should register
the site-specific SRV records.
Location of the DCs hosting a
domain with a single label DNS
name
Specifies if the computers to which this setting is applied
attempt DNS name resolution of single-label domain
names.
Force Rediscovery Interval Specifies a time limit when clients will be forced to
rediscover domain controllers. Useful when the domain
controller configuration changes frequently on a net-
work. By default, clients are forced to rediscover domain
controllers every 12 hours.
Ignore incoming mailslot messag-
es used for domain controller lo-
cation based on NetBIOS domain
names
Determines if the domain controller will respond to
mailslot responses for more information about the
domain controller. Mailslot requests are only used by
Window NT or older clients that use NetBIOS names to
locate and log on to domain controllers.
Try Next Closest Site Determines if client computers will automatically try the
closest site if a domain controller is not available. By
default, clients will request a domain controller in the
closest site by using the DC Locater call
DS_TRY_NEXTCLOSEST_SITE.

Group Policy Setting Description
Chapter 3: Active Directory Domain Services and Domain Name System 75
Benefits of Using AD DS Integrated Zones
AD DS integrated zones provide a number of advantages:
■ The zone transfer process is replaced by AD DS replication. Because the zone informa-
tion is stored in AD DS, the data is replicated through the normal AD DS replication
process. This means that the replication occurs at a per-attribute level so that only the
changes to the zone information are replicated. Between sites, the replication traffic can
also be highly compressed, saving additional bandwidth. Using an AD DS integrated
zone also enables the use of application partitions that can be used to fine-tune the
replication of DNS information. In addition, when new domain controllers are added
to the domain, the DNS information is automatically replicated to the new domain
controller without any further configuration.
■ Integrated zones enable a multimaster DNS server configuration. Without AD DS,
DNS can support only one primary name server for each DNS zone. That means that
all changes to the zone information must be made on the primary name server and
then transferred to the secondary name servers. With AD DS integrated zones, each
DNS server has a writable copy of the domain information, so that changes to the
zone information can be made anywhere in the organization. The information is then
replicated to all other DNS servers.
■ Integrated zones enable secure updates. If a zone is configured as an AD DS integrated
zone, you can configure the zone to use secure updates only. This gives you more
control over which users and computers can update the resource records in AD DS.
■ Integrated zones provide additional security. Because the DNS zone data is stored in
AD DS, you can use access control lists (ACLs) to secure the dnsZone object container
in the directory. This feature provides granulated access to either the zone or a specified
resource record in the zone.
In some cases, organizations are hesitant to use AD DS integrated zones because DNS must be
installed on a Windows Server 2008 domain controller. This can create an additional load on
that domain controller. Another issue is that if all client computers in an organization are

configured to register their host records in DNS, the AD DS database may contain hundreds
of thousands of additional records.
Note
You can combine AD DS integrated zones with secondary zones. For example, you
might have three domain controllers in a central location with several remote offices where
you do not have a domain controller. If you want to install a DNS server into a remote office,
you can install the DNS server role on a member server running Windows Server 2008 and
then configure a secondary zone on the DNS server. The secondary server will then accept
zone transfers from the AD DS integrated zone.
76 Part I: Windows Server 2008 Active Directory Overview
Default Application Partitions for DNS
When you install DNS while you are promoting the first server in the forest to be a domain
controller, two new application directory partitions are created in AD DS. These partitions are
the DomainDnsZones partition and the ForestDnsZones partition. DNS zone information is
then stored in these directory partitions, rather than in a text file on the DNS server hard disk.
Each of these partitions contains different information and has a different replication
configuration. The DomainDNSZones partition contains all of the domain controller records
that are important for locating domain controller services within the domain. All of the
resource records described previously, except the resource records that include the _msdcs
value, are stored in the DomainDnsZones partition. The DomainDnsZones partition is replicated
to all DNS servers running on domain controllers in a domain.
The ForestDnsZones partition is replicated to all DNS servers running on domain controllers
in the forest. The ForestDnsZones partition contains the information that is required for
domain controllers and clients to locate domain controller services in other domains in the
forest. For example, the ForestDnsZones partition includes a domains subzone that lists all of
the domain GUIDs and lists the domain controllers for each of the domains. The ForestDns-
Zones partition lists all of the domain controllers by GUID in the entire forest and lists all of
the global catalog servers in the forest. The _msdcs subzone is stored in the ForestDnsZones
partition.
Note

The DNS application directory partitions are created only if you choose to install DNS
when you promote the first domain controller in the domain or forest. If you want to take
advantage of DNS application directory partitions after you have already upgraded the
domain controller, you must manually create the partition before you can use them. To create
the partitions, you can use the DNS Manager or the DNSCmd command-line tool. If you are
using the DNS administrative tool, right-click on the DNS server name and select Create
Default Application Directory Partitions. If you are using DNSCmd, open a command line and
type dnscmd DNSservername /CreateBuiltinDirectoryPartitions /forest. This will create
the ForestDnsZones partition. To create the DomainDnsZones partition, use ”/domain” as the
last parameter in the command, instead of ”/forest”. You can create the DomainDNSZones
partition for all domains in the forest by running the command with the /Alldomains parameter.
Because this command modifies the configuration directory partition in AD DS, you must
be logged in as a member of the Enterprise Admins group.
The DNS application partitions can be viewed through the DNS Manager and through tools
such as DNSCmd, ADSIEdit.msc, or Ldp.exe. In the DNS Manager (shown in Figure 3-2),
the ForestDnsZones partition information is listed in the _msdcs.forestname delegated zone.
The DomainDnsZones partition is listed in the DomainDnsZone subzone within the domain-
name zone. In ADSIEdit.msc, the application partitions can be viewed by connecting to the
dc=domaindnszones,dc=domainname partition or the dc=forestdnszones,dc=forestname partition
(shown in Figure 3-3).
Chapter 3: Active Directory Domain Services and Domain Name System 77
Figure 3-2 The DNS application directory partitions in DNS management console.
Figure 3-3 The DNS application directory partitions in Adsiedit.msc.
On the Disc You can use the ListAppPartitions.ps1 Windows PowerShell script on the CD
to list the application partitions deployed in your forest and to display which domain
controllers have a replica of the partitions. If you are running Windows PowerShell on a Windows
Server 2008 computer, you must configure the PowerShell script execution policy to allow
unsigned scripts by running the Set-ExecutionPolicy RemoteSigned command. Also, you need
to provide the full path when running a Windows PowerShell script.