Understanding Tenant Membership Findings

Tenant membership findings represent a unidirectional link between two types of assets within an identity provider's ecosystem:

  1. An asset from the Identity Provider - such as a user account, group, or resource.

  2. The "tenant" asset - represents the broader entity or domain encompassing the asset. The nature of the "tenant" depends on the specific Identity Provider.

These findings help identify relationships between assets and their tenants, offering insights into asset organization and hierarchy.

Linking Assets to a Tenant

For Active Directory (AD), assets are linked to their tenant (AD domain) using the distinguished name (DN) of the asset. The DN provides hierarchical information about the asset's location within the directory structure, which is used to determine the tenant.

Identifying the Tenant

When an asset corresponds to an AD object (e.g., a user or group), its tenant is identified as follows:

  • Extract the distinguished name of the asset.

  • Identify the tenant from the domain component (DC) entries in the DN.

Example

  • Asset DN: CN=UserA,CN=Users,DC=tenable,DC=corp

  • Tenant: DC=tenable,DC=corp (representing the AD domain).

Special Cases: Understanding Forest Root Domain Links

In some instances, the relationship between an Active Directory (AD) asset and its tenant (domain) may not follow the expected structure due to how AD handles certain objects. This section explains these "special cases" in more detail for clarity.

What Are Forest Root Domains?

Active Directory forests consist of one or more domains organized hierarchically. The forest root domain is the topmost domain in this hierarchy, encompassing all other domains within the forest. Some objects within AD reference the forest root domain in their distinguished names, even if they belong to a different domain. This behavior can affect how tenants are identified.

How Special Cases Arise

When identifying a tenant from an asset's distinguished name (DN), the domain components (DC=...) typically indicate the asset’s domain. However, there are exceptions:

  1. Forest-wide Configuration Objects

    • Certain AD objects are tied to configurations or settings that apply to the entire forest rather than a specific domain.

    • These objects have distinguished names ending with:

      • CN=Configuration,DC=...

    • Such objects link to the forest root domain instead of their "real" domain.

Example

  • DN: CN=Configuration,DC=forestRoot,DC=com

  • Tenant: The forest root domain (DC=forestRoot,DC=com).

  1. Forest DNS Zones

    • Some objects manage DNS zones shared across the entire forest. Their distinguished names end with:

      • DC=ForestDnsZones,DC=...

    • These objects are associated with the forest root domain, not their specific domain.

Example

  • DN: DC=ForestDnsZones,DC=forestRoot,DC=com

  • Tenant: The forest root domain (DC=forestRoot,DC=com).

Why This Matters

Understanding these special cases is crucial for accurately interpreting tenant membership findings. Key implications include:

  1. Tenant identification may differ from expectations

    • An object that appears to belong to a specific domain may instead be linked to the forest root domain.

    • Objects in the "Configuration" or "ForestDnsZones" naming contexts link to the forest root domain due to their forest-wide scope.

  2. Hierarchy and scope clarifications

    • Objects tied to the forest root domain often have broader applicability, as they manage or represent settings at the forest level.

  3. Use in troubleshooting and auditing

    • Misinterpretations of these cases could lead to errors when auditing domain structures or troubleshooting identity-related issues.

By understanding these nuances, you can confidently interpret findings and maintain accuracy in auditing and troubleshooting tasks.

Why Tenable Identity Explorer Chose "Tenant" as the Root Container Name

It is a generic, non-IdP-specific name for the root container of each Identity Provider (IdP) to ensure it works across different systems, such as "Entra tenants" and "AD domains."

The term "tenant" was chosen because it is widely understood in identity management, neutral across platforms, and already aligns with existing standards like Microsoft Entra. This ensures clarity, consistency, and flexibility for managing diverse IdP implementations.