Planning for Active Directory

Domains and Forests—One or Many?
I've heard people talk about the nirvana of one AD domain for an entire enterprise. Some might indeed achieve this dream in Win2K, but if you don't anticipate getting there anytime soon, don't worry. Just keep the following multiple-domain design considerations in mind.

Keep the forest root empty. If you plan to have multiple domains, you might want to keep the forest root (the first domain you build as an infrastructure container) free of production users. Because this domain has a special role in your infrastructure—housing the Enterprise Admins and Schema Admins groups—reserving it for a few trusted administrators is common.

Limit trips to other trusts. When users access resources in a domain other than the one they belong to, they traverse a trust relationship (even in Win2K) and incur a performance penalty. Thus, a multiple-domain design that requires users to make frequent trips across trust relationships can slow response time, especially if you create GPOs in one domain that users must link to from another domain. To mitigate performance concerns in a large forest, you can create "shortcut" trusts between frequently accessed domains to reduce the number of hops a cross-domain communication needs to make.

Define a security policy for each domain. The domain is still the security boundary in Win2K. Thus, you must explicitly define any security policy (e.g., account lockout behavior, password length) in each domain—don't define the policy for one domain and expect that policy to protect all domains.

Limit replication between domain controllers. Because the domain is a replication boundary, you might also need to consider creating new domains to limit the amount of data replicated between domain controllers—especially across slow WAN links. You can control data replication to some degree through your site design (I describe how later), but you might need to partition really large domains in any case because of network bandwidth constraints.

How many forests you should have is an easy question to answer. In almost every case, you should be driving toward one forest in your production AD infrastructure. (You might also have a test or development forest that you use to test changes to AD.) The reasons behind striving for one forest are pretty straightforward. Win2K today offers no easy way to integrate multiple forests within an environment. Remember that a Win2K AD forest shares a common schema, a common Global Catalog (GC), and common Kerberos security trusts. If you build a second forest, it's a completely foreign environment. You must build explicit, nontransitive, NT 4.0-style trusts to allow sharing between the two forests.

Sizing Domain Controllers
After you settle on the namespace's logical layout, the next step is to figure out how to physically implement the design. This task isn't as trivial as it might sound because at the physical level, you need to consider factors ranging from your domain controllers' hardware requirements to the site topology for AD replication. Along the way, you must ensure that your physical implementation takes into account AD's current limitations. Last, you need to consider your DNS implementation. DNS server availability is crucial to proper functioning of AD replication and client logons.

When sizing your AD domain controllers, you might ask yourself: How big is big enough? If you decide to collapse 10 NT 4.0 account domains comprising 100,000 users into one AD domain, chances are that each domain controller in the new domain needs more horsepower and disk space than it previously required. But how much more? Microsoft provides a tool for quickly determining your domain controller requirements; see the sidebar "Active Directory Sizer," page 60, for more information.

Each new AD object you create requires some disk space on the domain controller. (The main AD database file, ntds.dit, resides on each domain controller in a domain.) The more objects— and the more object attributes—the larger your AD database will be. AD is much more scalable than an NT 4.0 domain. However, an AD database also consumes much more disk space than the NT 4.0 SAM because AD includes many more object types (e.g., volumes, Group Policies) and because AD objects can have many attributes (e.g., user objects can contain phone numbers, addresses, and email addresses). I upgraded an NT 4.0 domain containing roughly 3000 user accounts and machine accounts and several hundred user groups, and the resulting ntds .dit file was approximately 38MB. Using the AD Sizer tool, I estimated that an NT 4.0 20,000-user domain with multiple extended attributes (and that included the use of Microsoft Exchange 2000 Server) would translate to a 500MB ntds.dit file. Multigigabyte ntds.dit files are common for large or complex AD domains.

Table 1, page 61, shows the typical size of a few different types of AD objects. A user object with the minimum number of attributes is 3.7KB. If you use the AD Users and Computers Microsoft Management Console (MMC) snap-in to create a user, the snap-in sets the minimum attributes, but you'll probably use many other attributes in your AD objects (especially if you plan to implement Exchange 2000).

Some less-obvious practices also affect AD size. For example, each access control entry (ACE) on an AD object's security ACL consumes about 70 bytes. Given the inheritance model that AD uses when applying security, you can easily make an ACL change that automatically adds new ACEs to thousands of objects. Be careful as you delegate control of AD objects in your infrastructure. When possible, delegate to groups of users rather than to individual users. This approach minimizes the number of ACEs a particular object or attribute requires.

Sites and Site Links
Designing a site topology is perhaps the most challenging part of planning an AD implementation. Before you begin designing, you need to be familiar with the AD concepts of sites and site links, naming contexts, the GC, and connection objects. Sites are AD objects that determine how AD replicates data across your network. Sites are associated with subnet objects that you define, and subnet objects correspond to the TCP/IP subnets in your physical network.

Sites control when and how often domain controllers replicate with one another. Domain controllers within a site (i.e., intrasite) replicate with one another on a fixed schedule—every 5 minutes by default. Domain controllers across sites (i.e., intersite) replicate on a schedule that you decide upon—but no more frequently than every 15 minutes.

In addition to grouping domain controllers for the purpose of scheduling AD-information replication, sites help workstations and member servers locate resources that are physically close on the network. For example, a workstation authenticating to an AD domain first examines its own IP address and subnet mask to determine which subnet it's on. Having determined its subnet and its site (through a query to AD), the workstation queries DNS to find a domain controller in the same site.

Sites belong to site links—groups of sites in which network connections of roughly equal bandwidth link the sites. For example, Figure 2 shows a company with four regional distribution centers. Each of the centers has a high-speed LAN connecting multiple workstations and domain controllers. A T1 line connects each center to each of the other centers. Each center is a site, but the AD administrator has placed them in the same site link in this case because the connections between the sites have the same bandwidth. When you define a site link, you can specify a schedule for the sites within that site link and a cost. The schedule controls how frequently (and at what time) replication occurs between sites in the site link, and the cost is an arbitrary value you assign to the connections between the sites.

All sites in a site link replicate with one another on the same schedule. A site can belong to multiple site links, which is where the cost metric comes into play. In the distribution center example, you might add "dial-on-demand" links between two of the centers as a failover precaution. You could build a new site link that includes the sites these two distribution centers represent and give it a higher cost than the T1 site link that includes all the distribution centers. This action gives AD replication two paths between the two distribution centers: the lower cost T1 paths that the sites usually use and the higher cost dial-up paths that the sites use when the T1 lines are out of order.