Windows Server 2008 R2 Unleashed (34 page)

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

Explaining AD DS Replication

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