Windows Server 2008 R2 Unleashed (33 page)
Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
.
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.
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
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
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
