Skip to content

[Query Issue]: Direct Principal Rights Assignment #37

New issue
New issue
Closed
#43
Closed
[Query Issue]: Direct Principal Rights Assignment#37
#43

Description

@kaasimir
kaasimir
opened on Oct 28, 2025

Query GUID

1d9c6ae3-38fc-4089-b5ad-fc3be0fa8eec

Query content

MATCH p=(n:Base)-[r:GenericAll|GenericWrite|WriteOwner|WriteDacl|ForceChangePassword|AllExtendedRights|AddMember|AllowedToDelegate|AllowedToAct|AdminTo|CanPSRemote|CanRDP|ExecuteDCOM|AddSelf|DCSync|ReadLAPSPassword|ReadGMSAPassword|DumpSMSAPassword|AddAllowedToAct|WriteSPN|AddKeyCredentialLink|SyncLAPSPassword|WriteAccountRestrictions|WriteGPLink|ADCSESC1|ADCSESC3|ADCSESC4|ADCSESC6a|ADCSESC6b|ADCSESC9a|ADCSESC9b|ADCSESC10a|ADCSESC10b|ADCSESC13]->(:Base)
WHERE (n:User OR n:Computer)
RETURN p
LIMIT 1000

Issue description

First off - top notch query. Great way to check if RBAC is implemented correctly. Kudos to you guys.

However, if I run the query as is, I get 1000 (due to the Limit in line four) different objects, including groups etc, which made no sense to me. After checking it, there seems to be a typo in there.

When I change the third line to "RETURN n", I get a bunch of users and computers, that either have some sort of execution privileges or outbound object control directly assigned to them. This seems to be the output as intended I assume.

I also included a check for enabled users and computers only, since I usually get too many results otherwise. It's optional however, feel free to remove it if you don't see the need.

So the query that works great for me looks like this:

MATCH p=(n:Base)-[r:GenericAll|GenericWrite|WriteOwner|WriteDacl|ForceChangePassword|AllExtendedRights|AddMember|AllowedToDelegate|AllowedToAct|AdminTo|CanPSRemote|CanRDP|ExecuteDCOM|AddSelf|DCSync|ReadLAPSPassword|ReadGMSAPassword|DumpSMSAPassword|AddAllowedToAct|WriteSPN|AddKeyCredentialLink|SyncLAPSPassword|WriteAccountRestrictions|WriteGPLink|ADCSESC1|ADCSESC3|ADCSESC4|ADCSESC6a|ADCSESC6b|ADCSESC9a|ADCSESC9b|ADCSESC10a|ADCSESC10b|ADCSESC13]->(:Base)
WHERE (n:User OR n:Computer)
AND n.enabled = TRUE
RETURN n
LIMIT 1000

Cheers guys

BloodHound version

latest version

BloodHound DB

default Neo4j

Activity

  1. martinsohn commented on Oct 30, 2025

    @martinsohn
    martinsohn
    on Oct 30, 2025
    Collaborator

    Hi @kaasimir, thank you, that makes sense.

    What do you think of the full .yml below

    • Changed name and description to explicitly state it's returning principals only
    • Changed resource to NIST RBAS
    • Added n.enabled, but commented by default
    • Added new BloodHound edges: WriteOwnerLimitedRights|OwnsLimitedRights|CanApplyGPO|ManageCA|ManageCertificates
    name: Principal With Direct Rights Assignment
guid: 1d9c6ae3-38fc-4089-b5ad-fc3be0fa8eec
prebuilt: false
platforms: Active Directory
category: Active Directory Hygiene
description: Returns principals with rights assigned directly to them instead of to groups they are a member of. Active Directory best practice requires granting rights to groups, then adding users as group members. This role-based access control (RBAC) approach ensures permissions are easily auditable and manageable. Results include inherited rights, which must be modified at the parent container level.
query: |-
  MATCH p=(n:Base)-[r:GenericAll|GenericWrite|WriteOwner|WriteDacl|ForceChangePassword|AllExtendedRights|AddMember|AllowedToDelegate|AllowedToAct|AdminTo|CanPSRemote|CanRDP|ExecuteDCOM|AddSelf|DCSync|ReadLAPSPassword|ReadGMSAPassword|DumpSMSAPassword|AddAllowedToAct|WriteSPN|AddKeyCredentialLink|SyncLAPSPassword|WriteAccountRestrictions|WriteGPLink|ADCSESC1|ADCSESC3|ADCSESC4|ADCSESC6a|ADCSESC6b|ADCSESC9a|ADCSESC9b|ADCSESC10a|ADCSESC10b|ADCSESC13|WriteOwnerLimitedRights|OwnsLimitedRights|CanApplyGPO|ManageCA|ManageCertificates]->(:Base)
  WHERE (n:User OR n:Computer)

  // Uncomment the below to only search enabled principals.
  // AND n.enabled = true

  RETURN n
  LIMIT 1000
revision: 2
resources: https://csrc.nist.gov/Projects/Role-Based-Access-Control
acknowledgements: Martin Sohn Christensen, @martinsohndk

    Do you think there should be a second .yml file for a query that can RETURN p, or just add some lines to this query that are commented by default like below?

    // Switch the comments below to show rights granted to a specific principal
// WHERE n.name = "USER@DOMAIN.LOCAL"
// RETURN p
RETURN n

  2. kaasimir commented on Oct 30, 2025

    @kaasimir
    kaasimir
    on Oct 30, 2025
    Author

    Hi @martinsohn ,

    thx for the reply!
    Your fleshed out query looks good too me. I tested it and it delivers the same result as my proposed one, seems great :)
    From my point of view this could be implemented like you suggested it.

    Regarding your question:

    Do you think there should be a second .yml file for a query that can RETURN p, or just add some lines to this query that are commented by default like below?

    I'm not 100% sure I understand your point, however to me it seems like this feature is already implemented, since you can always just check for inbound control on an object. So if the query would deliver a similar result, I'm not sure an extra query is needed. However if I misunderstood I hope no hard feelings. Just let me know in case and I'll have another look.

    Cheers,
    kaasimir

  3. martinsohn
    added a commit that references this issue on Jan 3, 2026

    Rename & improve 'Direct Principal Rights Assignment'

    eb32e69

  4. martinsohn commented on Jan 3, 2026

    @martinsohn
    martinsohn
    on Jan 3, 2026
    Collaborator

    Hi @kaasimir, I will close this issue with #43

    We decided to keep most of the original query by having RETURN p because that behavior is what we use in similar pre-built queries:

    By returning the path, the user is immediately able to see the directly assigned rights. The user cannot rely on Outbound Object Control as it also returns indirect rights.

  5. martinsohn
    closed this as completedon Jan 3, 2026
  6. d3vzer0
    added a commit that references this issue on Jan 5, 2026

    Query updates - bugfixes & improvements (#43)

    7eae011
  7. d3vzer0
    added a commit that references this issue on Feb 17, 2026

    fix: Query updates for owned clauses (#47)

    4e6dd3a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions