Windows 2000 Domain Architecture: Design Alternatives

By Microsoft Consulting Services

Abstract

This document presents alternatives for designing the Microsoft® Windows® 2000 Active Directory™ service, particularly for Domain architecture and Organizational Unit (OU) hierarchy. It discusses the pros and cons of various Active Directory deployment architectures and assumes that readers are already familiar with Active Directory.

On This Page

Introduction Active Directory Design Guidelines Design Alternatives Design Alternative 1 - Single Domain Design Alternative 2 - Organization Tree Design Alternative 3 - Organization Forest Design Alternative 4 - Geographic Tree Design Alternative 5 - Geographic Forest Design Alternative 6 - Multiple Forests Domain Architecture Working Model Related Links

Introduction

This document identifies some alternatives for designing the Microsoft® Active Directory™ service structure, focusing on Domain Architecture and Organizational Unit (OU) Hierarchy.

This document is not intended to be a complete tutorial for the Microsoft® Active Directory™ service—readers should be is familiar with the basic concepts of Active Directory.

The document's first major section explains Active Directory design guidelines. This section introduces the concept of Domains, multiple Domains, the reasons for creating them, and additional design considerations for Domains. This section also presents Domain models, including geographic namespace architecture and organizational namespace architecture. Next, the document introduces the concept of trees (a hierarchical grouping of Domains formed into a contiguous namespace) and forests (a logical set of Domain trees that may form a contiguous or disjointed namespace). The document explains reasons for creating multiple forests, including the fact that they allow multiple schemas.

Another section introduces the concept of organizational units (OUs)— containers used to organize objects in a Domain. This section explains reasons for creating OUs, and additional design considerations for them. For example, the shallower the OU hierarchy, the easier it is to search with LDAP. This section also presents OU models, including geographic, organizational, object-based, or project-based hierarchies.

The rest of the document presents design alternatives for Domain architecture. The document suggests designers consider questions such as: whether the internal namespace should be the same as the external namespace or what the name should be for the top level (root) domain in the Active Directory namespace. The document's design alternatives section features designs with a single Domain, multiple Domains to form a single tree, an organization forest, a geographic tree, a geographic forest, and multiple forests. The document ends with a domain architecture working model for an unnamed company.

Active Directory Design Guidelines

Before looking at specific Domain Architectures and Organizational Unit Hierarchies, it's useful to examine the reasons for creating such structures, as well as to address some specific design considerations.

Domains

A Microsoft® Windows® 2000 Domain is identified by a boundary of security (for example, authentication and domain-level security policies) and replication, and it is distinguished by a unique namespace.

Multiple Domains can be joined hierarchically in a contiguous namespace to form a Tree. Multiple Domains and/or Domain Trees can be joined (potentially with a non-contiguous namespace) to form a Forest. All Domain Controllers in a Forest share a common Global Catalog, Configuration and Schema.

Reasons for Creating Domains

When designing a Domain Architecture, the recommended approach is to start with a single Domain and add additional Domains as necessary—providing specific justification for the creation of each Domain. Possible reasons for creating additional Domains are itemized below:

• Administrative Considerations (Politics). Decentralized organizations often have different groups of administrators responsible for managing users and resources throughout the organization. For example, each Organization in Company A has their own set of administrators, which manages the organization users and resources. Some organizations are further decentralized, from an administrative perspective, along geographic boundaries. These administrators may not want to share control of a Domain. For example, a Domain Administrator can always gain access to and take ownership of objects within its Domain. However, a delegated OU Administrator does not have this ability.

• Unique Policies. Different locations or Organizations may have unique security and administration policies, which may require separate domains.

• Network Traffic. By creating multiple domains, network traffic is reduced because only changes to the Global Catalog, Configuration and Schema are replicated between Domains. Within a Domain, the entire Domain database, as well as the contents of the SYSVOL partition (which includes Logon/Logoff Scripts and Group Policy Objects), are replicated to all Domain Controllers in the Domain.

  Note: Although the entire Domain database is replicated to each Domain Controller in a Domain, the impact on link traffic is mitigated. After initial replication, only changed properties are replicated. In addition, with the use of Sites, replication traffic can be scheduled and is compressed significantly.

• Network Connectivity. Within a Domain—and between Sites—the RPC Inter-site Connector must be used; you cannot use the SMTP Inter-site Connector within a Domain. If your network cannot support RPC between locations (low or intermittent bandwidth and/or high network latency), then you must use the SMTP Inter-Site Connector. However, the SMTP Connector cannot be used to replicate the Domain Naming Context. Put another way, if the SMTP Connector must be used, then it must be used between Domains.

• Capacity. Should the number of objects in a Domain significantly exceed one to two million objects, a separate Domain should be considered.

• International Differences. Differences in languages and business practices could require separate domains.

• Namespace Requirements. Organizations may have a requirement for one or more specific DNS domain names.

• In-place Upgrade of Existing Domains. A possible Coexistence and Migration Strategy is to upgrade existing domains in-place, with an eventual migration to a domain architecture that is different than the current domain architecture, requiring the implementation of "temporary" Windows 2000 domains.

Additional Design Considerations for Domains

• Design for the minimum number of domains. The larger the number of domains to administer, the higher the administrative costs and the more likelihood of adjustment during reorganizations.

• Design for a minimum depth of the domain hierarchy. A good rule of thumb: if you can't remember the FQDN of the domain, then it's probably too long.

• Choose stable (static) constructs for Domains. A good design will withstand company reorganizations without the need to restructure the domain hierarchy.

• Each Domain requires at least one Domain Controller to hold the Domain database and provide services such as Domain Authentication. For most Domains, however, it is recommended that at least two Domain Controllers should be available in each Domain for fault tolerance. This may affect the decision to create additional domains.

• During migration from Microsoft Windows NT® 4, a multiple-domain architecture may be maintained during a period of coexistence, thereby creating "transient" Windows 2000 domains. These domains may later be collapsed into a smaller number of Windows 2000 domains.

Certain policies can only be applied at the Domain Level. If any of these policies need to be unique for specific logical organizations (such as Organizations), then different Domains must be created. Examples include:

• Password (length, expiration)

• Account lockout (threshold, duration)

• Kerberos (ticket lifetime)

• Encrypted File System (recovery)

• IP Security (usage level)

• Public Key

• Certificate Authorities

• The root domain (for instance, the first Domain that is installed in a Forest) cannot be renamed. It is critical to select the correct name for this Domain up front.

• The root domain cannot be removed from the forest. It is even more critical that the root domain be based on stable criteria and has longevity. Child domains can be removed from the forest.

• Deep LDAP searches submitted to a Domain Controller will only generate referrals within the Tree to which the DC belongs. Deep LDAP searches submitted to a Global Catalog will generate referrals to any Domain within the forest.

• Pruning and Grafting of hierarchies of containers and leaf objects have various levels of support in the initial release of Windows 2000. This should be taken into consideration when determining domain (an organizational unit) hierarchy. For some of these, with limited support for prune and graft, it is important to get it right the first time. Some examples of the prune and graft capabilities:

  • Move leaf objects (user, group, and computer) within a domain. Supported within the Active Directory Users and Computers snap-in.

  • Move user and group leaf objects between domains. Supported with a Resource Kit utility (MOVETREE), based on ADSI.

  • Move computer objects between domains. Supported with a Resource Kit utility (NETDOM).

  • Move a sub-tree (OU hierarchy) within a domain. Supported within the Active Directory Users and Computers snap-in.

  • Move a sub-tree (OU hierarchy) between domains. Supported with a Resource Kit utility (MOVETREE), based on ADSI.

  • Move a domain within a Forest. Not supported in the initial release.

  • Move a domain between Forests. Not supported in the initial release.

  • Split/merge domains/forests. Not supported in the initial release.

• Active Directory Domains can be used to control replication. From a Domain perspective, all properties of all objects within the Domain are replicated to all Domain Controllers within that Domain. Further, Global Catalog servers contain a partial replica (all objects, selected properties) of all Domains in the Forest. To reduce the amount of domain data that is maintained in a DC (or to reduce the amount of domain data that is replicated to a DC), separate Domains can be created. Although replication between Sites is compressed and scheduled, initial replication to Domain Controllers in remote sites can be significant. Strategically locating Domain Controllers and Global Catalog servers can be used (as an alternative to creating additional domains) to mitigate this issue. For example, we can consider placing DC's and GC's in regional IT hubs, as opposed to every remote office. One trade-off that should be considered is trusting your network for logons vs. trusting your network for replication.

• Each user has a User Principal Name (UPN), which is the friendly name for users and computers. The UPN consists of a short name concatenated with a DNS name suffix. By default, the UPN is constructed from the User Logon Name and the Domain Name (for example, jsmith@companya.com). Each UPN name must be unique in the forest. However, by adding "alternate UPN names" to domains, you can change the default UPN name for each user. For example, each domain can have the alternate UPN name set to companya.com, so that the UPN name for all users will be in the form of UserLogonName@companya.com, regardless of which domain the user resides.

Domain Models

Several models can be used to define the Domain Architecture. The two most common models are identified below, but hybrid models are certainly possible:

Geographic Namespace Architecture

A geographic model structures domains along stable geographic boundaries. For example, the first level Domains can be based on continents (North America, Europe, Asia, and so forth), the second level Domains can be based on countries and third level Domains—if necessary - can be based on smaller geographic units such as states or regions.

Advantages

• Domain Architecture not likely to change, as geographic boundaries are generally stable.

• Helps to optimize network traffic, as all intra-domain replication is constrained within a geographic region—and WAN is typically also modeled along geographic boundaries.

• Isolates language dependencies within a country.

Disadvantages

Political implications in that administrators in different organizations must "share control" of a Domain.

Organizational Namespace Architecture

An organization model structures domains along business units. For example, the first level domains can represent Organizations and the second level domains can represent sub-businesses.

Advantages

• The namespace logically represents the business practices of the organization itself.

• Provides a familiar model to end users and administrators for searching and browsing the directory.

• Addresses the political issue in that Organization administrators completely "own" their Domain.

Disadvantages

• Domain architecture is less stable than geographic model, as corporate reorganizations, acquisitions and divestitures are common.

• Not optimized for network traffic. Organizations are often widely disbursed geographically—which means that the organizational model may not follow the WAN architecture. This has implications for intra-domain replication of the Active Directory and SYSVOL partition.

• Possibly increases hardware requirements. Geographies, regions or campuses that house multiple business units may require Domain Controllers from each of those business units.

Forests and Trees

A Tree is a hierarchical grouping of Domains that are formed into a contiguous namespace (for example COMPANYA.COM as the parent, with child domains of CHILD1.COMPANYA.COM and CHILD2.COMPANYA.COM). The name of a Tree is the name of the domain that is highest in the hierarchy. For example, the Tree name in the previous example is COMPANYA.COM. By default, all domains in a tree have two one-way transitive trust relationships between parent and child domains.

A Forest is a logical set of Domain Trees that together may form either a contiguous or disjoint namespace. A Forest is named the same as the first Tree that is installed in the Forest. In addition to the transitive trust relationships that exist between parent and child domains, in a Forest there are also two one way transitive trust relationships between peer top level domains.

All Domains in a Forest have the following in common:

• Schema—the formal definition of objects, properties and their relationships.

• Global Catalog—partial replica of all objects in the forest.

• Sites and Services Configuration—enterprise configuration information, including physical sites and enterprise network services.

If multiple domains are implemented as a forest, then one domain should be identified as the Enterprise Root Domain. This is a special domain in the Enterprise that cannot be deleted or renamed and the role cannot be transferred.

When designing a Forest Architecture, the recommended approach is to start with a single Forest and add additional Forest only if necessary—providing very specific justification for the creation of each Forest. In almost all cases, it is envisioned that a single Forest will work for even the largest companies. However, for completeness, possible reasons for creating additional Forests are itemized below:

Reasons for Creating Multiple Forests

Possible reasons for creating multiple Forests are itemized below:

• Multiple Schemas. Some organizations may require multiple Directory Schemas. For example, an organization may have a quasi-official relationship with a joint venture. Although the level of trust between the two organizations is high, thereby warranting some type of relationship between their Windows 2000 deployments, each organization may have unique schema requirements. In this case, multiple Windows 2000 forests can be deployed, each with their own schema, and perhaps with manual trusts established between the forests.

• Grass Roots Implementation. The initial release of Windows 2000 does not support forest merge—largely because of the complexity of merging schemas. If a grass roots implementation of Windows 2000 exists within an organization (separate from the officially sanctioned Windows 2000 implementation) then it is not possible to merge these forests. They can, however, be logically linked with Windows NT 4.0 style trusts.

• Acquisition. Again, since forest merge is not supported in the initial release of Windows 2000, if an organization that has already deployed Windows 2000 acquires another organization that also has Windows 2000 already deployed, these forests must remain separate.

• Politics. "Enterprise Admins" and "Schema Admins" have special permissions in a forest, by default. There are "span of control" political implications to this, which can be mitigated by the implementation of separate forests.

Advantages

Some of the advantages of a multiple forest implementation are:

• Each organization has complete ownership of their Directory.

• Each organization can maintain it's own Directory Schema, meaning that Schema modifications are more localized and have less of an impact on the Enterprise.

• Pre-existing Forests can easily be incorporated into this model (for example, acquisition of a company that already has Windows 2000 Active Directory deployed—or a grass-roots deployment).

• Divestitures can be handled more easily. A spin-off of an Organization-based multiple forest model is easy. On the other hand, with a single forest, extricating a single Organization will be more difficult. It may be possible to move the spinned-off Organization domain(s) to another network and provide them with a replica DC from the Enterprise Root Domain, but there are possible issues with FSMO's, KDC's, and so forth.

Disadvantages

Some of the disadvantages of a multiple forest implementation are:

• No single enterprise directory. Each Forest will have it's own independent directory. Directory Synchronization between Forests will not be possible in the initial release of the product.

• No cross-business security context by default, although Windows NT 4 style trusts can be explicitly added.

• No transitive trust relationships possible across Forests.

• Mergers of Organizations will require Forest Reorganization—a very significant operation—especially in the initial release of Windows 2000.

• User and resource transfers between Organizations (for example between Forests) will be a significant operation.

• Exchange 5.5 will be able to populate (via replication) Exchange objects and properties into the Active Directory using the Active Directory Connector. (The ADC actually supports bi-directional replication.) The ADC is designed to replicate between one or more Exchange Sites (in a single Exchange Organization) and one or more Windows 2000 Domains (in a single Forest). The ADC will not fully support replication between a single Exchange Organization and multiple Windows 2000 Forests.

• No single enterprise-wide GAL for Exchange Platinum (the next release of Exchange—which uses the Windows 2000 Active Directory for its directory service). For MAPI clients that have a Platinum mailbox, the GAL will be the Global Catalog. Since the Global Catalog is specific to a Forest, there will be a Global Catalog (and hence a GAL) for each Organization (or, more accurately, for each Forest).

• Platinum servers will use the Active Directory for routing information. Without a single Active Directory, routing cannot efficiently be handled between Forests.

Organizational Unit

Organizational Units—or OUs—are containers that are used to organize objects within a domain. For example, OUs can contain Users, Computers, Groups, Printers, Applications, File Shares and other OUs. They are distinct logical administrative units that are used to delegate administration within a domain.

Reasons for creating Organizational Units

When designing an OU Hierarchy, the focus should be on reflecting the organization's business model. Possible reasons for creating OUs are itemized below:

• Enhancing administrative control:

  • Delegate administration to an OU, as well as deciding who will have access to the OU.

  • Keep objects with identical security requirements together.

  • Simplify object administration.

  • Control visibility of objects, such as printers, users, and so on.

  • Make resource administration more efficient (for example, assign permissions once for an OU with many shares rather than multiple times for each share).

• Policy Application. Controlling policy application so that it applies to a distinct group of users or computers. Policies can be scoped such that they apply to a Site, a Domain or an Organizational Unit.

• Migration. In Windows NT 4.0, delegation of administration was achieved through resource domains. This was expensive, requiring additional management and hardware. Windows 2000 enables you to collapse resource domains into a hierarchy of OUs.

• Limiting Number of Objects. While there is no practical limitation to the number of objects that may exist in an OU, for end user browsing purposes it may make sense to limit the number of objects in an OU.

Additional Design Considerations for Organizational Units

• Although OU hierarchies are unique to a Domain, it is recommended that first level OUs should be standard throughout the organization, in order to provide consistency.

• The shallower the OU hierarchy, the better the search performance will be. LDAP searches are degraded when there are a large number of OU levels. It is recommended that there be no more than 10 OU levels in an OU hierarchy.

• The number of OUs, or depth of the OU hierarchy, will have a negligible impact on replication.

• Delegation of administration at the OU level, as opposed to the object level, will be easier to track and manage, thereby reducing administrative costs.

• The OU hierarchy should be beneficial and meaningful. Do not create OU structure for the sake of structure. When creating an OU, do so with a clear understanding of the following:

  • Who will administer the OU?

  • Who will be able to view the OU and it's objects?

• Pruning and Grafting of hierarchies of containers and leaf objects have various levels of support in the initial release of Windows 2000. Refer to the earlier section on Design Considerations for Domains for a complete review of pruning and grafting support.

Organizational Unit Models

Several models can be used to define an OU hierarchy, and clearly it is the business needs that must drive the OU hierarchy. Some common models are identified below, but hybrid models are certainly possible:

Geographic Hierarchy

A geographic model structures OUs along stable geographic boundaries. For example, the first level OUs can be based on continents (North America, Europe, Asia and so forth), the second level OUs can be based on countries and third level OUs can be based on smaller geographic units such as states, cities, provinces and so forth.

Advantages

• First-level OUs may not change as often as with other models because geographic boundaries generally remain stable.

• OU administrators can easily identify where resources are physically located.

Disadvantages

The design may not mirror the organization's actual business practices.

Organizational Hierarchy

An organizational model structures OUs along business units. For example, the first level OUs can represent the Organizations and second level OUs can represent sub-businesses.

Advantages

• It is user-friendly because it builds upon knowledge that users already have.

• It is easy to browse and query to obtain required information because resources are in clearly defined locations.

• Unique business policies can easily be applied to the appropriate business units.

Disadvantages

It may require restructuring if a division or business unit is renamed or reorganized.

Object-based Hierarchy

An object-based model structures OUs along object classes. Examples of Object Classes are Users, Computers, Groups, Printers, Shares and so forth.

Advantages

• It makes resource administration easier because OUs are designed by object type.

• It is easier to create common access control lists (ACLs) for object classes.

• Resource administration can be customized according to the various levels of the OU administrator because OUs are designed by object type. For example, it would be easy to grant appropriate permissions to "Account Operators" on OUs that contained only user accounts and to "Print Operators" on OUs that contained only printer objects.

Disadvantages

Potentially, there are a large number of object OUs.

Project-based Hierarchy

A project-based model structures OUs along corporate projects.

Advantages

• When you must separate objects by project, this model can provide an easy method for tracking costs and expenses.

• This model controls access by creating a separate hierarchy for each project. Therefore, it could be a good choice if project security were an issue.

Disadvantages

• Projects have a definite life span, and this restricts the longevity of an OU.

• Because projects change frequently, maintenance of this kind of model may be high.

Administration Hierarchy

An OU hierarchy can be developed which solely models the administrative model of the organization. For example, a central IT organization can be represented as a first level OU, Organization IT organizations can be represented at the second level, and branch or departmental IT organizations represented at a third level.

Advantages

• This model makes the system administrator's job simpler because resources are organized from an IT perspective.

• It is easy to identify OU administrators in a domain.

Disadvantages

• It is division-centric and may be difficult for users because everything appears under one division.

• This model may not reflect the way that the organization conducts business.

Design Alternatives

This section will identify and describe the potential design alternatives for the Company A Domain Architecture, as well as examine the pros and cons of each alternative. At this point, the OU Hierarchy is not detailed extensively, as the first step is to get the Domain Architecture agreed to. However, the OU Hierarchy discussed at a high level, because it's important to understand what might be going on under the covers (in the OU hierarchy) for any potential Domain Design.

Possible alternatives are:

• Single Domain for all of Company A.

• Multiple Domains to form a Tree; Domains based on Organization.

• Multiple Domains to form a Forest; Domains based on Organization.

• Multiple Domains to form a Tree; Domains based on Geography.

• Multiple Domains to form a Forest; Domains based on Geography.

• Multiple Forests; Forests based on Organization.

Internal vs. External Namespace

With any domain architecture, the question remains whether the internal namespace (only available within the firewall on the corporate network) should be the same as the external namespace (publicly available on the Internet). Some of the reasons why they should be different:

• There are a large number of names that are already registered for use on the Internet for Company A. Selecting a single (or small number of) root domain name(s) for the Internal Namespace will allow for an opportunity to consolidate the namespace.

• With a "split domain namespace" (same names available externally and internally), there is additional management overhead in maintaining the DNS zones—both externally and internally. For example, with a split domain, there are some computers and services that should only be available internally and some that should only be available externally—thereby mandating that the external DNS zone file and the internal DNS zone file (for the same namespace) must be different.

• There is significant administrative overhead in managing both the Firewall and Proxy configurations if the internal and external namespaces are the same.

Root Domain Name

Another question is "What should the name of the top level (for example root) domain in the Active Directory namespace be?" Remember that an Active Directory Domain name is precisely a DNS Domain name. There is also the corollary question—"Who owns that DNS Zone?" There are a few options here, which are described below.

No Pre-Existing DNS

If there was no pre-existing DNS infrastructure at Company A, then the recommendation would be to select a DNS Domain Name for the root—say, COMPANYA.COM—and use Microsoft DNS to manage that zone. This is not the case at Company A, but the benefits of using Microsoft DNS will be summarized here, because they still make sense for some of the other alternatives that will be discussed below.

• SRV record. The DNS Server(s) that manage an Active Directory Domain must support the SRV record (RFC 2052). The SRV record is a generalization MX record, and allows specific services to be registered in DNS. For example, Domain Controllers and Global Catalogs are explicitly registered in DNS with those specific roles. Therefore, when a client is looking for a DC or GC (for logon), it can locate an appropriate server that is providing that service.

• Dynamic DNS (DDNS). The DNS Server(s) that manage an Active Directory Domain should support the Dynamic Update Protocol (RFC 2136). Windows 2000 DNS clients (for A records), as well as DHCP Servers (for PTR records), will dynamically update the Microsoft DNS Server with mappings. In addition, Windows 2000 servers will register multiple records in DNS based on roles and other criteria. If Dynamic Update were not used, then every time any of the following were modified, the DNS would have to be manually updated:

  • Domain Controller name

  • Roles (for example, Domain Controller, Global Catalog, Member Server)

  • Sites

  • IP Addresses

  • Promotion/Demotion

• Incremental Zone Transfers. The Microsoft DNS server also supports Incremental Zone Transfers (RFC 1995). With standard DNS, full zone transfers between Primary and Secondary must be performed whenever there are any changes made to the database.

• Active Directory-Integration. The Microsoft DNS server can be integrated with the Active Directory, so that the DNS "database" is actually stored in the Active Directory, rather than in a flat text file. Some of the advantages of this are:

  • Management of a single replication topology. Both DNS and Active Directory have databases that are replicated amongst computers. With Active Directory-integration of the DNS database, then only a single replication topology needs to be managed.

  • Multi-master update. With standard DNS, changes to the DNS database may only be performed on the Primary master. Secondary masters always get their copies of the DNS database from a Primary master (or another secondary master). With Active Directory-integration, changes to the DNS database can be performed on any DNS server that manages that zone.

  • Secure dynamic update (RFC 2137). Allows authentication of hosts that are dynamically registering their names.

• Fully Tested and Compatible with Active Directory. The Microsoft DNS will of course be fully tested and compatible with Windows 2000 and the Active Directory. Other DNS servers will need to be tested more extensively to ensure that they handle an Active Directory zone properly.

Existing DNS Infrastructure

If there is an existing DNS infrastructure that is managing the zone that corresponds to the selected Root Domain, then we need to understand whether it meets the requirements of Active Directory. That is—it must support SRV and it should support DDNS. The latter is a strong preference, but it's possible that the organization can accept the associated administrative overhead of using a DNS that doesn't support dynamic update.

If DDNS is a requirement for the organization, and the current infrastructure does support DDNS, then we must understand the additional overhead that will be placed on the existing DNS server infrastructure to support dynamic updates for the Windows 2000 environment.

Let's look at a specific example. Suppose that Company A decides to use COMPANYA.COM as the root domain name for the Active Directory Namespace. This means that a DNS infrastructure must be in place to support the COMPANYA.COM zone. If there is already a DNS zone with this name in Company A, then we must determine whether the servers that are managing the COMPANYA.COM zone can meet the requirements of Active Directory outlined above.

If these requirements, desires and load implications are not adequately met by the current infrastructure, then there are at least three alternatives:

• Upgrade all of the existing DNS servers that are managing the Active Directory zone(s) to a version that meets all of the requirements.

• Migrate the DNS servers to Microsoft DNS.

• Delegate a new zone, subordinate to the existing root zone, and use Microsoft DNS servers to mange that delegated zone. This new zone could then be the root domain for the Active Directory namespace. For example, a new domain named ENTERPRISE.COMPANYA.COM could be created and delegated from the DNS servers that manage COMPANYA.COM.

Design Alternative 1 - Single Domain

This model identifies a single Domain for all of the Company A enterprise and would likely be combined with an Organizational Unit model that is based on either Geography or Organization. The Single Domain hierarchy can be identified as shown in Figure 1.

Figure 1:

Advantages

Some of the advantages of this model include:

• Centralized administration of security policies for the entire enterprise.

• Consistent domain-level policies for the entire enterprise.

• Organization Unit hierarchy provides distributed administration of Organization objects.

• Extremely flexible model for acquisition, divestiture and reorganizations.

• Extremely flexible model for user and resource (in fact—any object) moves.

• No need for Global Catalogs—every Domain Controller has a full replica of all objects in the enterprise directory. Also a disadvantage—see below.

• Geographies, regions or campuses that house multiple Organizations may share Domain Controllers.

• Straightforward namespace design—a single DNS name.

• Models the Organization hierarchy, so

  • Users are familiar with this model, making it easy to browse and query

  • Unique Organization policies can easily be applied

Disadvantages

Some of the disadvantages of this model include:

• Organizations do not have sense of "ownership". Who are the Domain Administrators for this single domain?

• Security Policies must be identical across the entire enterprise.

• Every Domain Controller has a full replica of all objects in the enterprise directory. Although a single partition of the Active Directory will likely scale to support the total number of objects in the Company A enterprise directory, the hardware requirements for every Domain Controller would be significant.

• Logon performance will be impacted.

• Backup and Restore will be more time-consuming, resource-intensive and complicated.

• Inefficient use of network bandwidth—every property of every object in the enterprise directory would be replicated to every Domain Controller. Of course, only deltas are replicated and sites can be used to control replication schedule and to compress data, but nevertheless every single property change in the directory must get replicated all around the world. Think about the impact of things like password changes.

Design Alternative 2 - Organization Tree

This model includes multiple Domains to form a single tree (for example, contiguous namespace). The root domain is created for enterprise-wide resources and to serve as a directory placeholder for the root of tree. Each Organization would be represented in the tree by what is referred to as a "first level domain". If necessary, for example based on unique security requirements or capacity or replication requirements, "second level domains" can be created. Second level domains could represent divisions within an Organization.

Organizational Unit hierarchies within each domains could be based on geographies or organizations ( departments or other divisions). For example, first level OUs could represent geographies and second level or third level OUs could represent departments.

The Organization Tree hierarchy can be identified as shown in Figure 2.

Figure 2:

A potential OU Hierarchy within each Domain could be represented as follows:

Figure 3:

Advantages

Some of the advantages of this model include:

• The namespace logically represents the business practices of the organization itself.

• Provides a familiar model to end users and administrators for searching and browsing the directory.

• Organizations completely own their Domain and their portion of the namespace.

• Centralized administration of security policies within each Organization at the First Level domain level.

• Consistent domain-level policies within each Organization at the First Level domain level.

• Organization Domain hierarchy provides distributed administration of Organization objects.

• Each Domain Controller maintains a full replica of a smaller portion of the enterprise directory—than the single domain model—resulting in faster logons, reduced hardware requirements, and more manageable backup/restores.

Disadvantages

Some of the disadvantages of this model include:

• Reorganizations, acquisitions and divestitures of Organizations will require Domain Reorganization—a significant operation—especially in the initial release of Windows 2000.

• User and resource transfers between Organizations are not trivial.

• Although improved over the Single Domain Model, this model is still not optimized for network traffic. From an intra-domain perspective, all properties of all objects in the domain are replicated to all Domain Controllers in that domain (and hence around the entire globe). Sites do mitigate this issue.

• Possibly increases hardware requirements (and associated capital and administrative costs). Geographies, regions or campuses that house multiple Organizations may require Domain Controllers from each of those Organizations.

Design Alternative 3 - Organization Forest

A variation of the Organization Tree model is the Organization Forest model. Functionally, this model is very similar to the Organization Tree model. The advantages and disadvantages of the Organization Tree apply to this model as well. The primary difference between the Organization Tree and Forest is that in the Forest, the namespace does not have to be contiguous.

One Domain in the Forest would act as the "Root Domain" and would hold enterprise-wide resources.

The Organization Forest hierarchy can be identified as shown in Figure 4.

Figure 4:

Advantages

Organizations would be able to maintain their existing (peer) namespaces, yet still be joined into a single Windows 2000 directory (forest).

Disadvantages

• Deep LDAP searches must be submitted to a Global Catalog instead of a Domain Controller. For example, an LDAP search to find a resource in ORG1.COM, submitted to a Domain Controller in ORG2.COM, would never return a referral to ORG1.COM. The same search submitted to a Global Catalog would in fact return the referral.

• One Organization can be viewed as "dominant" as the enterprise root domain will hold enterprise-wide resources.

Design Alternative 4 - Geographic Tree

This model includes multiple Domains to form a single tree (again, a contiguous namespace). The root domain is created for enterprise-wide resources and to serve as a directory placeholder for the root of tree. First level domains could be based on continental and geopolitical boundaries. Second Level domains can be created, where necessary, and could correspond to countries. Any third level domains would be based on states and/or other geographic regions. Organizational Unit hierarchies within each domain could be based on Organization and other organizations (such as departments or other divisions). For example, first level OUs could represent Organizations and second level OUs could represent departments. The Geographic Tree hierarchy can be identified as shown in Figure 5.

Figure 5:

A potential OU Hierarchy within each Domain could be represented as follows:

Figure 6:

Advantages

• Domain Architecture not likely to change, as geographic boundaries are generally stable.

• Helps to optimize network traffic, as all intra-domain replication is constrained within a geographic region—and WAN is typically also modeled along geographic boundaries.

• Reduced hardware requirements (and associated capital and administrative costs). Geographies, regions or campuses that house multiple Organizations may be able to share Domain Controllers across Organizations.

• Consistent Domain Level policies across Organizations.

• Each Domain Controller maintains a full replica of a smaller portion of the enterprise—than the single domain model—resulting in faster logons, reduced hardware requirements and more manageable backup/restore.

• Reorganizations, acquisitions and divestitures of Organizations will not require Domain restructuring. Instead, OU restructuring can be performed in such cases, which is a much less expensive operation.

• User and resource transfers between organizations (yet remaining in the same geography) are much simpler to manage.

• Isolates language dependencies within a country.

Disadvantages

• Political implications in that administrators in different organizations must "share control" of a Domain. However, this can be partially mitigated with delegation of administration at the first level OU level.

• Security policies are applied at the geographic level, which may not meet unique business requirements for an Organization.

• Domain level policies are applied at the geographic level, which may not meet unique business requirements for an Organization. However, applying Organization Policies at the first level OU level can mitigate this.

Design Alternative 5 - Geographic Forest

A variation of the Geographic Tree model is the Geographic Forest model. Functionally, this model is very similar to the Geographic Tree model. The advantages and disadvantages of the Geographic Tree model apply to this model as well. The primary difference between the Geographic Tree and Forest is that in the Forest, the namespace does not have to be contiguous.

This is an unrealistic model. The reason for implementing a Forest vs. a Tree is to maintain (or implement) a disjoint namespace. Disjoint namespaces may make sense from an Organization perspective, but not from a geographic perspective. Consider a root domain of ORG1.COM and a child domain of NA.ORG1.COM. If we had another child domain representing Europe, why would it be named anything other than EU.ORG1.COM (or whatever abbreviation is selected to represent Europe)? There wouldn't be any reason to name it something like EU.ORGANIZATION1.COM, unless such a domain already existed and it was determined that namespace would be maintained.

The Geographic Forest will not be considered further at this time.

Design Alternative 6 - Multiple Forests

This model includes multiple Domains to form multiple distinct Forests. Although each Forest can be Organization or Geographic based, the likely motivation for creating such a hierarchy would be due to Organization naming or political issues. Hence, this section considers a Multiple Forest model, where each Organization deployed it's own Forest. Second level Domains and/or First and Second Level Organization Units can follow any of the models previously discussed.

The Organization Multiple Forest Model can be identified as follows. Note that there are no transitive trust relationships between the Organization Domains in this example. Explicit (Windows NT 4-style) trust relationships can be implemented as required to provide a certain level of cross-Forest security context.

A potential Multiple Forest hierarchy is shown below:

Figure 7:

Advantages

• Each Organization has complete ownership of their Directory.

• Each Organization can maintain it's own Directory Schema, meaning that Schema modifications are more localized and have less of an impact on the Enterprise.

• Pre-existing Forests can be incorporated into this model (for example acquisition of a company that already has Windows 2000 Active Directory deployed—or a grass-roots deployment).

• Divestitures can be handled more easily.

Disadvantages

• Contrary to Company A Guiding Principles.

• No cross-business security context by default, although Windows NT 4.0 style trusts can be explicitly added.

• No transitive trust relationships possible throughout the Company A enterprise.

• Reorganizations of Organizations will require Forest Reorganization—a very significant operation—especially in the initial release of Windows 2000.

• User and resource transfers between Organizations will be a significant operation.

• The Active Directory Connector will not provide full functionality in this configuration.

• No single enterprise-wide GAL for Exchange Platinum clients.

• Platinum servers will not be able to efficiently handle routing between Forests.

Domain Architecture Working Model

This section identifies an initial design for the Company A Enterprise Domain Architecture. It is fully expected that this will be an iterative design process and that the design will evolve over time. However, an initial design is being proposed that the design team believes best meets the Company A enterprise requirements—as they are understood at this time—while weighing the general advantages and disadvantages of the various architectures.

By identifying a specific Domain Architecture, the team has something that can be logically evaluated and specifically tested against when drilling down into specific detailed designs. The domain design in this section should be considered the target when considering all other aspects of the Windows 2000 design, including such things as DNS design, Administrative Model, Security Design, Software Distribution, Group Policies, Windows NT 4 Coexistence/Migration, Exchange Coexistence/Migration and so forth.

After evaluating the various Domain Architecture alternatives described earlier in this document (as well as a hybrid Geographic/Organization model), the initial target architecture is a Geographic Tree. The architecture makes the most sense for Company A based on all the advantages listed earlier (and summarized below) and for other reasons that are addressed in this section.

The following diagram depicts the high level view of the proposed Domain Architecture:

Figure 8:

The selected architecture is one that is based on stable geopolitical boundaries. The primary reasons for selecting this domain model are 1) minimization of intra-domain replication across geographies (and hence across the WAN) and 2) major cross-Organization IT datacenters are planned on a geographic basis.

A Top Level or Root Domain will be created to act as the root of the Tree from a namespace perspective as well as the Enterprise Root Domain to hold enterprise-wide resources and roles. There is currently no companya.com DNS zone that exists within Company A, so there is no conflict with any existing DNS namespace. This document contains more details on DNS below.

Specific domain creation criteria will need to be established, but the initial design identifies 3 Tier 1 (also referred to as First Level) domains which are based on the geographies that house the largest population of users and resources: North America, Europe and Asia Pacific. It is possible that additional Tier 1 domains will be created, but the current thinking is that a Tier 1 Domain will always represent a continental or geopolitical boundary. So, for example, it is conceivable that a domain is ultimately created for South America, but if so—it will be created as a Tier 1 Domain. Similarly, it is possible that a continent with a very large set of geographically disbursed resources might be split into multiple domains (such as Northeast US and Central US), but the initial position is that Active Directory Sites will be used for physically partitioning the Directory for replication.

Tier 2 (or Second Level) Domains may possibly be created where there is a significant user and resource population, and there is a local IT staff to support the Domain. No Tier 2 Domains have been identified yet, although two Tier 2 Domains have been shown in the diagram above for illustrative purposes. The current thinking is that Tier 2 Domains will represent Countries and will be named with the ISO 3166 two-character country code.

It is not currently envisioned that there will be any Tier 3 (or Third Level) Domains. The domain creation criteria will need to be sufficiently strong to justify creation of a Tier 3 Domain. Tier 3 Domains would likely be based on boundaries such as states or other geographic regions.

The Organizational Unit Hierarchy has not yet been defined, however it is currently envisioned that a multi-level OU Hierarchy will be defined that is consistent across every Domain. The OU Hierarchy will also be multi-tiered, with each Organization represented at Tier 1. The subsequent tiers of the OU Hierarchy will be defined based on the administrative model, application of policies, security model, delegation model and so forth.

The advantages of this model are reiterated below:

• The Domain Architecture is not likely to change, as the continental and geopolitical boundaries are stable. Splitting and consolidating domains is not trivial.

• Helps to optimize network traffic, as all intra-domain replication is constrained within a geographic region—and the WAN is also modeled along geographic boundaries. For example, major locations in the North America domain will be connected by significant network links (T3 or better).

• Reduced hardware requirements (and associated capital and administrative costs). Geographies, regions or campuses that house multiple Organizations will be able to share Domain Controllers and Global Catalog Servers.

• Consistent policies (including security policies) can easily be applied across Organizations.

• Organization reorganizations will not require Domain restructuring. For example, a merger of ORG1 and ORG2 would still result in the merged organization having users and resources in the same geographies. This might result in OU restructuring, but this is a trivial operation as compared to domain restructuring.

• User and resource transfers between organizations (yet remaining in the same geography) are trivial to manage. Again, this could be handled with moving users and resources between Organizational Units in the same domain.

• Isolates language dependencies within a geographic region. Administrators in a geographic region typically share the same language requirements, which allows all administrators in the domain to utilize the same language for administration.

• Ensures a consistent schema across the enterprise.

• The potential disadvantages of this model are reiterated below:

• There was originally a concern that there would be political implications in that administrators in different Organizations must "share control" of a Domain. This will not be an issue based on the shared datacenter model that is being considered for Company A.

• Security policies are applied at the geographic level, which may not meet unique business requirements for an Organization. This will not be an issue; in fact, this turns out to be an advantage as it provides Company A the opportunity to implement consistent security policies across the enterprise, including Account Lockout policies, Password strictness and Aging, Kerberos Ticket lifetimes, and so forth.

• Domain level policies are applied at the geographic level, which may not meet unique business requirements for an Organization. Applying Organization Policies at the first level OU can easily mitigate this.

• Divestiture will be relatively painful. There is simply no easy way to prune a domain from one forest and graft it into a different forest. More on this below.

Divestiture

Divestiture of an Organization from Company A is an issue that was considered when coming up with the initial Domain Architecture. Forest-split is simply not a feature that is inherent in the initial release of Active Directory. Therefore, the required Forest and Domain reorganization that would be necessary for a divestiture would be non-trivial for any single Forest solution. The only architecture that easily and natively supports divestiture for the initial release of Active Directory is the multiple Forest model. However, the multiple Forest model has been dismissed as an option, based on all of the disadvantages that have been enumerated earlier in this document.

So, how would a divestiture be handled in a single Forest model? Initially, this will need to be handled in a brute force fashion. A new Forest will need to be created and the users and resources (and permissions) from the original Forest will need to be moved to the new Forest. Some tools will exist that can be used to assist, but it will still not be trivial. For example, the contents of the Domain(s) that need to be split off can be exported in an LDIF format and then re-imported into Domain(s) into the new destination Forest.

This process of splitting off resources into a separate Forest would be significant independent of which single Forest model was implemented. For example, it would be no more painful for a Geographic Tree model than it would be for an Organization Tree model. Actually, it might be slightly more complex, but not significantly more complex. If the brute force method were used in an Organization Tree model, then entire Domains could be exported and then re-imported into the new Forest. If the brute force method were used in a Geographic Tree model, then only portions of Domains would be exported and then re-imported. The filtering of the appropriate resources should be a relatively trivial operation, however.

Physical Architecture

At this point we have only touched on the physical topology implications of this design. Active Directory Sites will be used extensively to physically partition the enterprise directory and to provide a sense of "nearness" when locating network resources. Initially, it is anticipated that at least 4 major datacenters will exist that are providing cross-organization IT services. Each of these datacenter locations would be considered an Active Directory Site. In fact, each of these locations might consist of several Active Directory Sites.

A detailed Site Architecture will be developed which identifies specific Active Directory Sites, as well as identifying site creation criteria. For example, regional IT Hubs would likely be considered their own Active Directory Sites. Branch Offices would likely be considered their own Active Directory Sites.

Domain Controllers and Global Catalogs will need to be strategically located throughout the physical locations. Remember that a user needs to contact both a DC from its home domain as well as a GC in order for network authentication to succeed. DC's for each Tier 1 Domain will certainly be placed in the major sites (datacenters) within those corresponding Domains.

DCs and GCs will also be strategically placed at other (non-datacenter) sites throughout the world. Various factors will be taken into account when determining the placement of these servers, including number of users that will be logging on a the location, domain(s) that will be used for logon, bandwidth to nearest datacenter or IT hub that already houses a DC/GC, load on those DCs, size of Domain Database, and so forth.

The initial thought is that Domain Controllers from every Active Directory Domain will be located in the major physical sites across the globe. This will allow roaming users to get authenticated locally when traveling. However, it's probably not necessary to place Domain Controllers from every Domain in every site in the world. The initial thought is to place Domain Controllers from every Domain in at least the major datacenter sites.

DNS Implications

As stated earlier, a new, internal-only DNS domain will be used for the root of the Tree: companya.com. Since this zone is not currently being managed by any DNS servers in Company A, nor is it a child domain of any DNS domains that are currently in existence in Company A, we can start with a clean slate. We will not have to support the Active Directory namespace with any existing DNS Servers (for example BIND or Windows NT 4). Nor will we have to delegate a child zone from any existing DNS domains. We can start with a new root DNS Domain, and we can use the Microsoft Windows 2000 DNS to manage that zone.

There does need to be a level of interoperability between the existing DNS infrastructure and the new DNS infrastructure. Currently, a single DNS domain hierarchy does not exist within Company A. Some Organizations work off the .com root and others work off of their own private root. Even the companies that use the .com root are not tightly integrated, as those child domains are not delegated from a common parent. However, name resolution is possible across the Organizations using a common set of servers (let's call them the Enterprise DNS Servers) that act as secondaries to the entire top level Organization zones, and the use of Forwarding statements. A detailed discussion of the current DNS design is beyond the scope of this document, but the key point to take away is that the Enterprise DNS Servers are authoritative (as secondaries) for all of the top level Organization DNS zones.

In the new Active Directory environment, we're going to have a set of DNS zones that are completely separate from the existing DNS infrastructure. However, it will certainly be necessary to provide name resolution across the entire Company A namespace. For example, a user in the Namericacompanya.com domain will need to perform name resolution for that domain, as well as it's parent domain (companya.com) and perhaps even it's peer or children domains. The DNS servers that manage companya.com zone (and any child zones) will be able to perform the resolution for the entire companya.com domain. However, you can expect that this user in Namerica.companya.com might also need name resolution to one of the "legacy" DNS domains as well. For example, there might be some intranet Web servers in ORG3.COM that need to be accessed.

Similarly, a user that still exists in the legacy environment will certainly need name resolution for servers in those legacy DNS domains, and possibly would need name resolution for servers in the new Active Directory DNS domains. For example, during the coexistence period some services are going to be moved from the legacy environment to the new environment (for example an intranet Web server might be migrated to the new Windows 2000 environment). In this case, the legacy user would require DNS resolution to the service in the new environment.

One way to provide enterprise-wide name resolution to resolvers in either environment is to manually update the DNS servers in both environments, as one might do in a "split DNS" environment where you have different DNS records for the same DNS zone on each side of a firewall. This approach is manually intensive and problematic, however.

The current thinking is that we can "bridge" the new companya.com domain with the legacy domains in the same manner that the Enterprise DNS Servers are currently being bridged with the existing top tier DNS Servers in each Organization. Simply put, the Enterprise DNS Servers will act as a secondary master for the companya.com zone by performing a zone transfer from the companya.com DNS Servers. In addition, the companya.com DNS Servers will act as secondary masters for each of the Organization top tier DNS zones, by performing a zone transfer from the Enterprise DNS servers. This obviously needs to be fleshed out in the DNS design, but at this point we're confident that this will work.

Note that the implementation of this technique will be handled most easily if we have a single DNS Domain for the Active Directory. If we had multiple non-contiguous DNS Domains for the Active Directory, then we'd have to implement the "bridge" to each of these Active Directory zones. (Note: A single DNS Domain means that we have a completely contiguous namespace. We may have child zones, but they are contiguous with the single root zone. Another way of stating this is that we have a single tree as opposed to a forest of multiple trees.) So, this all leads to the point that if we have a single Tree in the Active Directory, then it will be simpler to implement the bridge. If we had multiple Trees in a Forest, or multiple Forests, it would be complex to implement the bridge.

One other note about DNS in this environment. We have been working under the assumption that the FQDN for a host in an Active Directory domain will have the same Domain name as the Active Directory domain in which it is a member. For example, an IIS server that's a member server of the namerica.companya.com domain might have a FQDN of webserver.namerica.companya.com. However, there is a possibility that in Windows 2000 you can have host be a member of an Active Directory domain, yet have it's FQDN refer to a different DNS domain. For example, that same IIS server might still be a member of the namerica.companya.com Active Directory domain, yet maintain it's legacy FQDN of webserver.org3.com. This is a feature that's still under consideration for inclusion in the initial release of Windows 2000 as to whether or not this would be supported or not.

Next Steps

As stated earlier, we now have a starting point that we can target as we move through each of our more detailed designs. Every time we develop an architecture or design for the Windows 2000 project, we should do so with this Domain Architecture in mind. We should clearly identify and understand the implications that all other designs will have on the Domain Architecture. The design areas that are of most importance with respect to the Domain Architecture are summarized below:

• Domain Creation Criteria

• More complete Tier 1 Domain Design and Tier 2 Domain Design

• Organizational Unit Creation Criteria

• Organizational Unit Hierarchy Design

• Site Creation Criteria

• Site Design

• DNS Design

• Naming Standards

• Replication Connector Criteria

• Replication Design

• Group Strategy

• Group Policy Strategy

• Software Distribution Strategy

• User Profiles Strategy (including Roaming)

• Client Side Caching Strategy

• Remote Boot Strategy

• Server Design Standards

• Backup/Restore and Disaster Recovery Strategy

• Administrative Model

• Security Policy

• Kerberos Design

• PKI Design

• WINS Interoperability

• DHCP Design

• Windows NT 4 Domain Coexistence and Migration Strategy

• Exchange Coexistence and Migration Strategy

• NetWare Coexistence and Migration Strategy

Related Links

See the following for further information:

• Microsoft Active Directory home page.

For the latest information about Windows 2000 Server, see the Windows 2000 Server Web site.