Improve handling of domain objects and their trust relationships #18
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This ignores ADIDNS related domain objects e.g. ForestDnsZones and DomainDnsZones which do not have an objectsid and cause issues when importing into BloodHound. Filtering based on the objectsid property seems justified because the attribute is declared as required for proper functionality in the BOFHound documentation.
|
Hey, thank you for the PR! This is a great improvement over the temporary SID hack I had in place. I'll get this merged in once your bof PR is accepted 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Last year I spend some time comparing the graph produced by BOFHound with the one from the standard SharpHound ingestor.
My approach was to provide as much data as possible to BOFHound by querying every single LDAP object in every naming context (i.e. certainly not what you would do in a red teaming setting).
This pull request addresses some difference I observed in the context of domain objects and their trust relationship.
objectsidattribute are ignoredsecurityIdentifierof thetrustedDomainobject. This relies on proper parsing of the underlying LDAP attribute, see corresponding changes to pyldapsearch and the ldapsearch BOF. This essentially reverts Fix trusted domain duplication #14, but should still fix Trusted Domains are Duplicated #12 or at least I get the correct trust relationships: