So, I was reading through a document a couple of days ago and came across discussions about AD Forests, Domains and Trees. As I was reading the document, I couldn’t help but start to question it all, after all the last time I really dealt with this was when I was doing my Windows Server 2000 training. This document became confusing due to how it had been anonymized before sharing. But it really got me thinking and then doubting what I had learned way back when. After a quick sanity check all was good. But it got me thinking, it’s not really discussed any more, but you can come across it within older environments.
In the post The Beginning – Create a Forest and Domain we created a Forest and the Root domain, but what are they? What significance do they hold? What other options are there?
Forest
Lets start with the highest level that we have. An AD Forest. The Forest will hold the Schema (what attributes make a class, what class makes an object, what objects are there etc). Within an AD environment, there is only one forest. Within any given network/environment, you can have multiple forests. These forests can trust each other if desires. A forest is also a security boundary.
The forest functional level defines the minimum domain functional level allowed. So, a forest functional level of Windows Server 2016 cannot have a domain running at Windows Server 2012 levels. Domains can be running at a higher level than the Forest Functional Level, such as a domain running Windows Server 2019.
I think the simplest way to describe it is, a forest is a logical collection of domains.
For our examples, we are going to use the infamous CONTOSO (contoso.com) for our forest name. It’s important to note that users who are in the Enterprise Admins group are, by default, Domain Admins of ALL domains within a forest.
Domains
Within a forest you have a collection of domains. Each forest has a minimum of 1 domain, and the first domain created is always the Forest Root domain. You can create multiple domains, and create domains that have a parent/child relationship.
The first domain created will share the name of the forest CONTOSO (contoso.com).
The domain functional level specifies what the oldest domain controller operating system is allowed, for example, a Domain Functional Level of Windows Server 2016 cannot have Windows Server 2012 R2 Domain Controllers. It can have Windows Server 2019 Domain Controllers though.
In a parent child relationship, you might have an additional domain EMEA (emea.contoso.com) which is a child of CONTOSO.
Trees
Trees are collections of domains within a forest. They may or may not contain child domains (branches). Additional trees do not need to share the same name space as the forest root domain. Each domain within a forest must be uniquely named though. All trees within a forest will share a common Schema.
For example, it is entirely possible to have the following 3 trees within one forest.
Tree 1 – CONTOSO (contoso.com), EMEA (emea.contoso.com)
Tree 2 – WINGTIP (wingtiptoys.com), EMEA (emea.wingtiptoys.com)
Tree 3 – WOODGROVE (woodgrovebank.com)
Trusts
Between forests, domains, even Kerberos Realms and NT 4 domains, there is a concept of Trust Relationships. Trust relationships allow accounts in one domain access resources in other domains. In the early days of Active Directory, a common set up was to have two forests, a user forest and a resource forest. There would then be a trust between these to allow access.
Trusts can be either one way or two way. With a one way trust one domain (resource domain) trusts the other (user domain) but not the other way around. In a two way trust relationship, both domains/forests trust each other.
When a new tree is created within a forest, a two way trust between the tree-roots is automatically created. When a child domain is added, a two way trust automatically gets created between the parent and child.
Trusts in itself is a fairly big topic when you start looking in depth, but this should give you an idea.
Design Considerations
Back with Windows Server 2000, there were limitations on the number of objects that you could have within a domain. As a result, some environments were forced to use multiple forests and domains. With the evolution of Windows Server, complete with evolution of Active Directory, these limitations no longer exist.
Generally, you will only need one AD forest and domain. The main reason for creating additional ones is usually political. The advice in today’s world is to go with just one forest/domain unless absolutely necessary. Creating multiple forests and domains creates additional administration overhead, running costs (even a VM has storage and compute costs) and complexity.
You may well have a case for more than one AD Environment, maybe it’s a test environment for testing Schema Upgrades, testing app compatibility with the latest Windows Server versions or testing MFA before rolling it out globally.
The other common reason for a second AD environment is regulatory requirements. Using PCI as an example, if you know your current production environment might not meet the needs of PCI requirements, you may create a PCI directory service which is built specifically with meeting PCI requirements in mind.
When choosing a domain name, always ensure that you use a public domain you own in some way. You could buy a domain specifically for the purpose of running Active Directory (companydomain.net for example), or more commonly, you create a subdomain (corp.domain.tld) and work from there.
Migrations
If your company grows via acquisitions you could end up with many AD forests and trees. It becomes a nightmare. You may wish to consolidate all of these back in to one single environment to simplify things. I am sure I will end up doing a full blog post on this but it is possible to do migrations using Active Directory Migration Tool (ADMT).
Maybe, you were one of the early adopters of Active Directory and went with a .local top level domain, these are a nightmare, especially when dealing with Macs, if you’ve had Exchange in the past you can’t just run a rendom to rename, maybe you need to be looking at a migration.
