We manage a multi-tenant Google SecOps (Chronicle) instance ingesting Windows Active Directory data from several independent customer environments, each isolated via Data RBAC namespaces/scopes.
We've discovered that some UDM Entities (both well-known built-in accounts like Administrator/Guest/krbtgt, and at least one regular user account) are being merged into a single entity node even though they originate from completely separate AD domains/namespaces.
Example of what we're seeing:
Say we have two separate tenants, "Tenant A" and "Tenant B", each with their own independent Active Directory domain. When we search for a user entity scoped to Tenant A (e.g., filtering by graph.entity.namespace = "tenant-a"), the returned entity record contains an unexpected mix of data:
graph.entity.namespace = "tenant-a"
graph.metadata.event_metadata.base_labels.namespaces = "tenant-a"
graph.metadata.event_metadata.base_labels.namespaces = "tenant-b" <- unexpected
metadata.event_metadata.base_labels.ingestion_kv_labels.key = "agency"
metadata.event_metadata.base_labels.ingestion_kv_labels.value = "tenant-a"
metadata.event_metadata.base_labels.ingestion_kv_labels.key = "agency"
metadata.event_metadata.base_labels.ingestion_kv_labels.value = "tenant-b" <- unexpected, different tenant's label on the same entity
relations.entity.namespace = "tenant-a"
relations.entity.group.group_display_name = "Domain Users"
relations.entity.namespace = "tenant-b" <- unexpected, Tenant B's group membership showing up
relations.entity.group.group_display_name = "Domain Users"
In other words, a single entity record ends up carrying ingestion labels, namespace tags, and group relationships from two different tenants at once — even though these tenants have completely separate ADs and are supposed to be isolated from each other via Data RBAC scopes.
Root cause we found:
Upon inspecting the raw entity data, we found that the merged entities share an identical product_entity_id (derived from the Windows AD ObjectGUID). It appears entity resolution/deduplication is keyed on product_entity_id + vendor_name + product_name, without namespace as part of the uniqueness constraint. So when two tenants happen to have AD objects with the same GUID (in our case, likely because their AD servers were provisioned from cloned VM templates without regenerating object GUIDs), their entities get merged into one, and relations/group memberships bleed across tenants.
Questions for the community:
- Has anyone else run into cross-namespace entity merging in a multi-tenant Chronicle setup?
- Is there a supported way to force entity resolution to respect namespace boundaries (e.g., some configuration under Data RBAC or ingestion settings)?
Any insight or pointers to relevant documentation would be greatly appreciated.
