AD Trust Attribute

Question

I have a doubt regarding AD-Trust information......
. Note: The following info has been acquired by running the Get-ADTrust command on the primary DC of a domain.

SelectiveAuthentication : False
showInAdvancedViewOnly : True
SIDFilteringForestAware : True
SIDFilteringQuarantined : False
Source : [redacted]
Target : [redacted]
TGTDelegation : False
TrustAttributes : 72
trustDirection : 3
TrustedPolicy :

The Trust Attribute value generally signifies the type of trust relationship (external, forest, etc)
According to the documentation provided by Microsoft (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e9a2d23c-c31e-4a6f-88a0-6646fdb51a3c?redirectedfrom=MSDN) this value can be one of the given list.
However the value of 72 = 0x00000048 in big endian format.
This indicates that the trust relationship is a combination of the following:
TAFT (TRUST_ATTRIBUTE_FOREST_TRANSITIVE)
0x00000008

And

TATE(TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL)
0x00000040

This means that we can assume it’s a trust between two distinct forests maybe in a situation of an acquisition/merger which requires federation to the resources of the scanning domain.
The trust attributes mean that the trust relationship is a cross-forest trust which should act as an external trust for SID Filtering purposes.
Now my doubts are :
• As “SIDFILTERINGQUARANTINED” is False, the trust (to be treated as an external for SID Filtering purposes) SID Filtering is disabled. He documentation for TATE specifies that “Only evaluated if SID Filtering is used and only evaluated on cross-forest trusts having TRUST_ATTRIBUTE_FOREST_TRANSITIVE. So does the TATE functionality get called?
• SIDFilteringForestAware is set to True. According to this blog, this attribute is “ Set to True if a forest trust is configured for selective authentication”. Now, the Selective Authentication is set to “False”. IS this not contradictory in nature?

Answer 1

Hi @Geet Pradhan

Let me provide a little bit of background that might help.

When a user accesses resources across a trust, the user's access token is passed to the target server they are accessing on the other side of the trust, yes there are a few additional steps that are completed by Kerberos, so yes this is a simplification but we are only interested in the user access token for this conversation. The user's access token is made up of SIDs, claims, and rights, these define what resources and rights the user has. The list of SIDs should only contain SIDs from the source domain and are used to provide access to resources in the target domain.

An exploit was identified that if you were to craft your access token to include SIDs from the target domain, it was possible that a bad actor could access resources that they were not granted access to. To help prevent this SID filtering was introduced, in simple terms with this option is enabled when accessing resources across the trust the target server would remove or ignore all the target SIDs in the presented access token. By enabling SID filtering you are enabling the removal of target SID from the access token. However these are not the only SID that get removed, a number of in-built or well-known SIDs are also removed, these are listed in the previous article I shared. These SIDs have the same SID in both the source and target domains, by removing these possible elevated permissions, permissions from one domain are not inherited in the target domain. Requiring specific permissions to be assigned to allow access to resource controlled by these well-known SIDs.

Due to a number of factors in the way authentication works in Windows, users in the source domain could access resources in the target domain, as they can see or access resources that are permissioned with everyone and authenticated user groups. To help prevent this and provide another layer of control what users can access, Selective Authentication was introduction. When Selective Authentication is enabled, the user must be assigned specific permissions on the target server to allow the user to access the resources on the server, if the user is not granted this permission, the user will not be able to access the resources on the server, even if they have permissions to access the resources.

That's teh background, so back to your question, the main problem is here is that the naming of the attributes in the TDO can cause confusion. While they are both called SID filtering, they achieve the out come in complete different ways.

I hope that helps.

Gary.

Answer 2

Hi @Geet Pradhan

Take look at this tool, it provides the details on TDO in a number of different way and can be used to confirm the means of values.

The DsTrust option displays the values returned by the DsAPI call, as used by the get-dstrust command.

Or if you use ldap-browser to view the TDO objects in the default name co text under cnn=system,dc=<domain>,dc=<com>

Gary.

Answer 3

Hi

Answering question based on my understanding.

As “SIDFILTERINGQUARANTINED” is False, the trust (to be treated as an external for SID Filtering purposes) SID Filtering is disabled. He documentation for TATE specifies that “Only evaluated if SID Filtering is used and only evaluated on cross-forest trusts having TRUST_ATTRIBUTE_FOREST_TRANSITIVE. So does the TATE functionality get called?

Yes the Tate is called as there are multiple levels of inspection and rejection of SIDs in the authentication request (PAC), the action that are taken are defined here 55fc19f2-55ba-4251-8a6a-103dd7c66280.

SIDFilteringForestAware is set to True. According to this blog, this attribute is “ Set to True if a forest trust is configured for selective authentication”. Now, the Selective Authentication is set to “False”. IS this not contradictory in nature?

I'm not completely sure on your comment/question here, I agree the name is totally confusing as selective authentication has nothing to do with sid filtering, but is the use of SID in the target domain to allow access to resources based on a sid.

Gary.