Have you ever wondered about the difference between an Active Directory forest and a domain? Wonder no more, as this comprehensive guide teaches you all you need to know about AD forest.
Overview
If you have ever managed an Active Directory Domain, you’ll struggle to see how AD forest comes into the picture. The reason for this is that you do not “see” the forest because it is logical, not physical.
When you have a collection of Active Directory Domain trees, you create an AD forest. So, an AD forest is a collection of one or more Active Directory Domains.
One major difference between a forest and a domain is that forests do not form a contiguous namespace (I’ll explain this term shortly). On the contrary, domain trees form a contiguous namespace.
In relation to AD forests, the term “namespace” defines the relationship between domain names. For example, Itechguides.com is a domain namespace.
If I introduce a child domain, UK.Itechguides.com, then, Itechguides.com and UK.Itechguides.com have a contiguous namespace.
On the other side of the logic, to form a forest, I can combine Itechguides.com and Dell.com. As you can see, Itechguides.com and Dell.com DO NOT share the same contiguous namespace.
In the remaining sections of this guide, I’ll dive deeper into these concepts.
How Active Directory Forest Works
As I hinted in the overview section, a forest does not require its AD domain members to share a distinct name or contiguous namespace. Since AD forest does not require a distinct name, the domains in a forest communicate by cross-referencing objects in the domains.
In addition to cross-referencing objects, AD forest members also communicate via Kerberos trust relationships. For the purpose of this Kerberos trust relationship, Active Directory forests form a hierarchy.
Talking about hierarchy, the AD forest seats at the top level of the Active Directory hierarchy. The next (lower level) in the AD hierarchy are the AD domains.
Then, each AD domain tree in the forest may have subdomains that share a contiguous namespace. It is important to mention that a single AD domain can make up a forest.
Moving on, there are three models of AD forest – Organizational, Resource, and Restricted access. Although these three models are different in architecture, they have a common attribute.
That is AD domains in the same forest share a common root (configuration), common schema, and global catalog.
As I mentioned earlier, there are three AD forest models. In the following subsections, I have explained how these three models work.
How the Organizational Active Directory Forest Model Works
This is the standard AD forest configuration. In this model, user accounts and other AD resources are contained in the forest and managed independently within the AD forest.
Additionally, if you configure the Organizational Active Directory forest model to prevent access to anyone outside the forest, you can use this model to provide service autonomy, service isolation, or data isolation.
Service autonomy, service isolation, and data isolation mean that users in one AD forest cannot access resources in the other AD forests.
In this forest model, if you want to enable inter-forest communication, you have to enable trust relationships.
How the Resource Active Directory Forest Model Works
Unlike Organizational forests, the Resource forest model does not contain user accounts. Rather, individual forests are used to manage resources instead.
Essentially, instead of containing standard users, a resource forest contains user accounts required for service administration. In addition to that, it could also contain user accounts needed to provide alternate access to the resources in that forest.
The second scenario may happen if the user accounts in the organizational forest become unavailable.
Like in Organizational forests, you can also establish trust in Resource forests. Similarly, trusts are established to allow users access to resources contained in the Resource forest.
How the Restricted Access Active Directory Forest Model Works
This is the third and final AD forest model. As its name suggests, you can use this forest model to isolate data between forests.
As you may have imagined, restricted forests do not create trust relationships. Essentially, a restricted forest isolates important data from other organizational forests.
Additionally, some companies may decide to create the restricted forest in a separate physical network.
In the features section of this guide, I will highlight the key features of these three forest models.
Features of Active Directory Forests
I have covered a reasonable ground in this article. So far, you have read the overview of AD forests as well as how it works.
Additionally, I discussed the three AD forest models and how they work.
To explain Active Directory forests further, I will now discuss their main features.
AD Forests do not Share a Contiguous Namespace
Although I have mentioned this in the overview and “how it works” section, it is important to highlight this feature of AD forests. Active Directory Domains in the same AD forest do not share a contiguous namespace.
A contiguous namespace links a child container (subdomain) to its parent domain by adding an additional identifier at the beginning of the DNS name of the namespace.
In my overview section, I used the example of Itechguides.com and UK.Itechguides.com as having the same contiguous namespace. I also said that this is an example of an AD Domain tree.
On the contrary, two AD domains with dissimilar namespaces can form an AD forest.
A Single AD Domain can Form a Forest
When you create a single AD Domain, an AD forest is created automatically. A forest can be made up of a single domain with just one domain controller.
Similarly, a forest can consist of several domains across multiple domain trees.
Domains in a Forest Share Some Common Attributes
As I mentioned in one of the previous sections of this guide, an AD domain in a forest shares a common root, common schema, and global catalog.
The forest root domain is the first domain that you deploy in an Active Directory forest. This domain contains the Enterprise Admins and Schema Admins groups.
AD SysAdmins use these two service administration groups to manage forest-level operations. Some examples of forest-level operations are adding or removing domains to and from the forest and modifying the AD forest schema.
Talking about the schema, I said earlier that AD domain forest members also share a common schema. AD schemas are a set of definitions of object types and attributes.
An example of an AD schema object is the user. Similarly, an example of an AD schema attribute for the user object is Display Name.
The schema holds a comprehensive definition of all the object names and their attributes you can use in the AD forest. An interesting feature of the AD schema is that you can extend it.
Extending the schema means defining custom objects and/or attributes.
Finally, Domains in a forest share the same global catalog server. A global catalog server is an AD domain controller that hosts the global catalog.
The global catalog is a partial, read-only copy of all objects in a multi-domain forest. The importance of these partial attributes held by the global catalog server is to speed up inter-forest searches.
For example, without the global catalog server, if you want to find an object in a different domain (in the forest), you would have had to contact a domain controller in the other domain.
This cross-forest search would be slower without the global catalog server.
Two Forests can Access and Share Resources via a Trust Relationship
One of the features of an Active Directory forest is that it offers service autonomy, service isolation, or data isolation. This means that by default, users and services in one forest would not be able to connect to other forests.
So an AD forest creates a security boundary. As I mentioned above, this means that users outside the first cannot access resources within the forest.
In addition to creating a security boundary, AD forests create a replication boundary. Since Active Directory forest has multiple domain controllers, replication occurs among the DCs.
However, replication cannot happen with any Domain Controller outside the forest. Talking about replication, an AD forest creates a replication boundary for the schema and configuration partitions.
Additionally, the forest acts as a replication boundary for the global catalog. As I hinted in the last subsection, the global catalog improves object searches between domains in the forest.
With all these said, when you create a Trust relationship between forests, you effectively enable cross-forest communications. So, in a forest trust relationship, AD forests can communicate with each other.
If you’re wondering how to create forest trusts, you perform this task with the Active Directory Domains and Trusts.
There are Three Forests Design Models
In the “how it works” section of this guide, I discussed how the three AD forest models work. In this section, I will highlight the features of each of the three forest design models.
The Organizational forest design model has the following features:
- Provides autonomy to users and resources within the forest.
- Separates data and services from people outside the forests.
- A Trust relationship between forests allows sharing of resources.
Similarly, here are the features of a Resource forest model:
- Resource forests do not contain user accounts.
- They contain accounts required for service administration and other specific purposes.
- In a Resource forest, users are created in an Organizational forest, while accounted required for administration (resources) are created in separate forests.
- Trust relationships enable resource access to users outside the Resource forest.
Finally, a Restricted access forest model offers the following features:
- A separate forest from the Organizational forest
- A Restricted access forest contains user accounts and data that an organization needs to isolate from the rest of the business.
- There is no Trust relationship between a Restricted access forest and the other Organizational forests.
- Users need a separate computer (from the computer they use to access other forests) to access a Restricted access forest.
Strengths Of Active Directory Forests
Provides Ease of Interaction Between Domains in the Forest
In the features section of this guide, I mentioned that an AD forest creates a security and replication boundary.
This boundary exists between a forest and other forests. However, an AD forest allows ease of resource sharing between member domains.
Additionally, resources are replicated between Domain Controllers in the same forest.
An AD Forest Shares a Single Global Catalog Server
This improves object searches between forest domains.
As I mentioned earlier in the guide, the global catalog server (GC) contains a partial replica of all objects in the forest. So, when a user in one domain searches for objects in another domain (in the same forest), the GC helps to return results faster.
Central Authentication and Authorization
AD forests act as a tool to allow users to sign in to computers (authentication).
In addition to managing sign-in, the AD forest also manages access to resources (authorization). This saves time and improves security compared to authorizing and authenticating from individual PCs.
Automatic Update Synching Across DCs and Automatic Conflict Management
Ideally, an AD forest should have more than one Domain Controller.
Additionally, except for Flexible Single Master Operations (FSMO roles), an AD forest operates a multi-master model. A multi-master model means that SysAdmins can update the same object from different Domain Controllers at the same time.
The AD forest takes care of synching changes across DCs and also managing conflicts.
Limitations Of Active Directory Forests
Security Vulnerabilities
The central management benefit that AD forest offers could become a disadvantage.
For example, this makes the whole system vulnerable to a single point of failure. Although this is rare since an AD forest has multiple Domain Controllers, it is worth mentioning as a rare possibility.
Creating Trust Relationships Increases Security Risks
When you create trust relationships between forests, it is not secure by default.
It requires carefully configuring authentication and permissions for each forest. So, apart from the vulnerabilities created by creating forest trust relationships, it is also time-consuming.
Besides, creating trust relationships incurs additional costs
Active Directory Forest Design can be a Complex and Lengthy Process
When you’re designing an Active Directory forest, you have to consider multiple factors.
Firstly, you need to determine the isolation requirements of your design. Additionally, you have to determine the number of forests.
Working through all these factors and more is time-consuming. To learn more about AD forest design and support limitations, read this Microsoft Learn guide – Determining the Number of Forests Required.
Frequently Asked Questions
An Active Directory forest is a collection of one or more Active Directory domain trees that contain one or more Active Directory domains.
On the contrary, an Active Directory Domain is a logical container for managing objects like users, computers, and groups.
The major difference between a forest and a domain is that the domain is lower than the forest in the AD hierarchy.
Essentially, a forest is a collection of domains. However, one domain can make a forest.
There are not two but three types of Active Directory forest design models – Organizational forest, Resource forest, and Restricted access forest.
An Active Directory tree is a collection of one or more AD domains. Meanwhile, a forest is a collection of AD trees that share the same common root, common schema, and global catalog.
An Active Directory forest can have one domain or unlimited domains. Although you can have unlimited domains in a forest, Microsoft recommends a maximum of 10 domains in an AD forest.
This number is purely based on the number of domains that Microsoft believes you can efficiently manage in a single forest.
Conclusion
The concept of “Active Directory forests” is essential to understanding Active Directory. If you’re an Active Directory SysAdmin, having this vital knowledge equips you to manage your AD environment efficiently.
Additionally, Active Directory architects equipped with this knowledge can design robust AD infrastructures. Thankfully, this guide has covered most of the things you need to kick you off in your understanding of this essential AD concept.
I started the guide with an overview of Active Directory forests. Then, I explained how AD forest works, followed by its features.
Finally, I discussed the pros and limitations of Active Directory forests.
My aim was to simplify AD forests, and I hope I succeeded in doing that. If I did, click on “Yes” beside the “Was this page helpful” question below.
You may also express your thoughts and opinions by using the “Leave a Comment” form at the bottom of this page.
Finally, if you’re keen to take your knowledge of Active Directory to a Pro level, read more Active Directory articles on our Active Directory Guides page.
