A “forest” is one of the more commonly used terms in Windows-based networks. It is often graphically presented as the border of a network with several groups of computers and entities listed or connected inside it – an image that many of us will find quite familiar.
So, what exactly is a forest? And, what do we use it for? We will be answering these questions, and more, in this article.
Definition – what is a forest in Active Directory?
To define a forest, we will first need to start by first defining an Active Directory (AD).
AD is a directory service that was developed by Microsoft for its Windows domain networks. AD structures are arrangements of information about objects – which could be resources (like servers and computers) or security principals like (users and groups). It comes as a set of processes and services in most Windows Server operating systems in use today.
Next, we will need to define a domain.
A domain is an area of a network that is clustered or grouped under a single authentication database that is run on a server. This server is known as a domain controller and is responsible for authenticating and authorizing all the users and computers in its domain. It is also responsible for permissions, modifications, edits, as well as assigning and enforcing security policies of all the objects under it – resources and security principals, alike.
Finally, and going back to the definition of a forest, we can say that a forest is a logical construct that is used by AD Domain Services (AD DS) to group one or more domains that are joined by a trust relationship.
A trust relationship is an administration and communication link between domains that allows user accounts and global groups to be used in domains other than the domain where the accounts have been defined.
To make it easier to understand, we can also assume that domains are the “TREES” of a FOREST.
What is a forest used for?
Domains are created to establish administrative boundaries between different network entities. A forest is, therefore, an extension of that: it is an administrative boundary that is used to make it easy to manage and authenticate more than one domain and the objects bounded by them.
How many forests can an organization have?
To answer the question: an organization can have as many forests as its network infrastructure requires.
But, it is advised that only one forest exist per company. Of course, exceptions might arise like when there is an absolute need for an added layer of security between domains. Or, for example, when there is a merger between two companies that happen to have their own domains.
Furthermore, perhaps, there is testing that needs to be done for the deployment of a new software solution on a domain and the administrator doesn’t want to take any risks that could interfere with the production domain.
The administrator can, thus, leverage an isolated replica of their AD structure to test and tweak the configuration of the new solution before implementing it on the production network, cutting the risk of this new addition affecting the organization’s day-to-day operations.
Things to consider before creating more forests
It should be noted here that adding a forest doubles the complexity of managing the AD schema. With that in mind, let’s have a look at some considerations that need to be taken when adding a new forest:
- A new forest should only be added if there is no possibility of achieving sufficient isolation in the current architecture.
- All stakeholders – users, managers, IT staff, and the organization as a whole – should be aware of the ramifications of adding a new, separate forest.
- Adding a forest means there will be a need for new application servers and, therefore, an increased IT budget.
- Plans should be made to double the number of administrators and security personnel as it is recommended that each forest has its own team of professionals looking after it.
And finally, always remember: the industry best practice is to integrate new domains into existing ones. Going against that would be ill-advised.
Active Directory forest best practices
Since we have just said that a single forest is the industry best practice, let’s have a look at some more industry best practices:
- The very first one would be consolidating domains into existing forests whenever possible.
- Administrators should adopt the “least-privilege” model where objects can only access must-have resources and nothing more.
- Administrative accounts should be held in reserve and only used when required and as per change management procedures; this means administrators will have a separate account for day-to-day activities and only use their privileged accounts when required.
Summary – single forest vs. multiple forests
Administrators should use a single forest whenever possible. It is advisable. It is easier to create a secure environment without having to worry about the added overhead of another forest – which comes with its own set of domains and headaches. They should leverage GPOs, data owners, and implement a least-privileged model.
Administrators can opt for additional forests if they seek an extra layer of security between, and around, the two forests and their individual domains. But, this will come at a cost and extra work will be needed to make the multi-forests more secure. Also, the workload doubles as configuring GPOs and permissions will still need to be done anew each time a new forest is added.
What are the types of forests?
Let’s now have a look at the three types of forests:
Organizational Forest Model
The Organizational Forest Model is the basic configuration where user accounts and resources are stored and managed together.
This model offers autonomy to users and resources in the forest and isolates services from being accessed by anyone outside the forest – unless a trust relationship has been established to facilitate the access.
Resource Forest Model
In the Resource Forest Model, user accounts and resources are kept in different forests. This configuration can be used to isolate a production domain from the, say, testing domain. In case of issues in the test domain, there is no fallout or effect felt in the mission-critical production environment.
In this model, users live in the organizational forest while resources live in the additional forests. The resources forests are assigned new or alternative administrator accounts. A trust relationship is required to enable sharing between users.
Restricted Access Forest Model
In the Restricted Access Forest Model, users and resources in one forest are totally isolated from those in other forests. This model or configuration is used when complete data security and limited user access are required.
Needless to say, there is no trust relationship between the forests. Users in one forest won’t be able to access resources in the other restricted forests. In case they do require access, they would need to log in to the restricted forest using a separate, authorized device.
A restricted access forest can be hosted in an entirely separate network if required, as it has no external dependencies that would prevent it from performing as it should.
Always use professionals when configuring forests
We have just gone through the definition of a forest, and we have seen that creating and configuring them is not something to be taken lightly. An organization’s efficiency and even existence – especially if it depends on all its users and resources being connected at all times – could be in jeopardy if there is a failure.
Therefore, always make sure to hire professionals who not only know how to create secure forests, or even setup Active Directory domain structures, but can also configure them to work at optimal performance levels.