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. For more information, visit the following Microsoft TechNet Web site:
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 Directory
The 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?
