Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
own domain. They can contain users and groups from any other trusted domain.
Most typically, these types of groups are used to grant access to resources for groups
in different domains.
.
Global groups—
Global groups are on the opposite side from domain local groups.
They can contain users only in the domain in which they exist but are used to grant
access to resources in other trusted domains. These types of groups are best used to
supply security membership to user accounts that share a similar function, such as
the sales global group.
.
Universal groups—
Universal groups can contain users and groups from any
domain in the forest and can grant access to any resource in the forest. Along with
this added power come a few caveats. First, universal groups are available only in
domains with a functional level of Windows 2000 Native or later. Second, all mem-
bers of each universal group are stored in the global catalog, increasing the replica-
ptg
tion load. It is important to note, however, that universal group membership
replication has been noticeably streamlined and optimized in Windows Server 2008
R2 because the membership is incrementally replicated.
Types of Groups
Although groups are covered in more detail in Chapter 6, the type of group used
(domain local, global, or universal) has significant impact on replication of group
objects for large, multidomain organizations as well as organizations with sites
connected through slow links.
For a single-domain organization with high-speed connections to all sites, domain local,
global, and universal groups are effectively the same because the organization has only
one domain, and replication occurs at high speeds to all domain controllers.
However, in a multidomain environment, by default, only the group name of a global
group replicates between domains, not the membership names. Therefore, if a user in
one domain wants to view the member list of a global group in another domain, the
user’s request will have to query across a WAN to the other domain to view the
membership of the global group.
Universal groups, on the other hand, do replicate group membership information
between domains, so a user query of a universal group membership list will be immedi-
ately available in the user’s local domain. However, because universal group member-
ship replicates between domains, if a list of group members is not needed to replicate
between domains, traffic can be minimized by simply making the group a global group.
Explaining AD DS Replication
129
Choosing Between OUs and Groups
Whereas OUs are primarily used to segregate administrative function, groups are useful for
logical organization of security functions. Translated, OUs are created if there is a need for
a department or physical location to have some certain type of administrative control over
its own environment. For example, an organization with offices in Japan could organize
its Japanese users into a separate OU and give a local administrator password-change and
account-creation privileges for that OU. Groups, however, can be used to organize users to
more easily apply security permissions. For example, you can create a group named
Japanese Office Users that contains all the users from the office in Japan. Security permis-
sions can then be established on objects in AD DS using that group. They could, for
example, be given privileges to folders in the main corporate location, something that
could not be done at the OU level.
To summarize, the basic differences between OUs and groups is that groups can be used
4
when applying security to objects, whereas OUs exist when certain administrative func-
tionality needs to be delegated. Chapter 6 gives a more thorough explanation of groups
and OU design.
ptg
Replication in AD DS is a critical function that is necessary to fulfill the functionality of a
multimaster environment. The ability to make changes on any domain controller in a
forest and then have those changes replicate to the other domain controllers is key.
Consequently, a robust method of distributing this information was a major consideration
for the development team at Microsoft. AD DS replication is independent of the forest,
tree, or domain structure, and it is this flexibility that is central to AD’s success.
Sites, Site Links, and Site Link Bridgeheads
For purposes of replication, AD DS logically organizes groups of servers into a concept
known as sites. Typically speaking, a single site should be composed of servers that are
connected to each other via high-speed connections. The links that are established to
connect two or more locations connected potentially through slower-speed connections
are known as site links. Sites are created with site links connecting the locations together
to enable the administrator to specify the bandwidth used to replicate information
between sites.
Rather than having information replicated immediately between servers within a high-
speed connected site, the administrator can specify to replicate information between two
sites only once per night or at a time when network demands are low, allowing more
bandwidth availability to replicate AD DS information.
Servers that funnel intersite replication through themselves are known as site link
bridgeheads.
130
CHAPTER 4
Active Directory Domain Services Primer
Figure 4.8 shows a potential Windows Server 2008 R2 AD DS site structure. Site links exist
between offices, and a domain controller in each site acts as the site link bridgehead. The
site structure is completely modifiable, and should roughly follow the WAN structure of
an organization. By default, only a single site is created in AD DS, and administrators must
manually create additional sites to be able to optimize replication. More on these concepts
can be found in Chapter 7.
NYC-BOS
DC - Site Link
Bridgehead
Boston
Site
Link
ptg
SFO-NYC Site Link
DC - Site Link
DC
DC
Bridgehead
DC - Site Link
k
DC
in
Bridgehead
New York
te L
SFO-
Si
DFW
-NYC
San Francisco
Sit
e L
DFW
ink
DC - Site Link
DC
Bridgehead
Dallas
FIGURE 4.8
Sample site structure where locations are connected by site links.
Understanding Originating Writes
Replication of objects between domain controllers is accomplished through the use of a
property known as Originating Writes. As changes are made to an object, this property is
incrementally increased in value. A domain controller compares its own version of this
value with the one received during a replication request. If it is lower, the change is
Outlining the Role of DNS in AD DS
131
applied; if not, it is discarded. This simplistic approach to replication is also extremely reli-
able and efficient and allows for effective object synchronization. For more information
on replication, including a detailed analysis of Originating Writes and its other key
components, refer to Chapter 7.
Outlining the Role of DNS in AD DS
When Microsoft began development on AD DS, full compatibility with the domain name
system (DNS) was a critical priority. AD DS was built from the ground up not just to be
fully compatible with DNS but to be so integrated with it that one cannot exist without
the other. Microsoft’s direction in this case did not just happen by chance, but because of
the central role that DNS plays in Internet name resolution and Microsoft’s desire to make
its product lines embrace the Internet.
4
While fully conforming to the standards established for DNS, AD DS can expand upon the
standard feature set of DNS and offer some new capabilities such as AD-integrated DNS,
which greatly eases the administration required for DNS environments. In addition, AD
DS can easily adapt to exist in a foreign DNS environment, such as UNIX BIND, as long as
the BIND version is 8.2.x or higher.
Given the importance of DNS in Windows Server 2008 R2’s AD DS, a thorough under-
ptg
standing of DNS is a must. Chapter 10, “Domain Name System and IPv6,” goes into
greater detail on DNS in Windows Server 2008 R2.
Examining DNS Namespace Concepts
A DNS namespace, simply defined, is the bounded logical area formed by a DNS name and
its subdomains. For example, europe.companyabc.com, asia.companyabc.com, and
companyabc.com are all part of the same contiguous DNS namespace. A DNS namespace
in AD DS can be published on the Internet, such as microsoft.com or msn.com, or it can
be hidden from public exposure, depending on the strategy and security needs of its
implementers.
.
External (published) namespaces—
A DNS name that can be resolved from
anywhere on the Internet is known as a published or external namespace. This type
of namespace was previously common for organizations that wanted the full conve-
nience of having their commonly used Internet domain name represent their AD DS
structure. Best practices have evolved to make this model less attractive, however, as
security becomes a concern and DNS must be set up as “split brain” because it is
generally ill-advised to have internal AD DNS zones accessible from the Internet.
.
Internal (hidden) namespaces—
For many organizations, publication of their
internal domain structure is too high a security risk. These organizations can easily
define their AD DS with an internal namespace that is not readable from the
Internet. For example, a company might have an external DNS namespace of
cco.com but decide that its AD DS structure will correspond to cco.internal or any
namespace it wants. Bear in mind that any combination will work for internal
namespaces because there is no limitation on using .com, .net, .gov, and so on when
132
CHAPTER 4
Active Directory Domain Services Primer
dealing with a namespace that is not published. For all intents and purposes, you
could name your domain ilovemydomain.verymuch if you want (although it’s not
recommended, of course). For practical reasons, however, the .internal namespace
has been specifically reserved for private name addressing, and using it is a best-prac-
tice approach in many cases.
NOTE
If deciding to use a domain namespace that theoretically could be bought and used on
the Internet either now or in the future, it is wise to purchase the rights to that domain
name to prevent potential conflicts with name resolution in the future. For example, if
you choose the internal namespace companyabc.com, you might want to first verify that
it is not taken and buy it if possible. If you find the domain name is already owned by
another company, you might choose a different domain name for your AD DS name-
space. Even though your domain might not be published on the Internet, home or lap-
top users who need dial-in or VPN access to your domain might experience conflicts
because they would be incorrectly routed to the wrong DNS name on the Internet
instead of your company’s namespace.
Comprehending Dynamic DNS
ptg
Dynamic DNS (DDNS) was developed as an answer to the problem of DNS tables having
to be manually updated when changes were made. DDNS in Windows Server 2008 R2
automatically updates the DNS table based on registrations, and can work in conjunction
with DHCP to automatically process DNS changes as clients are added and removed from
the network infrastructure. DDNS is not required for AD DS to function properly, but it
makes administration much easier than previous manual methods.
NOTE
Although DDNS is fully supported by Windows Server 2008 R2 and is typically enabled
for all Windows AD DS domain-to-domain name replication, DDNS is still sometimes not
implemented at the enterprise level. Organizations with UNIX-based DNS servers tend
to manually or statically update DNS tables rather than dynamically update DNS tables.
This is solely the choice of the DNS administrator in an organization to enable DDNS.
Comparing Standard DNS Zones and AD-Integrated DNS Zones
Standard DNS essentially stores all name records in a text file and keeps it updated via
dynamic updates. If you are accustomed to using UNIX BIND DNS or other standard
forms of DNS, this is essentially what Standard DNS is in Windows Server 2008 R2.
AD DS expands upon other implementations of DNS by allowing administrators to inte-
grate DNS into AD DS. By doing this, the DNS zones themselves exist as objects in the AD
DS, which allows for automatic zone transfers to be accomplished. DNS replication traffic
piggybacks off AD DS traffic, and the DNS records are stored as objects in the directory. In
Windows Server 2008 R2’s implementation of AD DS, AD-integrated DNS zones are opti-
Outlining AD DS Security