Windows Server 2003 on HP ProLiant Servers : Logical Structure Design (part 1) - Domain and OU Structure

When you develop the logical design, it is essentially the development of the forest and domain structure, including the OU structure, Global Catalog (GC) server planning, naming standards, Group Policy, and trust definitions. The fundamental components of the logical structure are illustrated in Figure 1.This section deals with logical design details needed in developing a new AD structure, as well as considerations if you already have a Windows 2000 domain structure in place. In today's business climate of seemingly continual mergers and acquisitions, few companies can consider their forest structure set in stone. In addition, the experience the Windows community has gained since the release of Windows 2000, along with new capabilities of Windows Server 2003, has provided motivation to re-evaluate the forest structure.

Your organization's logical structure includes the forest structure, domain structure, and OU structure, and is commonly referred to as the design of the namespace. These elements form the foundation for all other aspects of AD, so it's critical to incorporate the right design for your organization.

1. Domain and OU Structure

The three basic domain structures illustrated in Figure 2 are the single domain model, the multiple domain model in a parent/child relationship, and the multiple domain model in a multiple domain tree relationship. In each model, OUs are used to create subdomain organizations for more granular administration and security purposes. Note that OUs contain nearly anything a domain can contain, including users, computers, printers, groups, shares, Group Policies, and even other (nested) child OUs. Administration of the OUs is delegated from a higher-level container (domain or parent OU).

This section details the differences and design considerations of multiple- versus single domain models. The decision really rests with the question “Can I accomplish my design criteria more effectively with OUs or domains?” To help determine this, refer to Table 1 to compare features of domains and OUs. Note that multiple domains are clearly more rigid and add to the complexity of the AD, as well as being more costly because you must add servers to create and support the additional domains.

Microsoft has been advising customers even before Windows 2000 was released that the best AD design strategy was to begin with a single domain and prove you need more. After nearly five years of experience with AD, we can say that this design principle is still true. That is not to say that a single domain will always suffice, but that exercise will force you to justify additional domains.

Single Domain

The single domain, as illustrated in Figure 3, is well suited for small- or medium-size companies with simple business organization models, as well as a large global enterprise. Microsoft itself implemented a multiple domain model and is now attempting to collapse it to a single domain model for security reasons. Remember that the key design principle is to create domains representing entities that do not change, and to use OUs for entities that do change (such as business units). Business unit names, location in the organization hierarchy, and subordinate organizations not only change, but also sometimes disappear altogether.

Creating domains based on business entities guarantees a lot of work for the system architect and Administrators, because changing organization structure and department names require changing the domain structure and names. As I worked with companies to design their AD models, it became clear that the most popular domain model is to name domains after geographical entities, such as Americas, North America, South America, Latin America, EMEA (Europe, Middle East, Africa), and Asia Pacific. As one designer noted, “The globe never changes.”

Thus, it becomes easy to see that a company just doing business in a single country or region would be a good candidate for a single domain model. College campuses would fit well in this example. Some features that qualify you for a single domain model include

• Centralized administration: Managing a single domain makes life much easier for Administrators if they operate in a central location.

• Small number of remote sites: Remember that a single domain contains all objects and attributes in the AD that must be replicated to all DCs in the forest. Multiple domain models partition the AD to reduce replication traffic, although GC servers hold about 70% of the data from each domain in the forest. Windows 2000 had limits of a single Bridgehead Server (BHS) per domain per site with no load balancing, requiring manual intervention. 

  note

  Windows Server 2003 contains significant improvements in replication performance that eliminate barriers that existed in Windows 2000 . The new application partition feature allows you to partition the AD independently of the domain level and replicate independently between any specifically targeted DCs in a forest. By default, this feature is used to replicate the DNS data stored in AD only to those DCs that are also running the DNS service. If the AD schema is to be extended to hold a lot of special data for your company's applications, you are now able to sufficiently control replication of this AD data using application partitions across domains, which might make single domains even more attractive.

  
  

• Monolithic business model: Organizations such as holding companies or corporations with multiple independent business units will not benefit from a single domain model. Rather these organizations will likely use a multiple forest model. A simple business organization without these complexities lends itself to a single domain.

• User population: There has never been any limit—real or practical—on the number of objects that can effectively be put into a single Windows 2000 or 2003 domain. HP built a domain in the early days of Windows 2000 that had more than 100 million objects (mostly users) with no significant degradation of performance as the number of objects increased. The single domain models I've seen are typically fewer than 40,000 or 50,000 users. However, that seems to be a result of taking other factors noted here, such as business structure, administration model, and so on, that tend to limit the size of the company and thus the user community. I don't know of a single instance in which the number of users was the sole design criteria for determining a single or multiple domain model.

Although Microsoft and experienced AD architects usually recommend that you start with a single domain model and then prove you need more domains, there are some very good reasons to implement a multiple domain model, as described in the next section.

Multiple Domains

Multiple domain structures are probably the most common AD configuration. Even in small organizations, multiple domains can have advantages. As I noted in the “Single Domain” section, multiple domain models are almost always named after geographical entities. One of the design practices to evolve as Windows 2000 was deployed in the past few years is the role of the empty root domain, also referred to as a “ghost” or “placeholder” domain. This domain contains enterprise Admin and schema Admin accounts, and serves as the forest root domain, which holds the domain structure together. It can be implemented either as a parent to the other domains or a separate domain tree, as shown in Figure 4. Compaq implemented a placeholder domain in a parent-child relationship. Figures 5 and 6 illustrate how Compaqtrimmed more than 1,300 resource domains and 13 master user domains (MUDs) to a simple 4-domain structure in a parent-child relationship.

I know consultants who have advised their customers to create a placeholder domain even if a single domain model would be sufficient. Their reasoning was for expansion. In reality, if you did create a single domain and later wanted to implement a placeholder domain structure,you could create additional domains and leave the original as the placeholder, migrating users, computers, groups, and so on to the other domains.

Consider the case of the Georgia (United States) Department of Transportation (GDOT),  which moved from a multimaster full mesh Windows NT domain model (shown in Figure 7) to a two-domain model with an empty root for its Windows 2000 infrastructure (shown in Figure 8). Essentially, this is a single domain model because GDOT employs a placeholder domain as a root domain, which contains only enterprise Admin accounts. GDOT replaced the Windows NT resource domains with OUs. Consider the simplicity of the new domain model. Note also that GDOT has migrated now to Windows Server 2003 without modifying its AD structure.

Figure 7. GDOT's Windows NT multimaster domain structure.

Figure 8. GDOT's Windows 2000 and Windows Server 2003 domain structure. Originally designed for Windows 2000 and did not change for Windows Server 2003.

A structure of this nature gives the simplistic advantage of a single domain with the flexibility of a multiple domain structure.

However, even though the empty root + one or many child domain structure has often been implemented in the past, the rising security awareness of Microsoft and companies using these infrastructures (including HP) has taught us some clear disadvantages of this AD design. Companies that have not yet deployed AD in their enterprise should especially take the following drawbacks into consideration when deciding between creating multiple domains within their forest (including the empty root domain) or multiple single-domain forests if one single domain forest won't meet their needs:

• Disaster-recovery practices, including restoring deleted objects, are more complicated and lengthened. For example, special recovery mechanisms are required to restore group memberships in universal or domain local groups of other domains in the forest; the order of operation becomes very relevant for forest-recovery scenarios needed to differentiate between rebuilds of GC versus non-GC DCs.

• Replication topology is more complex due to a larger number of connection objects.

• Token evaluation on GCs. Token evaluation depends upon the domain in which a GC resides. This can cause intermittent and difficult to troubleshoot application failures.

• Trusts between forests (that is, between the root domains of the forests) that are not at Windows Server 2003 forest functional level behave like Windows 2000 cross forest trusts; that is, they are not transitive and need to be created between each participating domain.

• When creating forest trusts (at 2003 forest functional level), they lack the visibility of child domains in logon dialogue (even if trust is transitive to child domains, users from “other” forests have to log on using their User Principal Name [UPN]).

• Additional DCs (security event logs, capital and licensing costs, Syskey, restore mode password management).

• More Flexible Single Master Operation (FSMO) role holders to manage and monitor as each domain has a PDC (Primary Domain Controller) Emulator, an RID master, and an infrastructure master.

• Duplication of policy for each domain. Domain-specific processes have to be executed multiple times (for example, if you want to ensure Global Policies in a forest).

• A more complex namespace is always more difficult to understand for help desk and other support staff and can thus increase troubleshooting efforts.

• More administrative and service accounts, which potentially increase the attack surface of an AD forest. Every domain Administrator of any child domain could—by the nature of how security in AD is designed—elevate his privileges to become an enterprise Administrator. As such, multiple domains could potentially decrease the security of an AD forest.

• Not-well-known security issue: Kerberos tickets can still be requested by and obtained for the disabled user in trusted domains within the forest (because DCs of the trusted domains do not check the status of an account when granting Kerberos tickets to access resources in their domain).