Checkout SlayerLabs.com!
Networks Engineered to Exploit.
- Windows/UNIX - Domains/Subnets - Initial/Post/Lateral - Low Cost VPN Ranges -

Trusts & Security 101

This post will be a brief guide on the exciting subject of Domain Trusts and Trust Security. A few more detailed write-ups by Microsoft that will be used as references:

• Explaining & Configuring Trusts
• Technet - Top Issues with AD Trusts
• Technet - Trust Technologies
• Technet - Security Considerations for Trusts
• Managing Trusts - Server 2008-2012R2

This post will attempt to keep this topic relatively straight-forward and simple as trust terminology can get a bit confusing.

Trust Basics

A Trust is a relationship that allows for Authentication and Authorization to share resources. User Alice from liberty.local may be able to authenticate to north.liberty.local, but may not have the authority to access any resources (shares, printers, etc) within that domain. She can Authenticate but is not Authorized.

There are two-way, one-way, transitive and non-transitive trusts. A Transitive Trust is a trust which is extended beyond the two domains between which it was formed. By default subdomains within a Domain Tree have a Transitive Trust.

For example, domains example.com, child.example.com and blog.child.example.com all fall within the same Tree and will all have a transitive trust - trust flows upward within trees.

Depending on the type of Domain, the default, or implicit trust will differ:

• Parent Child Trust: Transitive - canada.local to north.canada.local
• Tree Root Trust: Transitive - Not an Forest or External trust, but the start of a new Domain name within an existing forest - the root of a new tree aka tree root
• Forest Trust: Transitive - Trust between two different forests - canada.local to usa.local
• Shortcut Trust: Non-Transitive - Trust between child domains - idaho.usa.continent.local to manitoba.ca.continent.local
• External Trust: Non-Transitive - Trust between one Domain within a Forest to another Domain within another Forest - sales.canada.local to accounts.usa.local
• Realm Trust: Non-Transitive - Windows Domain to Non-Windows Domain - Windows to Kerberos

Here is a visual example from Microsoft outlining a few Trust types. The resources cited up top dive deep into each trust type if things are still fuzzy.

Trusting vs Trusted Domains

A Trusting Domain is the domain which is allowing its resources to be accessed. A Trusted domain is a domain which users/groups/resources can access the other Domains resources.

One way to remember this is:

• trusTED - Ted, the user/person is granted access.
• trustING - A thING or resource that is being accessed.

Securing Trusts

Although there are plenty of examples and techniques on how to attack domain trusts, there aren’t a whole lot of resources on Securing Domain Trusts. Most of this can be attributed to general AD security practices. If a Domain Admin of a trusted Forest has been compromised, then your AD infrastructure is, for the most part, fair game.

Intraforest trusts (child domain, shortcut, tree-root) are inherently secure. As mentioned previously, the trouble comes from Interforest trusts, or External/Forests trusts.

If an attacker wanted to compromise a large bank for example, they may enumerate other Forest Trusts as initial vectors. Are the security practices at a mom and pop financial processing site just as secure as this major bank with plenty of resources? Maybe the users at mom and pop financial service are more susceptible to phishing attacks because they don’t have the budget for official cyber security training? The scenarios go on and on.

Microsoft has Security Considerations for Trusts guide you should definitely go over. This section will be a simple overview of the official documentation and other relevant resources.

Officially there are only a few ways to secure interforest trusts: SID Filtering, SID History and Selective Authentication

SID Filtering & History

SID Filtering prevents users from one Forest to grant elevated privileges within another Trusted Forest - this is Enabled by default. Eg: Domain Admin Bob, on canada.local could not elevate privileges of himself of other users within canada.local onto usa.local.

Attackers may use SID History to elevate privileges or pivot onto External Trusts. An attacker could monitor network authentication requests to obtain SIDs of Domain or Enterprise admin, then add this SID to their low priv domain user SID histroy. Once this SID is added in the SID history, further access control mechanisms to resources will consider all SID data/history to determine if that user or principle has the rights to the resource.

SID Filtering can provide countermeasures against this attack by disallowing, or filtering inbound access requests for SIDs that do not refer to the directly trusted Forest or Domain. This may limit an attack on a non-trusted domain from spoofing a Domain Admins SID from a trusted domain/forest.

SID History should also be disabled between Forest Trusts.

Why Would SID Filtering be disabled? - AD migrations. Using ADMT and NetDom, admins should disable SID filtering to grant permissions from the old Domain during the migration. How long will the full migration take? Maybe the admins will keep it disabled until the migration has tied all the loose ends? By that time would they forget to re-enable it?

Here’s a 2016 Active Directory STIG that covers SID Filtering and SID History. As mentioned above, the two primary configurations to secure trusts:

• Ensure SID filtering is Enabled on all External Trusts
• Ensure SID history is Disabled for all Forest Trusts

Selective Authentication

Another layer of security System Admins can provide is Selective Authentication. Admins can select which groups of users can access or authenticate to the trusting resources. Do you want everyone to be able to authenticate to your resources?

When adding the External Trust to your DC, you’ll be prompted to allow Domain-Wide Authentication or Selective Authentication. If you decide to add Selective Authentication, be sure to grant the desired users/groups Allowed to Authenticate security permission through Active Directory Users and Computers.

Audit

So how do I check if all these are set?

To check if SID Filtering is enabled, use netdom via cmd. In this example usa.local is the trusting and canada.local is the trusted.

C:\>netdom trust usa.local /d: canada.local /quarantine

SID filtering is enabled for this trust. Only SIDs from the trusted domain
will be accepted for authorization data returned during authentication. SIDs
from other domains will be removed.

The command completed successfully.

Great, the output is showing successful. If you desire to disable SID Filtering update to /quarantine:No.

Now, to check SID History:

C:\>netdom trust usa.local /d: canada.local /enablesidhistory
SID history is disabled for this trust.

The command completed successfully.

In this case it may be reasonable, and OK according to Microsoft to enable SID History as long as it’s an External Trust. This may be useful if you migrated users from one domain to the other, and they still needed to access resources on their original domain. In this case, SID history would be beneficial.

This topic can get confusing without real-world examples, so be sure to checkout the sources if you have any further questions.