This is the latest in a series of posts we call “QOMPLX Knowledge.” These posts are intended to provide basic information and insights about the attack activity and trends that are driving malicious campaigns and that QOMPLX researchers encounter in our forensic work with customers.
To understand cross-forest trust relationships in Active Directory, you must first understand Active Directory’s logical structure as prescribed by Microsoft. Active Directory follows a clear hierarchy, from top to bottom. In that hierarchy are: forests, trees, and domains.
- Forests represent the complete Active Directory instance, and are logical containers made up of domain trees, domains, and organizational units.
- Trees are collections of domains within the same DNS namespace; these include child domains.
- Domains are logical groupings of network objects such as computers, users, applications, and devices on the network such as printers.
The domain objects that make up a forest share many critical structural elements. These include schema and configurations and a two-way transitive trust relationship that is automatically set up once objects join a domain in Active Directory. In these transitive relationships, trust is extended between parent and child objects in a domain and between child domains and objects trusted by those domains. These trust relationships are automatic and reflexive.
A cross-forest trust is a Windows Server feature that allows trust to be managed between the highest grouping—Active Directory forests—inside and outside your organization.
- Cross-forest trusts are trust relationships between Active Directory forests, trees, and domains
- Trusts are either transitive or non-transitive, and either one- or two-way
- Default trusts automatically established within Active Directory are Tree-Root and Parent-Child trusts
- Other trusts, such as external, realm, shortcut, and forest trusts, must be determined by a privileged administrator
Trust Relationships Across AD Forests
Trust relationships between domains across Active Directory forests must be in place before users are allowed to access network resources within the enterprise perimeter, or external resources beyond the network perimeter. This trust is a building block of identity and access management. This is especially true as businesses grow via mergers and acquisitions and as the workforces increasingly access work from home or other remote locations. Cross domain trust is also important as enterprises rely more upon third-party relationships with suppliers and partners to grow their business.
Forests essentially act as a security boundary for the structure making up Active Directory, but some experts caution that this approach may have its drawbacks.
“An Active Directory forest may be designed with multiple domains to mitigate certain security concerns but won’t actually mitigate them due to how domain trusts in the forest work,” warned Sean Metcalf, who runs the Active Directory Security website. “If a group has security requirements for their own domain due to security reasons, it is likely they really need their own forest," he wrote.
While there are many different ways to attack Active Directory, threat actors may also choose to abuse domain trust relationships. Gathering information about trust relationships during reconnaissance activities once an attacker has a network foothold, allows them to potentially identify pathways where lateral movement would be possible. Since domain trust relationships authenticate users on respective domain controllers and the respective trust allows users access to resources, attackers can also follow these same routes.
Attackers might follow a common strategy that would first involve enumerating trusts between forests, trees, and domains that builds a map of potential reach an adversary might have. A number of native Windows methods and API calls could be used to enumerate trusts, some of those include NLtest and dsquery, or open-source third-party tools such as Empire, PowerSploit, or PoshC2.
The same approach can be taken to enumerate users, groups, or servers that have similar trust relationships that could be abused as a bridge between domains. A threat actor might then have enough information to decide which accounts to target with known tools and attacks such as Pass the Ticket or Kerberoasting where service tickets or credential hashes are stolen from memory and used to privilege escalation and lateral movement, or are cracked in offline attacks and used to enable other attacks.
Enterprise Active Directory administrators may mitigate these attacks by auditing and mapping trust relationships between forests and domains, minimizing the number of them whenever possible. Another best practice is to segment sensitive domains on the network, reducing the attack surface available to threat actors.
Types of Trusts in Active Directory
In the meantime, as mentioned above, trust in an Active Directory forest is automatically established as two-way and transitive. This means that parent and child domains— tree and root—inherently trust each other. That means Active Directory objects are trusted to access resources across those domains. Moreover: as new child domains are created, they inherit trust from the parent domain and are able share resources, as well.
Non-transitive trust, therefore, is a trust that stops with the domains with which it was created. In such a scenario, domains A and B may trust each other, and B and C may trust each other, but that trust doesn’t extend between A and C without a separate one-way trust being created between A and C.
Trust, meanwhile, can be just one-way. For example, one domain is considered a trusting domain, and another is trusted, therefore trust is established either in an outgoing or incoming direction.
A high-level glossary of trusts within Active Directory looks like this:
- Tree-Root Trust: This type of trust is created when new root domains are added to an Active Directory forest. These are two-way transitive trusts and only domains at the top of each tree are part of this trust type.
- Parent-Child Trust: When new child domains are added, two-way transitive trust is automatically established by Active Directory between the child domain and its parent. Parent-Child and Tree-Root trusts are default trusts automatically established by Active Directory.
- Forest Trust: Forest trusts must be created by a privileged administrator. It establishes a trust relationship between two AD forests, allowing domains in either forest to transitively trust each other. The administrator may determine whether trust is two-way or one-way.
- Realm Trust: This type is used to establish either two-way or one-way trust relationships between an Active Directory forest and a non-Windows Kerberos environment such as UNIX, Linux, or UNIX-like operating systems.
- External Trust: External trusts are non-transitive trusts created between Active Directory domains and those located in a different forest, or between an AD forest and a pre-Windows Server 2000 domain such as Windows NT.
- Shortcut Trust: A shortcut trust manually establishes a trust relationship between domains in large Active Directory forests that allows authentication times to improve by shortening the trust path between domains.
The ability to create a cross-forest trust relationship is limited to those privileged users who are part of the Domain Admins or Enterprise Admins security group and have trust-creation privileges. Administrators, meanwhile, may also restrict access to resources to certain identities within a forest, if need be. Microsoft also provides a snap-in for AD domains and trusts that verifies trust between forests, trees, or domains.
Trust relationships between forests, trees, and domains establishes a path where users are able to access resources they require. As described, some of these relationships are automatically established by Active Directory and allow for two-way transitive trust. Cross-forest trusts, however, requires careful consideration of relationships between users and objects within domains, and the trust that must be established in order to readily access resources on both sides of the relationship.
Here are the previous entries in our QOMPLX Knowledge series; look for more in our QOMPLX Knowledge series in the days and weeks ahead: