Active Directory Components

There are four principle components to an Active Directory design:

Each design component builds on the others to produce the overall Active Directory design. For example, although the OU design and the domain design can account for the geographic needs and the administration needs of the organization, respectively, without a site design, a user, who needs to authenticate and access information from a remote office over a slow link, could suffer poor performance. In addition, if Active Directory domain, OU, and site designs are solid but the organization needs to replicate directory data to another subsidiary that needs to use a different namespace, Active Directory Forest design needs to be included for your Active Directory design to be considered accurate and complete.

Terminology and Context

Before we discuss each of the four principle components of Active Directory, let us first introduce some Active Directory terminology and define the context for proper Active Directory design.

Active Directory Forest

The Active Directory Forest is a group of one or more Active Directory domain trees that trust each other. In a Forest, domains are organized into trees. All domains share a common schema, configuration, and Global Catalog (GC). Unlike directory domain trees, a Forest does not share a contiguous namespace. Therefore, Forests do not need a distinct namespace, like microsoft.com or msn.com. This means that multiple namespaces can be supported in a single Forest. If you plan to deploy an enterprise network comprised of numerous businesses, you might want to consider designing an Active Directory Forest as a way to logically represent and organize your business, business operations, and geographic structures.

Active Directory Tree

The Active Directory tree is a collection of one or more Windows 2000 domains that share a common schema, configuration, and GC. There can be multiple trees within a single Forest. Active Directory trees share a contiguous namespace resulting in a parent-child namespace relationship, like microsoft.com and sales.microsoft.com. The Active Directory tree design is the basis for Windows 2000; it helps define the namespace and the logical structure of your network.

Active Directory Domain

The Active Directory domain is an administrative boundary for a Windows 2000 environment. An Active Directory domain can span one or more locations, and it has its own security policies. A collection of domains that trust each other and that have a common namespace form a Directory Tree. All trees in the Forest share a common schema, configuration, and GC. It is important to model your Active Directory domain design in such a way that aligns with your administrative and security models so that the Windows 2000 enterprise is both easy to administer and to manage and secure from unauthorized access.

Global Catalog (GC)

Each domain replicates objects amongst its Domain Controllers (DCs). Domain objects are not replicated between domains. To provide object visibility between domains, the GC is a partial replica of every Windows 2000 domain in Active Directory. The GC stores a replica of the entire directory. In addition, it also contains a partial list of attributes so that information (users, computers, and printers) can be quickly found and "sourced" in Active Directory and across domains. If you do not consider which Windows 2000 servers will function as Active Directory GC servers, you could severely affect a user's ability to locate important network resources.

Active Directory Partition

Active Directory servers always store at least three partitions: the schema partition, the configuration partition, and the directory partition, which contains the subtree information. The domain partition only replicates between DCs within the same domain. The schema and configuration partitions replicate between all DCs in Active Directory. Active Directory partitions replicate, therefore, you need to consider your physical network topology and your users' computing needs and characteristics when designing Active Directory partition schemes.

Organizational Unit (OU)

The OU is a container in the Active Directory domain that can contain other OUs, user objects, group objects, computer objects, and more. OUs are a way to organize your objects into logical containers based on organizational structure, geographic structure, or any combination of the two. Defining a solid OU design enables you to assign a flexible administrative model that eases the support and management of a large, distributed enterprise. The OU design is also used for applying group policy.

Active Directory Site

The Active Directory site defines a set of Windows 2000 Servers holding Active Directory partitions, which are considered well-connected LAN speeds, such as 10Mbps Ethernet. Designing a solid Active Directory site, which is based on your physical network topology, ensures that Active Directory and all dependent applications and service operate with high-performance and high reliability. How DCs replicate and which DCs Windows 2000 clients prefer is based on your Active Directory site topology.

Active Directory Forest Design

Active Directory domains are identified by DNS names, for example wadeware.net. A domain always contains one or more DCs. A collection of Active Directory domains refers to a Forest. The primary purpose of an Active Directory Forest is to improve the management of multiple domains—typically a daunting task in prior versions of Windows NT—and simplify user access to network resources in the directory. In a Forest, all domains share a common schema, configuration, and GC. When the domains in a Forest have a contiguous namespace, they are referred to as a domain tree; when they do not share a contiguous namespace, they form separate domain trees within a Forest.

Figure 2.1 illustrates a typical Active Directory Forest design—one with a contiguous namespace and one with a discontiguous namespace.

The first domain in an Active Directory Forest is referred to as the forest root. You create the forest root when you install the first Active Directory DC and establish a new Active Directory Forest. Once established, you can create additional DCs in the same domain, additional domain trees, or a child domain of an existing domain tree. In certain circumstances, you might want to establish new Active Directory Forests.

When designing your Active Directory design, the first step is to define your Forest design. A key decision factor is whether to define a single Forest, which is most typical and easiest to manage and support, or multiple Forests, which although more difficult to manage, offers distinct advantages based on the specific characteristics of an organization. Considerations of an Active Directory Forest design include

• Organizational Structure —The structure of each business entity, such as partnership, joint ventures, and conglomerates, must be considered. Depending on the organizational structure of each business entity, you might need to create either multiple Forests or a single Forest.

• Administrative and Security Model —Each business entity's administration and security model can affect the design. For example, in a partnership, each business can have its own identity, business processes, Information Systems (IS) support organization, and security policies. In this case, it probably makes sense to create a separate Forest for each business in the partnership, especially if their security policies prohibit a trust relationship or if changes in one business, in other words new user objects, should not manifest themselves in the other business. When considering a multi-Forest design, it is important to know the trade-offs with regard to the user experience and the administrative complexities that come with having multiple Forests.

• Organizational Changes —Creating multiple Active Directory Forests could have a significant impact if you foresee organizational changes. Merging Active Directory Forests is not a one-step process. Creating trusts is more difficult to manage if you need to provide access to network resources located within another Active Directory Forest. Try to anticipate these changes when designing your Active Directory Forest.

• Namespace Design —Namespace design is based on your defined organizational structure. This process involves defining the Global Namespace, which is the combination of the DNS namespace and the Active Directory namespace. Defining your namespace correctly, both internal and external, is a key component that drives the decisions around your Active Directory Forest design. Some common models for namespace design include

  Geographic—when the namespace is based solely on the geographic attributes of the organization

  Political—when the namespace reflects the organizational structure of an organization

  Geo-Political—when the namespace reflects a mixture of the geographic and political structures of an organization

  Political-Geo—when the namespace reflects the political structure of the organization first and then the geographic structure of an organization

  Functional—when the only consideration for the namespace is operational necessity

• Trust Relationships —In prior versions of Windows NT, establishing and managing trusts between domains was difficult, especially if you had a master domain model with a number of resource domains. When you create domains or domain trees within an Active Directory Forest, two-way transitive trusts are automatically created between each domain in the Forest, making administration much easier. Understanding the trust relationships required for your organization helps to define the Active Directory Forest design. Multiple Active Directory Forests require explicit trusts to perform inter-Forest lookups, and even then, objects need to be imported from one Forest to another.

• Global Catalog (GC) —Because directory searches reference the GC and because the GC is replicated throughout the domains and domain trees in an Active Directory Forest, the GC server placement and the quantity of GC servers are critical for fast directory-wide lookups. Knowing what type of access to resources located on the network that your users would need helps to determine your Active Directory Forest design.

By understanding the specific components of Active Directory and the terminology associated with each component and by factoring in the considerations previously described, you will be able to successfully define your Active Directory Forest design. After you have completed this task, you are ready to go a step deeper in the Active Directory design process and focus on defining the Active Directory domain design.

Active Directory Domain Design

Like the Forest design, the Active Directory domain design is an essential part of Active Directory. As a second step, you need to carefully consider your domain structure. Many factors can affect your Active Directory domain design:

• Active Directory is a distributed database—with parts of the directory (represented by domains) stored on DCs within a domain tree or a Forest. Given this fact, it is important to correctly partition the directory in such a way that stores relevant data close to the users of that data, while ensuring fault-tolerance and reliability.

• A domain is an administrative boundary—meaning that domain administrators have full access to objects in their domain but not to other domains within the Forest.

• A domain is a unit of authentication—which requires a DC to service authentication requests.

• A domain has a common database partition—which replicates between all DCs in the domain. Therefore, if a domain spans multiple physical locations, the domain database partition replicates itself to those physical locations. This replication can be managed using Active Directory sites, but the replication is inevitable.

To define your Active Directory domain design, you should use the following process:

In previous versions of Windows NT Server, the Security Account Management (SAM) database had a limitation of storing no more than 40,000 objects. This limitation required large organizations to build and maintain elaborate domain structures, using a variety of domain models, including single, master, and multi-master domain models. Furthermore, a read-write replica of the SAM was stored on a single machine called the Primary Domain Controller (PDC). This meant that all domain changes, such as creating user accounts, needed to be accomplished on the PDC, and these changes would then replicate to backup DCs, called BDCs. With Active Directory, Windows 2000 can now scale up to millions of objects, and changes to the directory can now be made on any number of DCs because the directory is now a distributed database that replicates throughout the domain, domain trees, and Forest. This model is called a multi-master domain because all DCs are equal, and they can have their objects modified. These modifications are then replicated to all other appropriate DCs.

Active Directory also offers a flexible administrative model because the domains are not the only method of granting or delegating administrative responsibilities. With Active Directory, you can create OUs that represent containers within Active Directory hierarchy. OUs provide the capability to administer portions of the directory and to organize objects (users, groups, printers, computers, and so on) into sub-units. This is especially helpful in large, distributed enterprises.

Figure 2.2 illustrates a couple of typical Active Directory domain designs. One is a single domain model made up of OUs, and the other is a multi-domain model made up of multiple domains forming a domain tree.

There are a number of ways to define your specific domain design. There is no single, right design; however, there are some common reasons for creating multiple domains. We always recommend starting with an assumption of a single domain (for simplicity), and then identify reasons why this domain model would need to change. For example, if you needed to preserve legacy Windows NT domains to create multiple domains because of physical limitations in your network or geographic structure, or if you need to portion administration to separate units within a large organization, you might need a multiple domain structure.

Like a Forest design, the key to a successful Active Directory domain design is to make sure you factor as many considerations—network, administration, security, organizational—and possibilities for change as possible. Many of these considerations are discussed in Chapter 7, "Designing the Windows 2000 Domain Structure." Typically, you need to come up with a number of different design alternatives and apply each design to your specific considerations before you can validate the best design for your organization.

Unlike the Forest design, Active Directory domain designs offer a bit more flexibility for change. With Windows 2000 and Active Directory, you can promote and demote DCs, and you can add and remove DCs with little effort or risk. You can partition and re-partition the directory and configure replication in a way that aligns with your organizational structure and network topology.

After you have completed the Active Directory domain design, you are ready to move on to define the OU structure of the directory.

Active Directory Organizational Unit Design

The OU design is another critical component to your overall Active Directory design. A number of factors need to be determined before you decide on a final design, for example the domain design. There is no single, right way to define your OU structure; there are only some common techniques and best practices.

Before we discuss these, let's define some of the basic properties of OUs:

• OUs are not security principles —They cannot be added to security groups. Furthermore, you cannot assign permissions or rights to OUs and, therefore, apply those rights (through inheritance) down the hierarchy to objects within the OU.

• OUs are used to delegate administration and control directory objects within the OU —This means that you can assign security to objects within the OU and then assign access control lists (ACLs) to these objects for further administrative granularity and control.

• OUs can contain other OUs —These are often referred to as nested OUs.

• OUs can be assigned a group policy —This allows for greater control and administration.

• OUs do not need to represent an is intuitive structure —Users do not navigate the OU structure; they virtually view the resources that they have access to based on the cumulative security, policy, and permissions applied to them from the Active Directory design. Although a common OU structure across domains is simpler to administer, it is not required.

Active Directory OU design can take on several forms. Because OUs are used to delegate administration and because users won't necessarily see the OU structure, the OU design is typically based on the Administrative Mode. Who is responsible for administering and managing certain portions (containers) of the directory?

Typically, administration can be delegated in three ways:

Because Active Directory can contain nested OUs and because OUs can contain multiple objects with assigned security and object attributes, it is easy to create a granular administrative model that meets the most specific needs of an organization, such as resetting passwords on user objects without being able to change or modify anything else about that object. However, just because OUs can be nested, it does not mean that they should be. The more OUs in a domain the more complex the administration of the domain will be. OUs should exist to satisfy a business requirement.

The Active Directory OU design needs to be carefully planned. If you do not have a complex organization or a highly distributed work force or administrative model, it is probably not wise to create a complex OU structure. Often Network Administrators, who know NDS, create Active Directory OU structure based on their organizational structure because they think that Active Directory's OU structure is used for "walking the tree;" this is not the case.

Typically, the OU structure is driven by the need to delegate administration or to apply group policy. Both of these design considerations are explained in two different chapters, Chapter 9, "Group Policies," and Chapter 13, "Developing an Administrative Strategy."

With the Forest design, the domain design, and now the OU design complete, you are ready to move on to the final component of your Active Directory design: the site design.

Active Directory Site Design

As mentioned at the beginning of this chapter, Active Directory site design is based on the physical topology of your network. One of the distinct advantages of Active Directory over other major directory service products is the notion of a site. Microsoft first implemented a site structure with Exchange and SMS. Although the definition and use of a site was slightly different with each product, the intention for defining a site was always based around an area of high-speed connectivity.

In Windows 2000, Active Directory uses a site structure to partition Active Directory based on high- and low-speed communications. For example, if you have a remote office that has a LAN comprising 100 users, which operates autonomously but requires access to corporate applications and email over a 56Kbps frame relay circuit, you'll probably want to consider defining this portion of the network, or the subnet for that location, as a separate site.

In this example, the site would enable Network Administrators to define explicit directory replication intervals and to apply configuration to the replication processes using more resilient transport protocols for slow-speed networks, such as SMTP.

Active Directory site design has several components. Each component has special configuration properties and requirements. A site link is a connection between two sites that uses a slow network connection, less than LAN speeds of 10Mbps. Site links can be configured based on a replication schedule, a costing model, a replication interval, and the type of transport protocol used for site-to-site Active Directory replication.

To define your Active Directory site design, you should start by defining or documenting your physical network topology. With this in hand, you can then identify the number of sites and the connections between sites, and then define the site links and the associated configuration properties of each site link.

By designing a solid Active Directory site structure, you are able to control how and where users authenticate to the Windows 2000 Active Directory domain. This means that users first try to locate a DC within their site, which is (by definition) connected at LAN speeds, before they attempt to locate another DC across a slow-link to another site. In prior versions of Windows NT Server, authentication to the NT domain over a slow link was slow and painful for end users. With the capability to define sites, Network Administrators can now define areas of high-speed connectivity and direct users transparently to authenticate with a preferred DC. The process for designing an Active Directory site topology is outlined in Chapter 10, "The Physical Topology: Sites and Replication."