Windows Server 2008 Active Directory – Forest

Forests, in the simplest terms, are just groups of trees. All trees in a forest trust each other automatically. Think of a forest as an extended family, and individual domain trees as brothers. If you have five brothers in a family, each child of those brothers trusts his immediate brothers, and (usually!) each brother's family trusts the other brother's family—cousins typically get along. Forests just refer to collections of domain trees that trust one another.

There are two caveats, though, which are fairly significant and bear mentioning:

The only way to add a domain to a tree is to create it completely from scratch, adding it to an existing tree at that time. It's the same with trees—you can't directly add an existing tree to an existing forest without deleting and subsequently re-creating it.

Likewise, two existing, separate domains can't be linked together as parent and child. For example, hasselltech.local created on one network and charlotte.hasselltech.local created on another, separate network cannot be joined later as parent and child. The child would need to be re-created or migrated.

Transitive forest root trusts

The latter of the preceding two limitations might be frustrating for you, and you're not alone. Fortunately, what experts might term an "official hack" is available to effectively graft existing domains together into a tree-like structure so that trusts are established. Although it's not as easy and not as flexible as a forest—AD DS makes things slick and easy when you do things its way—it will work, with effort and maybe a bit of luck. The tool is called a transitive forest root trust, and with it, you can make two disparate forests trust each other.

Let's say I have a forest called businessone.com. Business One purchases another organization with an AD DS forest created already, known as businesstwo.net. Recall that I can't just graft businesstwo.net onto the already existing forest at Business One. However, with a transitive forest root trust, I can make it so that businessone.com trusts businesstwo.net, achieving some of the benefits of one unified forest. However, there are limitations and disadvantages:

Each forest must be operating in at least the Windows Server 2003 forest functional level. Although I will cover this later, suffice it to say that all domain controllers in each domain in each forest must be running Windows Server 2003, if not Windows Server 2008. This might be a prohibitive expense.

You'll learn more about this feature later in this chapter, but keep this in mind for now: a transitive forest root trust does not automatically make one, unified global catalog. Two separate forests still equals two separate global catalogs.

Transitive forest root trusts do not flow through. For example, businessone.com and businesstwo.net trust each other. But if businessone.com buys businessthree.org and a trust is set up there, businesstwo.net will not trust businessthree.org automatically—another trust will need to be set up. With that, we're back to the kludgy trust process found in Windows NT 4.0.

So, transitive forest root trusts aren't the answer to everything, but they are a reasonably effective way to create a "pseudoforest" within already existing trees.

The dedicated forest root model

You also can create a hedge against future AD DS changes if you are deploying Active Directory for the first time. If a department in your organization deploys AD DS ahead of other departments, as the other groups come on board, they effectively become subordinates of that first domain. How does a smart administrator get around that problem? The dedicated forest root model provides a way to maintain the autonomy of multiple domains that you create.

A dedicated forest root domain can be either an "empty domain," which contains only a small number of universal users and resources, or a normal production domain that just happens to be at the root of a forest. The latter is not recommended. An empty forest root domain that does not serve as a production domain is advantageous for several reasons. For one, the domain administrators group in the root domain has power over the forest, which is something you might not want. Keeping the root empty allows you to delegate administrative authority to individual domains without giving everything away, a security protection that keeps honest administrators honest. It also helps you to structure your AD DS environment; a constant root makes further changes logical and easy to implement and manage—for instance, if you acquire a new company or build a new office. The forest root domain, if kept empty, is very easy to replicate and to back up. And if you ever make changes to the administrative authority in your business, you can transfer the keys to the kingdom to others without affecting the administrators' autonomy of your child domains.

However, the key to the empty root strategy is to keep the root empty: have it contain only one administrative account—the Enterprise Administrator, which is, of course, created by default when you create the first domain in a new forest—and use that only when absolutely necessary. Then, create all the domains you need under that first domain and you won't have one particular domain in your organization unnecessarily holding Enterprise Admin-style accounts.

Of course, this method has its downsides. Costs definitely are involved: for one, you need a separate license of Windows Server 2008 for your dedicated forest root domain controller, and you have the burden of administrative responsibility in ensuring that the root domain is kept up, patched, and the like. However, if you are in a high-growth industry and your organization is likely to make acquisitions and divestitures within the near future, it's best to use this method to hedge against major changes to AD DS structure.