In the first Daily Drill Down of this series, you learned that Active Directory is Microsoft’s answer to directory services. You also learned that a directory service offers a means of organizing and searching objects, including network resources such as servers and printers.

AD in Windows 2000 does much more, serving as the repository of data that controls and enables authentication and security. It provides for simplified and decentralized administration by enabling you to categorize and classify resources (such as servers) as objects in AD, then apply permissions to those objects to control the tasks that individuals and groups can perform on the object. In short, AD is the cornerstone of Windows 2000 networking and security. Think of it as a directory that houses data about your entire network infrastructure, resources, and users.

While you don’t need to know the inner workings of AD in order to implement it, you do need to understand its components and their functions, as well as how AD affects the Windows 2000 domain structure. To understand AD and how it will impact you, you should first understand domain structure in Windows 2000.

A walk in the forest
While this series of Daily Drill Downs deals primarily with Active Directory, you can’t discuss AD without discussing domains. After all, one of the primary functions of AD is to house your domains. So, an important concept you need under your belt before you delve too deeply into AD is the way domains are structured in Windows 2000, which is different from how they’re structured in Windows NT. Explaining the entire domain analysis and design process would take several Daily Drill Downs in itself, so we’ll focus on just the key points.

The best way to understand the Windows 2000 domain structure is to start not at the individual domain level, but at the top and to think of the domain structure in terms of a namespace, much like DNS. Like the DNS namespace, the domain structure is an inverted tree. At the top of the structure is the top-level domain, or root domain. Once created, the root domain can’t be renamed, deleted, or changed—an important consideration you’ll learn about shortly.

The domain structure can grow down from the root domain much like the DNS namespace. The root domain can have any number of child domains, each of which can have their own child domains. And like the DNS namespace, a domain can have only one parent ( can’t fall under both the com and org domains, for example). Figure A illustrates a sample domain structure using root as the name of the root domain.

Figure A:
This sample domain structure has at the root.

Domains under a root domain form a domain tree. While domains can have only one parent domain and ultimately one root domain, AD can contain multiple root domains. Each root domain and its underlying child domains represent a domain tree, while a collection of domain trees in AD that share the same schema, configuration, and global catalog represent a domain forest. The ability to create multiple trees offers considerable flexibility in domain structure, as illustrated by Figure B. If your company buys a competitor or opens a new division, for example, you can easily integrate its domains into your AD as a new tree.

Figure B:
AD can contain multiple domain trees in a domain forest.

Just as a tree has a root domain, so does the forest. This might seem confusing since the forest root domain isn’t directly linked to all domain trees. Think of the root domain as the archetype for the forest. This forest root domain defines the schema and configuration for the forest and also determines trust relationships between trees in the forest, which you’ll learn more about later. The root domain of the first domain tree created in AD serves as the forest root domain. It is not only the physical root for the first tree, but it also serves as a pattern for other domain trees to come.

Naming your root domains
A domain tree represents a contiguous namespace. All subdomains are named within the context of the root domain. For example, with the root domain named, the tree might contain the domains,,, and so on.

A forest does not represent a contiguous namespace, as each tree has a uniquely named domain root. It’s therefore possible for two domains in different trees to have the same local domain name, as the domain names resolve uniquely in the context of the forest. Assume that you have two trees in the forest, the first rooted at and the second at You could have domains named support in both, which would resolve uniquely to and

Have you noticed that the example domain names up to this point bear a striking resemblance to DNS names? While there is no direct correlation between Internet domains and Windows 2000 domains, you should still take Internet domains into consideration when designing your domain structure and root domain name, whether your organization has an Internet presence or not. Here’s why.

Assume that your company has an Internet presence now, or at least has registered its own Internet domain or plans to in the future. We’ll use as an example in explaining domain structure and critical design considerations. The company has both an external identity and an internal identity. The external identity is the Internet domain The internal identity is the company’s internal LAN, which may or may not have any relationship to the Internet presence. The root domain could be the same for both— Under that domain, you can create child domains as needed, such as a domain structure for the internal LAN and another structure for the Internet domains, including its subdomains. The result is a domain tree.

You don’t have to use your Internet domain as the root AD domain, however, and there are several reasons not to do so, including the following:

  • You might want to maintain a logical separation between your Internet presence and intranet.
  • Domain names are a hot commodity today and acquisitions happen all the time. Since you can’t rename your root domain after you create it, using the Internet domain as the root AD domain can cause problems down the road if you change your Internet domain name, sell the domain, or are acquired by another company.
  • It’s much easier to configure proxy services for the intranet and Internet if the namespaces are separate.
  • Perhaps you don’t have an Internet domain at the moment or are not using it, but you’ve acquired the domain name only to protect it for future use.

Taking all these things into consideration, Figure C illustrates a domain structure that takes the Internet into account.

Figure C
Here’s a sample domain structure for a company with an Internet presence.

In this domain structure, the domain functions as a DNS domain rather than an AD domain. The domain sits outside the firewall and outside the structure of AD, functioning like any other Internet domain resolved through the DNS namespace. On the inside of the firewall is AD and the internal domain structure, with the root domain named (or we could simply name it root and drop the suffix for simplicity).

Another approach is to create the Internet and intranet domains as separate trees in the forest, as illustrated in Figure D. This allows you to use whatever naming scheme you wish for the intranet, keeping it separate from the Internet side. This naturally requires separate domain controllers (DCs) for each domain, but that’s probably a good thing—you’ll get better security and probably better performance by separating the two.

Figure D:
The intranet and Internet domains are separate trees in the domain forest.

Whatever domain structure you ultimately choose, you have a lot of work to do analyzing your existing domain and organizational structure and determining the best domain structure to accommodate it. You can perform that function without knowing a great deal about AD, since AD is simply the mechanism through which you’ll implement your domain plan.

Windows 2000 domain controllers
If you’re a Windows NT Server user or administrator, you’re no doubt familiar with the domain structure in NT. One domain controller functions as the primary domain controller (PDC). All other DCs in the domain function as backup domain controllers (BDCs). The PDC synchronizes its domain data with the BDCs on a regular basis and the domain can be synchronized manually as well. If the PDC fails or goes offline for some reason, a BDC can be promoted to take its place.

In the Windows 2000 AD-based domain structure, all DCs are peers. The DCs contain and manage AD, which serves as the database by which the DCs authenticate users, manage access control, and perform many other services and functions. In effect, DCs in AD function as a cluster, automatically synchronizing and replicating AD across all of the DCs in the domain.

The replication is transparent, although you can control how often replication occurs. This control enables you to control bandwidth usage between DCs in the domain. The automatic nature of the replication helps ensure that the DCs are always in sync and are able to service client requests and minimizes administration problems by replicating changes made at any DC to all other DCs.

When trying to understand AD and how it relates to domains, don’t constrain yourself to equating AD with just one domain. AD stores information about all domains in the forest, not just a single domain. Each DC maintains a copy of its own part of the forest (its own domain) and data about other domains or other elements of AD. However, it’s important to understand that while future versions of AD might allow a single server to host multiple domains, for now a DC can host only one domain.

Domain trust relationships
Another important difference between Windows NT domains and Windows 2000 domains lies in trust relationships. In a trust relationship, one domain trusts the authentication mechanism of all other trusted domains. For example, if a user is authenticated by domain A, and domains B and C trust A, then B and C will both accept A’s authentication of the user without requiring their own authentication. The access that users from a trusted domain have in the trusting domain depends on the access controls in effect in the trusting domain.

In Windows NT, trust relationships do not exist by default and are unidirectional. If you want A to trust B and B to trust A, you must explicitly create two trust relationships, one for each direction of trust. Trust relationships are not transitive in Windows NT. A might trust B, and C might trust B, but that doesn’t mean that A trusts C.

In Windows 2000, however, each domain has a bidirectional trust relationship with its parent domain. In addition, each root domain has a transitive trust relationship with the forest root domain. Windows 2000 trust relationships are transitive, which effectively means that all domains in a domain forest share transitive trust relationships. Domain D1 trusts domain D2, and vice versa. This trust is automatic in Windows 2000. In Windows NT, you would have to explicitly create trust relationships between the two domains.

This automatic, transitive trust simplifies trust administration since you don’t have to set up or manage trust relationships manually. However, automatic transitive trusts also mean you must consider the trust relationships and their ramifications when you design your domain structure.

In situations where a transitive trust is not appropriate, you can explicitly create a nontransitive trust relationship. Because of the nature of a Windows NT trust relationship, a trust relationship between a Windows 2000 and a Windows NT domain is nontransitive. If needed, you can explicitly create a bidirectional trust between them by creating two unidirectional trust relationships, just as you would between Windows NT domains.

Back to the AD structure
Now that you have some background in Windows 2000 domain structure, we can get back to AD and its structure, starting with a key ingredient—the Global Catalog.

The Global Catalog
An important part of AD’s structure is the Global Catalog, or GC. The GC is the mechanism through which searches occur in AD and therefore is critical to all AD functions including authentication. In the simplest terms, the GC functions much like a key database that simplifies searching AD. The GC contains a full writable replica of all objects in AD for its host domain. It also contains a partial, read-only replica of the other domains in the forest. This read-only replica contains a copy of all objects in the domain forest, minus all but the attributes useful for searching. In essence, the GC serves as a flat database of the objects in the forest that enables quick location of any object in the directory—it’s the directory’s directory. The GC is built automatically by AD’s replication mechanisms.

By default, the first DC in a domain forest is designated as the GC server. Status as a DC does not equate to being a GC server—the only DC that functions by default as a GC server is the first one in the domain forest. Other DCs that come online do not function as GC servers unless you configure them as such.

Why configure a DC to act as a GC server? Redundancy is the primary reason, and availability is a close second. Since a GC server is necessary for authenticated logon, it’s a good design practice to include a GC server at each site, particularly when the domain spans a wide area with links susceptible to failure. Having a local copy of the GC enables users to log on through AD if the link to the other GC servers is down. If the GC is unavailable, Windows 2000 uses cached credentials for the logon.

As you begin planning your domain structure and AD implementation, keep in mind the GC’s function and decide how you’ll provide redundancy. Plan on providing additional GC servers where necessary, even if your network will comprise only two DCs.

A site is an AD object that represents a network location or group of network locations, identified by one or more TCP/IP network segments. In abstract terms, a site is a network location that contains AD servers that reside on the same part of the network. Sites enable you to structure AD to take advantage of network topology to improve access and replication and enable you to structure your directory services along physical network boundaries.

Sites are significant for a handful of critical functions. In authentication, AD takes sites into account to determine the DC and GC closest to the user based on the IP address of the client and its relationship to the subnet range of the site. The site configuration also determines how AD replicates changes to other DCs and GCs.

AD sets up replication between DCs in a site automatically so there are at least two replication paths between one DC and another. AD uses a three-hop rule in which there are no more than three hops to a DC that has already received the replication data from another source. In other words, replication is no more than three hops away in either direction. This helps ensure that if a DC goes down, it doesn’t hamper replication. All of this happens automatically, so you don’t really need to concern yourself with it in terms of how you design your network and implement AD, but you do need to understand it in order to know when you need to create additional replication connections.

You can manually define connection objects in AD that serve as points of replication between DCs. In the majority of situations, you can let AD design its own site replication topology since it will ensure adequate redundancy and fault tolerance. In some situations, however, you might need to create a manual replication link. You can do so through these connection objects, which you’ll learn more about later.

Site links
Site links connect two or more sites for the purpose of replication. Site links are unidirectional and are set up automatically by AD when you create sites and add DCs to the sites. In most cases, you needn’t concern yourself with site links other than to know that they exist and the function they serve, but on occasion you might need to manually create site links to address special network topology or replication issues. Just bear in mind that they are unidirectional, so you’ll have to establish them in both directions if you need bidirectional replication.

You have a handful of options when you create a site link. You can choose between RPC or SMTP as the data transfer protocol for the link, depending on your requirements. SMTP is not as reliable as RPC but doesn’t require as much CPU overhead. RPC provides compression and therefore is more efficient, an important consideration if the site link traverses a relatively slow connection. As with routing, you can configure the cost to a site to determine the network route used for replication, allowing AD to determine the least expensive route. You can define the frequency at which the site link checks the need for replication to control network bandwidth utilization. Finally, you can control when the replication can occur over the site link, allowing you to prevent replication during peak periods of network use.

At this point, simply understand that Windows 2000 creates site links automatically and, in most situations, you can rely on AD to create and manage its own site links. If your network spans a wide geographical area or incorporates routes with a relatively high cost, you can use site links to refine your replication topology and control costs.

Organizational units
As mentioned, AD serves as a container of containers. Within the main container (AD itself) are one or more domain trees. Each domain tree is in essence a container—it contains domains. Each domain can also contain objects, and the object that provides for organizational structuring within a domain is the organizational unit (OU). You have considerable flexibility in how you employ OUs within a domain, since they are rather generic container objects that lend themselves to organizing nearly any type of entity, even users, groups, printers, file shares, or other entities. You can nest OUs to create essentially any structure, so it’s easy to mimic your departmental structure or design the domain to suit your needs.

OUs are useful for several reasons. First, they enable you to control access to directory objects and thereby delegate administration. For example, you might create OUs along departmental lines and give one person in each department the ability to manage user accounts and passwords in his or her own department. It’s important to understand, however, that OUs are not security principals—you can’t grant permissions based on OU membership.

Perhaps as important as the ability to delegate administration through OUs is the fact that you can apply group policy at the OU level, as well as the site and domain levels. This enables you to apply policies and restrictions on a very granular basis.

We’ve touched a little on replication in this and the previous discussion of AD. Replication happens automatically across AD, so beyond the issues discussed in relation to sites and site links, replication isn’t a topic you need to worry about. However, as you’re designing your domain structure and laying out AD, keep replication in mind as a benefit of AD to be exploited and integrated into your network structure.

Because the replication incorporated into the design of AD works so seamlessly, you should take advantage of it for replicating and ensuring fault tolerance for other types of data, such as DNS zone data. As mentioned in part one of this series of Daily Drill Downs, you can create AD-integrated DNS zones that replicate automatically throughout the directory on a Windows 2000 DNS server. At this stage of the planning process, take a look at all of your data and services and determine if replication through AD will add fault tolerance, simplify resource access, or provide other benefits, if any, over your current methods. Also, examine your current replication methods to determine how to replace them through AD.

What’s next
At this point, you should have enough background to begin developing your domain structure and planning implementation of Active Directory. In the next Daily Drill Down in this series, we’ll jump into the trenches and start installing and configuring AD.

Jim Boyce is a former contributing editor and monthly columnist for WINDOWS Magazine. Jim has authored and coauthored over 40 books about computer software and hardware. He has been involved with computers since the late 1970s as a programmer and systems manager in a variety of capacities. He has a wide range of experience in the MS-DOS, Windows, Windows NT, Windows 2000, and UNIX environments. In addition to a full-time writing career, Jim is a founding partner and vice president of Minnesota WebWorks, a Midwest-based Web development firm.

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.