Domain Components

Root Domains, Child Domains, Domain Trees, and Forests

Now that you have a basic understanding of the responsibilities of the Operations Masters, you might have noticed that we are throwing around terms such as domain and forest. What's the difference between these two, and how do the Operations Masters fit into the picture?

Up to this point in our tutorials, we have created a single domain with a single domain controller:

This is as simple as it gets. All five Operations Master roles plus the Global Catalog are present on our sole domain controller, DC01 (the Infrastructure Master doesn't really have a function in our domain, simply because it is located on the same domain controller as the Global Catalog). All our shared folders, users, groups, OUs, and printers are located in guinea.pig, a single domain.

Of course, as this chapter's name suggests, we're not going to stop at just one little domain. We can add child domains (or even grandchild domains) to our existing setup. For example, let's say that our company, Guinea Pig, Inc., opens a new plant in Denver. We want to be able to give the Denver plant its own domain, while still retaining it as a part of the main guinea.pig domain. We decide to create a new domain named denver.guinea.pig , building on our existing domain structure, as shown on the following page. Note that our first domain is the root domain , because it is the first domain we created. The second domain is a child domain , as it is an offspring of the root.

The really nice thing about this new setup is that although these two domains have their own separate place in our company, members of guinea.pig can access resources in denver.guinea.pig, and members in denver.guinea.pig can access resources in guinea.pig. Of course, members of each domain do not have full reign of each other's resources; standard NTFS permissions still apply here. So if a user in guinea.pig does not have permission to access a shared folder in denver.guinea.pig, then he is denied access. The point we are trying to make is that, by default, both domains "trust" each other, so that information has the potential to flow freely . This relationship is known as a two-way trust relationship.

Now let's say that Guinea Pig, Inc., builds yet another plant, this time in Austin. That plant also needs to have its own domain, but yet be part of the whole guinea.pig domain. So we now have a domain tree which looks like this:

Why do we call this pyramid structure a domain tree? Notice how all three domains carry a common DNS name (i.e., guinea.pig). Any number of domains connected in this fashion and that carry a common DNS name space are said to be a domain tree .

But what does adding a third domain do for our trust relationship between and among domains? By default, trust among connected domains is said to be transitive . If you think back to your math classes, the term transitive property may ring a bell.

The transitive property states that given values a , b , and c if:

a = b

b = c

then:

a = c

So assuming our trust among these three domains is transitive, if:

austin.guinea.pig trusts guinea.pig guinea.pig

trusts denver.guinea.pig

then:

austin.guinea.pig trusts denver.guinea.pig

This facilitates a very powerful flow of information from domain to domain. And since the trust is two-way, the trust relationship works in reverse:

if:

guinea.pig trusts austin.guinea.pig

austin.guinea.pig trusts denver.guinea.pig

then:

guinea.pig trusts denver.guinea.pig

And to reiterate, NTFS file permissions still apply so that users in each domain do not have full reign of resources in other domains. ( So you see; there was a use for at least some of that material in math class ).

So far, we have discussed root domains, child domains, and domain trees. The next step in our hierarchy is the forest . A forest is a grouping of domains that have three items in common: a common schema , a common site and replication scheme ( Note: we'll go more into these concepts later in the chapter ), and a common Global Catalog .

Placement of Operations Masters In Domains and Forests:

Now that we have a working knowledge of what makes up a domain, a domain tree, and a forest, as well as the domain controller Operations Master roles that glue this whole thing together, how do we assemble this puzzle? Microsoft has set up the following hierarchy in the placement of Operations Master servers.

A domain must contain only one of each of the following:

• PDC Emulator

• RID Master

• Infrastructure Master

If the domain is single with a sole domain controller, all five Operations Master roles plus the Global Catalog run on the domain's only domain controller ( Note: the Infrastructure Master is non-functional, as it is on the same domain controller as the Global Catalog ).

A forest must contain only one of each of the following:

• Schema Master

• Domain Naming Master

Once again, even though the Global Catalog is not an Operations Master, it is still a required component of a forest. As noted earlier, the Global Catalog acts as a map to point clients and servers in the right direction when searching for objects in the directory. A forest without a Global Catalog is analogous to a road trip without a map; navigation is all but impossible . There can be more than one Global Catalog in a forest, which is a good practice if one of them should fail.

Since a forest has three Operations Masters for each domain plus two Operations Masters for the entire forest, you can use this simple equation to determine how many Operations Masters you will need for any given forest:

[Number of domains x 3] + 2

Figure 5-1 shows the placement of Operations Masters and the Global Catalog in a forest.

Figure 5-1: 1 : Schema Master
2 : Domain Naming Master
3 : Global Catalog*
A : PDC Emulator
B : RID Master
C : Infrastructure Master
* Although the Global Catalog is a forest-wide entity, any number of domain controllers in the forest may be a Global Catalog. Having more than one Global Catalog increases fault tolerance.

In this portion of the book, our hardware and software needs have grown, and are going to continue to grow. Since we are adding a second domain, a child domain, we obviously need a second domain controller. This means that we need another server computer and another copy of Windows Server 2003. The following tutorial assumes that you have the following items in your possession, in addition to the previous hardware and software requirements outlined in earlier chapters:

• One additional, licensed copy of Windows Server 2003

• One computer capable of running Windows Server 2003

• The additional network capacity to accommodate the two new servers

The following tutorial illustrates the procedure of adding a new child domain to the guinea.pig domain called denver.guinea.pig.