Active Directory Forest Trust: Attention Points

Article
1/17/2024

Introduction

An Active Directory (AD) Forest is the security and administrative boundary for objects and entities. Due to some business need, if we want to establish a bridge between two AD Forests, we need to configure Forest Trust between those forests.

However, you have to be very careful while configuring the Forest Trust, as it will open the security boundary before another AD Forest, which might belong to a different organisation or entity.

**You should always consult key stakeholders, security team and take their written approval before you configure a Forest Trust. **

This article will focus on some of the important aspects and considerations while configuring a Forest Trust. This will also provide you checklist, which might be useful during the planning stage.

About Forest Trust

Forest Trusts are created between Forest Root Domains, and it is valid for all Domains within the entire Forest.

So if we establish Forest Trust between Forest A and Forest B, that will also be valid between the child domains (if any) of these two forests.

This is where Forest Trust differs from External Trust, which is valid between two Domains.

Forest trusts are typically useful in below scenarios:

Company A has merged with Company B, and now both companies need to access each other resources. In this case, the ideal solution is creation of a two way trust.
Company A will use an application , which is developed by Company B and hosted in company B's environment. In this case, typical configuration is an one way trust.

We will discuss Trust Direction in the next section.

Trust Direction and Access

When a two way Forest Trust is created between Forest A and Forest B, all domains in Forest A will trust all domains in Forest B and vice versa.

If a one way Forest Trust is created, where Forest A is Trusting Domain and Forest B is Trusted Domain, then Forest B can access resources within Forest A, however Forest A cannot access resources within Forest B.

Please remember that in a one way trust, direction of trust and direction of access are always opposite to each other.

Security Settings on Forest Trust

An external or forest trust exposes a larger surface to attack . Therefore, it is important that proper security measures are taken while creating these trusts.

There are two security settings available in Forest Trust that can be used to enhance the security of communications made over Forest Trust.

SID Filtering.
Selective Authentication.

SID Filtering

When SID Filtering is enabled, all the foreign SIDs will be removed (quarantined) from user's access token while accessing any resource through Forest Trust. The most common impact of this is, a migrated user account which is still using any resource using old SID will not be able to access that resource anymore. This is because when SID Filtering is enabled, it will block (filter) SID History through a Forest Trust.

When we create a forest Trust, SID Filtering is enabled by default. In some cases, we need to disable SID Filtering. The most common scenario is during an AD migration, when SID History of user accounts need to be enabled, so we need to disable SID Filtering.

Please note that SID Filtering can be disabled or enabled from the trusting Domain / Forest side of the trust.
**
**

If the trust is External trust, then we have to run a command on any Domain Controller of Trusting Domain :

Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:No /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>

If the trust type if Forest Trust, then the command is different. We have to run below command on any Domain Controller of Trusting Forest' s Root Domain :

Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /enablesidhistory:Yes /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>

**Please note that disabling SID filtering is a security compromise, and not at all recommended unless there is a specific business need. Even if it is disabled on a temporary basis (Ex: during AD migration ), it should be enabled as soon as the need is over. **

When SID Filtering is disabled, a rogue domain administrator can clone a SID from the other domain and add it to their SID History, granting them unauthorized rights.

To re-enable SID History please use these commands:

External Trust:

Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:Yes /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>

Forest Trust:

**Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> enablesidhistory/:Yes /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>

Authentication Level

While creating a Forest Trust, the wizard will ask what kind of authentication level will be configured on the Forest Trust.

Forest Wide Authentication

When is Forest Level Authentication is enabled, the Domain Controllers of Trusting Forest will authenticate all access requests, made by users from the Trusted Forest. Once authentication is successful, access to the resource is granted or rejected based on the resource Access Control List (ACL).

There is a risk in this approach. Once the foreign user (from trusted Forest) has been successfully authenticated by Domain Controllers of Trusted Forest, it becomes a member of the "Authenticated User" group. This group does not have any permanent member, membership is computed dynamically based on authentication. Once an account is a member of the "Authenticated User" group, it can access all resources where the group "Authenticated user" has access.

Selective Authentication

To combat the above mentioned security loophole and have some control on the authentication, we can opt for the Selective Authentication level. In this level, not all users are authenticated by Domain Controllers by default. Instead, when a Domain Controller of Trusting Forest detects that an authentication request is coming from a trusted forest, it first validates whether the user account has been granted exclusive permission on the resource that is holding the object.

For example, a file share has been configured on a file server. If a user from a trusted forests wants to access that file share, that user account has to be explicitly granted "Allowed to Authenticate" right on the file server. Only then the Domain Controller will authenticate the user, otherwise Domain Controller will reject the authentication request, and the user will not be part of "Authenticated User" group.

We recommend referring this technet article for more insight on Selective Authentication.

AD Site Configuration for Trusted Forests

There is one more important point that needs to be considered. Which Domain Controllers in Trusted Forest will authenticate users? If the site configuration is not correctly done in Trusted Forest, users and computers from Trusted Forest can be authenticated by any Domain Controller in the forest which may be on a different geographical location. This is not what we want.

To prevent this, and to ensure that those users and computers are always authenticated by nearest Domain Controllers, we should create AD Sites in the Trusted Forest, with the exact same name of Trusting Forest Sites where resources are located. It can be en empty site, with no Domain Controllers. Site Links must be created to at least another site, which is having Domain Controller.

Once this design is implemented, the "Automatic Site Coverage" feature of Active Directory will ensure that the users from the Trusted Forest are getting authenticated by nearest Domain Controllers . No additional configuration is required.

Let's assume Forest A is Trusting Forest and Forest B is Trusted Forest. Here is how the authentication Works:

Users at Forest B (Trusted Forest) will try to access a resource at Forest A (Trusting Forest). Let's assume that the resource is a file server, which is located at Site Bangalore" at Forest A (Trusting Forest).

In order to authenticate the user, a query will be generated for a Domain Controller, which is available at site "Bangalore", but not at Forest A but at Forest B, since the user belongs to Forest B. So it will first try to locate a DC with matching site name at Trusted Forest.

If there is no site called "Bangalore" in Forest B, then the next attempt would be to contact any Domain Controller at Forest B. This is where the authentication requests randomly go to any Domain Controller, which may be in a different location.

If, on the other hand, a matching site exists in Trusted Forest (In this case "Bangalore" in Forest B), then the authentication requests will go to that AD site. If that site is having it's own Domain Controller, then it will use that. Otherwise, if that is an empty site, then the nearest Domain Controller (available through site links) responds to the authentication request.

Due to this reason, it is always recommended to create AD Site in Trusted Forest, with matching site name with Trusting Forest where resources exists. Please note that the site same should be identical , and it is case sensitive. If resources exists in more that one sites in Trusting Forest, then we should create all those replica sites in Trusted Forest. It is not mandatory to keep Domain Controllers within those sites, it can be an empty site without any Domain Controller and without any subnet. However, in that case it should be linked with another site which is having Domain Controllers and which is geographically nearest to the physical location of the resource in the Trusting Forest.

Once Site Link is established with an empty site, the other site (having Domain Controllers) automatically "assumes" the responsibility of authentication for the empty site. This feature is called Automatic Site Coverage. This can also be checked in the DNS SRV Records of the empty sites, which Domain Controllers have been delegated this responsibility. In our diagram, we have linked the empty site "Bangalore" with another site "Mumbai" which is having Domain Controller. So now onwards that Domain Controllers at Mumbai should authenticate users, while accessing any resource at Forest A "Bangalore" site.

For two way Forest Trust, this configuration needs to be done on both sides because both parties will access each other. So in Forest A, sites need to be created matching with Forest B resource sites. Similarly, in Forest B, sites need to be created matching with Forest A resource sites.

During the Forest Trust setup, usually the routers and firewall settings are done in such a way, that it would only allow to reach selective Domain Controllers and DNS Servers of the other side. In that case, we have to be careful that traffic is allowed between the Trusting Forest and those Domain Controllers at Trusted Forest, which will authenticate the users.

To know more about automatic site coverage please check this Technet Article.

Checklists : Forest Trust Creation

Now that we have discussed the basics of Forest Trust, let's create two checklists which would cover all the points which needs to be considered while creating the trust. Since Forest Trust is typically created between two business entities, it is better if both the parties follow these checklists.

Checklist 1: Business Proposal

Before configuring the Forest Trust, you should prepare a business proposal, similar to the below table. You should discuss it with key stakeholders and get a sign-off. Typically, you should also get a sign-off from the security team before you create a Forest Trust. Stakeholders from both the organisations / entities should be involved.

You should also keep the signed approval in organisation's central repository for future reference.

Item	Description	Organization 1	Organization 2
Organization Name	Name of the two organizations that have agreed to establish a Trust
Direction of Trust	Mention Trust Direction (Two Way/ One Way/ Trusted Forest / Trusting Forest)
Forest / Domain Name	Mention Name of the Forest / Domain with which you are establishing the trust
Business Justification	Mention business justification for creating the Forest Trust.
People Involved	Mention stakeholders name who are involved in trust creation, from both the organisations. They should be business / service owner approving the Forest Trust creation.
Date and Validity of Trust	Mention Trust Creation Date and Validity Date (Ex: Permanent / Till certain date)
SID Filtering	Enabled or Disabled ? If Disabled , Temporary / Permanently ? If Temporary, how long ?
Reference Number	Mention reference number to plan / perform this activity.

Checklist 2: Action Plan

Now that the Forest Trust proposal is approved by stakeholders, it's time to prepare the Action Plan for configuring the Forest Trust.

Item	Description	Forest A	Forest B
Network Connectivity	Ensure there is network connectivity established between Forest A and Forest B.
Firewall Rules	Ensure these ports are unblocked between two forests, at network level : 53 TCP/UDP DNS 88 TCP/UDP Kerberos 389 TCP/UDP LDAP 636 TCP LDAP (SSL) 445 TCP SMB 135 TCP RPC Endpoint Mapper 1024-65535/TCP RPC for LSA, SAM, Netlogon (*)
Name Resolution between forests	Name Resolution should work between Forest A and Forest B. For that use conditional forwarder or stub zone.
Trust Type (1-way or 2-way) and Trust Direction	If the Trust is one way, then please mention the Trust Direction, which one is Trusting Forest and which one is Trusted Forest. If the trust is a 2-way trust, then both forests are trusted as well as trusting.
Access	Membership of Enterprise Admin group is required. Alternatively, the Domain Admin of Forest Root Domain (or equivalent access through delegation) can create Forest Trust.
Outgoing Trust Authentication Level	If we want users from the specified forest to have access to all computers in the local forest, on the Outgoing Trust Properties page, we have to click Forest-wide authentication. This option is preferred when both forests belong to the same organization. If we want to selectively limit authentication to particular users and groups from the specified forest, on the Outgoing Trust Properties page, we have to click Selective authentication. This option is preferred if the specified forest belongs to a separate organization.
SID Filtering Status	By default, SID Filtering is enabled. Disabling SID filtering imposes security risk.
Site Coverage	Is there site available or configured at Trusted Forest, with matching site name with Trusting Forest where resource exists ? For a two way trust, this needs to be done on both sides. If matching site name has been created, are Domain Controllers available within that site ? Alternatively, is this site linked with another AD site where Domain Controllers are present ? Are SRV Records (on the Trusted Forest) reflecting correct Domain Controller name which will do the authentication? Are network packets allowed between that Domain Controller and the Trusting Forest ?

Share via