MORE INFORMATION
Administrative Boundaries
The reduction of the number of trust relationships that must be
managed is a great improvement in Windows 2000 and Windows Server 2003.
However, another improvement was greatly needed, and that had to do with
administrative boundaries. In Microsoft Windows NT 4.0 and earlier,
administrators who needed the capability to administer subsets of users or
groups within a given Windows NT domain had to be given sweeping, domainwide
administrative permissions. Even if their administrative rights should not have
spanned the entire domain, the rights they needed required that such sweeping
rights be granted. In Windows 2000 and Windows Server 2003, that has changed
with the advent of organizational units (OUs).
Domains
The Windows 2000 or Windows Server 2003 domain is an
administrative boundary. Administrative rights do not flow across domain
boundaries, nor do they flow down through a Windows 2000 or Windows Server 2003
domain tree. For example, if you have a domain tree with domains A, B, and C,
where A is the parent domain of B and B is the parent domain of C, users with
administrative rights in domain A do not have administrative rights in B, nor
do users with administrative rights in domain B have administrative rights in
domain C. To obtain administrative rights in a given domain, a higher authority
must grant them. This does not mean, however, that an administrator cannot have
administrative rights in multiple domains; it simply means that all rights must
be explicitly defined.
Organizational Units
Organizational units enable administrators to create
administrative boundaries within a domain. With OUs, administrators can
delegate administrative tasks to subordinate administrators without granting
them sweeping administrative privileges throughout the domain.
Let's
clarify with an example why OUs are so useful. Say the sales force within your
organization has its own network administrators and resources, such as printers
and servers, and funds all these network resources with its own budget. The
network administrators from the sales force want control over the sales force
resources, policies, and other administrative elements within the sales force
group. However, the sales force is part of the corporate domain.
If
this were a Windows NT 4 network, the administrators of the sales force unit
would have to be added to the Domain Administrators group to get the
administrative privileges they needed to administer the sales force unit. Such
membership in the Domain Administrators group gives the sales force
administrators administrative control over the entire corporate domain (not
just the sales force unit). Such sweeping administrative control isn't
appropriate, but it's the only way to provide the sales force administrators
with administrative control over the sales force's resources and policies.
With Windows 2000 or Windows Server 2003 and the advent of OUs,
that's changed. In a Windows 2000 or Windows Server 2003 network, the
supervising network administrators can create OUs, including a sales force OU,
within the domain structure, and thereby establish new and more limited
administrative boundaries.
The solution could go something like this:
create an OU for the sales force unit, and give the sales force administrators
full administrative privileges only for the sales force OU and not for any
other area of the corporate domain. With the creation of OUs, membership in the
Domain Administrators group (which grants administrative privilege for the
entire domain, including its OUs) can be restricted to only those
administrators who have administrative responsibilities that cover the entire
domain. This results in a more secure and better-run network.
What if
your organization needs to have OUs within OUs? Can you nest OUs? The answer to
that question is yes, but there are performance considerations you should know
about. You can nest OUs, but performance becomes an issue after you go deeper
than about 15 OUs. There are other issues you should consider when you decide
whether to nest OUs (and whether to use OUs at all), which I'll discuss in
detail in Chapter 7, "Planning an Active Directory Implementation."
Active Directory Interaction
Where does Active Directory services fit into all of this? Why is
it absolutely necessary to fully understand domains and domain structure in
order to understand the planning requirements of Active Directory services?
Because Active Directory is inextricably tied to the domain structure of your
Windows 2000 or Windows Server 2003 deployment.
Emulating the Domain Hierarchy
As we already know, Windows 2000 and Windows Server 2003 domains
form a domain hierarchy and one or more domain hierarchies can form a forest.
The directory, as a complete unit, is simply the collection of all objects in
the forest. To ensure that Active Directory services would scale to millions of
objects in a single directory, however, there had to be a strategy for
"breaking up" the directory into parts because, simply put, one mammoth
unpartitioned directory would not scale well. The solution was to partition the
directory, enabling it to scale well and perform well.
The Active
Directory partitioning scheme emulates the Windows 2000 or Windows Server 2003
domain hierarchy. The unit of partition for Active Directory services, then, is
the domain.
This emulation of the domain hierarchy achieves a number
of goals:
- Scalability is ensured
- Performance is maximized
- Replication overhead is minimized
The following section explains in detail how the Active
Directory partitioning scheme emulates the domain hierarchy, why scalability is
ensured and performance is maximized, and how this emulation of the domain
structure minimizes replication overhead.
Cataloging the Domain (the Directory Partition)
The primary goal of Active Directory services is to create a
catalog of objects that reside in the forest. Of course, the catalog wouldn't
be too terribly useful if it were so big that it became slow and clumsy. For
example, imagine all the friends you could take on a snow--skiing trip if only
you had a school bus--but try parallel parking that bus, climbing a mountain
pass with that bus, or parking it in your garage. A better approach would be to
have a convoy of cars, each of which could carry skiers who lived near each
other. You would then avoid the painfully slow climb up the pass, and you could
find parking places scattered about the parking lot. Best of all, each car
could service the getting-home requirements of a few skiers, thereby getting
everyone home faster than if they were loaded in the single bus.
To
take the bus comparison a bit further, imagine the problem you'd run into if
you made more ski-frenzied friends. If there were too many, not all of them
would fit on the bus. In such a situation, you would have to get an entirely
new, bigger bus, which would be even more cumbersome than before. And as more
skiers are invited, the time it takes to get everyone home after the skiing
trip gets longer and longer. In comparison, when cars are used, you simply have
to add more cars to the convoy as you invite more friends; the result is
essentially no additional inconvenience for any existing skiers, nor any
additional transit time when getting skiers home. Active Directory services
helps you avoid getting on the overloaded bus. Instead, the directory is broken
into pieces--just like the convoy of cars--and the benefits of such an approach
are similar in nature to the benefits of using a convoy, but much farther
reaching.
Partitioning the Directory
To help you picture how Active Directory services gets
partitioned within the forest, I'll provide an example of a simple forest.
Figure 3-5 illustrates the sample forest and its single domain
tree.
Figure 3-5. The A, B, C, D,
E, and F domain hierarchy
The forest consists of all of the domains
illustrated in Figure 3-5. The entire directory consists of all the objects
contained in all the domains in the forest. However, to increase scalability
and performance, you must break the directory into multiple pieces, the
aggregation of which creates the complete directory.
Remember that in
Windows 2000 and Windows Server 2003, the unit of partitioning is the domain.
So, when we take another look at our domain hierarchy example, we can compare
the logical domain hierarchy to the way that the directory is partitioned.
Figure 36 compares the domain hierarchy to the directory catalog. As you can
see, the directory is simply the aggregation of each domain's
partition.
Figure 3-6. The domain hierarchy/directory partition scheme
relationship
Remember that noncontiguous trees in the same forest
still form one directory. Don't confuse trees with forests, and don't confuse
the boundary of the enterprise (the forest) with the contiguous nature of a
given domain tree within the forest (the tree). Most organizations, hopefully,
will be able to plan and deploy a single tree--equating to a single
namespace--that constitutes their entire forest. That's the easiest deployment
to envision, manage, and maintain. But deployments aren't always that neat and
acquisitions happen, so you need to remember the following logical equation:
One forest = one schema = one directory catalog
Also realize that a single domain still constitutes a forest. If
you're fortunate enough to be able to sensibly design your Windows 2000 or
Windows Server 2003 domain structure as a single domain, realize that your
single domain constitutes the forest. What does that mean? It means that the
entire directory catalog will be in one unpartitioned unit. (The domain is the
unit of partitioning--one domain = one partition.)
Perhaps one of the
most important advantages of partitioning the directory catalog has to do with
the catalog's scalability, specifically in terms of the effect of adding a
domain to the domain tree, or even adding another entire domain tree to the
forest. Adding a domain or a domain tree does not add administrative or
replication burden to the existing domain hierarchy and administrative
structure. Because of the partitioning of the directory, and because each
domain controller in any given domain contains only directory catalog
information particular to its domain, when a domain or even a domain tree is
added to the forest, network performance and scalability are not affected. When
combined with the new transitive trust relationships established among domains
in the same forest, this partitioning of directory catalog information makes
scaling to very large enterprise deployments with Windows 2000 or Windows
Server 2003 and Active Directory services possible.
Getting Information About Objects in Another Domain
With all this talk about partitioning the directory catalog, you
might be wondering how information from one domain partition gets accessed by
users in another domain. After all, if the domain controllers in one domain
contain information about objects only in their domain, what happens when users
need to get information about objects that reside in another domain? Good
question, and fortunately the answer is straightforward: Active Directory
services uses DNS lookups and queries to resolve queries, just like the
Internet.
Although Active Directory services and Windows 2000 or
Windows Server 2003 use DNS for their lookup service, they both use a special
service (SRV) resource record (RR) entry that designates a given DNS entry as a
domain controller. Domain controllers, in turn, determine whether they are able
to resolve a query, such as would be the case if the query were about an object
in their local domain. If they cannot, the request is referred to a domain
controller that either can resolve the request itself or can point the domain
controller to the next logical server to which the request should be made.
Eventually, the domain controller that can resolve the query is found (or is
definitely not found), at which time the client is referred to that server to
continue with the query process.
DNS queries are explained in more
depth in Chapter 6, "Active Directory Services and DNS."
Distributing the DirectoryThe next points to make clear are how the partitioned directory is
distributed and how it interacts with the Windows 2000 or Windows Server 2003
domain model. In Windows 2000 and Windows Server 2003, each domain controller
in a given domain contains a copy of the directory partition for its domain,
enabling each domain controller to locally resolve queries for information
about objects in the domain to which it belongs.
This approach makes
sense because in many cases, users (or other entities that make use of Active
Directory services) make more use of domain-local network resources than they
make of resources located in a remote domain. By distributing a copy of the
domain partition to each domain controller in the domain--and by making each of
those copies readable and writable--the following enhancements and improvements
are realized:
- Performance is increased because any domain controller can
perform local searches for objects found in its domain.
- Scalability is increased because each domain controller
contains a readable and writable master copy of the directory catalog
partition.
- Scalability is also increased because no single machine is
burdened with performing all the updates for the directory.
This approach is especially useful when remote sites or branch
offices are part of the network topology. By putting a domain controller
(which, by definition, contains a copy of the directory catalog partition) at a
remote site, user queries can be resolved locally. This means that the use of
perhaps expensive or limited wide area network (WAN) resources can be
minimized. The benefit of placing a domain controller at a remote site or
branch campus isn't confined to WAN resource savings because, of course, the
performance of queries will also be improved by having the domain controller
(and its directory catalog partition) available on the remote site's local area
network (LAN).Replicating the Directory Since each domain controller contains a writable master copy of
the Active Directory partition for its domain, changes can be made to a
domain's partition on any available domain controller. When changes are made on
one domain controller, there must be a way to get change updates replicated to
other domain controllers. This process of distributing updated information to
appropriate domain controllers is called replication.
In Windows 2000
and Windows Server 2003, the unit of replication is the domain partition.
However, only changes at the attribute level of a given object are replicated
to other domain controllers, rather than entire objects. The result is a
significant savings in replication traffic, and any time operationally required
network traffic can be reduced, the better the solution.
Update
priority is determined through the use of Update Sequence Numbers (USNs).
Rather than comparing the values for object attributes, Active Directory
services uses a running number--the USN--to determine whether replication is
needed, and if so, which object attribute values need to be transmitted. For
more information on USNs, see the "Replication" section in Chapter 4, "Active
Directory Scalability Architecture." This implementation of USNs is another
advantage of having the domain as the unit of partitioning; it limits
replication traffic (which is already limited to attribute changes) to the
confines of the domain in which the changes were made.
Cataloging the Enterprise (the Global Catalog)
Finally, there must be some way for Active Directory services to
quickly respond to user queries. Although many user queries pertain to the
domain in which the users belong, there are also many queries that are not
domain specific, and rather, are made throughout the enterprise. For example,
e-mail name queries. A truly enterprise-ready and performance-minded directory
service must be able to service such frequent and global queries without
generating undue network traffic and without having to jump through multiple
query referrals. The answer is a directory catalog that contains a subset of
attributes for every object in the enterprise. In effect, it must be a catalog
of object attributes that are globally interesting. For Active Directory
services, that answer is the Global Catalog. The Global Catalog consists of
selected attributes from every object in the enterprise, which means that
selected attributes from every object in the forest are available for
domain-local querying. Just as Microsoft has created a default set of objects
in the schema, default attributes from each schema object are tagged for
inclusion in the Global Catalog. (You might never need to modify these-but you
can.) Most objects have approximately 15 attributes, and approximately seven of
those attributes are tagged for inclusion in the Global Catalog.
The
Global Catalog sits on selected domain controllers within each domain and
services queries that are specific to global searches. When a user submits a
global query based on an object's attribute, and that object's attribute is
tagged for inclusion in the Global Catalog, the query can be resolved by a
domain controller in the local domain that is configured to keep a copy of the
Global Catalog. Because there is at least one domain controller housing the
Global Catalog in each domain, queries directed at global searches can be
performed and resolved quickly. Attributes included in the Global Catalog by
default were chosen because they don't change very often, and that's the way it
should be. Using static information in the Global Catalog minimizes replication
traffic; after all, when an object's attribute that's tagged for inclusion in
the Global Catalog changes, that change must be replicated to all Global
Catalog domain controllers across the entire enterprise. Apart from the
minimizing of replication traffic, static information in general is more
appropriate for global searches.
Conclusions
Windows 2000 or Windows Server 2003 domains and Active Directory
services are two sides of the same coin; domains are administrative boundaries,
as well as partitioning and replication boundaries for Active Directory
services. Just as the Windows 2000 or Windows Server 2003 forest is the
all-inclusive organizational structure for Windows 2000 and Windows Server 2003
domains, the Windows 2000 or Windows Server 2003 forest is the
all-object-inclusive structure for Active Directory services, as well as the
framework within which all objects are defined by a single schema. In short,
the domain structure is the Active Directory services structure. If you don't
understand Windows 2000 r Windows Server 2003 domains, you can't understand how
Active Directory services operates--which is why domains have received as much
attention in this chapter and this part of the book as they have.
Scalability is achieved in Windows 2000 and Windows Server 2003 because domains
no longer require exhaustive two-way trust relationships; now trusts are
implicitly created and then augmented when a Windows 2000 or Windows Server
2003 domain must interact with downlevel domains or when trusts must be
established with forest-external domains. Scalability is also achieved because
the domain-level partitioning scheme of Active Directory services minimizes the
impact of adding domains--so much so that Active Directory services can scale
to networks as large as the Internet.
Despite the partitioning of
Active Directory services and the Windows 2000 or Windows Server 2003 domain
model, the cohesiveness of a Windows 2000 and Windows Server 2003 networking
environment is ensured by virtue of the Global Catalog. By keeping selected
object attributes in a catalog that spans the entire enterprise, often-searched
object attributes can be readily accessible, regardless of where the query
originates or where the target object resides in the organization.
Of
course, keeping all the Windows 2000 or Windows Server 2003 domain terminology
straight can be difficult, as can getting a clear understanding of why such
organizational and hierarchical containers--such as forests, domains, and
OUs--were created in the first place. It might help if you consider the
following loose associations between Windows 2000 or Windows Server 2003 domain
terms and how a large organization might apply the structure to its
environment:
- Enterprise boundaries--forests
- Corporate boundaries--trees
- Division boundaries--domains
- Departmental boundaries--organizational units
But what if your organization doesn't look like this? What if
you aren't an enterprise or a corporation, or you don't have departmental
boundaries? If any of those responses reflect your thoughts, don't worry--these
loose associations are only guidelines to give you an idea of how forests,
trees, domains, and OUs can meet the requirements and requests of large and
small organizations alike. Maybe you don't need OUs, or maybe you need only one
domain (which you determine after reading Chapter 7, "Planning an Active
Directory Deployment," right?). Regardless, you should keep one thing in mind
throughout the planning, deployment, and management processes.
Keep
it simple.
Domains, directories, and networking are complex enough on
their own without the burden of an overly complex deployment plan. Can it work
with one domain? Can it work with only a few OUs? Great--then use only one
domain and a few OUs. You'll hear this call for simplicity throughout Part II
of this book because simplicity works: keep things simple, and they'll be
easier to manage, easier to administer, and easier for your users to use. And
after all, that's the goal, isn't it?
