Windows Server 2008 R2 Unleashed (33 page)

.
RID master—
All objects within AD DS that can be assigned permissions are

uniquely identified through the use of a security identifier (SID). Each SID is

4

composed of a domain SID, which is the same for each object in a single domain,

and a relative identifier (RID), which is unique for each object within that domain.

When assigning SIDs, a domain controller must be able to assign a corresponding

RID from a pool that it obtains from the RID master. When that pool is exhausted, it

requests another pool from the RID master. If the RID master is down, you might

not be able to create new objects in your domain if a specific domain controller runs

ptg

out of its allocated pool of RIDs. There is one RID master per AD DS domain.

.
Infrastructure master—
The infrastructure master manages references to domain

objects not within its own domain. In other words, a DC in one domain contains a

list of all objects within its own domain, plus a list of references to other objects in

other domains in the forest. If a referenced object changes, the infrastructure master

handles this change. Because it deals with only referenced objects and not copies of

the object itself, the infrastructure master must not reside on a global catalog server

in multiple domain environments. The only exceptions to this are if every domain

controller in your domain is a global catalog server or if you are in a single-domain

environment. In the first case, there is no need to reference objects in other domains

because full copies are available. In the second case, the infrastructure master role is

not utilized because all copies of objects are local to the domain.

Transfer of an OM role to another domain controller can be performed as part of regular

maintenance, or in the case of a disaster recovery situation where an OM server is brought

offline, the OM can be seized to be brought back online. This is true for conditions where

the schema master, domain naming master, PDC emulator, infrastructure master, or RID

master either needs to be moved to another system (transfer) or has gone down and no

backup is available (seized). The transfer and seizure of an OM role is done through the

use of a command-line tool called ntdsutil, shown in Figure 4.4. Keep in mind that you

should use this utility only in emergency situations and should never bring the old OM

server that has had its role seized back online into the domain at risk of some serious

124

CHAPTER 4

Active Directory Domain Services Primer

system conflicts. More information on the use of this tool can be found in Chapter 7,

“Active Directory Infrastructure.”

FIGURE 4.4

Viewing the ntdsutil utility for AD DS management.

Understanding Domain Trusts

ptg

Domain trusts across forests used to require individual, explicitly defined trusts for each

domain. This created an exponential trust relationship, which was difficult, to say the

least, to manage. Windows 2003 took the trust relationship to a new level of functionality,

with transitive trusts supplying automatic paths “up and down the forest tree.” These

trusts are implicitly easier to understand and troubleshoot, and have greatly improved the

manageability of Windows networks.

Conceptualizing Transitive Trusts

Two-way transitive trusts are automatically established upon the creation of a subdomain

or with the addition of a domain tree into an AD DS forest. Transitive trusts are normally

two-way, with each domain trusting the other domain. In other words, users in each

domain can access resources such as printers or servers in the other domain if they are

explicitly given rights in those domains. Bear in mind that just because two domains have

a trust relationship does not mean that users from one domain can automatically access

all the resources in the other domain; it is simply the first step in accessing those

resources. The proper permissions still need to be applied.

Understanding Explicit Trusts

Explicit trusts are those that are set up manually, similar to the way that Windows NT trusts

were constructed. A trust can be set up to join two unrelated domain trees into a shared

security framework, for example. Explicit trusts are one-way, but two explicit trusts can be

established to create a two-way trust. In Figure 4.5, an explicit trust has been established

between the companyabc domain and the companyxyz domain to join them into the same

structure. Explicit trusts to down-level (pre-Windows 2003 Functional mode) forests are

Understanding Domain Trusts

125

required as cross-forest transitive trusts are not available until the forest is in Windows

Server 2003, Windows Server 2008, or Windows Server 2008 R2 Functional modes.

Explicit Trust

companyabc.com

companyxyz.com

Transitive Trusts

Transitive Trust

asia.companyabc.com

europe.companyabc.com

japan.companyxyz.com

4

FIGURE 4.5

Sample explicit trust between two domain trees.

When an explicit trust is set up to expedite the flow of trusts from one subdomain to

another, it is known as a shortcut trust. Shortcut trusts simply allow authentication verifi-

ptg

cations to be processed faster, as opposed to having to move up and down a domain tree.

In Figure 4.6, while a transitive trust exists between the asia.companyabc.com and the

europe.companyabc.com domains, a shortcut trust has been created to minimize authenti-

cation time for access between the two subdomains of this organization.

companyabc.com

Shortcut

asia.companyabc.com

Trust

europe.companyabc.com

FIGURE 4.6

Sample shortcut trust between two subdomains in a forest.

Another possible use for explicit trusts is to allow connectivity between an AD DS forest

and an external domain. These types of explicitly defined trusts are known as external

trusts, and they allow different forests to share information without actually merging

schema information or global catalogs.

126

CHAPTER 4

Active Directory Domain Services Primer

Defining Organizational Units

As defined in the RFC for the LDAP standard, organizational units (OUs) are containers

that logically store directory information and provide a method of addressing AD DS

through LDAP. In AD DS, OUs are the primary method for organizing user, computer, and

other object information into a more easily understandable layout. As shown in Figure

4.7, the organization has a root organizational unit where three nested organizational

units (marketing, IT, and research) have been placed. This nesting enables the organiza-

tion to distribute users across multiple containers for easier viewing and administration of

network resources.

Domain

Users

ptg

Marketing

IT

Research

FIGURE 4.7

Viewing an organizational unit structure that provides a graphical view of network

resource distribution.

As you can see, OUs can be further subdivided into resource OUs for easy organization

and delegation of administration. Far-flung offices could have their own OUs for local

administration as well. It is important to understand, however, that an OU should be

created typically when the organization has a specific need to delegate administration to

another set of administrators. If the same person or group of people administer the entire

domain, there is no need to increase the complexity of the environment by adding OUs.

In fact, too many OUs can affect group policies, logons, and other factors. Chapter 6,

“Designing Organizational Unit and Group Structure,” gives a detailed rundown of the

design considerations encountered with organizational units.

Determining Domain Usage Versus OU Usage

As previously mentioned, some administrators tend to start applying the AD DS domain

structure to political boundaries within the organization. The dry-erase markers come out

and, very soon, well-meaning managers get involved, organizing the AD DS structure

based on political boundaries. Subdomains start to become multiple layers deep, with each

department taking its own subdomain. The AD DS structure allows for this type of admin-

Outlining the Role of Groups in an AD DS Environment

127

istrative granularity without division into multiple domains. In fact, the rule of thumb

when designing domains is to start with a single domain and add additional domains only

when necessary. In a nutshell, the type of administrative control required by many organi-

zations can be realized by division of groups into separate organizational units rather than

into separate domains.

OUs can, therefore, be structured to allow for separate departments to have various levels

of administrative control over their own users. For example, a secretary in the Engineering

department can be delegated control of resetting passwords for users within his own OU.

Another advantage of OU use in these situations is that users can be easily dragged and

dropped from one OU to another. For example, if users are moved from one department

to another, moving them into their new department’s OU is extremely simple.

It is important to keep in mind that OU structure can be modified on the fly any time an

administrator feels fit to make structural changes. This gives AD DS the added advantage

4

of being forgiving for OU design flaws because changes can be made at any time.

Outlining the Role of Groups in an AD DS

Environment

The AD DS group structure, although not new in AD DS, provides an efficient mechanism

ptg

for managing security on large numbers of users. Without groups to logically organize

users, permissions on each object in a network would have to be set up manually on a

per-user basis. This means that if an entire department needed access to a printer, each

user would need to be manually entered into the permissions list of that printer. These

tasks would make administration of security daunting.

The concept of groups was therefore devised to ease administration. If a large department

needed access to that same printer, the department’s group need only be supplied the

necessary permissions. This greatly eases security-based administration and has the added

advantage of providing for ease of transition if specific users leave the company or are

transferred to a different department. For example, imagine an administrator in charge of

printing and her user account is a member of a group named Printer Admins, which has

full administrative privilege to the printers. Now, if this user transfers to become an email

administrator, for example, reassigning permissions to a new print administrator is as

simple as adding that new user to the Printer Admins group. This capability greatly simpli-

fies these types of situations.

Groups in AD DS work in the way that previous group structures, particularly in Windows

NT, have worked, but with a few modifications to their design. Groups are divided into

two categories: group type and group scope. There are two group types in AD DS: security

and distribution. Essentially, a security group can be used to apply permissions to objects

for the members of the group. A distribution group, on the other hand, cannot be used for

permissions but is used instead to send mail to members of the group. Group scope in AD

DS is likewise divided into several components, defined as follows:

.
Machine local groups—
Machine local groups, also known as simply “local

groups,” can theoretically contain members from any trusted location. Users and

128

CHAPTER 4

Active Directory Domain Services Primer

groups in the local domain, as well as in other trusted domains and forests, can be

included in this type of group. However, it is important to note that local groups

allow resources to be accessed only on the machine where they are located, which

greatly reduces their usability.

.
Domain local groups—
Domain local groups are essentially the same thing as local

groups in Windows NT, and are used to administer resources located only on their