Planning for Active Directory

You can find no end of articles and white papers and even books emphasizing the importance of proper planning before implementing Windows 2000 Active Directory (AD) in your infrastructure. Indeed, if you think AD is just an incremental change from the way you do things in your existing Windows NT 4.0 domain environment, you're in for an unpleasant surprise. A directory service such as AD significantly increases the manageability and complexity of your network infrastructure. Far from being just an extension of NT 4.0 domains, AD provides features such as delegated administration and Group Policy-based desktop management and could even serve as a critical business platform for developing directory-enabled applications. Proper planning of this infrastructure is not only crucial, it's required. Let's look at some of the technical considerations and challenges involved in planning an AD implementation—from laying out your namespace to designing a replication topology.

The Logical Namespace
Planning an AD infrastructure starts with deciding how to lay out your namespace (i.e., how to organize your network resources within AD). In NT 4.0, your namespace choices are simple and few. Domains support only two levels of hierarchy, no delegation boundaries exist within a domain, and NetBIOS doesn't support hierarchical naming. With the advent of AD—a hierarchical directory service based on X.500 concepts and using DNS for its name service—your choices are much more complex. The AD namespace has three main tiers: domains, domain trees, and forests.

Domains. A domain is the security boundary in AD, just as it is in NT 4.0. An AD domain shares a common security policy and the same security groups, such as domain local and global groups. A domain is also a replication boundary—AD replicates Domain A objects only to Domain A domain controllers.

Domain trees. Win2K introduces a new concept: the domain tree. A domain tree is a hierarchy of domains that are part of a contiguous DNS namespace. For example, the top-level domain mycompany.com might have two child domains: east.mycompany.com and west .mycompany.com. The three domains form an AD domain tree. Mycompany .com might also create the subsidiary yourcompany.com and build a separate domain tree with the DNS namespace yourcompany.com.

Forests. Forests are another new AD feature. A forest is a collection of one or more domain trees that share a schema and a Kerberos security boundary. Each forest can have only one schema, which defines AD's objects and properties. Transitive Kerberos trusts connect all domains within a forest. A forest treats domains outside itself the same way NT 4.0 domains treat one another with respect to trusts. So, if you build two forests in your enterprise and want to share resources between them, you must use old-style NT 4.0 nontransitive trust relationships to do so. In addition, you currently can't merge two forests.

Figure 1 shows the relationships between domains, domain trees, and forests in AD. Note the 2-way Kerberos transitive trust in place between my company.com and yourcompany.com. A distinguishing feature of AD is that transitive trusts connect all domains within a forest.

Designing the logical namespace is an exercise in deciding how many domains, domain trees, and forests you need and how to name them. If you have an existing NT 4.0 infrastructure, you must also decide whether to reproduce or improve that domain structure in the new namespace. Given AD's ability to delegate administration through organizational units (OUs), you should need far fewer domains in Win2K than you do in NT 4.0. In addition, the need for a new domain is driven less by the need to delegate administration and more by replication and security concerns (I discuss these concerns shortly).

Factors other than your existing NT 4.0 domain model will influence your namespace design. As you go through the process of deciding how many domains your AD implementation requires and whether you need one or more domain trees or forests, you must also consider political and organizational factors, geographic factors, and technical factors.

Political and organizational factors. Will your namespace design respect and preserve your organization's existing political boundaries? If not, you might quickly learn that the fewer domains you want to have, the greater your diplomatic skills must be. Don't underestimate the political ramifications of collapsing several existing domains into one.

Your AD namespace design should attempt to "abstract" the organization so that the namespace can weather the vagaries of frequent organizational reshuffling. For example, if much of your East Coast sales department becomes part of the West Coast sales department, you shouldn't need to move OUs or users across domains. Rather, you should be able to simply switch users from one user group to another. Another factor to consider is that Win2K makes it difficult, if not impossible, to rename domains and absolutely impossible to rename the forest root domain. So, if your namespace depends on the ability to change domain names, you'll need to reconsider your approach.

The technical support model that your company uses—centralized or decentralized—affects your OU design. To create more granular delegation, you can either build more OUs or use security groups within an OU. If you choose to build more OUs, you potentially increase your effort each time you need to make a change that applies to all OUs and you increase the complexity of your AD namespace. Using security groups to control delegation requires you to thoroughly understand the AD security model and doesn't give you as clear a picture onscreen of where delegation lines are drawn as separate OUs do.

Geographical factors. If you work for a large multinational company or a company with multinational aspirations, try to design your namespace with an eye toward how your AD might grow across national borders. How will you handle new acquisitions or separate support organizations?

Technical factors. Microsoft has done a reasonable job of implementing a full-featured directory service in Win2K, but some technical challenges remain that will point your AD namespace design in one direction or another. I will detail some of these shortly, but for now, be aware that you should have a good working knowledge of AD's limitations before designing your namespace.

You might also find yourself designing around certain Win2K features. For example, the way you use Group Policy Objects (GPOs) might influence how you implement your AD namespace. At the very least, before you finalize your namespace decisions, you should know how Group Policy functions and how it might affect your design.