Tenable Research reveals an Active Directory anomaly: intra-forest trusts created under Windows 2000 lack a key identifying flag, even after domain and forest upgrades. Learn how to find this legacy behavior persisting to this day, and use crossRef objects to correctly distinguish these trust types.

We don’t always get to go time traveling in our work here at Tenable Research. But a recent investigation into Active Directory trusts sent us on a trip in the wayback machine to the era of Windows 2000. We discovered that on very old Active Directory trusts created on Windows 2000, intra-forest trusts do not have the TRUST_ATTRIBUTE_WITHIN_FOREST flag enabled. The flag, which was introduced in Windows 2003, was not retroactively applied to existing trusts at the time. Even when the domain is upgraded to more modern versions (like 2016), this old trust attribute never updates automatically. This makes an internal Parent-Child trust look exactly the same as a potentially insecure external trust (one lacking the security setting known as SID Filtering/Quarantine), because both can show an empty or zero value for the trustAttributes.

A bit of Active Directory history

Active Directory trusts are represented by Trusted Domain Objects (TDOs) stored as objects of class trustedDomain. The description of their trustAttributes in the official [MS-ADTS] Active Directory technical specification defines the TRUST_ATTRIBUTE_WITHIN_FOREST value simply as:

If this bit is set, then the trusted domain is within the same forest.

Only evaluated on Windows Server 2003 and later.

One could easily ignore the mention of Windows Server 2003, considering how old it is, and assume it wouldn’t cause a problem nowadays. But, given what we observed in some AD domains, it also means that trusts created with Windows 2000 didn’t have this flag. And we can only assume that it was never retroactively applied (unless the trust was re-created of course), which is an issue.

Unfortunately we didn’t find any official documentation to confirm that theory.

We only found an old personal blog where the author wondered about the same issue, while noting that it concerned a migrated NT4 domain. A more recent blog post mentions a very similar situation, with some tricks to fix it; it isn’t official Microsoft guidance, however, and should be taken with extreme caution.

Finally, we spoke with several seasoned AD experts who confirmed that they have encountered similar situations.

Reproducing the issue

To confirm our hypothesis, we set about reproducing the issue in our lab by creating an Active Directory forest called prehistoric.lan, which comprised two AD domains connected via an intra-forest Parent-Child trust relationship:

• prehistoric.lan (PREHISTORIC short name): the parent


• child.prehistoric.lan (CHILD short name): the child

The setup began with one Windows 2000 domain controller in each domain. Therefore, the forest (FFL) and domain functional levels (DFL) were 2000.

Immediately we observed what we expected: the trustAttributes were equal to 0 in the TDO, in the parent domain, representing the trust with the child domain:

Out of curiosity, we also looked in the opposite direction to see if the TDO in the child domain represented the trust with its parent:

The trustAttributes wasn’t 0, but 4194304 = 0x400000 (TRUST_ATTRIBUTE_TREE_PARENT) which is documented as “Previously used trust bits, and are obsolete.” This one was not a concern for us.

Then we upgraded the parent prehistoric.lan domain to the 2003 domain functional level by adding a 2003 domain controller, then removing the initial 2000 domain controller. Remember, this is the version when the new TRUST_ATTRIBUTE_WITHIN_FOREST flag was introduced. However, as we hypothesized, the TDO in the parent domain kept its trustAttributes=0:

We thought perhaps it was a matter of forest functional level, so we also upgraded the child domain to domain functional level 2003 with the same steps, then upgraded the forest functional level to 2003. Same observation for the TDO in the parent domain, which is still set to trustAttributes=0:

For an even higher level of confidence, we then upgraded the parent prehistoric.lan to the 2016 domain functional level and the observation remained the same:

And finally, as you may have guessed, we also upgraded the child domain to domain functional level 2016, then upgraded the forest functional level to 2016, too. And the trust remained stuck with trustAttributes=0 like it did at the very beginning in the Windows 2000 era:

We didn’t upgrade further. We were very confident that our hypothesis was confirmed: an intra-forest trust, created under Windows 2000, will never automatically obtain the TRUST_ATTRIBUTE_WITHIN_FOREST flag even when the domain and forest are later upgraded.

Here comes the confusion

We have confirmation that we can be missing the TRUST_ATTRIBUTE_WITHIN_FOREST flag even for intra-forest trusts, but is that really an issue? Can’t we simply ignore it? After all, we have the other TRUST_ATTRIBUTE_FOREST_TRANSITIVE flag set for cross-forest trusts. We should be good, right?

Unfortunately, the answers are “no.” The reason? External trusts, which are another kind of inter-forest trusts. They don’t have any dedicated flag in “trustAttributes”, so they can be found with trustAttributes=0 or, more commonly, with trustAttributes=4 when the TRUST_ATTRIBUTE_QUARANTINED_DOMAIN flag is correctly enabled.

Here’s an example, taken from a different lab, of an external trust between two forests, first with trustAttributes=4 when quarantined, then with trustAttributes=0 after disabling the quarantine:

Here lies our problem: trustAttributes=0 can mean either:

• intra-forest trust which is too old to have the TRUST_ATTRIBUTE_WITHIN_FOREST flag set; or


• external trust without quarantine

Surprisingly, we also noticed that the classic “Active Directory Domains and Trusts” admin tool is not affected by this confusion, as it’s able to show the correct trust type (Parent-Child in our case) for these trusts despite the ! We suppose that there is a mechanism, somewhere, to fix the interpretation of these trusts, or that it relies on other indicator(s). Unfortunately, we didn’t find the definitive location where this magic happens. We confirmed the observation in the first lab we used, see how the “Active Directory Domains and Trusts” admin tool correctly shows the trust type as “Child” despite trustAttributes=0:

We wondered if perhaps we could find the answer in the official AD PowerShell module, which relies on Active Directory Web Services (ADWS), and which is easier to reverse-engineer. Unfortunately, the Get-ADTrust cmdlet doesn’t have the same magic. It interprets directly trustAttributes, and so incorrectly considers that this Parent-Child trust is not intra-forest!

Therefore, we had to find an alternative way to interpret these Trusted Domain Objects where trustAttributes=0. We thought about finding hints in their other attributes but there was nothing characteristic so we had to find a different source of information.

CrossRef to the rescue

At this moment we remembered about the crossRef technical objects, also stored in AD. They are used to store different naming context types, but those relevant for us are the domain crossRef objects. Each Active Directory domain has a corresponding crossRef object, but only for those that are in the forest (e.g. a crossRef is not created when there’s a forest trust), so we have our solution.

When there’s a trust object with trustAttributes=0, search for a corresponding crossRef object where trustedDomain.trustPartner == crossRef.dnsRoot:

• There’s a corresponding crossRef, which by definition means that the target domain is in the forest: so it’s an intra-forest trust


• Otherwise, if there’s no crossRef, it means that the target domain isn’t in the forest: so it’s an external trust

This alternative rule allowed us to interpret the correct types for these confusing trusts (others continue using existing rules) and the updated interpretations were validated outside our lab in a real-world environment.

Conclusion

Active Directory is full of surprises, even on very old topics, such as trusts, that we may think are fully mastered by now. It was an interesting discovery which brought us back ~25 years in the early days of Active Directory.

A correct interpretation of Active Directory trusts is required in AD exposure management solutions such as Tenable Identity Exposure, whose Dangerous Trust Relationships Indicator of Exposure implements the alternative we identified for this confusing case. More broadly, we hope that sharing this discovery will help AD administrators and security experts to properly understand when they stumble upon these in their manual reviews or in their custom scripts.

We are very proud to serve Tenable customers who trust us with helping secure their Active Directory domains that they created two decades ago and maintain to this day.

The post Active Directory Trust Misclassification: Why Old Trusts Look Like Insecure External Trusts appeared first on Security Boulevard.

Clément Notin

Source: Security Boulevard
Source Link: https://securityboulevard.com/2025/11/active-directory-trust-misclassification-why-old-trusts-look-like-insecure-external-trusts/