Skip to main content
Applies to BloodHound Enterprise and CE
Yes you can! You can find all the details here
Yes you can!You can remove generic data by using one of the following three (3) options:
  1. Cypher commands in the Explore UI
    • Requires enable_cypher_mutations: true in config. For more info click here
  2. Admin UI → Database Management page
    • The following checkboxes will be displayed
    • All Data
    • Active Directory Data
    • Azure Data
    • … X Data (there will be 0 or more checkboxes here that allow you to delete any data that had been ingested with a source_kind provided)
    • Sourceless Data (checking this box will delete all entities that do not have a kind that can be found in the source_kinds table. You can observe the source_kinds your BloodHound instance is currently aware of by calling GET api/v2/graphs/source_kinds.)
  3. API: Clear-Database
No, not yet.In the initial BloodHound 8.0 release, OpenGraph nodes and edges are not supported in the Search or Pathfinding tab, so the Cypher tab must be used to query the data manually.
Have you built a cool project using OpenGraph and want it featured here? Already got your project in the list and need to update something? Open a “Library Change” issue on the BloodHound Docs repo and we’ll get it added for you!Submissions from the community will have a icon next to them while those by SpecterOps employees will have a SpecterOps icon.
Slow ingestion speeds are commonly seen when using a Neo4j graph database and are typically resolved by switching to a PostgreSQL backend. For full, officially supported OpenGraph functionality, use a PostgreSQL backend (see Requirements).To switch to a PostgreSQL graph database, set "graph_driver": "pg" in your bloodhound.config.json file and restart the BloodHound services/containers. You will need to re-ingest any data into the new database.
This behavior only applies to BloodHound Enterprise Edition (BHE). BloodHound Community Edition (BHCE) does not perform reconciliation.
One of the benefits of BloodHound Enterprise Edition is active management of the data in the graph to ensure freshness and accuracy. As part of this data management, there is a reconciliation step that runs shortly after ingestion and deletes orphaned nodes (nodes that have no edges). This is distinct from the edge post-processing behavior and is intended to reduce stale or unconnected objects in the graph.What this means:
  • Ingesting nodes without edges in BloodHound Community Edition (BHCE) successfully creates and displays all nodes, including orphaned nodes.
  • For the same data uploaded to BloodHound Enterprise Edition (BHE), the nodes without edges are ingested and immediately deleted during the reconciliation step.
Recommended workaround:Every node must be linked to another node. Use one of the following methods to link your OpenGraph nodes:
  • Ensure each node defined in the payload has at least one edge connecting it to another node (either predefined or otherwise defined in the payload). This is the simplest method to resolve orphaned nodes.
  • Anchor your OpenGraph data to a lightweight root node (an arbitrary node that orphaned nodes can be connected to without impacting the rest of the graph design). For example, create a single root node (such as (:OGRoot)) and add a containment edge (such as (:OGRoot)-[:OGContains]->(:YourNode)) to keep nodes from being orphaned and pruned. Use an edge kind that you exclude from your path queries if you don’t want it to affect pathfinding.
The initial OpenGraph implementation introduced the source_kind metadata field to let you create a source and quickly apply it to all nodes in the payload. This preliminary process applies the source_kind to all nodes in the payload—whether you define or reference them—which can create unintended side-effects when building hybrid paths that connect OpenGraph nodes to Active Directory (AD) or Azure (AZ) nodes.If you reference AD/AZ nodes when defining an edge in an OpenGraph payload that uses this metadata field, the system inadvertently applies the source_kind to those non-OpenGraph nodes. If you delete this source and its OpenGraph data, then those AD/AZ nodes are also deleted.
A more comprehensive solution is currently being designed to prevent this issue. The process described below is a workaround until the new design is implemented.
What this means:When you delete OpenGraph data that references AD/AZ nodes with an OpenGraph source_kind, those AD/AZ nodes may also be deleted even though they are part of the core AD/AZ graph.Recommended workaround:Use a two-step upload process when building hybrid paths.
  • First payload (isolated subgraph): Upload only your OpenGraph nodes and edges and set source_kind in metadata. Ensure that every node has at least one edge within this payload (for example, connect nodes to each other or to a root node and add a containment edge, such as (:OGRoot)-[:OGContains]->(:YourNode)). Do not link to AD/AZ objects in this payload.
  • Second payload (linking AD/AZ nodes): Link the isolated subgraph’s nodes to the AD/AZ nodes that connect your subgraph to existing AD/AZ entities. This avoids cross-source side effects when source_kind is present.