How to fix an obsolete AD Trust

When running a few Active Directory (AD) scans to check for any open vulnerabilities or misconfigurations, I discovered that one of our trusts was marked as not having SID filtering enabled. For those who don't know what SID filtering is, it basically helps to prevent security identifiers (SIDs) from being used inappropriately. This is crucial because SIDs are unique identifiers for each user, group, and computer account in a network, and improper use can lead to security risks such as unauthorized access.

SID filtering ensures that SIDs from a trusted domain are not passed to the trusting domain unless they are explicitly allowed. This helps to prevent SID history abuse, where SIDs from an external domain might be used to gain elevated privileges in another domain. In our case, the absence of SID filtering meant that this particular trust relationship was potentially vulnerable.

Now, this normally wouldn't be a big issue. SID filtering can be disabled and enabled with just one command, and it is typically disabled when you want to migrate users, groups, etc., from one domain to another. The issue this time was that the trust which didn't have this filter enabled was a Parent-Child Domain Trust. These kinds of trusts have SID filtering enabled by default.

Identifying the Problem

Verifying if SID filtering was actually disabled or if the scanner tool had an issue showed that we actually weren't protected. However, all GUIs regarding trust (such as AD Domain & Trust) showed that everything was normal. After a bit of research, I found the issue. When you need to troubleshoot a trust, the best way to start is to check the general settings that are applied to it. This can be done with the PowerShell command Get-AdTrust -Filter*, which showed something rather unusual. The trust between our parent domain and our child domain had the TrustAttributes set to 4194304, which, according to Microsoft's Documentation, means "Previously used trust bits, and are obsolete."

This is rather unhelpful and doesn't explain how trust with these settings even functions. What was even more concerning was that the IntraForest attribute was set to false. Now, that is something you absolutely don't want to see on a Parent-Child Trust. Intra-forest Trusts are a type of trust that is transitive and exists within the same forest, which typically involves higher levels of trust and tighter security integrations.

Note: All images presented have been censored to a certain extent. The relevant information for this blog post is marked. Result of Get-AdTrust with obsolte

As a comparison, another child domain trust returned the following as the expected result:

Result of Get-AdTrust healthy

Understanding the Risks

Before diving into my solution, which ultimately fixed the issue for me, I want to emphasize that we deal with sensitive configurations here. You probably don't want to try this on your production systems without thorough testing. Such changes should always be tested in a staging environment before being applied to the production system. While figuring out a solution for this problem, I broke the trust multiple times in our staging environment.

It's also worth noting that Microsoft does not provide specific guidelines for this kind of issue. The solution came from trial and error. Additionally, I could not replicate the issue in a new environment myself and needed to clone the domain controllers (DCs) to test it properly. Both domains used at that time had a domain functional level of Windows Server 2008 R2, and both trust-supported Kerberos AES encryption.

Steps to Fix the Issue

Irrelevant if you only want to fix the Symptoms or the core Issue, all that are listed below need to be executed from both sides. As an example, if I say `Write-Output "currentDomain" "trustedDomain", then you will out current Domain with the domain that you domain controller your are currently connected with and the trusted domain would be the remote one. After that you would switch to the other domain and do the same.

Also, the order in which you execute the command seems to be relevant.

Fix the Symptoms

If you have this kind of issue and don't want to risk breaking your trust completely but want to fix the SID filtering issue, you can simply enable SID filtering manually in both domains again using the following command: netdom trust currentDomain /domain:trustingDomain /enablesidhistory:No /usero:domainAdmin /passwordo:domainAdminPwd

This command will re-enable the SID filter. Both /usero:<username> and /passwordo:<password> are optional and only needed if you don't have domain admin rights. In my experience, only performing this step will not break anything. However, your trust will not be marked as an Intra-Forest trust but instead will be considered by Active Directory as an external trust. If you are fine with that, this is the easiest and safest option.

Fix the Core Issue

To fix the issue, you must first enable the SID filter manually, as already shown above. If you receive a message stating that "SID history is already disabled for this trust," this is fine and can be ignored.

After that, you will need to quarantine the trust. Quarantining is typically done when you want only the SIDs from a single trusted domain to be valid. This will break the transitivity of that trust and, therefore, normally should not be done to a healthy Parent-Child Trust.

You can enable the quarantine using the following command in both domains: netdom trust currentDomain /domain: trustingDomain /quarantine:yes /usero:domainAdmin /passwordo:domainAdminPwd This command will enable the quarantine on both domains, which will also force an update to the trust attributes. The value should become 36, and the Intra-Forest value should update itself back to True. Both /usero:<username> and /passwordo:<password> are optional and only needed if you don't have domain admin rights.

If everything is done correctly, the trust should look like this from both sides: Result of Get-AdTrust with quarantine

Next, you should be able to deactivate the quarantine on both sides using the following command: netdom trust currentDomain /domain: trustingDomain /quarantine:no /usero:domainAdmin /passwordo:domainAdminPwd This disables the quarantine, changing the trust attributes to 32 (the value we want). Both /usero:<username> and /passwordo:<password> are optional and only needed if you don't have domain admin rights.

Now, the trust should be restored to the default state of a Parent-Child Domain, and everything should work as expected.

Check the Health of AD

The last step is to check that everything still works, especially regarding the trust's transitivity. As mentioned before, the changes we applied might break the transitivity. Therefore, for the next few hours, you should ensure that replication stays healthy, that you can access resources across the trust, check for any unexpected warnings or errors in the DC logs, and monitor the general amount of logs to ensure they don't suddenly increase.