Planning a Domain Structure

Once you've settled on the overall design of your namespace, you need to design your domain structure to support it. Each branch of the namespace breaks down to either a domain or an organizational unit (OU). Whether a branch is a domain or an OU depends on a variety of considerations, including the need for replication, security policy, resource availability, quality of the connection, and so forth.

Domains vs. Organizational Units

Windows 2000 network trees are made up of domains and organizational units. Each provides for administrative boundaries between branches on the tree, but they have different implications and resource requirements.

Domains

The core unit of the Windows 2000 Active Directory is the domain, just as it is in Windows NT 3.x and Windows NT 4. All network objects exist as part of a domain, and the security policy is uniform throughout a domain. Unlike Windows NT, Windows 2000 security is based on Kerberos version 5, and the trust relationships are transitive. In transitive relationships, if domain A trusts domain B and domain B trusts domain C, then domain A also trusts domain C.

One-way Windows NT 4-style trust relationships can still be set up. More important, the relationships between Windows 2000 domains and legacy Windows NT domains are based on the one-way, nontransitive trust relationships inherent in Windows NT. It is essential that you consider these relationships when planning your domain structure.

With Windows 2000, the concepts of primary domain controller and backup domain controller are finally history. Domain controllers in Windows 2000 are multiple master and peer based. Each controller of a domain has identical authority over the domain, and if any controller goes down, the others continue to administer and authenticate the domain. Any domain controller can originate a change to the domain and then propagate the change to the other domain controllers in the domain.

The domain is also the unit of replication. Changes in the domain are replicated throughout the domain, even when the domain spans multiple sites or locations. This capability allows domain controllers at distant sites to originate changes to the domain and have the changes replicated across the domain.

Whereas access rights are transitive across domain boundaries, administrative rights are, by default, limited to the domain. This allows you to grant administrative rights to a key user in a particular domain without worrying about compromising the overall security of the organization, as the administrative rights stop at the domain boundary unless explicitly granted to other domains.

Organizational Units

The OU concept is new to Windows 2000. It has some of the characteristics of an Active Directory domain, but without the resource overhead of one. An OU is contained within a domain and acts as a container for directory service objects. It forms a branch of the contiguous DNS namespace, and it can in turn contain other OUs. Thus, the domain corp.microsoft.com can contain other domains within the DNS namespace, such as finance.corp.microsoft.com, and it can also contain OUs such as hr.corp.microsoft.com. The OU provides a convenient administrative boundary, and rights and privileges for administration can be granted to users in an OU without compromising the rest of the domain. However, an OU does not require a separate domain controller, nor is it involved in replication.

The closest analogy to an OU from the Windows NT domain model is the resource domain, but without the domain controller overhead that was required under Windows NT. In cases where there is no particular need for a separate security policy for a given administrative container, the OU provides an appropriate and less resource-intensive boundary. Moreover, in case of need, an OU can be easily promoted to a domain.

Designing a Domain Structure

Once you have designed your namespace and everyone involved has signed off on it, you're ready to start designing and implementing your domain structure. The design of your domain structure will closely match the design of your namespace, although you might make a decision that certain namespace boundaries require only OUs, not full domains. Your choice between an organizational unit and a domain should be based on whether you need a separate security policy for the entities within the namespace boundary. If a particular namespace boundary will not require a security policy that is different from that of its parent, you will probably find an OU to be an appropriate division, as it requires fewer resources to implement. As mentioned earlier, you can easily promote an OU to a domain later if that becomes necessary.

Designing a Tree Domain Structure

If you'll be creating a single, contiguous namespace and therefore a pure tree domain structure, you'll want to create the domains in hierarchical order, starting at the top of the tree. The first domain will be your root domain and will, most likely, have either all of the users in it (for smaller, single-domain models) or no users at all (if you use a structural domain as the root domain). For those familiar with the Windows NT 4 domain models, this pattern very roughly corresponds to the single-master domain model, with one important difference. Users need not (and most often should not) reside in a single master domain, but should reside in their actual appropriate place in the domain structure.

As you branch down the tree of your namespace, you create domains or organizational units for each branch of the tree. The decision about whether to create an OU or a domain depends on your overall security model, the quality of the connection to the location, and a variety of other factors, including political considerations from the original namespace planning. If you're in doubt at any point, simply create an OU—it's easy to upgrade the OU to a domain later.

Designing a Forest Domain Structure

The forest of trees structure is most often used to accommodate an existing namespace that is noncontiguous and can't easily be made contiguous. You'll end up with multiple root domains, all on the same level. Below each of these root domains, you'll have a contiguous namespace for that tree. Each branch of the namespace is either a domain (with its attendant requirement of one or more domain controllers) or an organizational unit. You'll generally create each tree from the top down, and each branch of the tree automatically has a transitive trust relationship with the other branches of the tree.

The trees in the forest share the same schema, configuration, and Global Catalog, with transitive Kerberos trust relationships among all members of the forest. The trust hierarchy within each tree follows the naming hierarchy. The trust hierarchy in the forest as a whole, however, follows the order in which trees are joined to the forest. This fact is transparent to the users but can be manipulated by the administrator to improve management and referrals.

Domain Security Guidelines

Within each domain, the security requirements, policy, and configuration are consistent. If you need to change the security requirements and policy for a subunit within a domain, you'll need to create that subunit as a domain, not an OU. Keep this limitation in mind as you plan your overall namespace—you'll need to have a separate branch of the namespace to have a separate security policy.

What is meant by security policy? What sorts of things does it entail? Chapters 18 through 20 deal exclusively with security matters, so for the moment, we'll take a summary view. The security policy includes the following:

• Logon requirements
• Certificates
• Password aging and minimum length requirements
• Smart card or other authentication add-ons
• Machine and time-of-day restrictions

Many of these things are comfortably the same throughout your organization, but there might be certain areas that require significantly greater security than that needed in the rest of the organization. If so, plan for areas that require extra care to be in a separate domain so that their more restrictive security won't be imposed on the entire organization.

Creating Organizational Units

In situations where you don't need to create separate domains for security reasons but do want to maintain a separate level in the namespace, you'll create a separate OU. Thus, you might have a domain called noram.microsoft.com that you want to divide into business units within the region. You could create separate sales, support, education, human resources, manufacturing, and finance domains under noram.microsoft.com. However, the overhead of separate domains (and their required controllers) for each of these units isn't necessary—especially because they all share a single security policy. Simply create OUs for each of them. If you later decide to upgrade one or more of them to a domain, you can do it easily.

Organizational units make useful boundaries for administrative purposes. Various administrative tasks and privileges can be delegated to the administrator for a specific OU, freeing up the domain administrator and giving the OU local control of its own resources.