Refresh failure for DirectQuery to Semantic Models after migrating from Premium P1 to Fabric F64 (SS

[AntoineW]

Hi everyone,

We are facing a refresh issue following the migration of a workspace from a Premium P1 capacity to a Fabric F64 capacity.

The Scenario: We have a report that connects to 5 other semantic models (datasets, analysis services) using DirectQuery. On the old P1 capacity, everything worked fine. Since moving to F64, the refresh fails.

The Diagnosis: It seems that SSO impersonation for refreshing DirectQuery data is behaving differently or is restricted on the new capacity.

What we have tried:

1. Workspace Identity: We explored using "Workspace Identity," but realized we cannot assign access rights to a semantic model for a workspace identity (only AAD users/groups are supported), so this was a dead end.

2. Current Workaround (Functional but not ideal):

   • We created specific connections in the gateway/connection manager.

   • We authenticated using Personal Credentials (OAuth2).

   • Crucial Step: We explicitly unchecked the setting "Use SSO via Azure AD for DirectQuery queries".

   • With this setup, the refresh works successfully.

3. Configurations : 

• XMLA Endpoint Read/Write Enabled
• Allow DirectQuery connections to Power BI semantic models Enabled

My Questions:

• Using personal credentials is not a sustainable production solution. Is the recommended best practice to use a Service Account (SA) with admin rights to manage these specific connections without SSO? Is it possible and how to do that with Direct Query sources? 

• Are there known limitations or configuration changes regarding SSO for DirectQuery-to-Semantic Models on Fabric capacities compared to Premium? Ideally, we would like to enable refresh without bypassing SSO manually.

Some references : 

- https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-directquery-about

- https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-composite-models#security-implica...

- https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-connect-tools#enable-xml...

Thanks in advance for your insights!

[v-dineshya · Accepted solution]

Hi @AntoineW ,

Please try below things to fix the issue.

1. Replace Default (SSO) connections with explicit connections per source.
2. Set those connections to service principal or workspace identity for Azure SQL/Fabric.
3. Ensure the Service Principle or service account has Build or higher on each upstream semantic model and any gateway data source permissions.

4. Keep Use SSO via Azure AD for DirectQuery queries on for interactive user experience when the source supports it, not expect it to power refresh with Entra SSO.

5. If refresh still fails and your model has calculated tables/columns over SSO‑enabled DQ, either move those calcs out or ensure the dataset is bound to non‑SSO explicit credentials.

Is best practice to use a Service Account (SA) with admin rights to manage these connections without SSO? Is it possible with DirectQuery sources?

Yes, use a service principal or a service account to own the dataset and to bind explicit, non‑SSO connections used for refresh, especially when the DQ sources are other semantic models. This is both feasible and common in production. Viewers still get row‑level results “as themselves” during interactive DQ, but refresh uses the dataset owner/SP identity. If your DQ sources are Azure SQL / Fabric Warehouse / Lakehouse, consider Workspace Identity instead of SP to avoid secret rotation. However, you currently can’t grant a workspace identity access to another Power BI dataset, so for DQ‑to‑semantic‑model chains you will still need SP/service account.

Are there known limitations or configuration changes regarding SSO for DQ‑to‑Semantic Models on Fabric vs Premium?

Microsoft Entra (AAD) SSO only covers interactive DirectQuery, while refresh with SSO is supported only for Kerberos (on‑prem) scenarios. When a model chains to other Power BI semantic models and also uses features like calculated tables/columns, Dual/Import partitions, or default SSO connections, scheduled refresh will fail unless you bind explicit credentials.

Please refer below links.

Solved: Default connection on Semantic Models - Microsoft Fabric Community

Solved: Refresh error - Single Sign-on (SSO)-enabled Direc... - Microsoft Fabric Community

Manage Semantic Model Access Permissions in Power BI - Power BI | Microsoft Learn

Overview of single sign-on for on-premises data gateways - Power BI | Microsoft Learn

I hope this information helps. Please do let us know if you have any further queries.

Regards,

Dinesh

[v-dineshya]

Hi @AntoineW ,

Thank you for reaching out to the Microsoft Community Forum.

Hi @deborshi_nag  and @XarraCaliuData , Thank you for your prompt responses.

HI @AntoineW , could you please try the proposed solutions shared by  @deborshi_nag  and @XarraCaliuData ? Let us know if you’re still facing the same issue we’ll be happy to assist you further.

Regards,

Dinesh

[v-dineshya]

Hi @AntoineW ,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.

Regards,

Dinesh

[deborshi_nag]

Hello @AntoineW 

I could not locate any published Microsoft documentation or official Microsoft blog that outlines a functional distinction in SSO-based DirectQuery authentication between Power BI Premium capacity and Microsoft Fabric capacity.

The official documentation indicates that SSO operates for DirectQuery by transmitting the user’s identity via Kerberos or Microsoft Entra ID, depending on the data source. There are some nuances; for example, Microsoft notes that Direct Lake employs SSO by default, and there is an automatic fallback from Direct Lake to DirectQuery when certain features are unsupported, although this scenario does not pertain to your case.

It remains possible that there is an undocumented behavioural difference that you have discovered!

[XarraCaliuData]

You’re right, using a dedicated service account is cleaner. For these cases, create a Service Principal and grant it the appropriate permissions in the workspace. Then, create a new gateway data source connection using the service account credentials (leave "Use SSO via Azure AD for DirectQuery queries" unchecked). Finally, update the DirectQuery connection to use this new gateway connection instead of the existing one.

[AntoineW]

For data sources such as "Power BI Semantic Model" or "Analysis Services," the Power BI Cloud connection interface often only offers OAuth2 (personal credentials).