Error using direct lake: don't have permission to view the content of a Direct Lake Table

[alfBI]

Hi,

We have developed a model connected by Direct lake to a lakehouse (model A)

User A has been granted with Read & read all rights on the lakehouse.

A report has been created on top of the model and a application has been created adding the report A as content

User A has been granted with view access to the app.

And with all that stuff in place following error message does appear when the app is loaded by the user A

What are we missing?

Note: All items on same workspace. User A is not member of workspace. The model A created is not the default one provided by the Lakehouse, it's a custom one.

Thx

[aeelissa]

So do we need to give users a read access to all LakeHouse data so they can use the Power BI Dashboard built in top of it? That's not smart I guess 😅

[amolt]

Hi @naeer 

No, it's not necessary to give access to all users. Look below in the comments for the answer. You need to change the connection parameters of the semantic model to use a “Service Principal ” account.

[aeelissa]

I need to share this report with +1000 user, I have to give all of them access to the lakehouse instead of just sharing the PBI report with them! 

[jbauer22]

We are having the same problem.  Please fix this Microsoft!

[rgcabusas]

I am facing same issue and while waiting for a granular security approach that there is no need to give access to entire workspace; what I did is.

-->> Create a new workspace
-->> Create a datamart specific to required data only for the report

This works on my end and provide a short term solution.

[MatthewH]

@Anonymous 

apologies, the language used in a few of the comments make it really unclear as to whether this is a problem that exists and is yet to be solved or whether it is one that has been solved and there's something that I and others are doing incorrectly.

please could you clarify?

I have a workspace with a report in, a dataset in and published as an app

the data set is in direct lake mode, connected to a lake house in a different workspace, where users do not have access.

do really need to create one Lakehouse per workspace in order to give people access? or is this a problem that is being solved?

[Anonymous · Accepted solution]

Hi @alfBI , @enerkat ,
Regarding the issue you were experiencing, the inability to view the semantic model with the error "You do not have permission to view the contents of the Direct Lake table" has been resolved.
The error that occurred when a user could not access Lakehouse in Direct Lake with a fixed identity is still being fixed. The engineers are still doing their best to resolve it. I will update here if there is any progress, so please be patient. 

Best Regards,

Ada Wang

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[mkjit256]

Any update on this? we are still having the problem. Our solution is a little bit more complicated that the workaround that was mentioned here. We are trying to push our data into a single lakehouse and then build different semantic models that would contain certain subsets of tables found in the lakehouse. 

[KV_PowerBI]

Hello @Anonymous 

I am facing the exact same issue as described by @alfBI .

I have a direct lake semantic model and a power bi report based on this model.

My organisation has Power BI premium P1 license.

Earlier with Power BI reports based on import model, I was able to share the reports with Power Bi (fabric) free users. 

Now I am trying to do the same with power bi report based in direct lake semantic model. The steps followed are similar to what @alfBI  has given above.

But the users are getting error "you don't have permission to view the content of direct lake table"

You have mentioned that the issue is resolved. However it doesn't seem to be resolved.

Thanks 

[kasun_rumesh]

@Anonymous  Any update on this? Do we need to find other solution which can be given access without shareing entire data lake with users?

[MatthewH]

I don't believe the problem we are all facing here is a bug. I think its by design. We implemented table level security using tsql. So everyone technically has access to the presentation layer but only the tables we want them to

[mkjit256]

Hello Mathew,
The whole idea of creating a semantic model on top of the lakehouse is to restrict what set of tables would a user have access too. I am planning on doing that using semantic model, until i faces this permission error problem.

Can you give a high level description on how did you do the table level security using tsql? if you have documents that would be amazing.

Regards

[MatthewH]

sorry, you've said the issue is resolved? I'm still experiencing an issue, my user has access to an app and access to a semantic model and is experiencing this issue today.

[enerkat]

In my case it works now if I give the user access to the app and to the lakehouse. 

[MatthewH]

access to the whole Lakehouse, or just the semantic model? My thought was to limit access to the whole lake house and only provide access to apps and relevant and semantic models to that person

[enerkat]

It seems that to use direct lake you need to give access to the lakehouse. 

[Arlo]

We spoke to Microsoft support and apparently in March 2024, it is still not possible to share a report with a user in your tenant without sharing access to the lakehouse/warehouse. This feels like a fundamental error by Microsoft. The entire purpose of workspaces is to segregate data, if we can't give access to view redacted data in a report, then what good does the service even do?

When a report is loaded, the report interrogates the database to run the queries. The report uses the end viewer's identity and passes that identity to the database. If that user does not have at least read access, the report will fail.

For example, we have employee reports about diversity. Those reports are shared with everybody in our org and they are calculated against a lakehouse table that contains payroll information, gender, ethnicity, time off balances etc...

Um, no I don't want to give everybody in our org the ability to read payroll data just to generate a report about gender & ethnicity populations at the business.

Thankfully, I found a workaround and it is suprisingly simple and effective. It's all about creating a service principal.

1. Create a new app registration in your Entra tenant. Generate a client secret. Take note of the application ID, your secret, and your tenant id. I named my app "Power BI Service Principal" to make it easy to identify.
2. In PowerBI online as an admin, go to the workspace that contains the Model. Right click the model and choose Settings.
3. Expand the Gateways & Cloud Connections accordion. The connection likely says Azure AD Single Sign-On. Click Create Cloud Connection
4. For the authentication method, select Service Principal and fill in your tenant ID, service principal (application ID), and secret from step 1. Save the connection. Save the settings.
5. Go into the workspace that hosts the data and model. Manage Access and add the service principal as a "Viewer" of the workspace.

Now any reports you share that use that model will use the service principal to authenticate against the lakehouse & model. Since the service principal key is secret and not available to report viewers, they can not access the underlying data.

That said, there is one warning, if you let users click on the "Explore Data" for your reports, that explorer will use the service principal you created, which then grants the report viewer the ability to view all data and columns. To prevent this risk, just disable the ability to consume the data on the report. It is secure, but just badly designed and I have to imagine MS is basically planning to do this same thing behind the scenes for a more elegant method.

[Flash777]

Hello! How did you disable the "Explore Data" feature? Can't find the option for that.

[amolt]

Hello @Flash777 , 

Perhaps this will help:

Solved: Re: Turn off Explore this Data feature - Microsoft Fabric Community

[amolt]

Hi @Arlo ,

Thanks for your workaround.
It works perfectly.
In my case I had to add the service principal as the workspace “viewer” BEFORE creating the new connection. After creating the new connection, you also have to select this new connection to use it in the model.