Microsoft Fabric Mirrored Azure Databricks Catalog: PowerBINotAuthorizedException with cross-tenant firewalled ADLS Gen2

Pablo sanchez 20 Reputation points
2026-06-08T10:26:42.23+00:00

Hi all,

I have a Fabric + Azure Databricks setup that I cannot find a documented working configuration for, and I am hoping someone here has solved it.

Setup:

  • Microsoft Fabric workspace in Tenant A.
  • Azure Databricks workspace in Tenant B, with its Unity Catalog and the underlying ADLS Gen2 storage account also in Tenant B.
  • The Fabric workspace consumes the Databricks Unity Catalog via Mirrored Azure Databricks Catalog (the dedicated Mirrored Catalog item, not a OneLake shortcut).
  • The cloud connection in Fabric authenticating against Databricks is configured with a cross-tenant service principal.
  • The ADLS Gen2 storage account in Tenant B has its firewall enabled (public network access set to "enabled from selected virtual networks and IP addresses").

Observed behaviour:

  • The Mirrored Catalog refresh works correctly when the storage firewall is OFF.
  • When the storage firewall is ON, the Mirrored Catalog refresh fails with PowerBINotAuthorizedException.
  • A VNet data gateway deployed in Tenant A reaches the same ADLS in Tenant B successfully for Dataflow Gen2, but fails for the Mirrored Catalog flow with the same PowerBINotAuthorizedException.

What the docs say:

  • Per the Mirrored Azure Databricks Catalog tutorial, when ADLS is behind a storage firewall the Mirrored Catalog flow uses the Fabric Workspace Identity to traverse the firewall, regardless of the authentication method configured on the cloud connection. The connection SP only authenticates against Databricks / Unity Catalog.
  • The documented mechanism to allow that Workspace Identity through the storage firewall is Trusted Workspace Access (a Resource Instance Rule on the storage account naming the Fabric workspace).
  • The TWA doc states explicitly: "Trusted workspace access isn't compatible with cross-tenant requests."

This matches the failure observed: the Workspace Identity lives in Tenant A, the storage account is in Tenant B, and the documented bridge (TWA) does not cross tenants.

Already ruled out:

  • Fabric Workspace Managed Private Endpoint: Mirrored Azure Databricks Catalog is not in the supported item types list (Spark notebooks, Lakehouses, Spark Job Definitions, Eventstream only).
  • VNet data gateway: not on the documented network paths for the Mirrored Catalog flow.
  • Fabric External Data Sharing: the Mirrored Azure Databricks Catalog item type does not expose a Delta Sharing / external data sharing option in the Fabric context menu (unlike Lakehouse and Mirrored Database items), so this path is not available for this item type.

Questions:

  1. Is there a Microsoft-documented configuration that lets Mirrored Azure Databricks Catalog reach a firewalled, cross-tenant ADLS Gen2 that I am missing?
  2. Has anyone solved this empirically, even if not formally documented? If yes, with what mechanism?
  3. If not, is the only realistic path either collapsing to a single tenant (losing the multi-tenant isolation) or attempting Private Endpoints despite Mirrored Catalog not being on the MPE supported item type list?

Thanks in advance to anyone who has hit this.

Azure Data Lake Storage
Azure Data Lake Storage

An Azure service that provides an enterprise-wide hyper-scale repository for big data analytic workloads and is integrated with Azure Blob Storage.

0 comments

Answer accepted by question author

Pilladi Padma Sai Manisha 10,770 Reputation points Microsoft External Staff Moderator
2026-06-10T05:48:29.34+00:00

Hi @Pablo sanchez

Thank you for providing such a detailed analysis of your architecture and the troubleshooting steps you've already completed.

Based on the behavior you've described and the current Microsoft documentation, your findings appear consistent with the expected design of Mirrored Azure Databricks Catalog.

When the underlying ADLS Gen2 account is protected by a storage firewall, Fabric uses the Workspace Identity to access the storage account, regardless of the authentication method configured in the Databricks cloud connection. The cloud connection is used to authenticate to Databricks/Unity Catalog, while storage access relies on the Fabric Workspace Identity.

The documented method for allowing Workspace Identity access through a storage firewall is Trusted Workspace Access (TWA) via a resource instance rule on the storage account. However, the TWA documentation currently states that Trusted Workspace Access is not supported for cross-tenant requests.

As a result, in a scenario where the Fabric workspace resides in Tenant A and the firewalled ADLS Gen2 account resides in Tenant B, the observed behavior is expected:

  • Mirrored Catalog refresh succeeds when the storage firewall is disabled.
  • Mirrored Catalog refresh fails when the storage firewall is enabled because the Fabric Workspace Identity cannot be authorized through TWA across tenants.

Based on the currently published documentation, I am not aware of a supported configuration that enables Mirrored Azure Databricks Catalog to access a cross-tenant, firewall-enabled ADLS Gen2 account using Trusted Workspace Access.

The available options would therefore be to:

  • Align Fabric and the Databricks/ADLS resources within the same tenant so TWA can be used as designed, or
  • Consider alternative data-sharing or replication architectures that do not require Fabric Workspace Identity to traverse a cross-tenant storage firewall.

For reference:

If this cross-tenant scenario is a business requirement, I would recommend opening a Microsoft Support ticket to confirm whether there are any recently introduced capabilities or roadmap updates that are not yet reflected in the public documentation.

I hope this helps clarify the limitation.

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-06-08T10:27:04.5466667+00:00
    1. The available documentation only describes a same‑tenant pattern for Mirrored Azure Databricks Catalog when ADLS Gen2 is behind an Azure Storage firewall. In that pattern:
      • Fabric uses the Fabric Workspace Identity to traverse the storage firewall, even if Service principal is selected for Databricks authentication.
      • The supported way to allow that identity through the firewall is via trusted workspace access, which explicitly “isn’t compatible with cross‑tenant requests.”
      • The docs do not describe any alternative cross‑tenant mechanism for Mirrored Azure Databricks Catalog to reach a firewalled ADLS Gen2 account.
      From the documented behavior:
      • “When ADLS Gen2 is protected by an Azure Storage firewall, Fabric uses Workspace Identity to access the firewall. Even if Service principal is selected for ADLS authentication in the Network Security tab, the Workspace Identity must be allowed in the Azure Storage account firewall.”
      • “Trusted workspace access requires creating a connection directly to the ADLS storage account… Trusted workspace access isn’t compatible with cross‑tenant requests.”
      There is no documented configuration that enables Mirrored Azure Databricks Catalog to access a cross‑tenant, firewalled ADLS Gen2 account.
    2. The context does not provide any empirical or workaround configuration (such as using VNet data gateway, managed private endpoints, or other network paths) that would enable this scenario. For Mirrored Azure Databricks Catalog, the documented path is:
      • Use a storage connection to ADLS Gen2 in the Network Security tab.
      • Allow the Fabric Workspace Identity through the storage firewall (same tenant) and assign appropriate Azure RBAC roles on the storage account.
      No additional cross‑tenant workaround is described.
    3. Based on the documentation in scope, the supported options are constrained to:
      • Same‑tenant deployment where the Fabric workspace, its Workspace Identity, and the ADLS Gen2 storage account are in the same tenant, so that trusted workspace access and firewall traversal work as designed.
      • Using Workspace Identity (recommended) or other supported auth types for the ADLS connection, but still with the firewall traversal performed by the Workspace Identity and controlled via Azure RBAC and firewall rules in the same tenant.
      The context does not document:
      • Mirrored Azure Databricks Catalog using VNet data gateway for data‑plane access.
      • Mirrored Azure Databricks Catalog using Fabric managed private endpoints (and it is explicitly not listed as a supported item type there).
      • Any cross‑tenant exception to the “trusted workspace access isn’t compatible with cross‑tenant requests” limitation.
      Within the provided documentation, the realistic supported path for a firewalled ADLS Gen2 with Mirrored Azure Databricks Catalog is therefore a single‑tenant arrangement where trusted workspace access and Workspace Identity can be used as designed.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.