-
Notifications
You must be signed in to change notification settings - Fork 299
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: Check for correct functioning of trust scanner for AD trusts #214
Comments
I do not see in the documentation what flag is corresponding to that |
You can find it in the first linked article. See the Unfortunately, reading the flag is a little tricky as it's encoded as part of a binary structure stored in the |
got it & thanks for reporting For me this is too short to include this in the upcoming version. |
implemented a parser. |
Awesome work, hopefully the open specifications team can answer your query quickly. Do you still need an example record from myself per your earlier comment? |
I'll take any samples to double check the current code |
Trying to reformulate what would be the rule:
|
Hey Vincent, I don't think I can provide a sample due to potential sensitivities around the data but very happy to test any beta builds when they're ready. Your proposed rule logic looks right to me (possibly influenced by Microsoft Open Specifications response). |
the answer was from me. There is no answer yet from MSFT |
A few years ago Microsoft released an update which adds additional protections for abuse of NTLM pass-through authentication:
Windows updates add new NTLM pass-through authentication protections for CVE-2022-21857
One component of this protection is a new "trust scanner" function wherein the PDC of the forest root domain will scan all domains in each trusting forest by issuing LDAP queries every 8 hours. The gathered information is stored in the
msDS-TrustForestTrustInfo
attribute of each Trusted Domain Object (TDO). In most configurations the trust scanner will work without any configuration changes, but some will require changes so the PDC can successfully issue the required LDAP queries to the trusting domains.In addition to the the obvious network connectivity requirements (LDAP access, associated services for name resolution, etc ...):
The latter one is probably the most common misconfiguration, as it requires explicit steps that are not a default configuration when a trust using selective authentication is used.
As for what PingCastle could potentially do, by reading the msDS-TrustForestTrustInfo attribute it should be possible to determine if the trust scanner is operating correctly by the presence of a
ForestTrustScannerInfo
record. In addition, it can be determined if the protections are disabled for the trust or specific domains via the flags in the records stored in the attribute.The text was updated successfully, but these errors were encountered: